Being a Software Architect at Salesloft

A recurring question I get at the office is “what does it mean to be an architect?” This is an excellent question and touches upon a principle that applies to all senior+ roles no matter what company one is working for.

#At Salesloft

To provide some context, architects at Salesloft are the technical owners for their respective parts of the product. They are embedded on product delivery teams, writing code and participating in normal team ceremonies. Some architects may span more than one team as well. Architects being in the trenches with the team is no accident. We want our architects to be close to both the customer and the code.

Further, architects have a higher level of ownership and continuous learning when they live with the results of their decisions. An architect who provides some given solution to a team then moves on to the next problem doesn’t really know if their solution worked long-term. What is architected on paper rarely matches the final result, especially as the realities of deadlines, customer commitments, and changing requirements set in. Conversely, seeing a project through from its inception to v2 or v3 or v4 allows the architect to reflect on what worked, what didn’t, how the initial solution translated to the final product, what they would do differently next time, etc.

#Being a software architect

So what does it take to be an architect? For me it comes down to one word: perspective. Perspective allows an architect to fulfill their two primary objectives:

1. Determine which direction we should be heading
2. Define the incremental steps needed to get there

To use the loose analogy of a group hiking through the woods¹, the architect is the one who runs up the nearby mountain for a few hundred feet of elevation to get a good lay of the land. From there, they can figure out where the group needs to go. This first objective, determining direction, is a constantly evolving process. For most products, there isn’t an end state. As markets shift and customer expectations change, the product changes as well. Consequently, architects maintain a continuous, active role in regularly re-evaluating direction. It requires balancing input from multiple sources – technical feasibility, customer requirements, security, etc. - and blending them into a single trajectory. Defining this trajectory gives the team clarity and purpose so they can all move in the same direction.

The second objective is equally important and, I would argue, the more difficult skill to hone. Even if the direction is known, there is very rarely a straight path to get from point A to point B. One typically has to zig zag through a full alphabet of points before arriving at a destination. The architect’s job, knowing the correct trajectory, is to help the team plan and prioritize the right work to consistently move in the direction that trajectory is headed. This is particularly true when one is working with an existing product, one that has it’s share of legacy code and tech debt. In these situations, iterative progress is a necessity. Iteration is deceptively powerful because, while no single step may seem large, the steps taken together in aggregate bring about significant change.

#30,000 feet

It all comes down to perspective, which in turn determines trajectory and requires iteration. Naturally, there are many behaviors related to how one applies this perspective. These will likely look different depending on company, organization, or even team. But the principle of perspective never changes. It’s what characterizes an architect and provides the means for them to have outsized impact in their organizations.