Update! I will be running the next iteration of How to Run an Effective Prioritization Activity on Thursday, December 12th, at 8AM PST (US), 11AM EST (US), and 4PM (16:00) GMT. Registration is now open. https://maven.com/s/course/272d87a145
In this post, we're going to discuss work "shape" mix and why it matters. As with most things, this is an oversimplification, but let's imagine three broad buckets of work:
Large, complex projects
Extensive dependencies across multiple teams and departments. High coordination costs. Require project and program management. A significant investment in time, energy, risk, and capacity. Project-based funding focused on project phases. ROI is considered on a project basis, with investment framed in time and materials. Risks include premature convergence, building bridges to nowhere, missing market window due to delays,
Independent product work
Teams are more autonomous. Iterative/incremental development focused on more stable outcomes and problems. Aligned with company strategy and high-level objectives. Teams operate as internal companies, not startups, as in zero-to-one efforts (see below). Accounted for through models like independent budgets, cost centers, internal P&L, capitalization, etc. Key risks are getting stuck at a local maximum, accumulating too much debt and stalling, or failing to shift as the market and/or strategy shifts.
Zero-to-one efforts
Building something new—resembles an internal startup. A mix of close executive attention (due to strategic importance) but operate best in a somewhat siloed environment. Milestone-based funding is similar to how VCs invest in a startup—smaller initial allocations, with additional rounds contingent upon reaching strategic milestones demonstrating viability. Key risks include either pivoting too early or not pivoting at all and squashing creativity because of the politics involved in high-profile innovation.
This model in no way captures the complexity of product work at scale—whenever I've done work shape activities with teams, we end up with 15+ shapes—but let's run with three for now.
As a startup grows and scale into the company, and as the company grows and scales into a bigger company, you tend to see a shift:
We start with 0-1 work across the whole (very small) company. Then, very early on, you start mixing in org-wide projects (e.g., Launch the Thing). Over time, you hopefully see the emergence of independent product work. That emergence isn't a given, by the way—some teams stay in ad-hoc chaos mode. And then, as dependencies, friction, drag, etc., increase, we see an increase in the % of large, complex projects. Some of this is inherent—bigger companies have more moving parts—and some of these changes are self-inflicted. You even see an uptick in 0-1 work at a certain point because siloed efforts are the only way to innovate.
The first 🔥in the diagram is an interesting place:
Things are getting harder. Before, you could throw people at the occasional large, complex project and treat it as a one-off. That is no longer the case.
Generally, as a company, you want things to be easier again! You don't want to overreact and deal with the 🔥by institutionalizing a new approach to work. At the same time, teams are struggling and need support. There is a push-pull between accepting and dealing with the new reality and trying desperately to turn back the clock somehow.
Pull things together, and you put out the fire. Let things slide, and you drift into 🔥🔥 and beyond. But this is much easier said than done because the drift can be hard to detect, and there are many ways to persuade yourself that it isn't happening.
The 🔥is a messy potential inflection point.
By the time you get to the 🔥🔥🔥s, things are dire. These companies either go under or are forced (in their mind) to implement heavy-duty processes that institutionalize the mess while banking on some kind of transformation.
It is very difficult to wind back the clock to the goal state:
Why is any of this interesting or important?
In all but the most trivial and small organizations, you will balance multiple "shapes" of work.
You will repeatedly find yourself in situations where you must choose between formalizing some new reality or being patient and allowing some pain/friction/confusion until the problem hopefully disappears. Put another way, while you will always be juggling multiple shapes of work, you can choose whether to formally acknowledge the different motions or decide instead to let things get messy.
There is a critical window during which you have a decent shot at preventing a slide, but navigating this window is a skill.
If you miss this window, you will have a heftier transformation/shift on your hands.
Here's another interesting thing to consider. In some companies, you see a dogged insistence that teams are independent. Everyone is incentivized to work independently, and no one wants to touch the large, complex projects. So you see something like this:
Eventually, the organization's lack of alignment catches up with it, and it hits a wall. At that point, it either keeps the same motion (but is better aligned), or perhaps the org chart is off, forcing it into large, complex projects.
Some questions to consider:
When does the independence of teams become a barrier rather than a benefit?
How do you approach supporting teams through a challenging transition where you must 1) convey that you're actively working to address the problem and don't endorse the status quo and 2) realistically acknowledge the current situation to support them?
How can a company know when it's better to let a small amount of friction or pain remain unaddressed rather than implement new processes to resolve it?
In your career, what signs have helped you distinguish between normal growing pains and more systemic issues that, if left unaddressed, could lead to entrenched problems?
Why might a company choose not to formalize its approach to a significant portion of its work, even if doing so could provide structure and clarity?
I hope you found this interesting!
A worthwhile exercise in any organization is to step back and identify 3-5 distinct "work shapes" that truly reflect how work gets done in your environment. A work shape is essentially a set of variables that shape how teams approach their projects, manage risks, secure funding, and allocate resources. Taking the time to define these shapes gives you a more honest view of your organization’s dynamics—and a clearer path forward.
Hi John! Would love to be there at the Maven session. However the link I click on says bad request. Can you please reshare?
Hi John, in the Now > Goal graphic you have an additional item: "Platform/Enabling", which is not mentioned in the text. Can you explain this a bit, so that I can check my mental picture? Thx