A few years ago my team received a bug report in our product whose solution required some technical design. A teammate felt it would be a great opportunity to try out the principle of "design as a team" and suggested that the whole team get together to work on the problem. So we did.
The exercise was a complete waste of time, except to show that this notion of "design as a team" is pure fantasy.
Some of the team members were not interested in the problem. They barely said a word in the meeting and could really have better used the time working on their own tasks.
Another team member insisted that we use his idea to solve the problem. We didn't: it would have broken some key design principles in the product while providing no clear benefit over the alternatives. But he was so unhappy that we didn't go with it that he spent the next couple of months complaining about this.
In the end, one team member designed and implemented a solution, not making use of any outcomes from the aforementioned team meeting. The implementation took about half an hour, completely solved the problem, and resulted in zero bug reports or complaints from users or stakeholders. The team meeting didn't contribute anything to the successful design in the end.
How (not) to involve the team in design
But isn't design as a team somehow a gold standard of collaboration? Is that not how we want to be building products nowadays?
This seemingly modern notion has an old name: design by committee. It's well-understood not to work. When one brings the whole team together to do design, two things tend to happen:
- Some of the team members, those with less stake in the design or its outcome, become disengaged and don't really participate. The meeting becomes a waste of their time.
- Some team members try to influence the design just to have their "fingerprints" on it (whether they are aware of this tendency or not). The resulting design becomes a muddled compromise of all the different people trying to take influence on the design.
One of the most important factors in the success of any technical design is conceptual integrity. Conceptually integral designs don't arise from muddled compromise but from the focused work of one or two designers (see also The Design of Design by Frederick Brooks, chapter 6).
Beware the ivory tower architect
I would be remiss not to mention another well-known anti-pattern, the ivory tower architect.
I was once placed in a task force to solve some urgent architectural problems in a product. I expected that it would be designing the solution. I was rather surprised when, on the first day, the task force manager handed us a technical design he had created and told us that we would be implementing it.
I didn't stay on the task force terribly long, but learnt later that the project utterly failed after several months. The entire product the team had developed was thrown away once it became clear that it would never successfully perform its function.
One key problem was that the manager played no role in the implementation. The engineers, on the other hand, had no feeling of ownership in the design, since it had just been handed to them from someone else. They felt like assembly line workers, just carrying out the work packets handed to them from above.
Technical design in a team done right
Engineering team is producing the most value when it is solving deep technical problems, which need deep technical design. How collaborative should that design be? How does the team create effective technical design while fostering a sense of shared ownership? To see the answer, I'm going to outline a design process consisting of several phases and show when different people can be involved, and how.
Step zero in a major technical design, as with any large project, should be creating alignment. It's critical that the key stakeholders are onboard with the project and the need for the investment. How much alignment one needs to create depends on the amount of required investment and, crucially, the required involvement from other teams. In this step, one identifies a chief designer (modern language: tech lead) who takes primary ownership and responsibility for the design and implementation.
Broadly speaking, the design then goes through three phases: discovery, design, and feedback.
Discovery
The discovery phase is marked by the chief designer collecting information as broadly as possible to flow into the design. They speak to engineers and stakeholders, product managers and UX designers. They find out about expectations, constraints, and possible booby traps. Constraints include in particular any aspects of the architecture or design of the surrounding system which may block some alternatives. This phase is also a good point to collect from a broad range of colleagues initial ideas on how to proceed.
There are lots of formats to proceed with this. Some might informally chat with different parties and collect information. Others might organize a formal design sprint. The most important point is that this phase is expansionary: its success is measured on how much useful information and how many ideas are collected.
Design
In the design phase, the designer, or a group of at most two designers, uses the information and ideas collected to work out and document a detailed concept to solve the problem. This phase is consolidatory: ideas are discarded and merged while collected information is categorized.
This phase is critical to avoiding design by committee. The restriction to at most two designers enables conceptual integrity. Equally critical is that the designers be involved in the implementation so that they have a real stake in the success of the design.
The design need not work out every detail of every aspect of the solution. Parts of it can be carved out to be handed off to more junior designers (see below). But it should be clear that every aspect has a solution. One omitted detail shouldn't be allowed to bring down the whole design. If that is in doubt, then the detail should be covered in the design.
The documented design must include a discussion of discarded alternatives. Why was a particular alternative not picked? Was the designer unaware of it or was there a good reason for this? This information is of particular importance when collecting feedback in the third phase.
Feedback
The designers share their concept with a larger round -- including other team members and stakeholders -- in the feedback phase. Here it is critical to get as wide a range of opinions as possible. Some may point out missed constraints, others missed alternatives. The earlier one knows that the design won't actually solve the problem or has some severe defect, the better.
Depending on the feedback, it may be necessary to go back to revisit the previous two phases. The design process is iterative in that sense. However, the designer is not obligated to incorporate all the feedback they receive. Should the design be untenable -- maybe it violates an unforeseen constraint -- then the designer has little choice but to revise it or throw it out. But, when it comes to personal preference, it is up to their own judgement how to proceed.
An hourglass
Putting these phases together, one sees an hourglass of collaboration: the designer starts by involving a lot of people in discovery, then work alone or in a pair, and finally collects feedback from a wide group again. Many colleagues may be involved with the design by providing initial input and final feedback. But the ownership and main responsibility for working out a complete design lie with one or two key designers.
Hierarchical design
A team with a few relatively senior engineers is likely eager to be involved in the design process. This can't happen if a single tech lead monopolizes the design work.
To involve the whole team, the tech lead builds an overarching concept for the problem and leaves parts of that design not fully specified. For example, the tech lead might come up with a concept for a new service and how that service would interact with other components in production. But they might not design the database schema or the data migration process, leaving those parts for other engineers to own.
The tech lead should leave the engineers a lot of leeway in making their own decisions, even if they consider a decision to be a mistake. It's important that engineers have the opportunity to make mistakes and learn from them. Only if the design is untenable -- and the designer unwilling to acknowledge that -- should the tech lead put their foot down and forbid it.
Engineers must also be expected to deliver on their designs. Tech leads should hold their engineers' feet to the fire, insisting on clear commitments about deliverables. If an engineer is dragging their feet on a design, the tech lead may have to take away responsibility for it.
Important is that the whole team, including the tech lead, be involved with the implementation of these individual pieces. This avoids the creation of knowledge silos within the team.
Conclusion
As a tech lead or a designer, don't think you need to involve your whole team or organisation in a design effort. If more people on your team want real responsibility, parcel out parts of the design for them, but only if they will really be involved with the implementation of said design. Otherwise, they should be satisfied to provide ideas and feedback.