Productivity: It’s a product, it’s a program
Yes, good eng managers can learn on the job and wear many hats, but embedding product and program know-how early can save a lot of pain.
Before we get started …
Do you know anyone in Berlin who might be great to anchor a new front-end platform team? lmk.
I’m familiar with Swarmia, Jellyfish, LinearB, Okay, Allstacks, and some others. (No links because I have no horse in this race, yet.) Who are you talking to in the devprod-as-a-service space?
Camille Fournier wrote about Which Meetings Should You Kill, which spawned an interesting Twitter thread from Marco Rogers. I have such mixed feelings on this! Like I say in the thread, empirically the argument is sound but I really worry about the impact on belonging. See the thread for more.
A good read on the legalities to keep in mind if you’re capturing data about how developers spend their time.
Productivity: It’s a product, it’s a program
Two roles have been top of mind for me these last few days: product manager and program manager. I’ve had a lot of occasion recently to recognize and reflect on the unique value of both roles: product, to look at the problem sideways, identify opportunities for non-incremental change, and figure out how to measure it; and program, to look at the problem upside down and backwards, using their relationships and deep network to wrangle process and stakeholders far and wide while keeping an ear to the ground and the vision in sight.
Camille Fournier wrote the canonical post about product for internal platforms in 2020, and you should read it if you haven’t, before you keep reading this — it’s served as the foundation for most of my thinking on the topic. In her post, she talks about the challenges unique to internal tooling teams, and offers strategies for addressing those challenges. When I first read it, I thought it did a fantastic job of describing the cross-functional work that’s required for a platform to succeed. Only later did I realize that plenty of engineering leaders were trying to achieve this success without the benefit the … functions.
Implicit in Camille’s post is that internal platforms are products. I’d suggest that productivity is another product, built on top of that platform (independent of whether you call that underlying thing a platform or not, yet); and that productivity is also an eternal program, seeking to drive alignment, change, and accountability around the effectiveness of software engineers, which only gets harder as a company grows and evolves.
As the macroeconomic climate continues to exist in a very uncomfortable limbo, companies that employ expensive software engineers are looking for ways to make those dollars go farther, to make those engineers more productive. There’s a nascent but already-populous industry ready to meet the need with a bunch of tools to help spot bottlenecks in the develop-review-deploy cycle.
What these tools don’t tell you, though, is what to do about it.
At a certain small size (likely an engineering population smaller than 50, and perhaps the actual breaking point is even smaller than 30 depending on lots of things), when a tool tells you that code reviews are taking five days at the median, you can improve that with minimal process: agree as a group that it’s important, agree on some specific changes you’ll make like always reviewing PRs first thing in the morning, agree that you’re going to keep track of it, and shake hands or high-five or whatever.
Beyond that size, driving even “simple” changes like improving code review time can require strategy, relationships, and change management: exactly what [good] product and program managers do. You also may start to discover there’s increasing leverage in solving differently shaped productivity problems as you knock down that low-hanging fruit.
There’s an evolution of need here: once you’ve conquered the problems you can solve by agreement, you’ll likely move on to problems you can solve with engineering: for example, getting build feedback to engineers more quickly. As you solve those problems, over time, fewer of your productivity problems will be strictly engineering-shaped. Solving these new problems will require software engineering, probably, but the harder work may be in figuring out exactly what to build and how to get people to adopt it. This is product and program bread and butter.
If you’re having a hard time picturing this, here are just a few examples I’ve been around:
A tool that let country managers run experiments on different localization strings. This was built in consultation with the director for international product, who advocated for it; once it was up and running, localization changes could be tested and then released broadly, all without engaging with the software engineering workflow at all.
A platform that allowed individual product teams to autonomously control and experiment with the contents and behavior of a section of a web page, eliminating cross-team reviews and driving delivery lead times close to zero.
An initiative to standardize a disparate set of front-end applications, such that a single infra team could be responsible for core dependencies and capabilities, eliminating a large swath of support requests from product engineers.
A project to make PR auto-assignment context-sensitive, for example preferring in-region reviewers when available, and tracking the frequency of reviews that do not have an in-region reviewer, thereby meaningfully influencing org structure in pursuit of productivity.
If this topic is relevant to your interests, I’d love to chat — I want to learn more about the realities at different companies, and maybe you can benefit from some of my past experiences. I’ve opened up a handful of gratis office hours — if you’re interested, sign up here and tell me what you want to talk about.
In the meantime, BYOPPgM
(Be your own product & program manager)
If you’re on the eng side of the house and tasked with improving productivity, and you’re already surrounded by people who have these skills, you’re lucky. If you happen to fluently wear the product or program hat whenever that’s needed, I hope you are well compensated.
If neither of those things are true, two things: first, figure out who these people already are in your world and start talking to them about the problems you’re trying to solve to learn about the value their roles bring; and second, consider including some new types of questions in your own thinking until you can make the case for bringing on the people who know this stuff best. Questions like:
Who are our users? When is the last time we talked to them or watched them use the tools we build and maintain? Do our users know how to talk to us? Why do our users need to talk to us? Are we helpful when they do? What do they expect of our tools, and where are we falling short?
It’s two years from now and there’s broad agreement that everything is so much better than it used to be. What changed? What work do we need to do now to unlock or unblock that change?
What business processes (not just engineering processes!) frustrate engineers the most? Who owns them? Are you measuring their impact on developers, from interruptions to blockers? Are they ripe for change or automation?
Whose goals align with productivity? Whose goals could be perceived as competing with productivity initiatives? How will you make the most of the first group, while also bringing the second group along?
If you have questions about this that I can answer like some sort of advice column, hit me up in the comments, maybe I’ll even make a whole thing out of it.