May 31, 2018

The shit chute

You’re a small team who are trying to change culture and practice within a large org. You’ve been set up well (like many other digital transformational teams) with strong, capable people who have done this shit before.

You know through experience that showing results, and showing a clear, detailed vision of what the ambition might look like gets attention and builds trust with the high-ups.

Build a case study, create an exemplar. So you start ranging around the org, looking for potential partners, people you can help make look brilliant by adding a little magic, bringing a bit of digital. And there you find the team, that one who get it, but just haven’t had the right people or investment to really move things along – they’re the one who are working diligently on that unloved, unsexy but deeply important thing that never had the chance to think about, let alone run as a product team. They’re excited, you’re excited.

But then word gets around, there’s a team who can help with design. They’re helping some bullshit team buried in the org, so surely there’s an easy argument that they can give a bit of time to that big, high-profile, super-important project that isn’t moving as fast as the high-ups want. So it begins.

Why isn’t it working?”

What do you know about your users?”

How does this work with that?”

But the super-important project team don’t want those questions - they want you to pull together a deck that shows the vision (their vision). They want you to show what the thing looks like with that nice design system you’ve been building. They already know what their users need they’ve been working on this for years…

So you negotiate, a bit of the shiny for a chance to show them how they could be doing things better. Quid pro quo. You’ll help them with the short term if they open the door to the possibility of Doing Things Differently™.

And now, you’re part of the problem. Welcome to codependency.

When this project fails to deliver, when it continues to stagger around in circles, collapsing and spraying its dying guts all over the org, you and your team are going to have that shit all over you, just like everyone else who went near it with good intentions. Everyone will be to blame, so nobody will. But all that capital you built up in the team is pissing away because you got everyone’s hopes up and turned out to be just another bunch of bright folks who talk a good game.

So, what do you do next time?

You make a shit chute.

The shit chute is a process for making sure that if you have to deal with toxic projects, HiPPOs, JFDIs etc is that you get it through your team without ending up covered in shit.

Fundamentally, this means you accept that this will happen (because you’re a strong, capable team who get things done) and that you won’t always have the luxury of saying no. It operates on the following principles:

  1. You get this done and you do it fast, the metric here is speed. Treat it like a bullshit project at an agency.
  2. You don’t try and change the course, question the rationale, or challenge the process. This isn’t the hill you want to die on.
  3. You protect yourself from the shit by being clear about what’s being asked and delivering accurately and precisely (again, ex-agency people who have been good account handlers in a past life will be useful in your team)

If you can’t swallow this as an approach, then think about it as a sort of chaos monkey - this is a test of your team’s resilience and ability to handle randomness. This is about making sure your team live to fight another day.

It might be that you need to make this a more formal part of your team’s charter, that it’s part of the way that you all work: sometimes you’re on 20% time, and sometimes you’re helping on the shit chute. Point is that you don’t make this another team - it needs to be part of what the team does.

Side note:

You’d have be some kind of monster if you created a dedicated shit chute team deliberately. It’s of course perfectly acceptable to create shit chute teams unconsciously and is in fact is fairly common. Look at most large orgs.

Last of all, another of the potential upsides for this along with the resilience test is that if the project manages not to collapse your team looks responsive, you’ve just built trust and a little bit of capital with those HiPPOs that you can save for later.

Final thoughts

Yes, this is a weird thing to do. When I’ve spoken to people about this the reactions tend to be either uncomfortable laughter or disbelief. I think that’s because as designers we tend to want to make things better, and we belive that things would be better if only people listened to us and did things the right (ie. our) way. It plays against the narrative of designer as saviour because it speaks of the designer as shit-shoveller, which is precisely what all those Medium treatises and LinkedIn motivational posts tell us design really ought not to be.

I prefer a different approach, I believe that you have to accept the world (and more close to home, the products you’re working on) as it really is. If you really have no choice, then accept that fact and attend to it. Fighting against the reality of a situation, pretending that somewhere there’s something better out there that only you can bring to life doesn’t really change things in the world (or the org) you’re in.

If the shit is flying, then let it fly through chutes so your team is somewhat protected and maybe even makes them stronger.


Process Product Teams Ideas


Previous post
Authenticity and integrity I’ve had a problem with the use of authentic when it comes to describing some sort of aspired behaviour or way of being, but hadn’t quite got around
Next post
A tool to help get your organisation into shape Doctrine Grid Tool I wanted to use Simon Wardley’s very helpful set of universally useful patterns (aka Wardley’s Doctrine) in some forthcoming