Conway’s Law for Product Organizations

Conway’s Law is an old but useful idea: the organizational structure of software development teams is reflected in the code that they produce. For example, creating a “platform” development team and an “applications” team will typically lead to a Platform API. And arguments about whether interesting modules belong to one group or the other (“our team gets to build it” vs. “the other team gets to do the fun stuff”). The technical architecture grows to look like the org chart. In broader terms, how we group people and delineate teams has a real impact on the products we produce.

I find this concept useful when making product assignments. Product managers (like all of us) think most deeply about the parts of the problem we’ve assigned to them. They naturally see their portion as important and think mostly “in the box” that we’ve given them.

Imagine, for example, the Director of Product Management for an e-commerce solution who aligns her 4 product managers with the 4 development teams covering (a) buyer experience and workflow, (b) pricing, check-out and financial transactions, (c) seller sign-up and reporting, and (d) scalable platform architecture. What should she expect?

• Deep thinking “inside the boxes.” The product manager and development team covering buyer experience (or whatever) quickly become experts in their area. They eat, drink and dream consumer workflows. They focus more on their part of the solution, less on company-level goals. No surprise that each of the four teams has its own backlog stretching well into next year.
• Implicit resource allocation. By staffing up four specialist teams intended to stay together for the medium/long term, we’ve defaulted into putting 25% of our technical energy against architecture, 25% against seller-side tools, etc. Imagine the pushback if we have a strategic need for all-hands-on-deck scalability work for the next quarter. Our Director of Product Management may have a mutiny on her hands — both from senior engineers and product managers. Why should other teams set aside their urgently needed UX improvements or seller portal upgrades when they will only be half as efficient at scale-up improvements?
• Technical/political problems along team boundaries. Predictably, the pricing team attributes declining purchases to problems in the consumer workflow, and the workflow team blames it on inconsistent price lookups. The two development teams become mutually suspicious, and their product managers feel duty-bound to take sides. Seemingly rational technical explanations just happen to support each side’s emotional position.
• Double-counted revenue. Product managers know that every major effort needs some ROI justification, even though consumer purchases can’t be completed with (only) architecture or (only) a thoughtful user experience or (only) pricing engines. Each product manager sees his portion as very valuable… and builds business cases based on that belief. So we often overcount the impact of improvements. Each team attributes revenue growth to its work, and forecasts more of the same.

What’s a product executive to do? Our Director tears down walls. She keeps her product managers cross-trained: brainstorming in each other’s little boxes (and outside the larger box). She pushes for intellectual honesty and realistic business justification. She finds opportunities to promote the greater good: occasionally mixing up assignments, sharing successes across artificial product boundaries, and encouraging her development-side peers to do the same. Sometimes she has to settle sticky cross-border issues that her individual product managers can’t negotiate on their own. Occasionally, she demands re-allocation of work across teams when strategy runs headlong into real-world problems. She is the next-level-up arbiter.

All of this requires anticipation. Our heroine knows that organizations must have some division of labor. And that every division of labor creates the potential for narrower thinking, boundary skirmishes, and inefficient resource allocation. So she’s constantly providing broad context and watching for problems. Pulling her product managers back up to the bigger picture. Applauding anyone who admits that some other team might have a great need for that next incremental hire. Getting out ahead of the problem. Being savvy about organizational behavior.

And (of course) this happens at every level. Product Line Managers use all of their scarce resources to promote their own product lines — and don’t share. Business Unit VPs re-assign people within their BU but never willingly give up staff to other BUs. Executives leading cross-business-unit initiatives need carrots (resources and revenue credit) as well as sticks (frequent proof of progress) for their initiatives to yield any results.

So regardless of your level, you need to remember how your piece fits into the greater whole. Watch for misaligned or overly narrow decisions. Promote cross-border thinking and reward systems among your product and development peers. Peek outside your box.

Sound Byte

Having a narrow product focus helps us be more productive and expert in our areas. It’s easy to get overly specialized, though, and lose perspective. Periodically, we have to hoist ourselves up to think about the customer’s end-to-end problem and whole solutions.