Thoughts on managing programs in “product-mode” (aka “tech”) companies

Luiza Nunes and James Lewis wrote a nice article back in 2020 called “How to manage a program in a product-mode organization”.

Quick summary

• “Product-mode” companies are set up such that there is less coordination required across teams/areas;
• However, there will still be cross-area programs that do require coordination;
• Key patterns: invest in a program kick-off, adjust the leadership style, manage the dependencies and risks, develop a strong communication strategy, invest in information radiators, have a “solution champion” (aka program manager)

Some thoughts…

“product-mode company” is clearer than “tech company”

Luiza and James use the phrase “product-mode company” rather than the more typical “tech company”. This more clearly highlights that the important distinction is not whether the organisation is a “tech” organisation or not but whether it is structured more for Products vs Projects.

Product vs Project is a “pick your poison” issue.

Product-mode makes it easier to accomplish things within the product boundary BUT makes it harder to accomplish things across product boundaries. There is no “perfect-mode” that makes everything easier.

Program Kickoffs, Conquer and Divide, Think It Squads.

Luiza and James list several target outcomes for “project kickoffs”:

• Align all stakeholders on what needs to be done
• Define ways of working
• Socialize context
• Clarify motivations, roles, and responsibilities
• Highlight risks, dependencies, assumptions

Beyond using a Program Kickoff (I knew these as “Inception” or “QuickStart” when I was at ThoughtWorks), I also like using an initial discovery team to achieve these outcomes (see Conquer and Divide). Spotify called these Think It Squads.

Without looking, the largest risk to any program is probably integration.

Without looking at the specifics, I’m willing to bet that the largest risk in most programs is integration, that is ensuring all the different pieces worked on by the various teams actually work together.

Integration tests and milestones are more trustworthy than status reports.

I trust whether integration tests are passing or failing more than I trust reports with red, yellow, green status. One of the key practices that should exist for most programs is a set of interim end-to-end integration milestones to provide trustworthy checkpoints of progress.

Anticipate dependencies by studying historical blockers.

If you want to understand what dependency (aka potential future blocker) risks are worth paying attention to, study historical blockers from previous programs.

Thanks to Troy Magennis for this insight.

What is an effective virtual equivalent to a physical program wall? Honestly, I don’t know.

I have yet to experience a virtual approach to visual management / informative workspace that is anywhere near as effective as the physical version. I’d be interested if anyone has.

Solution Champions, Chief Engineers, Product Champions, Entrepreneurial System Designers, Technical Program Managers

“We believe that the discipline of program management is crucial to ensuring success when any initiative involves the orchestration and coordination of multiple teams to deliver value.”

Program management doesn’t necessarily require a distinct position, but someone needs to fill the role. If programs happen often enough, it’s likely that a distinct position is needed.

Luiza and James suggest the title “Solution Champion” over “Program Manager”. I’ve also seen “Chief Engineer” (Toyota/Lean), “Product Champion” (Poppendieck), “Entrepreneurial Systems Designer” (Kennedy), and “Technical Program Manager”. “Technical Program Manager” seems to be the most popular term used in the tech industry at the moment.