Nurturing Design in Your Software Engineering Culture
There are a few qualities that differentiate average from high performing software engineering organisations. I believe that attitude towards the design of code and architecture is one of them.
In my experience, the culture is better and the results are better in orgs where engineers and architects obsess over the design of code and architecture. In orgs where it’s all about delivering tickets as quickly as possible or obsessing over technology, the culture and results are poorer.
There’s huge variety between those two extremes, and there’s also a point where too much focus on design and not enough on delivery is hugely counter-productive as well. Both valuing design and striving for continuous delivery are necessary.
Martin Fowler argues that internal quality of a software system enables new features and improvements to be delivered more sustainably. Design, how things are named, structured, organised and so on, is a fundamental part of internal quality. In Accelerate, Nicole Forsgren shows a link between well-designed, loosely-coupled architecture and more frequent software delivery.
If you’re interested in improving the design mindset in your engineering culture, I hope that the following techniques provide you with some food for thought. Please feel free to leave a comment if you have other suggestions or experiences you’d like to share.
Continuous Critiquing
Exploring options and assessing trade-offs is the key to producing better designs, and it is how we become better designers. So we need to make it part of everything we do.
I love pair programming and mobbing because every small decision is debated and challenged. For many people, this is a waste of time; it’s pretentious developers geeking out over unnecessary perfectionism. My experience is the opposite. When I’ve worked with organisations deploying to production tens or hundreds of times per-day, it was this obsession on the small details that made the code and infrastructure easier to continuously improve and deploy.
The same mindset should also be applied to architecture; involve the whole team and challenge the small details. Arguably, the benefits are even greater at an architectural level where decisions are more costly and harder to reverse.
Simon Brown taught me how to review architecture diagrams 10 years ago. I highly recommend his writing on the topic. I also like ADRs as a tool for forcing us to consciously make design choices and evaluate the trade-offs.
Collaborative Mindset Required for Continuous Critique
Continuously critiquing is destined to fail in some teams. It requires people who are open to receiving and seeking out feedback on their ideas. Equally, it requires people who enjoy constructively reviewing and providing feedback. Unfortunately, I’ve met many technologists who don’t meet this criteria and macho cultures where openness is considered weakness.
Spread Domain Expertise
Design is more than generic technical patterns that can be applied to almost software system. The true value of design is building software systems that are optimised for solving business problems and are easy to evolve over time as the business needs change. This necessitates a good understanding of the domains the software represents.
When architectural boundaries align with domain boundaries, changes will be easier to make, and dependencies between teams will be fewer. No generic technical patterns can help you to define the right boundaries and interaction patterns. Equally, code that accurately describes the domain it is modelling is often far easier to understand and change.
A good understanding of the business domains is the key enabler for engineers and architects to create business-optimised designs. Regularly spending time with domain experts is important.
Use Visual Collaboration Techniques
Visual collaboration techniques are the answer. They help to spread domain knowledge, and they enable everybody to participate in continuous critiquing and design activities.
Domain Storytelling and EventStorming are my goto techniques for bringing domain experts and engineers together to collaboratively model business flows. I’m also a proponent of Example Mapping, a technique for collaboratively crunching domain knowledge to define requirements.
Visualisation techniques like EventStorming can also be used to design code. In fact, Software Design EventStorming is like a DSL for designing business processes that translate directly into code. This is useful because it allows developers to collaboratively design the domain-focused parts of the code before being side-tracked by accidental complexity.
It’s important that teams have tools that enable them to constantly visualise their work, especially when working remotely. Teams should have access to tools like Miro and be using them extensively.
Encourage and Reward Design
When engineers feel that taking time to design things well is acceptable, they are more likely to do it. Technology leaders need to be vocal in their approval of taking time to design architecture and code well, and be clear that quality design is just as important as delivering lines of code.
Investing in design should be rewarded. Technology leaders should be looking for case studies of good design and broadcasting them to the whole engineering organization, calling them out as examples of great engineering practices for all to aspire to.
When I was younger, I was fortunate enough to have mentors who invested a lot of their time teaching me about design and encouraging me to think about design. They were sending me signals: it’s important to take your time and think about design, you don’t need to rush and finish as quickly as possible.
Blogs, Videos, Slack Channels, Communities
Encouraging and rewarding design requires effective communication channels where information can be shared and reaches the intended audience. There are many opportunities to spread design ideas and success stories including internal blogs, slack channels focused around design, and presentations at company-wide engineering meetings.
Leverage Influencers & Multipliers
Good ideas spread faster when they are being promoted by people who are well respected and connected. Those people are your influencers.
Design influencers can be people who lead others or individual contributors who have a high level of respect from their peers. When these people promote good design habits, others will naturally follow.
As a leader who wants to improve the design culture in your organization, you need to identify potential influencers and support them with the time and resources that will allow them to build and spread good design habits.
Provide Design Training & Coaching
Training can accelerate the design learning process for any engineer or architect. Training influencers can be exponentially beneficial; the more and faster they learn, the more and faster the rest of your organization learns.
The same applies to coaching. A good coach can help multipliers rapidly improve their design skills with regular 1:1 and group sessions.
Early Adopters
There’s a subtle difference between influencers and early adopters. Some influencers may not be good early adopters because they take time to be convinced themselves. Early adopters are people who are more open to new ideas and techniques or they have already seen the benefits.
Run Regular Design Katas and Internal Workshops
Design katas are an excellent way to build up an appreciation for design, both at the code and architectural level. They’re also an effective tool for spreading design skills between more experienced and junior members of a team.
Katas and workshops are useful techniques for early adopters/influencers and enabling teams to employ.
Hire for a Design Mindset
I’ve seen enough evidence to believe that some engineers and architects will never be happy working in collaborative and design-focused engineering cultures. They prefer to work in isolation and just deliver. Therefore, design mindset needs to be emphasised during the interviewing process for the benefit of the employer and the candidate.
When interviewing software engineers, I always provide at-home coding tests which focus on design. During the interview, we then discuss their solutions with the candidates to see their approach to design and their openness to receiving feedback on their designs. This is also an accurate reflection of how they can expect to work if they join the team.
Likewise, similar architectural activities can be conducted where the candidate reviews the employer’s architecture and vice-versa. The keys I look for are: are they able to evaluate trade-offs, can they explain their thought process, are they open to feedback and defending their choices in a constructive way.
Hiring Influencers
When there are no obvious influencers in the company, or the time taken to train them is excessive, hiring people into senior technical positions can allow them to play the role of influencer. Hiring new people who have worked at big companies, or who are known in the industry, can create excitement.
Create an Enabling Team
A central concept in Team Topologies is the Enabling Team. An enabling team’s goal is to help other teams achieve a specific outcome. Enabling teams can be formed with improving design culture.
For example, an enabling team could be created with the goal of ensuring every team is collaboratively defining requirements and spreading domain knowledge.
Such an enabling team could provide Example Mapping training, coaching, and facilitation until all teams in the organization were successfully applying Example Mapping. At that point, having achieved their desired outcome, the enabling Team would be disbanded, and maybe another enabling team would be formed with a different mission.
Invite Design-minded Techies to Speak at Your Company
There are a lot of interesting people in the software development and architecture communities who are passionate about design. Inviting them to speak at your company and interact with your teams is a great way to get people excited and introduce new ideas into your org. It can be a cost-effective approach. Often, speakers are looking to try out new talks, for example.
