# Make Boring Plans

https://skamille.medium.com/make-boring-plans-9438ce5cb053

A recent blog post continuing the trope of _boring is good_. This time it moves a bit away from technology into team management and tech team processes. I like this shift, it well complements the [choose boring technology piece](https://qoto.org/@FailForward/105618393533273455).

## Novel Technology Deserves Boring Plans

> When we don’t attend to the boring parts by making our plans predictable, the interesting parts turn into extra stress on top of the overwhelming anxiety of juggling these moves.

1. turn vision into boring plans
2. start small
3. execute a change; observe; make notes; learn
7. iterate

## A Strategic Plan Is Obvious and Simple, Even Boring

> Good strategy provides the clarity that enables boring plans.

> Your teams need more than a clear idea of the end state and the hope that smart engineers will inevitably get you there. Plans that are formed around hope are failing plans; hope is not a plan. Plans that change constantly are failing plans. When your plans are constantly changing, it is a sign that you either are making plans that express a certainty you don’t have, or you haven’t done your research to get the right certainty in place. Either of these is a waste of time and an unnecessary stress on the team.

Yes, of course.

Now there's something to add. Once upon a time when I was a junior high-flying and invincible programmer, I would spend nights coding and debugging some project shortly before the deadline, just to beat it into submission and drag it kicking and screaming to the delivery. Proud I was. And so were my managers. I do not know whether they considered it right, or not back then, we all felt somewhat powerless in the face of the unknowns we faced developing something nobody attempted before (because such is the nature of fun projects, right?) and at the same time proud of what we achieved.

Fast forward about one and a half decade later, as a lead of a severly understaffed and underfunded team delivering yet another _interesting_ project (read: with a lot of uncertainty in feasibility and execution). Before the dealdine where you just feel to be a step from everything falling in place and yet everything starts breaking down, my team worked hard a few evenings and nights to beat the project into submission. We of course made it. Then, a couple of days later I apologised to the whole team for all of that and promised to myself never to get into such a situation again (which is of course a fallacy, but one needs to have ambitions, right?).

Apology from a tech lead, or a manager is in order in such a situation, because such situation should never have happened. Because _boring is good_ dictates that to be on time, we shall have worked 9-to-5 and have all the integration and validation test done 2 weeks before the deadline. And we didn't. Because the planning failed. Because the project was not planned to be boring enough.

Keeping learning...