Sometimes, you get stuck — an individual, a team, a company — somehow, despite your best efforts, things are going badly and you can’t see a way out of it, and it’s getting demoralising and exhausting.
I’m focusing this on the context of software engineering teams, but the core concepts are, I think, more generally applicable.
Why am I writing about this? Well, I’ve been there, and will be again. I’m writing this as a starting point for my future self, and for any individuals and teams who may be feeling stuck. Hopefully it’ll help you forge a bright new future! Or, if not, at least distract you from your troubles for 5 minutes.
The Situation: Understanding Where You Are.
So, you are in The Situation. Everything feels slower and more difficult than it should be. Improvements you try to make don’t stick, and you feel like you’re going round in circles, without the time to properly address problems. And there are so many things that need fixing, it barely feels worth fixing any one thing.
Stay calm, deep breath. Attempt to imagine a future where things are not awful. It is possible.
Now, write down everything that is going wrong — all the symptoms. You are going to diagnose the shit out of these, figure everything out, and (gradually) make everything awesome again.
The word symptoms is deliberate, you’re after the face value badness here. “Our customers are unhappy” and “We’re writing loads of bugs” may well be related, but to get the full picture, it helps to keep these separate at first, Remember to think about both technical and human problems. “We frequently have to rollback releases” and “developers are unhappy” are both part of the knot you’re untying.
An example list might looks something like this:
# Symptoms:
- We keep finding bugs and performance issues.
- Bad architecture.
- It takes a long time to write a new feature.
- Our customers are unhappy.
- We feel constantly rushed.
- Our processes are inefficient and unreliable.
- We aren't reviewing code properly.
- We're skimping on testing.
- There's a lot of bad code.
- We keep missing project deadlines.
- We have high staff turnover.
- We're not communicating well.
- There isn't time to properly onboard people.Right, so you’ve got some issues — but you knew that already.
Next, draw some arrows between these, to indicate what symptoms are causing or contributing to others. You’re likely to end up with a messy web of arrows, but you’re not hanging this on the wall, so chill.
The idea of this is to identify your specific negative feedback loops. These may be small or big and will probably overlap.
When no more arrows spring to mind, just take a look at the resulting Web of Sadness. Perhaps it’s given you some ideas already, but, perhaps not. It may help to write down the feedback loops you think are the most important, high impact, or easiest to break.
Now, I don’t know your specific situation, so I’m not going to give you a plan, or a magic formula. Honestly, my main hope is that you walk away from this article with a place to start and the belief that there is a destination. At this point, the most important step is the next one.
Instead of a plan, here is a question to consider:
Where in this web is the easiest place to make an improvement?
Look at individual symptoms, or if you can, individual arrows —directly fixing “Feeling rushed” is hard, but you might be able to break the arrow to “Not reviewing code well” by clearly communicating and agreeing as a team that reviews take priority over other work, or to find a faster, more fun way of reviewing than pull requests. In turn, this should help reduce the burden of bad code that’s leading to bugs, that’s making everyone feel rushed.
At this stage, mindset changes can be as important as process changes, but still need a cheerleader to make them happen. Be the person positively encouraging your team that it’s worth their time to invest in proper tests, because “look, I drew a picture that says it will be worth it!”.
Looking at your web, and considering these questions, you should be able to come up with some next steps that will start to unravel this knot.
Unravelling The Knot
The knot is a deliberate analogy for this sort of situation. Imagine you are trying to untie a very tight, tangled knot. You can spend a lot of time at the start just loosening slightly, pulling at different parts of the thread to make enough space to properly untie it. This is how resolving this kind of situation can feel. Like you’re making only small bits of progress at the start; tiny changes, that don’t feel like they’re fixing the systemic problems. But soon enough, you’ll notice the freedom these give you to start properly untying whole sections of your knot, and the improvements will feel faster and more satisfying.
Focussing on small changes is important, even if they’re are not the ones you ultimately want. Spending a day improving a process or tool that you know you ultimately want to replace feels like a waste of time. But if it breaks a feedback loop right now it will almost certainly move you in the right direction overall. It’s about buying yourself breathing room.
Often, in situations like this, someone will say something like “of course what we really need to do is <insert gold-plated high-effort solution here>”.
This is often counter-productive. It’s good to have dreams, and keeping the destination in mind is useful, but don’t insist on walking 100 miles south because the train station was in the wrong direction.
If you’ve already tried to fix something, and it hasn’t worked, don’t immediately move on to the next thing. Ask why it hasn’t worked and try again.
Summary
So, a quick recap of the first steps to your bright new future (or of the last dreary 5 minutes of your life - I wouldn’t want to presume.):
- Believe! If you don’t think it can get better, you won’t have the motivation to make it so. And you need to have the right mindset for the next step…
- Write down everything that is bad. All the symptoms.
- Connect the symptoms — how do they contribute to each other?
- Analyse the loops — find the easiest ones to break, and prioritise those improvements.
- Make a plan for how to ensure you actually implement those improvements. If you’ve tried and failed before, ask why, and try and do things differently this time.
- Profit — hopefully literal, but enjoying your job more is also worth something.
OK, but…
I’ve definitely left some questions unanswered, but I think they deserve their own space, so I’ll get to them another time (and if you have your own, please do let me know — answering other people’s questions is more fun than those of my curmudgeonly, cynical alter ego):
- “This is all very well, but how do we even find the time to make even small improvements when we’re fighting fires all the time?”
- “Those negative feedback loops are very vague, can you give me some concrete examples?”
- “Some of these symptoms are caused by organisation-level problems that I don’t have the authority to fix. What am I supposed to do with those?”
