Driving software design forward

The last person I'd let design is me, the Architect

In order to scale, Architects should not design. They should facilitate the software architecture process. This is how to scale and enable autonomy.

But then, who should design? Effectively, all engineers.

• Junior Engineers design for small problems that only impact things the team owns

• Senior Engineers design for large problems that only impact things the team owns

• Staff Engineers design for problems that may impact things owned by other teams

• Principal Engineers design for problems that may impact many things owned by many other teams

• Architects design for problems that impact a majority of the teams and projects

For most designs, the person designing should be someone other than the Architect. Unless all your problems impact a majority of the teams and projects. In that case, I weep for you.

The Engineer that owns the design is the "Driver" of the design. Architects are always there to assist.

Let’s dig into the details.

Start with the Driver

In DACI terms, the Driver is the person who moves the project forward and is responsible for the decision-making process.

Ideally, Driver election is voluntary. To get everyone familiar with the concept, though, the Driver might need to be chosen. The Architects, Principal Engineers, or Engineering Managers should help with choosing.

What does "driving" mean for design?

A software design is a means to discuss a problem and how to address it. Ultimately, it results in a decision: How and whether we address the problem.

A design is only an artifact, though. Designing is an active process that involves many people. Without clear responsibilities, everyone assumes someone else will do it. To set clear responsibilities, there is exactly one Driver.

The Driver will endeavor to help everyone involved understand and agree on:

• the problem

• what the user needs

• the constraints we're working with

• what the business needs

• the risks involved

• potential solutions

• who is impacted

• what the impact is

• how we'll solve the problem

Essentially, the Driver aligns everyone on the user's experience, how the current solution fails to meet the user's needs, and how we think we can improve the user's experience. This, in effect, is design. So in effect, the Driver drives the design.

Drivers aren't just waiting for alignment and approval. They're "driving" for it. That means reaching out and figuring out "what do we need to do to move this forward?".

In practice, getting alignment means having conversations, researching, informing, and negotiating. The Driver doesn't do all this alone. Software development is a team activity. For a design, there may be many collaborators. An Architect or a more senior engineer that is familiar with the process is one of those collaborators.

Architects can help with:

• removing blockers

• identifying and connecting to stakeholders

• conveying technical strategy

• refining requirements

• managing expectations

• mitigating risks

With an Architect's high-level understanding and connections, it seems like they are the ideal person to drive the design.

Typically the higher level an engineer is, the more they should focus on strategy and elevating other engineers. Architects are no different. If Architects are doing all the designing, they will not have time to do any of their other responsibilities. Just as if a Staff+ Engineer is coding all day, they can not do any of their other responsibilities.

The team who is responsible for implementing the design and its Engineers are better suited to do the design.

Not only will they learn more, they will:

• feel more ownership of the solution

• better understand the needs of customers

• better understand the impact of their work

• build connections with other teams

In short, they'll be empowered with autonomy. Autonomy, is key to scaling software design.