Balancing your execution, re-planning the roadmap

The good, the bad and the debt

The roadmap is considered a holy document for most tech organisations. It ties together commitments between interdependent departments in ways that requires careful (and expensive) planning steps, estimations, projections and good will towards achieving the seemingly impossible while remaining optimistic.

The debt

Do you put support tickets onto your roadmap?

Vacations?

Bugfixes?

Refactoring?

Unexpected wtf!? sprints?

Generally, no.

One would assume those elements are averaged out by each department lead to create a significantly certain element of stability.

The cure

The solution to all of the uncertainty is having a good tech culture.

Ever heard of Agile Transformation?

Digital Transformation?

Yes, the outcome of that.

I like to call it ensuring good Execution Quality.

But the effort that goes into planning and re-planning the processes itself should be an active ingredient on the roadmap.

When you make a plan for the day, you don’t assume taking a shower, having lunch, exercise or sleep are unnecessary, instant activities.

Execution quality is no different.

Deceleration < Acceleration

The target is constantly moving. I like explaining this with Little’s Law.

Yes, the one about queues.

You want to stay ahead of the curve of your incoming workload.

Not by a little bit, by a magnitude!

You will slow down at first, then decelerate as your Product’s feature set grows. It’s natural that you also need to re-invest into acceleration.

Pragmatism

Four areas of your business to constantly re-evaluate:

• How firmly can you delegate to non-engineers?

• What part of your system can be outsourced?

• What work or rituals can you eliminate?

• What can you afford to do twice (rather than abstract)?

Create tools to allow your non-technical staff to solve problems on their own (give them superpowers!):

• Triage support and bug tickets to the most knowledgeable person first…

• … then have them delegate to someone who can learn from it if necessary\

• Conduct an Inverse Conway Manoeuvre to match your team organization to your roadmap

• Do NOT your team organisation to your areas technical debt

---

Sometimes simple matters require hard decisions.

Stop-and-go, context switching and hesitation will kill your productivity much more than doing something twice.