Getting software out of the door is one thing above all else.

Hard work.

The differing teams I've worked on over the years both within work and within Open Source have taught me that pretty much anyone can force some software out of the door - the real trick in this business is learning how to push the software out of the door on time and too budget every time without fail.

Being brutally honest with myself I know that over my career I've released software on time, I've released late and on occasion early. When these things have happened there hasn't always been a rhyme or reason to the way things have gone, despite by best efforts.

Sometimes its failed because of poor specs

Sometimes we won because someone on the team made the right choice.

Sometimes we failed because of a poor choice.

Sometimes there was a hero, at other times people flagged at the last moment.

Throughout all of this the one thing that I've come to realise was the biggest failing was when someone on the team failed because they pushed too hard. Even before I became a manager I could see people becoming the IT Hero that was needed, it was something that I had done in my early career because there was a void which needed to be filled. Not knowing any better (And not having a decent role model) I pushed myself beyond what was sustainable to get the job done, I watched others do the same and it became how we got software out of the door.

The day that heroics became the norm for deploying software was the day I and the teams I was part of lost the game.

I wish that I could say that I realised this quickly, and went on to fix this problem and lived a happy easy life - but I cannot do that. No what followed was a fair few years of trying to get software out of the door and doing so through heroics, through all nighters, through life.

It wasn't until the end of 2018 I finally realised I'd burned out sometime before but had been soldiering on because that is just what you do right?


Very wrong.

Whilst I was working like that I always felt that there was a better way to do things, every time I strived to get there I found myself at another business critical issue or a problem that only I had the knowledge to fix, or it at least it seemed quicker for me to fix it than explain how someone else could do it.

Over the past few months I've really had some quality time to sit and think about how a team can function day in day out and deliver software and I think it comes down to one thing that every C-Level executive, IT Manager and anyone who actually delivers software needs to learn and understand.

Successful software delivery teams need to develop a sustainable pipeline of delivery.

For me there are two key words in that statement the first being sustainable, which means that you need to work at a pace which doesn't leave people exhausted. I'd suggest based on experience that developing at 80 to 90% of your full capacity is a good way of doing this - it leaves head room for emergencies and unexpected issues and doesn't leave you in a deficit provided teams only push to 100% for a short period of time. I would define a short period of time as 2 to 4 weeks, where you need to put in this extra effort for more than 2 weeks I'd suggest dialling back for a sprint and giving your developers a break - 70% should let them recover.

The second important word is pipeline. A pipe in your house connected to the mains gives you a continuous stream of water, it doesn't give you 3 litres to start with and then dial back because its tired. The idea of a software pipeline goes hand in hand with the idea of working below full tilt, you always want to be delivering software and keeping your developers fresh.

For the rest of my career I'll be pushing the idea of sustainable development everywhere I go.