Originally written with help from my team and posted at https://medium.com/usa-today-network/a-culture-of-architectural-design-77ad815dfc90

The API Services team at the USA TODAY NETWORK values well-designed software services with good architecture. Who doesn’t? We seek to achieve this goal by having everyone involved in the architectural design.

Promoting “design as a culture” — where the entire development team is involved in the architectural design — has some significant advantages:

• The team has a better overall understanding of the solution design and is aligned on the project goals. This in turn leads to better and faster development through greater understanding of what needs to be done and ensures smoother communication.
• Everyone involved in the design has skin in the game. Greater ownership of the project increases engagement and job satisfaction.
• Architects enjoy more time to work on development. Experienced developers who are tasked solely with architecture responsibilities can grow stale in their development skills, which ultimately reduces their effectiveness.
• Most engineers find it more satisfying to be involved in both the design and implementation of a project than to only work on one aspect.
• Good ideas can come from anyone. When everyone contributes, the quality and creativity of your solutions increases.
• The team grows in their skill and understanding, making them that more effective for the next project.

After embracing the idea that all developers should be involved in design, the primary disadvantage to this approach becomes clear — it takes more coordination and time to finalize a design.

The idea of everyone doing design has many parallels with teams doing code reviews. In both you trade some upfront time for other benefits which outweigh that cost. With a larger portion of the team enjoying a better understanding of the project up front, we see overall improvements in velocity and quality which make up for the initial slowdown.

Putting it into Practice

Implementing the idea of “software design as a culture” is fairly simple: assign design tasks to various team members. The hard part is mentoring and teaching your entire team good design principles. Here are a few suggestions for how to get started:

• Designs must be peer reviewed. Similar to code reviews, architectural designs are most valuable when reviewed.
• Answer these questions: Why is a project being considered as something to spend time on? What is being asked for specifically? How to build the project? This last question is the main design but the why and what questions align priorities, build a common understanding and foundations needed for a quality architecture.
• Projects come in different sizes and so should designs. Sometimes design is skipped for small projects or when there are changes to existing projects, which is generally a mistake. The why, what and how questions should still be answered — but in a size appropriate way.
• Design docs are not just prose, they should often include diagrams. In all cases the design document should be easily reviewable. A common format used by the team can aid in readability.
• Save design docs — They are great for a history of why changes were made and to help on board new team members.

The practice of “software design as a culture” is a shift in thinking that returns many benefits for your team and organization. The change requires a focus on building this skillset for your team but results in better designs with fewer mistakes, greater alignment on work priorities, increased productivity and improved job satisfaction.