May 2022 – James Osborn

Timeboxing Exploration

It’s easy to fall into the trap of Analysis Paralysis. One more bit of data, a couple more answers to a survey, the feelings of that final stakeholder.

Whenever we are in an uncertain time, you can think that it’s best to get to certainty before trying to act.

It’s a false premise, fight that urge.

Most of the information that you need to make a decision will be easy to gather, and the last few pieces will be a lot more expensive and probably less valuable.

So instead, set aside a timebox to do this exploration and to gather information. I find it works best if you are clear about what you are trying to learn, what the decision is you are trying to make, and also honest about what you know now.

By making decisions based on a fixed amount of data collection, you can move on to actually seeing how the analysis you’ve done holds up in the real world, and start on any course corrections early.

Pick shorter timeboxes for smaller decisions. If it’s low impact or low risk, don’t waste much time on it at all. If you are investing a couple of weeks work for the team, then spending a few hours to validate assumptions is great. Spend a couple of days on your plans for the quarter, and a week or two to set a annual strategy.

You need to be disciplined, and actually stop and make the decision once you hit the limit of the timebox. So start with the smaller activities to build confidence and go from there.

Once you’ve done the analysis, made the decision and implemented the outcome, then review the outcomes to see how you did.

The way to make good decisions is to make lots of them, to learn what went well and to do more of that. You get there by focusing your exploration time, learning the most important things, making that decision and doing it all over again!

Carrying the Pager

I prefer to build teams that own the whole lifecycle of their work. They get involved in the design, understanding the problems of their customers. Everyone pitches in to build the solution, whether it’s describing possible features, writing the software or packaging it up to deploy.

Most importantly, the team run and operate the systems they build. There might be supporting ops teams, but if something goes really wrong, the team is on hand to fix it.

This model encourages the team to work in balance. No one behaviour is over incentivised. They are encouraged to solve problems rather than build systems for the sake of it, and they feel the pain of something being broken straight away.

Maybe it means that new features are not delivered quite as quickly as they could be if the team are just building them and having someone else manage them. However, this split model causes more dependencies. The management teams are often a bottleneck, so when things go wrong they can be harder to fix, and if it’s not an urgent issue, it may never be looked at all.

So, if you are just starting out you can drop features at pace, and if you are running them as well you can fix up what you need to immediately. You have fast feedback loops.

In bigger orgs, you move at the pace of your customers, you cut dependencies and aren’t at the mercy of an overstretched ops team.

Carrying the pager instils the philosophy of care and concern in your team, forces them to feel the pain of their users and to resolve issues when they come up.

You should then also take a turn. Leaders should also carry a pager. Maybe an escalation rather than sitting on a single rotation, but in the same way that the team feels the pain, you need to feel the pain of being on call. You make sure that you don’t let this pain get too much. An occasional page for a real issue is fine, constant noise of a system working as expected should be squashed immediately.

We should all carry the pager at some point, it’s one more way to stay connected to what’s going on!