How did we end up here? I had messed up a technology choice.

At the heart of making technology choices is recognising that it involves a trade-off. The ability to evaluate trade-offs is a skill integral to making digital products, irrespective of role — whether you’re a designer, product manager or developer. Of course, most product decisions are made together as a multidisciplinary team. But when it comes to making technology choices, the engineering team is in the driving seat.

In order to make good choices — whether on a framework, library, approach or platform — the constraints and goals of the product need to be known — both the short-term ones and future ones; sometimes this means a trade-off between the two. For example, if working towards an initial release that’s intended to be used by only a small set of users, then deciding to defer investing in scalability can be a reasonable choice.

(And yes, this kind of trade-off can lead to technical debt.)

Once the potential alternatives have been figured out, a key part of evaluating them is considering the impact they will have on users, the business, your team, and on other developers. (This last category is important as they may be working on the product in the future.)

Finally, the decision and the trade-offs involved need to be simply and clearly communicated.

These decisions will typically have different audiences and will likely need a different type of explanation, based on varying interests and perspectives. For example, decisions about performance that impact user experience, or decisions about time to market that impact business requirements will clearly have a broader audience. However, others that are more technical in nature (such as those involving complexity, maintainability or dependencies) may have a more focused audience.

Due consideration of these different audiences is essential. Being able to explain why this person (in a specific role) should care is vital:

Back in the cold meeting room, being made even colder by the client’s reaction, I was realising that I had failed to consider these angles fully.

We had selected to use a framework that was opinionated and gave a great foundation on which to build. This choice had some trade-offs that we felt were valid and worthwhile: it was a new technology (so not many developers had used it before) and it incurred some additional operational complexity.

However, whilst we had considered the technical aspects of our choice, we hadn’t given enough thought to our client’s technical stakeholders having their own concerns and priorities. Unfortunately when we described our choices we hadn’t presented our research or reasoning, or offered them a chance to investigate it together.

On a fast moving project this was an oversight.

Whilst a choice may be good (and sensible) from a technical perspective, non-technical aspects and communicating your decision-making process and rationale are crucial.

In the future, to help our teams (and clients) consider and challenge choices from every angle, we’ve created the Technology Choice Canvas:

Not every technical decision needs to be shared with everyone, however, the most significant decisions to be sweated are architectural ones. These are decisions that need to be considered from every angle and discussed with the whole team.

A software craftsman once described to me architectural decisions as ‘the things that are difficult to undo’. My benchmark is to ask whether this is something that will be easy to replace if we wanted to do so later down the line.

(Of course, the size of decisions that you share is a judgement call. I recommend capturing smaller decisions using ADRs.)

You can use the canvas in two ways:

Each box asks you to state what you know about your choice from a specific perspective. For each box, there are a number of questions to consider (found on the first page of the PDF).

The canvas can be filled out alone or as a team. If you are doing this as a team — which we recommend — draw labelled boxes on a whiteboard and ask the team to write post-it notes for each box, one by one. The best people to involve in this process are the project’s engineers or those who have done the research.

You can then use the completed canvas to play back your findings to the broader team, checking with the designers and product managers that they agree with your assumptions and the trade-offs you’re proposing.

This process may feel exhaustive — not least considering the roles exercise in the right hand column — but we’ve found it an essential tool in communicating technology choices to our clients and beyond. It uncovers assumptions and allows trade-offs to be understood, challenged or agreed upon.

If you use this, we'd love to hear how you get on. Any questions or comments are welcome! The canvas was developed in a workshop by the Made by Many engineering team: Callum, Eric, Kat, Łukasz, Madeleine, Oli, Raffi, Rosie, and Sam.