Monkeynoodle.Org

Process is what people do, not what they say. In other words, what we say is aspirational, what we do is factual. If you describe what the people are doing now, you’ll be very successful in establishing a process for new hires to follow. But what if some teams don’t follow the same process, and you want to get everyone to follow the best process? If you want to make a change in what teams do, you have to work with the team to make that change happen and negotiate the trade offs. Buying a tool or consultant to drive process change is great news for that vendor but won’t do squat for your organization unless you’ve already adopted process that aligns with that tool and hired people who are receptive to that consultant’s ideas. If these conditions are true, a process and the tools to support it can have great unifying utility. A unified product operations process is especially attractive when the organization is growing and operating many products on a shared platform. If those conditions aren’t true, there are fewer reasons to bother: onboarding a new engineer to the product only happens once per engineer when there’s only one product. Why institute a product operations process where a page of documentation will do?

To unpack an assumption: “what is the potential value of a unified product operations process, anyway?” There’s two potential value targets that matter:

• Legibility. The number one driver of unified operations process is improved legibility, to executives, the field, the customers, and the marketplace. What solutions will we ship, when, and at what cost? If those are hard questions to answer, there’s demand for change.
• Fungibility. The other attraction of a uniform process across all projects is that effort will be more fungible. If the process is the same across all operations, developers will only need to adjust to local domain knowledge when they move from one operation to another. In this way, we can see that easy movement of the perfectly spherical developers across the frictionless vacuum of projects to be done can be attained.

As product leaders, we’re hoping not to have projects at all, but rather products: indeed, there’s a book about that. We fear that squads of developers jumping from project to project is a recipe for bad outcomes and Brooks’ Law. Still, the industry zeitgeist in 2023 is layoffs and recession, and that means doing all the jobs to be done with fewer people. Fungible resource teams are the kind of short-term benefit purchased with long term pain that is very hard to pass up in this environment. The act of reorganizing from the front-end + back-end + integrations horizontal team structure can also be a very effective table flip on a development organization that is growing sick (for instance, demanding a rewrite before new development can be addressed).

Another attractive idea in down economy is getting rid of supporting roles, such as the product manager. Marty Cagan suggests the answer is a new role definition and process. I think that’s a rebranding of product management, and probably a good idea if only to ease the linguistic challenge of “PM? Do you mean project or product manager?” Count the number of times you’ve said “project-I-mean-product” or vice versa in a week; it’s in the dozens for me. I think the real driver for that rebrand is not about labels though, it’s coming from a desire to reduce or kill the PM role. Things got done before Product Management, after all. In fact, some of the biggest and most impactful things humanity has ever done happened before PMs. Someone has to do the things a PM does, but it doesn’t have to be a dedicated role with this name. Since unifying the product operations process is typically done by a product manager, it’s certainly worth asking if that’s at all attractive to an organization seeking ways to eighty-six their PMs.

And so, we circle back to “what is the operational process by which product gets made” with new questions:

• does the organization really even want product?
• does the organization want a product production process?
• does that require people dedicating themselves to process?

Most software companies really do want technically sophisticated product, because the product has exponential revenue potential across many customers while projects only have linear revenue potential from the one customer that they fit. But wait, what if we could quickly write one-and-done projects that don’t need maintaining and then just sit in the marketplace exponentially collecting revenue? It’s a great dream, though I can’t think of a real world example of this model: from dinosaur financial models to PC shareware to phone apps, software must keep swimming or eventually die.

Operations process can be very useful to a group of functional teams sharing commonality between those functions (e.g. they’re all on the same platform (which is itself a product needing to be managed)). If the organization is instead a conglomeration of fellow travelers that don’t really have anything in common other than who writes the funding checks, then there’s not a lot of value to unified process either. In that case the actual ask is probably for legibility, so OKR and SLO are the engines to use operational and business metrics in.

Lastly, does the organization need someone to focus on process? I think there is a critical need for an executive leader to operate the planning process: as stated before, it’s about what people are actually doing, and a leader needs to lead the people in doing the thing. I am far less certain that a middle manager really needs to live in the process tools and ensure everything is being done correctly and legibly: this feels like delegation of the tedious bits rather than a functional addition of value. I’m not saying that there’s anything wrong with delegating work or doing that work for pay, folks gotta eat. Rather, I don’t think this sort of role is organizationally necessary: if the person doing it disappears, it will just be done by someone else.