Inlining engineering investments.
An engineering team’s first responsibility is to support a product roadmap, but to do so effectively over time requires making investments in the engineering team itself. Without these investments, the customer has a worse experience, morale is dampened, and productivity drags.
Yet so often priorities are viewed in a zero-sum context: if we pick up work to improve developer tooling, it’s at the immediate cost of a new feature. Stakeholders haggle for time on the roadmap — which is to say, they jockey for access to fixed resources.
One solution is to build discrete, specialized teams to cover topics of interest. Say a few product squads working alongside a team dedicated to developer tooling. This model can work and even scale well for a while, but there are tradeoffs to acknowledge.
The first cost is cost in the literal sense: you need a much larger team to support the division of work. It’s intuitively obvious: if you want more work done, you need to hire more people. And of course it doesn’t just mean more engineers; you need more product managers, project managers, designers, engineering managers, and so on.
But there are more insidious costs.
Specialized teams by their nature have a harder time grasping the big picture and shared goals of a growing organization. Engineers may see their narrow lane of responsibility but lose comprehension of the adjacent work. If one team is upgrading build tools, are they aware of another team’s interest in moving to a new CSS utility framework?
Siloing means much deeper investments need to be made in communication and coordination.
Another cost is the way specialized teams tend to influence overall complexity.
Most engineers will build right up to the outer bound of whatever their mental model supports. In other words, if the scaffolding I bring supports construction of a ten-story building, I will build all ten stories, not one or two. Or the classic example in project management: give a team ten weeks to complete a project and they will find a way to use all ten weeks.
While specialized teams have the luxury of a narrower field of view, they are of course constructing pieces of much larger system. Those complex small pieces bind together, causing aggregate complexity to balloon over time. Overhead cost will continue to grow alongside that system — things like documentation, training, maintenance, or rewriting how systems interoperate.
Create advocates before creating silos.
At my first startup, we established a “testing advocate” and a “security advocate” — two individual contributors who had a passion for their respective topics and excelled at communicating with the team. Their primary responsibility was not to write the most tests or fix the most vulnerabilities. Instead, their explicit role was to train others on the team how to write effective unit tests or demonstrate best practices in application security.
In addition to individualized training, they led team workshops and partnered with leadership to inform roadmaps to improve tools or recommend outside vendors.
We avoided organizational complexity by creating a culture and shared understanding of these values. As the saying goes, culture scale better than process.
On a startup these advocates can stand in place of building out a dedicated team. On a larger or more traditional, advocates help build bridges of communication between teams.
Position investments as a “how” when roadmapping.
I always chuckle when I hear product managers and engineering managers arguing about percentages of time.
“Could we have 10% committed to writing tests?”
It always feels like a pleading or a defensive posture. It also assumes, perhaps for simplicity’s sake, that 10% is the right number today and should work down the line too. The truth is, priorities ebb and flow.
Some initiatives are indeed discrete pieces of work that have a time cost. But try to think of engineering investments more strategically. Instead of asking for time in a sprint toward writing unit tests, build and foster a culture of writing tests, then account for this as a higher cost of completing approved product work.
Before you think this is about manipulating a product manager, consider the inverse. What would happen if we consistently neglected to do necessary work? What would be the cost for knowing what it would take to ship high-quality, bug-free, scalable code—but instead not doing it?
The bill always comes due, but when it arrives later its cost will be amplified considerably. Quality assurance cycles protract, customers experience degrades, and taking corrective action becomes more complex.
When we acknowledge the costs and pay them upfront, we reduce the total cost over time. Investing in our tooling, the scalability of our code, our unit tests, et cetera — they’re all intrinsic parts of delivering the feature roadmap.
Product and engineering are distinct disciplines, but they both face many of the same challenges. How do you rationalize a decision? How do you split your time? How do you think about long-term investments when you have one eye on the next sprint? How do you emphasize the importance of strategic work when delivering a feature feels so much more concrete and obtainable?
The answer may be to blur the lines, to inline the work. Know where you want to be over time and why you want to be there, then infuse the building blocks into everyday work. Avoid spring cleaning. Avoid laundry lists. Avoid viewing roadmap allocation as a zero-sum competition of priorities.
Make the good, rather than the bad, accrue incrementally. Define the work and then do the work, all the time, every day.