Maximal agency
In technology there are waves of progress: VPS’s replacing server rooms, dynamically allocated cloud computing replacing VPS’s, and cloud orchestration and serverless replacing EC2-style cloud compute.
There are also waves in the management of software teams. Six Sigma, extreme programming, BDD, agile (scrum, kanban…), SAFe (barf), lean, Shape Up – the list goes on.
I think we’re on the cusp of another wave. I like to call it “maximal agency.” Roughly, it combines the writing of folks like Marty Cagan, Teresa Torres and Jeff Paton. Plus, the growing canon of books showing the inner workings of the best product development organisations, like Working Backwards and No Rules Rules.
Maximal agency
All of these writers seem to share two simple convictions, that can appear at first glance to be in opposition:
- The conviction that people are their best when they are directing their own work, not following orders. Being instructed inhibits people’s creativity and tendency to take responsibility.
- The conviction that organisations exist to do massively ambitious things, sometimes spanning the efforts of thousands of people. That when we come together we ought to be greater than the sum of our parts.
These convictions imply two aims: high individual agency and high collective coherence. Achieving them both is not at all straightforward, but is the aim of the maximal agency model. It is easy to empower individuals to make decisions, but to wind up making many sub-optimal decisions. It is also easy to enforce collective coherence, but rob individuals of decision-making power in the process.
Simply put, we want our cake and we want to eat it.
Local optimums and global optimums
Say you tell someone to dig a whole six foot deep. When they’re one foot down, their spade hits a boulder.
Now, the local optimum path is clear: dig the hole somewhere else. It’s going to be a heck of a lot easier than moving that boulder.
The global optimum on the other hand isn’t clear at all. What if, for reasons of some grand plan, the hole is only going to be valuable if it’s dug exactly there? What if you’re one of ten hole-digging teams preparing the ground for the foundations of a new structure?
And yet again, what if there is no such plan, and the global optimum and the local optimum actually have the same path (move the hole)? We’d sure hate to move that boulder for no reason.
If you ask any software engineer, designer or researcher about their work, you will find that this whole-digging problem occurs multiple times a day for all of them. At its root, product development is a creative decision-making process that navigates a constant flow of new information. Decisions are typically high volume, of highly variable impact, and caused by something that’s only just been uncovered – i.e. you didn’t know you’d have to make the decision until bam, you do!
Pure global
Most large organisations, often unintentionally, solve the whole-digging problem in a simple way: they don’t give the whole-digger a choice. The decision about where to dig the whole is made so far up the organisational chain that by the time the whole-digger has hit the boulder it’s unrealistic to expect them to engineer a change of course.
Put another way: it’s cheaper to move the boulder than do the organisational work to revisit the decision about where to put the hole. For this reason, most organisations unknowingly and unnecessarily move a great deal of boulders.
Pure local
What about if we give the digger the decision? Clearly this will be fast, since there is little or no organisational wrangling to do. And it will be made in possession of more facts than an older decision would have been.
The problem, as we’ve already seen, is that without a great deal of extra knowledge, we might well make a decision which is good for us in the moment but bad for the organisation in the long term.
For example, say a team decides the product it is trying to build just has too many risks. The technology is unproven, plus it targets new customers who they don’t understand well. They decide to row back to a more pedestrian enhancement that they know will help existing customers.
There’s nothing intrinsically wrong with this decision. But most product portfolios balance riskier and less risky bets. That team’s position as an innovative moonshot might have made sense next to several much safer initiatives.
In such a model, it’s also uncler what if anything the point of leadership is. If everyone is autonomous, are organisational leaders just master craftspeople, responsible only for building the expertise of their juniors? Or is there more to it?
Management by decision-context
For self-direction and overall coherence to co-exist effectively, we need to distribute knowledge of the holistic goals and strategy. Every actor must be independently able to make globally optimal decisions.
In essence, we want every person, and every team, to make the decision that a perfectly informed CEO would make. This solves the tension between coordinating many teams and maximising self-direction.
Leadership in this context is not about task definition, but decision-context definition. There is an art to this, since it shouldn’t be necessary for every team to know everything – this would create massive unnecessary cognitive load. Instead, the problem needs to be decomposed into problems that can be satisfyingly solved autonomously.
Agency for teams and individuals in this context is “maximal” in the sense that they have the most ability to move the course of the company.
Continuous discovery
If task definition becomes primarily a matter for teams, not leaders, then teams also need the tools to define the best work to do. Continuous discovery is the process of deriving the optimal work to do to advance our goals. For that to work we need to distribute in the company the ability to find out what customers want.
In practice, this boils down to a systematic approach to customer research that doesn’t rely on particular very knowledgeable people (the founder, say) to be the wellspring of customer insight. Research becomes a backbone function, like infrastructure, that all teams call on constantly.
Designers also have a critical role. Prototyping is now so cheap it’s effectively free. In this world it is almost always easier to simply show what a team is thinking of building, rather than writing a long document (the long document may still be useful for “why” we are building it). Conversations with customers around these prototypes are usually much more interesting than discussions about pain points in the abstract.
Discovery is also providing an upwards information gathering function for the company at large. If we discover it is just too hard to dig holes in a certain area, we have the option of changing the overall plan. The team can do this together with leadership by agreeing to change their goals (which might involve adjusting the goals of other teams).
The focus on impact
When teams proceed by accomplishing tasks, they can also be evaluated in terms of tasks. But when a team is given goals, it can only be evaluated on impact.
Instrumenting impact measurement is still a non-trivial task for most companies. Outside of big tech, few companies invest in the infrastructure to make it easy for teams to spin up, experiment on and share metrics. It’s a worthy investment though, since once you have it it can be endlessly leveraged in all work by all teams.
Having an idea of the current state is necessary but not sufficient. Impact also has to be the currency of success in the company. You would think this would be common, but in practice politics and optics often outweigh impact when companies make progression decisions about individuals.
We can prevail over this risk by tying impact directly to the performance evaluations of individuals. When career progression and impact share a common incentive framework, we get a purer focus on doing the thing with maximal impact for the company.