I have been thinking a lot about burgers recently…
…
Well, not exactly. Specifically, I’ve been musing about how a burger can mean pretty much anything. As long as it has some form of a bun, a patty and perhaps a few accoutrements, it’s a burger. But to some people, a burger is the gourmet, multi-layered, artisanal creation you might find at exclusive, Michelin-star restaurants. To others, a burger is the quintessential, utilitarian, deliciously sloppy smashburger at your local mom-and-pop shop. Heck, I have even heard people argue that a hot dog is a type of burger (note: it is not). It makes you wonder though: when we say “let’s grab a burger” - are we even talking about the same thing?
Don’t fret. Today’s essay is not about burgers, and this has not turned into a culinary blog. Rather, I want to explore another topic that is dear to us, delicious to sink our teeth into, and similarly open to wide interpretation. It is about working out how product work actually works.
We are living in an era where our priors are being reassessed in real-time, both of our own volition and with AI now at the forefront - supercharging what’s possible, and scrutinizing what’s necessary. Some of us are excited and energized about this, while others of us are responding with some anxiousness or defensiveness. What makes these debates tricky is not just how much is at stake, but how much it requires a new level of legibility and alignment around how work happens that many orgs, teams and individuals are not accustomed to. We have so many organizational structures and norms to align strategies, articulate goals, make decisions, review artifacts and track deliverables. But we lack shared rhythms and language to build coherence on how the work must happen. What do we mean by taste or product sense? What is craft, and how do we develop it? What roles matter, when and how do they collaborate? Etc. And as a result, it often feels like we are spinning a bit: talking about “burgers” and expecting others around us - our bosses, our teams, our peers - to intuitively know what we mean.
Over a series of essays, I want to explore some elements of product work where these debates feel most fraught and consequential, as we reimagine (and sometimes rediscover) the essentials. Today’s first essay in this series is on a topic that is particularly dear to me: the value of specializations in our product work.
When I was applying for what ultimately became my first tech internship at Expedia, I was offered one of 3 roles to interview for -
Developer - the people who build the software. At the career fair, this was translated to us naive college kids as simply “programmers”.
Tester - the people who try to break the software, so we can fix it before users find the bugs instead.
Program Manager - the people who define the requirements, keep the team organized and communicate with leadership and “the business”.
That was it. At least, that was how the “tech team” was explained to me for my first time. Only after getting hired did I discover there were other types of people that I needed to work with closely to build and ship stuff: a centralized team of “web designers” who did all the cool design work, and had a very cool research lab that I’d visit as frequently as I could despite working on a backend product. A ragtag group of “SQL devs” who’d float around teams in an embedded/but not really committed fashion - who would spend their days performing data alchemy with SQL. And not to forget, a fiercely independent group of Ops and RelMan folks who would keep the site running, and be in charge of our then seasonal, monolithic, weekend-long code releases. These guys had a lot of street cred and mystique for working in physical spaces that looked more like data centers than offices for human beings.
I share this experience not just to date myself. But to point out that the range of specializations that are embedded into product teams today is a somewhat modern phenomenon that has emerged over the last decade or two. Even if the value of specializations in general predated that.
And like many of you, my mental model of what comprises a “tech team” has had to evolve and update along the way:
From “Product Management” → core product PMs, growth PMs, platform PMs, innovation PMs, monetization PMs…
From “Design” → product designers of many types, researchers of many types, content designers, systems designers, design engineers…
From “Engineering” → frontend engineers (web or native), backend engineers, platform and infrastructure engineers, security engineers, site reliability engineers, QA engineers…
From “Data Analysis” → data scientists, applied scientists, data and ML engineers, behavioral economists, quantitative researchers…
From “Operations” → product ops, design ops, research ops, technical program management, project management, release management…
The rise of specializations - and the corresponding expansion of product teams - did not happen by accident. In most cases, these roles and sub-roles emerged because our problems got harder, our work got more complex to build/execute/scale, and our understanding of the craft needed to build product matured over time. When you collaborate with experts from other functions, you are quick to realize all that you don’t know about their craft, and can appreciate how they augment your role in crafting a better product. When you have the right mix of talent and expertise, aided by a strong collaborative model, everyone levels up!
Now, we can take for granted that PMs come in different flavors, that the field of Engineering is complex and multifaceted, that Data Scientists are not just “SQL Devs”, that Designers not only deserve a seat at the table but are most influential in shaping & showing what’s possible, and that Research is a distinct craft that can make all other functions smarter and more empathetic in understanding users. But these ‘facts’ that we operate with today are derivative of years of lessons we have acquired about the nature of product work, and what has been a gradual unbundling of necessary skills and crafts across our industry over that time.
Specializations can add layers of contrasting textures and distinct tastes to a product team. But there is a challenge that comes with too many layers too.
Like the gourmet burger that looks great on Instagram, but is too big to take a bite out (without it collapsing on itself!), teams can become bloated too. Every specialist on the team is another point of alignment and communication within the team. Even if unintentional, each ‘node’ within a team’s ‘collaboration graph’ can become a bottleneck in the process of building and shipping product fast. Expertise has a price, and that price is coordination cost.
Additionally, when a team is comprised of too many specialists, it can become very easy and tempting for individual team-members to ‘stay in their lanes’, at the expense of the overall goals and velocity of the product. Specializations tend to become functions within organizations, and functions tend to become silos within teams. Combating that form of entropy is itself a skill of the best PMs and product leaders. As I’ve written before, they actively build systems and cultivate cultures within the team to address the layered complexity of product teams. This shepherding leadership skill has become more important over time, as teams have become larger and more diverse. But now, the ground is shifting once again.
There is a big appetite these days to shift to smaller teams, more generalist product builders, empowered by AI to ship faster. In my opinion, much of this appetite is not specific to AI at all; it is a reaction to the accumulation of the coordination cost to velocity of bloated product teams (and orgs). Especially in a world where AI has made coding - what we have always seen as the core ‘patty’ - feel trivial now. This appetite is relatable to any of us who have experienced our teams have to grind through a series of handoffs, multiple layers of alignment and approvals to ship anything in recent years. The impulse to smash the burger is understandable, and quite satisfying!
But I believe our mindsets must be stronger than that. Neither should we accept the status quo, nor should we flatten it all either. We should look to maximize the leverage our new capabilities offer us, and actively update our priors too. We should build on what we have learned, not discard it. Expertise always matters - and arguably matters even more as development gets cheaper - no matter how you might bundle or unbundle access to it.
I often say that the intent for my writing is to offer perspectives or principles - not prescriptions. My belief is that with that, you are better equipped to find the right solutions to your specific context or problems. So, to that end, I will close today’s essay with a few opinionated “how might we” questions that can help you navigate today’s topic better than before - for your product work and teams.
How might we color over the lines more than we do today, and encourage our teams do the same?
…versus staying in our lanes
How might we enable more diverse, cross-functional craft to be done by more of our people?
…versus giving more surface-level responsibilities, without enablement
How might we prioritize maturity & readiness of our talent in addition to structural change of our teams?
…versus putting too much stake into new structures doing the heavy lifting
How might we adopt a positive-sum mindset to how all functions work better and faster together than today?
…versus trying to replace or work around each other
How might we build new collaborative rituals & norms that raise the bar on our product craft, across all its flavors?
…versus simply hoping that craft can sustain at a higher pace than before
Have a question or musing of your own?
Feel free to drop a comment below, or DM me.
Enjoyed today’s musing?
Consider sharing with a colleague or friend who may benefit too.
Interested in more of Waqas’ Musings?
Find all my past essays at https://waqas-sheikh.com, and subscribe below 👇
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.