I’ve been mulling this for a while, recently prompted by thoughts from Josh Robb and Amy Nguyen.
Many infrastructure development teams don’t have a product manager, or have a fractional product owner/analyst working primarily on detailed technical requirements. That forces an architect or senior developer to manage a range of responsibilities they are not interested in, and perhaps not qualified to handle: sorting conflicting business priorities; internally “selling” the value of architecture and specific improvements; tying technical decisions to quantitative business metrics; lobbying for increased staffing versus other teams; motivating developers with real-world examples of how their work matters to end users.
Said another way, great development teams want to work on great technical problems. But these never arrive gift-wrapped or fully defined or conflict-free or with clearly articulated business value. So two observations:
All very theoretical, so let’s construct an example…
Imagine that we’re at a medium/large ecommerce company with 90+ developers and mission-critical back-end infrastructure. We’ve formed a dedicated infrastructure development team to look after buyer profiles (name/address/PII, order history, payment info, marketing preferences) and buyer analytics (transaction logging, engagement stats, demographics, lifetime value, campaign response rates). The team’s overall goal is to streamline and standardize buyer information, especially for scalability and consistent reporting and privacy management. Our “direct customers” are other product/development groups responsible for shopping carts, order status, recommendation engines, marketing campaigns, and legal compliance.
Inevitably, most of the following will arise:
- Conflicts among internal consuming groups about this team’s priorities. The Recommendations team and Shopping Carts team each has a two-year backlog for Infrastructure, and each (of course) wants their list handled first.
- Where’s the infrastructure boundary? Our architect drew a beautifully symmetric diagram of RESTful microservices, including only the universal profile attributes she thinks fit into this layer. Meanwhile, the Order Status team needs some geographic delivery history which they expect will be of general use to all teams. So technical leads fall into a philosophical argument defining “infrastructure” or belittling each other’s academic credentials. The underlying issue, though, is that neither team has bandwidth, so each constructs technical arguments for why the other team should do the work. (“That’s really an application-level issue, not an infrastructure problem.”)
- What our common end users need/want, versus how each application teams interprets end user needs. For example, the Shopping Cart team wants the fewest number of required fields for payment (“faster checkout!”), while the Recommendations Engine team wants multiple payment options per user for its highlighted deals (“AmEx-only product discount”). Potentially mis-aligned goals, with each team presenting its demands as technical specs. So the Infrastructure team must decide when to force standardization; when to branch codelines; when to force design collaboration around a unified customer experience; and when to let application teams go their own way. If we simply do what each group demands of us, we create more confusion and too many data representations. This smells as much like politics as architecture.
- Executive interrupts. Once our leadership hears that we’ve formed an Infrastructure team, they will each have just a few ideas for the team to estimate and schedule. (“What if we use machine learning to suggest payment method based on ship-to-address?”) And our Infrastructure team will be thrown into hot partner/customer situations. (“Sephora will use our platform if we can support their 460k SKUs in our recommendations engine. Go figure out if we can do that, or what it would take.”) Collectively, the exec team wants 200% of every team’s capacity.
- Alignment with broader strategy. The company wants to expand into Europe, which requires some essential GDPR infrastructure. But our current (North American) marketing team could boost holiday engagement with some fixes to our purchase history API. What’s the right blend of short-term and long-term investment?
- Context/economic analysis tied to user behavior. Our team complains about lack of context and unclear value quantification. Uninformative tickets come in from the Order Status team demanding “faster response times on the shipping cost API,” which doesn’t help us understand the real need or success thresholds or business value. Our Infrastructure team is hungry for more context, such as “our users abandon shopping carts as wait time to display shipping costs goes beyond 3.5 seconds. If we can shorten that by 0.3 seconds, we can increase conversion by 3-5%. That’s $6-10M/month.” We won’t build exactly the right thing – or get excited about doing it – unless we have the bigger picture.
- Supporting multi-team initiatives. Most big efforts require collaboration and shared priorities across several teams. The product managers on these teams do a lot of horse-trading and joint business justification to get things done. Lacking a product manager on our Infrastructure team, complex decisions are made without Infrastructure’s representation.
And so on.
Note that technical teams tend to think of these inevitable conflicts in purely technical terms: if we could just define “infrastructure” more precisely, and get our consuming teams to attach exact economic value to every request, we could accurately compute the priority of everything and work only on the most valuable stuff. (Hint: honest differences of opinion, unconscious bias, personalities, sales pressure, misaligned incentives, developer optimism, and wildly inaccurate value estimates mean that spreadsheets are insufficient.)
And remember that we didn’t hire anyone on the development team for expertise handling these kinds of questions. (Don’t believe it? Look at your Engineering job descriptions and interview process for experience negotiating cross-team product priorities.) So developers who have to catch these issues will (a) do it poorly versus someone who is tasked/trained/assigned/prepared to do product management; (b) resent having to do it; and (c) will expend much more time/energy. We’re constantly complaining about talent shortage and drains on development productivity — canceling periodic meetings to save 30 minutes/week — yet we toss untrained/unwilling engineering leads into choppy organizational waters.
But this is a lot of what product managers at larger companies do. So it’s easy to see how a competent PM immediately makes her team 10% more productive. Which, by the way, pays for her salary. With the side benefits of a development team that’s happier, more focused, has fewer interrupts, and has clearer context for their work. (Listen carefully, and you’ll hear “lower turnover of key engineering staff.”)
A strong product manager will have the team working on more of the most important stuff. So company goals and broader strategy stuff gets done better/sooner. I’d suggest that good product management delivers 35%+ more strategic value and actual outcomes from each team, versus forcing technical leads to do their own politicking and cross-team prioritization. Ergo: a product manager assigned to each infrastructure team is worth 2-4 developers.
Sound Byte
Development teams and their product managers solve adjacent, but different problems. If a work stream is important enough to merit its own development team, then it’s important enough to assign a product manager. Together, we solve for what needs doing and how to gracefully get it done.