On the face of it, this might seem like a contradiction. What has design got to do with budgets and deadlines? Surely creativity has no place in the world of spreadsheets and Kanban boards? What can a discipline that juggles risks, timelines and stakeholders learn from one focussed on user needs?
Plenty, I think. My background is delivery – not design – but as I’ve worked with designers over the years, I’ve learnt that our two disciplines have more in common than might first appear. Many of the general principles are the same, and some of the methods developed for design are directly applicable in delivery too.
But perhaps more than that, I’ve found that a good way to challenge old habits is to take a look at yourself from a new perspective. For me, learning about design has helped break some bad delivery habits and refresh my way of thinking.
So here are four ways I think we can deliver a little better by thinking more like a designer.
1. Act as one team. Create space and opportunity for collaboration
Designers know the value of collaboration
Stickies on the wall and breakout sessions in flow; designers know how to run a collaborative workshop. And I don’t think it’s just for fun. Designing products often means solving broad problems, so it’s natural to bring together varied skills and experiences. It also means you catch problems and spot opportunities that individuals working alone might miss.
In delivery, short-term pressures can squeeze the space for collaboration
Collaboration feels like a natural fit for delivery managers too, right? Our roles mean we tend to coordinate others, to be generalists rather than specialists. Collaboration should be a core part of our work and our decision-making. But a problem I’ve seen many times is that quality collaboration – and sometimes any collaboration at all – can fall victim to project circumstances or bad habits.
Faced with the pressure of deadlines and budgets, it’s easy to let collaboration fall by the wayside for the sake of ‘just getting something done’.
A common example is how we assign tasks across the team. This should be a balancing act. Sometimes short-term efficiency is the priority; when a deadline is just around the corner, we might simply give people the tasks they’ll do best. But at other times, we prioritise the long-term: the health of the team and the quality of output. We might mix up task assignments or encourage pairing. These can have a short-term cost, but they spread knowledge and skills, and introduce fresh perspectives to tasks that can lead to better outcomes.
The problem is, day-to-day pressures on delivery managers make it very easy to habitually prioritise the short-term: “Here’s a ticket I know you’ll smash out the park, I’ll see you in two weeks when it’s done”. We pigeonhole our staff, silos of knowledge develop, and the habit becomes self-reinforcing. We’ve accidentally squeezed the space for collaboration out of our teams.
One way to permanently make space for quality collaboration is to incorporate user story kick-offs into your sprints. These are just sessions to discuss requirements, risks and basic implementation approaches before development begins. But importantly, they include representatives from across the team. By creating a space for different disciplines to work together, you get that broad experience that can lead to different perspectives and new ideas. And, of course, you spread a little knowledge too.
2. Ask questions. Make time to challenge the status quo and to think creatively
Designers keep an open mind
The designers I’ve worked with have a habit that I really like: slowing down, asking questions, and challenging assumptions and constraints. I think this is part of a particular style of thinking. Rather than rushing to easy or established solutions for a problem, a designer might challenge the problem, think creatively around it, and perhaps find something better.
Delivery managers need to be careful about tunnel vision
In delivery, it’s very easy to approach things in a more linear fashion, and to default to established ways of thinking. For example, you know that if you are behind schedule with a fixed budget, de-scoping work will resolve the problem. Tried and tested, right? But by always thinking this way, we risk only ever finding the good solutions, and never the great ones. It’s the style of thinking that’s fundamental here.
We once had a project where a delayed external dependency threatened to push back an essential beta test. It would have been easy to accept the delay and the associated risk, but instead, the team asked questions. It turned out that, of the two user groups covered by the beta test, only one required the external dependency. So there was the better solution: split the beta test in two, and test the two user groups independently. Half the beta test could then run on schedule, and only half needed to be delayed.
Going back to much earlier in my career, I remember a project where an integration failure was blocking an upcoming go-live date. And unfortunately, the project involved two mainframe systems – neither of which had been updated since the ’90s – and they didn’t benefit from the automated testing strategies that are the norm today. We tried literally weeks of manual testing and isolated investigations, but no luck. Then we did something different: we got everyone in a room, grabbed a whiteboard, and visually mapped out all possible root causes across the system’s architecture. Within the day we’d solved it. The issue was, in fact, caused by a peripheral service. Our initial investigations had simply been too narrow!
The severity of these examples was quite different but the solutions were similarly simple: ask questions, grab a whiteboard, slow down!
3. Accept uncertainty, then deal with it. Create an environment where we can manage uncertainty with experimentation
Designers are comfortable with experimentation
Iterative product development necessitates experimentation. Some of those experiments will succeed, and some will fail. To a designer, that’s OK. The purpose of the process is to move from hypotheses to validated solutions by continually iterating on the product. That means being comfortable with trial and error, and more importantly, fostering an environment that allows learning and exploration.
The whole team needs to be comfortable with experimentation
So how can delivery managers and wider technical teams get comfortable with a little trial and error? Well one thing that helps me is realising that we do already experiment, it’s just that we prefer language like “sprints”, “retros” and “contingency”. It can be helpful to remind ourselves (and our teams!) that the whole point of retros is to learn and improve; the point of contingency is to leave room to explore the uncertain, and sometimes that means experimenting.
Also don’t forgot the concept of a “technical spike”. It’s perhaps not as well-known as the designer’s prototype, but it similarly proves (or disproves!) a technical approach by quickly building a narrow but deep journey through the most uncertain areas. Useful for evaluating new tools or platforms, or simply when you’re trying something novel.
For me though, a key thing with all the above is your team culture, including the relationship with stakeholders. It’s incredibly important when experimenting to be disciplined: agree the process or decision points with your stakeholders, set finite boundaries for time and/or budget, don’t experiment for experimenting’s sake! And be very careful with language; a failed experiment is not the same as a “mistake”. Use the best foresight you can for making decisions, but don’t unfairly judge failures with hindsight.
You can’t escape uncertainty in software projects, but with careful use of experimentation, you can deal with it.
4. Shift left! Build short feedback loops into your project from the start
Designers validate user needs early and often
Designers obviously care about user needs. In design, users are both a source of unknowns and a key measure of success. And the earlier that designers develop an understanding of users, the more time for setting the product’s direction. Major surprises close to delivery (or worse, after!) could be too late. So a key part of design thinking is to validate user needs early – to shift the validation left – and to do this with short, regular feedback loops from users, as early in a project as possible.
Delivery managers can validate early too
Just as designers validate user needs, delivery managers need to validate project needs, approaches, risks and other unknowns. These “uncertainties” might cover users, technology, stakeholders, competing priorities and more. And the feedback loops might be user feedback, automated tests, external audits, or something else. But whatever the details, the key lesson from design still applies: validate early, validate often, shift left!
So if something can be tested or reviewed, it can be tested or reviewed earlier. If security is a major risk, don’t leave it all to a pre-release penetration test to resolve it; schedule a mid-development test as well. Or better, get an early security review at the project planning stage. If performance is your worry, ask your Tech Lead to bake automated performance testing into your build pipeline. And if you’ve got a tricky migration, book dry runs well ahead of your go-live date.
Releases themselves can also be an opportunity for validation. I once worked on a re-platforming project with dozens of different customer types, each with different needs. If we had released to all customers simultaneously, that would have been a big bang of features late in the project, with little opportunity for feedback. Instead we released a smaller set of features, much earlier, but to only a single customer group (known internally as the “friendly” customers). We used the feedback from these initial customers to refine features before releasing more widely.
If all this sounds expensive, keep in mind that often things like performance tests can be automated once near the start of your project and then run cheaply throughout. But yes, sometimes you just need to weigh the cost of mitigations against the risks themselves, so for me what’s key is to establish your risk management approach early, and then iterate. Shift left!
Does this sound familiar?
Given my delivery background, it’s probably no surprise that I’ve twisted everything I’ve learnt about design to sound like the agile principles we all know so well. Still, I think there is real overlap between the two disciplines. And I’ve found that working with designers and learning about Design Thinking has given me a fresh perspective on these issues, and a useful reminder of why these agile principles matter so much.
Of course, not all projects allow you to apply 100% of these ideas 100% of the time; budgets, deadlines and other realities of life mean that a delivery manager’s laser-like focus still has its time and place. But I like to apply the mindset when I can, whether that’s mitigating risks earlier or spotting situations that would benefit from a little collaboration. You don’t need to be a designer to have an open mind!
