Letters from the grind: A few words on company wide prioritization

From time to time I find myself writing longish e-mails to individuals or groups, offering them my point of view on various topics that are currently on their radar. This one – an attempt to provide some clarity on company wide prioritization and strategic coherence – went out to a Management Team.

A few words on the X Development Process:

We recently introduced a new end-to-end development process here at X. This process, from Idea to Done, is specifically tailored to help us make as informed decisions as possible, and to make these decisions just-in-time. Just-in-time here means finding the sweet spot where we make our decisions when we have as much information as possible, without waiting too long and by doing so, putting ourselves in unfavourable situations.

So, what we have now is dynamic prioritisation (as the priority of our company wide backlog can change at any time), with the option of dynamic capacity allocation (as we can allocate capacity from teams toward special themes – in a controlled manner – at our leisure).

The value of this is that we can respond quickly to new information and make sure that we at any moment in time always focus our limited capacity of development on the most valuable initiative.

If a metaphor can be permitted, this is the process equivalent of a fighter jet. It’s fast, light on the touch and small adjustments can have a massive impact. With this comes two important questions that X as an organisation needs to ask:

A) Do we need a fighter jet?

B) Do we know how to fly a fighter jet?

If the X organisation do not feel capable enough to pilot a fighter jet and would rather move slower and more predictably – the tweak you are looking for is to freeze the company backlog for the time horizon you feel comfortable with. Tilt that backlog over on its side, and you have a traditional road map. If you do so, however, I would advise you to adhere rather strictly to your decision to freeze the priority. If you don’t stick with that decision, you might benefit more from continuing practicing piloting that fighter jet.

We can all learn to live with- and navigate in uncertainty – it’s a core skill in this day of age. The illusion of certainty and control, however, is more problematic. Not only because we do not expose ourselves to the learning opportunity, but also because it makes every change of plan feel like an error that is painful and dramatic, when in reality, it’s just the cost of operating in this environment.

One final note on the subject: for every action there’s reaction, and if we want to steer towards effect, we need to follow up on our initiatives, and tweak them until such time that we get the outcome we’re looking for. My personal observation is that a fixed priority road map tend to move people away from the “outcome” mindset into the “output” mindset, where it doesn’t really matter if we get the outcome we want, as long as we get the output. This is where we check of activity goals and feel content with that, but the effect of the initiative is ignored or forgotten.

When it comes to the question wether X needs a fighter jet or not, that depends entirely upon our findings when we scan and make sense of our surroundings. If we from our understanding of our environment decide that we do not need this speed and responsiveness, then we can downgrade our fighter jet to a more slow moving vessel, and gain the value of increased predictability. The choice is yours. Choose the vessel that you think will take you to your destination.

In the context of situational awareness, it’s also worth mentioning that in order to get the full benefit of a very responsive development process, X’s ability to regularly scan the internal and external environment, make sense of these signals and subsequently form a path forward, must be in good shape. If we are sluggish in gathering- and making sense of new information, then we are not getting the full value of a very responsive development process. That would be like trying to pilot a fighter jet whilst taking the occasional nap. In this setup, the brain must always be switched on. And so, this process demands a lot from us, and it’s hard work, but there’s really no way we can fly a fighter jet on autopilot.

A few words on predictability

Freezing the backlog for a set amount of time would give you predictability in the sense that you would know the sequencing of the work items (A will be processed first, then B and only after that C). The other aspect of predictability concerns the size of the work items. We can only get this information from the estimates that the developers provide. Estimates consist roughly of the parameters size and complexity, which equals effort. To get an estimated time of arrival, we need to add the parameter “capacity”. This is all notoriously difficult.

If we feel we need “better estimates” we would first have to ask ourselves what we might do with the information. How would that information help us in our decision making process and/or planning? Without an answer to that, we should stand down on that initiative. If we do know what we might do with such information, we would have to invest in it. The investment consists of two parameters:

A) time from developers (cost of their time)

B) the associated opportunity cost (cost of delay of the value we are currently delivering, as developers talking about future work is not delivering started work)

Suffice it to say, we get what we pay for. Now, there’s a sweet spot to be aimed for to do a sensible amount of estimation. This is the point where any extra investments in better estimates no longer gives a healthy return of investment on the additional time spent.

Any dialogue with developers about estimating a work item start with the question “OK, what is it that we’re going to build? What should it do? What are the specifications?”. This is reasonable, as we need a certain amount on information to be able to assess the effort involved. And so we find ourselves again trying to find a sweet spot, this time regarding specifications. We know that detailed specifications more often than not will be changed or discarded, and often we need the help of developers to write these specifications.

To sum up:

A) High uncertainty in the specifications will give us a low confidence level in our estimates. We could be off by a mile.

B) High certainty in the specifications is expensive to attain, will most likely not lead to the best outcome, and the value of the estimates we get does not justify the additional ost.

This is one of the reasons why our current process have a “discovery phase”. During this time boxed period we expect the teams to:

A) Figure out what do to together, and build shared understanding.

B) Write specifications together and find the sweet spot regarding detail.

C) Provide estimates that lies within our acceptable error margin.

D) Move the work item to the state of “Ready for Development”.

As the discovery phase is time boxed, the investment is highly predictable in terms of both calendar time and cost.

Our process in relation to prioritization, strategic goals and OKR’s

We have established a prioritisation model that evaluates initiatives based on the extent we believe the initiative takes us towards our company wide strategic goal. That means that for us, “value” is identified to mean “most impact towards strategic goals”. These strategic goals are identified by the Management Team, and it is also the Management Team who choses the planning horizon.

If the Management Team changes the planning horizon and the strategic goals, our priorities would change accordingly, but our prioritisation model would stay the same. This tight coupling between strategic goals and development efforts is usually a desirable trait, and it highlights the hight impact the strategic choices we make have on our development. It therefore becomes very important to continuously evolve and improve the process by which these goals are set.

It is unknown to me how the Management Team set our strategy and strategic goals, but we do know that these goals have historically been communicated in the OKR format. The great benefit of the OKR format is that they give us a qualitative goal and the measurable outcomes that we believe will take us towards that goal. The other benefit the OKR’s are supposed to bring is that teams get involved in setting their own goals and subsequently their actions, which can lead to increased buy-in and accountability.

Historically, the way X has used the OKR framework has been suffering from one critical defect: OKR 101 says that each team should be able to deliver on their OKR’s independently. This has not been the case at X. It goes without saying that when the OKR’s of one department cannot be reached without help from other departments, critical dependencies and sometimes even conflicting goals, are there by design, built into the structure. This is not surprising, as the value stream cuts across our organisation, no matter how we choose to slice it. Looking closer at the tech department in isolation, we find that the team boundaries are not clear enough to make good use of team specific OKR’s. This is because the underlying structure is not clearly bounded either, and the teams are not staffed to solve all their team specific missions autonomously. This reality must be taken into consideration when choosing our process for cascading and aligning our goals.

Looking at our company wide backlog, it’s currently – rather tellingly – populated exclusively with cross team work items. Consider this: Would politically valuable initiatives such as “A”, “B” “C” and “D” be discarded if they did not emerge naturally through any team’s OKR process? Or would they somehow find their way in there anyway through some “process backdoor”? The question is rhetorical.

This tells me that with the current organisational situation and structure:

A) Cascading OKR’s can not be the only goal setting process in the organisation.

B) Given the above – should we choose to use OKR’s – we would need to find clear decision rules to resolve conflicting priorities.

C) Should we choose to use OKR’s – the goals must be possible to reach independently and autonomously for each team.

One final word on OKR’s is a word of advice: processes benefit from being adjusted to fit our reality, simply because it’s a very tall feat to adjust our reality to fit our processes.

Leave a comment

Your email address will not be published. Required fields are marked *