Several years ago, I refuted common thinking and made the case for preferring product engineers over principal engineers. As someone who was almost always capable of coding circles around anyone else in the room, I realized that what genuinely mattered was the ability to do the right thing for the business, not just be busy and use the latest and shiniest tools. The last few years’ “gold standard” has rotten. If you’re content with the status quo of tech for tech’s sake, you’re complicit in mediocrity. With the shift in our industry, it’s becoming clearer that the best engineers are not only product-oriented but also profitability-minded. Here are the principles to achieve that mindset.

First Things First

While industry titans built empires with scrappy, lean teams, most organizations are bloated with engineers chasing vanity metrics. This is probably an example you’ve heard, but it’s extremely relevant in this case. Instagram and WhatsApp had hundreds of millions of users when they were acquired, and only a dozen or so engineers. We’re talking about teams that had several native apps, a complex backend, and all before the “easy” days of cloud infrastructure. In some ways, Telegram is doing the same today. Edit: After publishing, I came across this tweet with some remarkable recent examples. Contrast that with your team, that might have even more engineers and is handling nothing as complex or close to that scale, right?

Profitable engineering is key for creating remarkable teams that deliver genuine impact. Life’s too short to lead mediocre teams, and the principles in this “manifesto” should help you manifest (pun intended) the right culture.

Outcomes Over Outputs

Hopefully there’s no need to start by stating that managing R&D based on inputs is completely wrong. When you are concerned about hours of butts-in-seats, you’re not likely to get anything remarkable out of the team. Outputs are better, but they’re not enough. In my work, I regularly come across teams that output everything that was asked, yet are not making any real progress as a business.

If you’re still patting yourselves on the back for moving Jira tickets, you’re merely celebrating busywork—not progress. Instead, profitable engineering organizations work in empowered teams together with their counterparts from Product, etc. These teams should receive desired business outcomes to achieve, and tailor their approaches together to get there. They measure success by business impact rather than hours logged or features shipped.

Appetites Over Estimates

Consider the following familiar flawed flow of features (try saying that fast three times): Product wants something done.
The relevant engineering team provides an estimate, with perhaps a bit of back and forth about scoping. They then go off developing this feature based on the time estimate given. However, when things take longer (and unfortunately that is the case in the majority of teams), things are “carried over” to the following sprint. Essentially, we can find ourselves investing much more work in a particular feature than the business would have wanted. This is all backwards.

Contrast this with the “appetite” approach, introduced by 37 Signals. Each major feature starts by setting the business’s appetite for it. Things are completely different when we start by being deliberate about how much effort a problem is “worth” and then come up with possible solutions that fit that time budget. 37 Signals goes a step further and does not allow things to “roll over” from one sprint to the next. The time limit here is placed at the right time, invoking the creative effect constraints have. Work is much less likely to become unprofitable if we boxed it from the get-go. Estimates are the comforting lies that keep teams complacent. Instead, set a business appetite and force creativity within real-world constraints.

Prioritization Over Fixed Budgets

Clinging to fixed ‘engineering time budgets’ is a crutch for teams too timid to prove their worth. Real profitability comes from challenging every assumption—even tech debt, which isn’t debt at all. When teams use these, engineers immediately slide from being profitability-minded to tech-obsessed.

Instead, even these changes and work ought to be prioritized with Product. That means that we’re accepting the responsibility to make the business case for tech debt work, and can no longer tackle it for the sake of our preferences. If a microservice is using older conventions, but is not expected to be changed at all in the next year, does it really make sense to refactor it? I’ve explained this concept at length in this series.

Valuable Innovation Over Hackathon Hype

The word “innovation” is thrown around easily, often without any real significance. Your hackathons might look nice on LinkedIn, but what impact have they really achieved that lasted after the hackathon was over? So often these are merely tech-debt-fests, or entail innovation that doesn’t really matter. I mean, that bot you created to tell whether the food delivery has arrived is cute, but is that driving any business impact?

Making innovation habitual and profitable requires embracing intermissions and focusing on tech capital (both explained at length in the free sample chapter of my book here). When we prioritize experiments because we can make the case for how, if they succeed, they will improve something in the business, we greatly increase the odds of cultivating valuable innovation. Hackathons have become little more than PR stunts—flashy events that yield temporary buzz but little lasting value. True innovation is born from disciplined, purpose-driven experimentation.

Org Growth Efficacy Over Vanity

Lastly, years of ZIRP have contorted so many companies’ thinking about org structure, and inculcated generations of engineers wrong. We see teams grow automatically, without thinking about the value the business ought to achieve by that growth. We raised funds, and now those ought to be “deployed.” Excessive organizational structures are created, like executives managing a single person, useless nano-teams, and more (see the organizational smells mentioned here).

Instead, you want to create highly profitable engineering teams, like the aforementioned Instagram. These are teams where growth in engineering is aligned with commensurate growth in business value generated (new product lines, faster go-to-market strategy execution) and not just in making any change more bureaucratic with the air of “seriousness.”