Most of my career has been spent working in start-ups, and the transition period while they’re scaling up and moving from “moving fast and breaking things” to “keep moving fast, but don’t break things” is always… an experience.
I remember when I first went through this. Being asked to keep up the pace in which we were designing and shipping new features while maintaining, or even improving, the quality of our work across multiple features and designers. It seemed like an impossible ask.
Deciding where the scale is set.
I always imagined these two points, speed and quality, at opposing ends of a scale, where moving closer to one naturally moves you further from the other. Where they’re always in opposition and trying to have both feels like a paradox.
Tipping the scale
It’s all too easy for that to become true as well. As that slider is pushed towards speed, with reasons like:
We’ve got a hard deadline that we can’t miss or push
We’re only releasing this feature to a small number of users
We’ll come back later and address the quality issues
It’s a new product, so this is just an MVP to know if users will like it
Another team will pick this up as it’s connected to their work more
We want to prioritise more business-critical features
Our stakeholders are ok with lowering the quality if it means we get to market sooner
We begin to justify the corners we cut, always with the best intentions, promising we’ll come back and correct it once we’re done, forgetting that nothing is more permanent than a temporary solution.
You’re likely familiar with these reasons as they’re commonplace. As Martin Fowler highlights with the tradable quality hypothesis, we also make similar decisions in our daily lives. “Shall I spend the extra for really fresh fish at Turners, or go to the supermarket?” Sometimes, we’re prepared to pay more, but in others, we’ll go for the cheaper option.
However, when we treat quality, especially internal quality, as a tradable commodity that can be cut to gain in other dimensions like cost, scope, or speed, it may provide a short-term boost in velocity, but is it worth it?
Does that initial boost outlive the benefits we could have gained from the cut quality? The answer is often no.
It's a slippery slope when we begin prioritising output over the outcome, measuring the number of designs produced and features shipped (output), valuing these higher than the benefits to internal and external users (outcome). Not to say it's done through ill intent. It’s just that one of these is much easier to measure than the other, and so we favour it.
”In the Build Trap, the focus is on shipping features instead of solving customer problems. This leads to products that are overcomplicated, unused, or poorly received by users.”
Balancing the scale
Now, I feel I should clarify that there is a time and a place when we should consider trading off quality for speed, which may be a little controversial. It’s when this practice becomes commonplace that we run into issues as it’s very much a negative reinforcement loop, where you try to repeat something that had a positive impact without understanding why it did.
When we encourage teams to skip discovery phases, neglect code, and push out features to meet deadlines, it results in products that are difficult to work with internally, causing a slow-down effect. And we create products that don’t solve the user’s problems or, worse, create more issues.
Some will jump to what feels like the obvious answer of adding more designers, developers, or product managers. As the adage goes, “Many hands make light work.” However, can you think of a time when adding more people to something spiralling has made it better?
Futurama. S3E7: The Day the Earth Stood Stupid.
I think it’s safe to say it’s rare when this does work.
Instead, we should be focusing on correcting the internal quality issues. It feels counter-intuitive at first, but we can move much faster by holding ourselves to a high standard and holding teams and members accountable to those standards. Think about it. How much easier is finding something in a clean room than in a messy one? We begin to clean the proverbial room by doing the following:
Build a culture of ownership.
It sounds like a generic culture value prop, but you can genuinely feel the difference when it is embraced. Let your teams own the features or areas they are working on. Listen to them when they raise concerns and make their contribution noticed.
Let them build something they own rather than churning out someone else's vision. Think back to times when you felt excited and energetic as you worked. Was it because you felt and were treated like another cog in the machine or because you were trusted to deliver?
You may worry that in doing so, they will focus on internal perfection and swing so far in the other direction that nothing is shipped, but you hired a team of professionals who care about their work as long as you’re providing them with the right expectations, trust that they’ll deliver.
Build quality into your estimates.
Very much a follow-up to the previous point. Your team cares about the quality of their work, and if you want them to own the outcome of that work, you need to allow them time to do so. Conversely, it would help if you were building in the time needed to ensure quality in your estimates and schedules.
Granted, that is a lot easier said than done, and we shouldn’t only include things like technical development and code reviews but also testing and design reviews. All of these will help raise the quality of the outcome. It is better to let a deadline slip over, pressuring the team to trade off quality to meet it. To quote Gabe Newell, “Late is just for a little while. Suck is forever.”
Build a design system.
I think this might be a touchy point, or at least it can be met with scepticism in the startup world. After all, who has time to build and maintain a design system when you’re small? But here me out as it again builds from the previous point.
I’m not talking about something robust and tokenised that everyone sticks rigidly to. I’m talking more about a foundational set of components that are reused consistently, that are used to build up larger patterns and are everywhere in your product—things like your inputs or share modals.
You don’t need a lot, only enough to get you going. You can use a predefined system like Material, Tailwind, or one of many others to help get yourself off the starting block and modify it slowly to meet your needs.
Taken from Martin Fowlers' Design Stamina Hypothesis blog https://martinfowler.com/bliki/DesignStaminaHypothesis.html
Walk before you run.
I know the points I’ve raised above don’t materialise overnight. They require effort, teamwork and communication to implement, and it’s much easier to get caught up in the pursuit of quick wins and instant gratification.
The hard part is getting started and building that internal buy-in that you can gain velocity by focusing on quality, specifically internal quality, as these are the one in the same.
