Great designers lean out of Design to make an impact
This is the third article in a series I’m using to define my opinions on High-Performing Design Cultures. By defining the qualities that I believe a high performing design culture has, I hope to spark a constructive conversation about how enterprises engage designers and how we step up to do our best work. I’m also keen to encourage designers themselves to look up and out, at the influences affecting our craft.
I’m not sure how many articles there will be yet…but I’ll keep a log of previous articles at the bottom of every new one.
This article has been one of the hardest I’ve ever had to write. I know what I want to say, but its taken a long time to actually form a narrative that does not read like stream of consciousness. I’ve concluded that this is because with this article, I’m exploring the continuous debate of how to level up design. From the personal existential debate we all have with ourselves internally and because it’s a debate that sometimes spills out into mildly toxic online discussions about who gets to claim the title of designer.
I’m fairly confident that the debate and the toxicity that is sometimes exposed into the public domain, are down to a form of design entrenchment. We are all reacting to external limitations and constraints by demanding more of our vertical. To some extent we should demand more, but I think the ultimate solution requires us to get over ourselves and lean out of our self-made ‘Design’ boxes.
So lets get into the thick of it, starting with one of the biggest myths in our industry at present.
The myth of equivalence and the three-legged stool (with one short leg)
There is a mythical fairy tale land called Bestdigitalproductland. In it, digital products are beautiful from concept to pixel execution. All end-users are happy, delighted and fulfilled. All delivery teams are continuously engaged in shipping nothing less than the best thing. In these teams, a perfect equivalence exists between Design, Product and Engineering. This equivalence provides a positive push and pull where each have the breadth, accountability and latitude to bring out the best in each other. It’s as intended by the great forepeople that came before, paving the way for the world as we currently know it.
Never heard of this land? You won’t be the only one. You will however have heard the metaphor of the ‘three-legged stool’. That metaphor is no less a myth than the poorly constructed nonsense in the paragraph above. The rhetoric around the three-legged stool is grounded in ideas of a perfect world. Therefore in the real world, when that equivalence is out of sync (which it most often is), we spend time dwelling on a number of problematic scenarios which limit the scope and performance of all parties.
In reality, the equivalence doesn’t exist because its just not true. Design rarely has equal stake and accountability. As a contributing vertical to this mythical equivalence, only Design has to rely on a successful trifecta.
Badly built, ugly but well conceived products can succeed in the real world(e.g. Craigslist…a personal opinion).
Cleverly engineered, hi-spec products can succeed in the real world without needing to pass the commercial product or design lens (e.g. Chromium…again personal opinion).
Great research that never results in product improvements, designs that are never built and strategies that are never implemented, mean we exist only to produce waste and beautiful portfolio sites (which are not waste, but also not tangible outcomes).
Perpetuating the myth of equivalence therefore harms not just the individuals who are experiencing everything but equivalence, it also harms how our industry frames the challenges we face. It prevents us from examining our contexts with the critical anthropological eye we should all have been trained with.
The formula for Constructive Tensions
High-performing design teams take a different view of the situation. The issue is not whether or not Design is equivalent, the issue is whether the right balance of constructive tensions exist towards the common goal and outcome. Each of the three verticals runs the risk of over-indulging in the myth of equivalence. Where Design can help all, is by taking a human-centred view of the situation.
Let’s reframe the challenge that the myth of equivalence attempts to address. What exactly is the value we think we are supposed to be getting?
The value is the perfect amount of tension to successfully deliver the best outcome. Tension is a much maligned word in human relationships. We talk about it often as a negative sentiment, one that must be relieved, removed and released. However in this context, we are looking for the type of tension you see in structural engineering or science. The perfect balance of protons, electrons and neutrons. The mathematically precise tension in the wires of a large suspension bridge. Essentially those worlds where each element is present, pushing and pulling in just the right quantities to allow magic to happen.
Like many things in the world, no two environments are identical, therefore the right amount of tension is also unique. In some cases, you want more Engineering influence. In some, its critical that Design takes the lead. Critically, Product Management is especially unique in each context and most likely should be (more on that later).
The role that each party plays is also important to reflect on here as it’s not always obvious when you consider job descriptions on wording alone.
These three roles have collective responsibility for the resulting consumer experience, all are bound by the constraints that exist in resources (e.g. cash, people, tools) and all should be operating as a challenger and supporter of each other. The crafting of harmonious push and pull between these three disciplines is the natural conclusion of the road we started with lean approaches, multi-disciplinary teams and a greater emphasis on collaboration.
Alas, we are human. Therefore what often happens is that there is almost always a negative bias, often towards Engineering as they have the biggest resource implications. The second most likely bias is Product as they hold the purse. Where negative bias exists, the losers in the resulting power struggle are usually Design and Product.
Let’s go through a few of the scenarios where negative bias is affecting the outcome and how it impacts the role Design plays.
Scenario 1: Feeding the beast — Where Engineering trumps all
This is an increasingly familiar scenario. The FOMO effect of a competitive landscape where the other guy has a better team, has adopted all the cloud tech and is primed to ship ship ship, is creating a strong market for Engineers. Whether start-up or established business, everyone is hiring as quickly as they can. And rightly so, we’re in a downturn for black box off-the-shelf products. Particularly as business have woken up to the risks posed by having no retained knowledge around critical points in their digital customer experiences.
But here is the thing. When you go from being significantly under-resourced to very well resourced, you better have things ready to be built. This means being clear on what you’re building, having ironed out all the quirks and options that may exist, and giving teams some certainty of the outcomes that are expected. All logical.
Yet somehow, Designers in these scenarios, are almost always left with the expectation that they must run ahead of the beast. The quest for certainty, in a world of scaled, enterprise Agile processes, places the ask on Design to paint the pictures well before they need to be consumed. Risk must be eliminated. Uncertainty and options nailed down. Any delay in feeding the beast is down to a bottleneck in getting designs out. The language that flies around presumes that Design are the arbiters of all that must be agreed upfront lest Engineering resources be either wasted or left twiddling their thumbs.
In this scenario, Product has a tendency to hide behind Design. Their job is to stack the pipeline and keep Engineering busy. They commission solutions that are complex, and offload the points of resolution to Design. Whilst this is no bad thing in principle, the race to keep the beast fed will ultimately wear down any Design talent and create a high-pressure culture with low-quality outputs.
The most common response I’ve seen to this scenario is to introduce more Product people and project management. As you have probably already guessed, the whole thing starts to resemble a very Waterfall process with low-quality designs and a lot of waste.
Scenario 2: Out manned, outgunned, outnumbered and under planned — Engineering MIA
The flip side to the first scenario? An Engineering team that never comes close to capacity. This is the land of the perennial MVP. There is never any resource to do more. There is never any resource to experiment. There is never any resource to improve deployment tools. There is never any resource to participate in the planning process either, meaning there are missed expectations on every front.
There may be a significant managed service presence in this scenario, an Engineering team for hire. With the best intentions however, the lack of in-house resource to adequately manage the division of work and the handovers between in-house and supplier teams is likely to be another point of drama.
If you have functional Product and Design teams in this scenario, its likely that they spend a huge amount of time together plotting how to get the business to invest in more in-house Engineering resource. Making flip comments about the quantity and quality of the Engineering resource available, becomes a cultural trait and there is likely to be brooding hostility between the leadership of the three orgs.
Despite their best intent, in this scenario, I feel Design and Product teams find it all too easy to play the blame game. There can be a lack of empathy in the work planning process, a sense of game playing to get Engineering to commit to something the other two believe is more valuable, even if there are real issues with how these outcomes will be delivered. This game playing has no benefit. Aside from developing a culture that is petty and poisonous, an under-resourced Engineering function is not a bad thing if you know how to use them (if you’ve watched Hamilton you may understand my reference above. If you haven’t, you should).
Where Product and Design don’t learn to use their scarce resource wisely, you will eventually get a lot of attrition. Things are being committed to and never delivered. Designs are being produced that are never built. No one is happy and everyone loses.
Scenario 3: Design by numbers — Product as the profit man
We all know a little bit about how this goes. Some of the largest tech businesses today are most likely experiencing this scenario. It’s common in mature digital products where reliability, scalability (e.g. MAUs, ARR and the like) and profitability are the business buzzwords and the only thing leadership care about.
Any ask that does not directly speak to these three metrics is automatically a lower priority. To a large extent this looks like a healthy environment (particularly for shareholders), but when you’re focused purely on these metrics, there is no horizon game. Every penny available is already committed to these issues. Trying to look too far ahead is a thought experiment. Experience, ethics and even satisfaction are all well and good, but unless the Product team can directly correlate these to reliability, scalability and profitability, forget about it.
You also get a lot of me-too behaviour, if it looks like the competition is getting a marginal gain with a feature, there is an aggressive push to get that feature built and launched!
The risk here as with others is attrition. Product will likely be overrun with sales driven profiles who are incentivised to hit numbers but are unlikely to have a long term investment in the business (average 2-year tenure). Leading indicators of future catastrophe are ignored and risk-accepted in favour of the short-term gain (e.g. social sentiment, supply chain issues, regulatory risk, cyber threats etc.).
The winners in this scenario are early investors, bonus hunting employees and venture capitalists. Making money is no bad thing, making money at all costs absolutely is because experience always comes due.
Scenario 4: Headless ship — Anyone seen Product recently?
The final scenario I want to talk about is where despite the presence of Product within the organisation, no-one really feels that anyone is steering the ship. Product is still an emergent practice. Slice your average Product person down the middle and what you get is a mixed bag of experience, job histories and accreditations. Unlike Design and Engineering, there is no real formal training for Product, so inevitably, Product is most likely to be governed by the organisation’s own inherent ethos. And herein lies a huge consensus risk.
Let’s revisit our myth of equivalence. Imagine a typical workshop around a new potential feature. Design lays out all the pain points. It’s high drama, fraught with danger for the user and a hero’s story for a solution concept that tested well. Engineering sigh a lot, click their teeth in places and despite seeming like it was all doom, come up with three options involving new feature libraries, a new spec from the cloud provider and a team that’s been hacking away at an old problem. At the end of it all, there are several ways to proceed, each with opportunities and drawbacks. Product thanks everyone and retreats with the intention gathering business input for a way forward. No one ever hears from them again. And the scenario plays again, and again. Somehow, tactical decisions are being made and things are getting done, but no one is really steering the ship.
At year’s end the summary of what has been achieved is like a bag of pick and mix as picked by someone who doesn’t understand why you wouldn’t put tangfastics in with heart throbs (if you know, you know).
The challenge with this scenario is that by many organisation’s standards, things have been achieved and progress is demonstrable. However you don’t build passionate Design teams and fight for scarce Engineering resources only to have no ambition or ability to drive a vision forward. Your risk once again, is attrition and slowly slipping into a quality downturn. While everyone is waiting on Product to show up and make a decision, even tactical metrics will stagnate or go the other way.
If you’ve been working as a digital Design professional for any length of time, you have likely seen all the scenarios above. You may even be living in an organisation that has a bit of everything. As I write this, my fingers are tense from the frustrations I have personally experienced and that come from chasing the myth of equivalence. My therapy and thesis on the route to establishing high-performance environments with the right amount of constructive tension, is leaning into the places where the negative bias is coming from.
Leaning out of Design and into…
I’ve been doing a lot of interviewing lately in my current role. The environment I’m in is one where I end up talking to designers about being colleague-centred. Humility comes up often, not the fake stuff where you still think you’re smarter than everyone, but genuine humility where you drop the saviour complex and get in the mud with everyone else. As I look back over the most fulfilling years in my career in Design and as someone who is results-oriented, a common thread is breaking out of my vertical and leaning into others.
Now in the off-chance I have triggered you into thinking I’m advocating the eradication of Design or even presuming to be so smart as to do the jobs of others, let me clarify what I mean.
When I was at Head London (before it was acquired by Zone Digital) we had one hairy, persistent problem when we transitioned to being an Agile shop. We’d done the maths on the commercials and felt to our core that we had to break our client’s addictions to fixed price, fixed scope projects that ultimately killed everyone’s soul (both client and agency).
Luckily for us, we did this at the cusp of the Agile boom when CTOs and CEOs alike were taking digital safari trips to the valley, reading HBR articles about true productivity and drinking more Lean Startup koolaid than Mr Reis could actually make. Selling Agile projects didn’t prove to be as big a challenge as we anticipated. Our real issue it turned out, was getting our clients to transition from managing projects, to being Product Owners and Product Managers.
When you’re working across multiple domains with a suite of client engagements in the 10s and a team that averaged around 40 people, you’re context switching a lot. So we drew boundaries and set the expectation that our clients would always have to be our Product Owners. They were the experts on their organisation, we were experts on helping them design and build digital products and services. So we needed our them to be decisive, we needed them to be empowered, we needed them to be familiar with Agile, we needed them to be interested in this new fangled way of working, we needed them to do all this whilst still working their normal day job in exactly the same way they’d always done, because although their bosses had bought into going Agile, nothing had actually changed for them in real terms. You can see where this went.
Retrospective after retrospective came back with the feedback that we just couldn’t get our clients to take on the role of Product Owner as it was intended (that darned myth of equivalence). The wonderful thing about being in a small agency is that you can see a scenario and just react to it without much drama. We decided to break the myth and appoint a shadow Product Owner for every client engagement. This role could be played by anyone in the team. It’s function was to absorb the client’s challenges and do whatever it took to make them successful. If it was a really technical client, we’d have a shadow Product Owner from Engineering. I personally played the role several times, as did some of our Project Managers.
When I look back at how simple the fix was, it feels ridiculous that we toiled for so long with this limiting idea of how the roles worked. Adjusting the point of tension so that we took on some of that Product responsibility changed everything. And this is something that I think a high-performance Design culture does, it adjusts to the right points of tension given their environment.
In my second article in this series, I talked about the firm intentions that high-performing design cultures flex around, number three was “No us vs them, just us together”. Leaning out of Design means looking at the problems that Product and Engineering have and taking collective ownership of how we can solve them together. Leaning out and taking a holistic colleague-centred view also means we allow ourselves to apply the best framing to the problem. Framing it well ultimately opens up the pool of solutions whether temporary or permanent.
So let’s look at our problem scenarios and how we might solve them if we leaned out of Design and reframed them.
Scenario 1: Feeding the beast — Where Engineering trumps all
Reframe: How can we best utilise a large talented pool of engineers?
Possible solution: Task some teams with working upstream on speculative solutions with Design. They (selected from those who want to lean into Design) can be trained on simple inquiry and research techniques if Design resource is more limited. They can build early prototypes, run mechanical turk experiments and form part of a solution space whilst others remain in production mode. Product can indulge in the opportunity to move quickly without necessarily fixating on following the product-design-build route. The idea here is not to move fast and break things in live environments, but to assume (rightly) that smart people can be empowered to make smart choices.
Scenario 2: Out manned, outgunned, outnumbered and under planned — Engineering MIA
Reframe: How do we make the most of the resources we have?
Possible solution: Change the quality gate from minimum viable product to minimum valuable product. Become selective about picking the features that truly drive the greatest value for end users and the business. Everyone becomes a Product Manager here, keeping a close eye on key metrics and being pragmatic and ruthless about scope creep. The resources you have will become more engaged and empowered. The message to new hires then becomes one of a small team doing significant, impactful things.
Scenario 3: Design by numbers — Product as the profit man
Reframe: How do we quantify the value of the right digital experiences?
Possible solution: Get into the metrics. Often organisations get very complacent in relying on the same metrics over a long period of time. When you dig into the metrics, there can emerge a picture where a measurement is actually masking an invisible objective. So play that game. Could you build an experience metric into the concept of reliability? Does profitability take a hit when you assess the impact of maintaining (rather than rebuilding) a poorly performing part of a journey? I’ve talked about attempting to build a qualitative measurement for Customer Experience Debt in a previous article. Getting stuck into the challenge of building a holistic narrative could be the route to getting traction on wider scope.
Scenario 4: Headless ship — Anyone seen Product recently?
Reframe: How do we phase opportunities so we can experiment and build better data around risks?
Possible solution: One of the biggest challenges that Product Managers face is balancing what can sometimes be unique commercial models with the perceived notions of how to get to Bestdigitalproductland. Everyone should understand and own the chance that taking punt comes at the risk of throwing away hard earned money, money that ultimately pays salaries and keeps shareholders at bay. So the trick to exploring new ideas then is being really critical about the best way to prove the case. How small could the first test be? What’s the next best question to ask? What data and feedback loops would build confidence in the right direction? These are lenses Designers use all the time to design research. Scale the context into the business environment including other variables and decisions could be easier to make for all.
Leaning out of Design will challenge your definitions of self
I am a Designer. This label feels true and almost super glued to the other seemingly immutable aspects of my identity. Earlier this year I was asked if I wanted to be a Design Leader or a Business Leader I felt an almost physical rejection of the idea that my career would move in a direction that eventually ditches Design. It’s not the first time I’ve felt that reaction and it’s usually a precursor to exploring my context and choosing to reframe. Why should any of us limit our impact to a single vertical? Especially if we are increasingly frustrated by the constraints that places on us?
High-performing Design cultures don’t exist to just be great designers. They know that the proof is in the pudding and the desired outcomes have to be the final arbiters of success. Individually, we may all feel that leaning out of our vertical drives a sense of panic, a sort of cognitive dissonance that feels like a glitch in the matrix. If we reframed that experience is part of the process of focusing on the real issue at heart, labels and verticals stop being as important as we may at first perceive them to be.
So let’s ditch the myth of equivalence. Lets ditch the existential debate. Starve the distractions and feed the focus — making impact.
You can read previous posts in this series:
