Speed vs stability: the divide between product and engineering

The urgency gap

Over the last few months, I’ve sat across from product leaders and engineers in different companies and they all told me the same story: a frustration from product managers and the leadship team about lack of urgency in dev teams and whether they truly care about the company’s success.

Product leaders and managers are super eager to deliver new features and to fulfill commitments to customers, but feel that the development teams are slow and don’t care if a feature gets pushed. “Why don’t the engineers feel a sense of urgency? They don’t care if a feature gets delayed for weeks!” “It feels like they don’t care about the success of the company!”.

AI didn’t create this problem, but it exposed it even further in these times of AI-hype, pressure, layoffs and a volatile market.

Speed meets hero culture

For years, there has been a lack of developers. Even junior (or not very skilled) engineers have been able to enjoy high salaries, lots of job opportunities and often a very relaxed work atmosphere.

The lack of tech knowledge in other roles meant that code was magic, performed by developers entrenched in a hero culture, who didn’t need documentation because they knew how it worked. For too long it has been possible to say “Oh this will take time, it’s complicated” and never get pushback. That changed when PMs started using AI tools to generate features in hours instead of weeks and suddenly questioning why this was supposed to take weeks, when they could do it in hours.

The strong agile movement led to lots of companies doing “kind of agile”. Lack of planning and structure and a minimum of estimates and a disdain for deadlines. Agile coaches laughed at estimating a feature or setting a deadline – that’s impossible, you never know! Well intending engineering managers tried to protect their teams from burnout. But there’s a difference between being open about risk (“We might hit an edge case”) versus just refusing to commit because it’s more comfortable that way.

Instead, some teams spent their energy on unnecessary debates over design details, reworking the same thing five times, sneaking in refactors (sometimes valid, sometimes not), social bonding and long discussions about a teammate’s home renovation — all under the banner of “Culture is Everything.”

Some companies prioritized a nice work atmosphere or conflict avoidance over actual delivery. Making sure that people can do their best work is very important, but something got lost along the way.

So yes, there has been a lack of urgency in too many teams that haven’t been delivering at a good pace. Too often, teams built their own tech castles — far from reality and deadlines, while other departments and stakeholders have grown impatient watching features slide into “future roadmaps” forever. But this is not the whole truth, and the responsibility is a bit more complex than that.

What you care about and what gets rewarded

For a product manager every new feature is a gold star, something to brag about and get appreciation for. For an engineer every new feature means more maintenance, more support questions, more complexity for all future work, possible tech debt. You know that you will need to fix future bugs, answer support questions and take this new feature into account in all future work for years to come. Despite this, engineers love to build new features.

In product “speed” usually means making great decisions and launching faster than your competitors can react. But for engineers, speed often means shipping something fragile and handling the burden later. Every new feature means more work in the future, especially when nobody asked for it again or realized how hard it became to support after launch. And sometimes those “cool” features are actually just tech debt disguised as innovation. Engineers dream about writing the perfect bug-free code that will never cause them any problems, so they can build new things without the burden of maintenance.

As a product manager, revenue manager, or CEO, you’re supposed to care about:

• Making the customers happy, solve their problems
• Have great ideas for new features, products or business opportunities
• Get more customers and find ways to make more money
• Make the company more profitable and successful
• Deliver lots and lots of cool features

As an engineer you’ve supposed to care about:

• The technical choices you make
• Writing quality code, solving problems and building cool things
• Making the systems maintainable for a long time
• Being an expert on your teams ownership and knowing the code base
• Being up to speed with new technologies and tools, trying them out
• Making the systems smarter, more efficient, more scalable

As an engineer you probably don’t have as much contact with customers/users as a product manager (or the CEO). As an engineer you probably very seldom get feedback from revenue/customer success about what features made a difference for the customers or made them choose your company. As an engineer you very seldom see exactly how the thing you built helps the customer day to day. You never get rewarded or appreciated for the customer reactions for the features you built – that usually goes to the product manager. Depending on the company the engineers might not be part of deciding what to build and why at all, just how to build it.

Your main reward is your salary and your day-to-day experience and learning. Even in companies with stock options for employees, they seldom mean any life changing money if the company succeeds. You’re usually better off investing your money in the open stock market. So, pushing out lots of new features in hopes of making profit for the company, so you get a few extra bucks from your stock options in five-ten years, compared to having a good working environment, and a solid code base that is maintainable and easy to work with… It’s not even a choice.

What will you brag about in the future?

When you look for your next job, what will you brag about in the interviews?

Product manager:
That great decision you made: How you came up with a great problem to solve, a great solution, how you made customers happy. How your idea turned profitable.
The big change you made: That new cool product strategy or idea that made all the difference. That problem you solved once and for all. How you owned every part of it from idea to delivery, proving your impact.
How it went: The features you delivered, the problems you solved for the customer, the success of your product area. How well your latest company did, preferrably because of your product area.

Engineer:
That great decision you made: Using that smart technology/tool. Solving that annoying tech problem.
That big change you made: Refactoring that old system and using that solution/tool to make it so much more efficient - that was brilliant.
How it went: The solid solutions and systems you built. How bug free and maintainable it was. The new technology you learned super fast. Was there a bug you spent weeks debugging before realizing your architecture was wrong? In engineering, failure teaches faster than success ever does.
For an engineer it doesn’t matter if they come from a company that lost customers and failed (unless it was because of a big technical mistake/breach), that was most likely outside of your control.

Manager or CEO:
That great decision you made: That new strategy and risky bet that made it all worth it. That new business opportunity or cost cutting your made that made all the difference. Or maybe it was a desperate pivot that saved the business.
That big change you made: That big re-org and restructuring that made the company more efficient. That new product area that made millions.
How it went: The success of the company. How that strategy paid off. How many new customers we got. How you made the company more profitable.

Why are you here?

There are some companies and products that engineers are genuinely excited about. I think many engineers would be incredibly proud of working for Gitlab or similar companies and being part of making cool features that other engineers all over the world will use.

But lots of companies have products that are not super exciting for an engineer, and not fun to brag about to your friends. These companies and products still need to exist and still need to attract and hire engineers. It might be a great product for someone in a different role and industry than you, but the product is not what makes engineers want to work there, even if it serves customers well. It’s probably something else: great benefits, a great company culture, working with cool technology or tools, learning lots of new things, a nice office with a good hybrid setup, work-life balance, nice colleagues. This is not wrong - I don’t know how we would find engineers for some companies otherwise.

If your main reason for being at a company are the benefits, what you’re learning, and your day-to-day experience, you might not be super excited about new customers, care about beating the competitors, or get super motivated to release features that you know will mean a headache later on, even if that excites your customers.

Why speed and stability need to be shared responsibilities

This conflict I describe in this post is not new but AI exposes it even further right now. Engineers have a toolkit to build new features in hours instead of months. But it doesn’t reduce cognitive load, eliminate complexity, or guarantee maintainable code. Some teams are slow because they haven’t learned to say no, others are fast because they built systems that actually last.

Product managers:

• Stop treating engineering as a “delivery function.” Start treating engineers as a strategic partners in ownership.
• Talk early and often about what assumptions they’re making, where risks lie, and how future maintenance could break things, before you ship anything.
• Have real conversations and include them in customer discussions and let them see their impact clearer. Do they even get the positive feedback from users/customers? Help them understand the users and customers and get their appreciation.

Company leaders:

• Don’t expect every employee to care about the company as much as you do. Try to understand why they like working there and what could be improved.
• Stop rewarding speed metrics alone and reward stability too, not just profit margins or customer acquisition.
• Celebrate teams that continuously ship without breaking anything. Let engineers see that their decisions matter long after launch.
• Some teams aren’t building fast because they lack urgency, maintainability, or are drowning in tech debt. Other teams aren’t building fast because they don’t feel included in decisions and lack motivation. And some are building fast because they can combine speed with stability and can see their impact. Try to understand what is true for your teams.

Engineers:

• Avoid hiding in the tech castle. Spend more time understanding other roles in the company: what does it mean for them to not be able to tell customers when a new feature will be released?
• Have the honest conversations and try to understand each other. Build trust by explaning and fulfilling commitments.
• You probably became an engineer because you love solving problems, get genuinely interested in the end users and try to understand their perspective and situation.
• Learn to describe the return on investment on technical initiatives – your product manager and engineering manager can help you. Will the team be able to develop 5% faster if you can get rid of that pile of tech debt or fix that infrastructure pain?

Engineering managers:

• Stop acting as a shield that absorbs pressure from Product. Your role isn’t to hide the business reality from your engineers or the technical risks from Product; it’s to translate them.
• Make sure that the team has honest conversations with the PM so they understand each other. Have conversations on estimates and deadlines, even if the answer is “we don’t know yet” rather than letting agile become an excuse for ambiguity.
• Reward not only clean code, but also shipping stable features that move the business forward, make sure that the team can see their impact.
• Help (and push engineers) to spend time talking directly with customers and end-users, so they understand their users day-to-day and how the team’s features solve real problems in a way that matters beyond code.
• Help teams explain technical investments as a form of business intelligence — specifically by translating the ROI into measurable time, cost savings, and risk reduction that leadership already understands.

If we can start communicating better with each other and truly try to understand each other’s perspectives we can start collaborating for real. We need to stop viewing speed and stability as competing priorities and instead start treating them as shared responsibilities, so we can start building something great together.

This blogpost is written by me, and all opinions and spelling errors are my own.