Creators vs. optimizers: why strong engineers underperform in the wrong seat

What you’ll learn

• Why strong engineers underperform when the work doesn’t match what energizes them

• How team needs shift from 0 to 100 to mature products (and why hiring doesn’t adjust)

• What happens when you sell “fast-paced innovation” but need production stability

• When to stop coaching and start reconsidering the seat, not the person

A VP of Engineering we know hired someone brilliant. Senior engineer, strong track record at a high-growth startup, with glowing references. Three months in, the engineer was visibly frustrated and underperforming.

The VP’s first instinct was to manage performance. Weekly check-ins, clearer expectations. and more coaching. None of this helped.

Here’s what was actually happening. The engineer loved building new things. Think greenfield projects, rapid iteration, getting something from zero to shipping fast. But this company was evolving. The product was live, customers depended on it, and most of the work was maintaining existing systems and fixing bugs. Important work, but fundamentally different from what energized this engineer.

This wasn’t a performance problem. It was a mismatch.

The engineer wasn’t bad at maintenance work; they could do it competently. But they didn’t love it, and that showed up everywhere. They dragged their feet on tickets. They got bored quickly. Within six months, they were gone.

The VP made a common mistake: treating all strong engineers the same. Hire someone talented, give them clear direction, and they’ll succeed. But people aren’t fungible. What energizes one engineer drains another. And if you ignore that, you end up with talented people doing the work they hate, which means everyone loses.

The pattern most leaders miss

Some people are energized by building new things. Give them a blank canvas and ambiguous requirements, and they thrive. They move fast, iterate rapidly, ship “good enough” and improve it later. Once something is built and stable, they get restless.

Others are energized by making existing things better. Give them a system that’s running well but could be faster, more reliable, better documented, and they’re in their element. They care about edge cases, test coverage, and long-term maintainability. Constant change and instability frustrate them.

We’ve seen this pattern across other roles too, not just engineers. Product managers who love discovery versus those who excel at execution. Designers who thrive on exploration versus those who like to perfect systems. Operations people who build new processes versus those who optimize existing ones.

Most people can do both. This isn’t about rigid capability boundaries. A strong engineer can build something new and maintain it. The question isn’t whether someone can do the work, it’s will that work energize them or drain them over time?

And “energized” isn’t just about happiness. It’s about sustained high performance. When someone is doing work that fits their preferences, they bring proactive problem-solving; they think two steps ahead, they take ownership beyond what’s explicitly asked. When someone is doing work that doesn’t fit, they execute competently but nothing more. The difference compounds over months.

This shows up in hiring all the time. A company posts a role for a “senior engineer.” They interview someone who was amazing at building a product from scratch at their last startup. They get hired and their new team places them on a mature team where most of the work is developing incremental improvements and providing production support. Six months later, they’re gone, and the company doesn’t understand why.

Neither scenario is about capability. It’s about matching people to work that fits what energizes them. And because most leaders don’t think about this systematically, they keep making the same hiring and retention mistakes.

How needs shift as products evolve

Here’s where the mismatch happens most often. Companies evolve but hiring strategies don’t evolve with them.

In early stages, when building from zero to something, teams need people who thrive in chaos. Requirements change constantly. “We’ll fix that later” is a valid decision. Speed matters more than polish. You need engineers who can build fast, iterate based on feedback, and ship things that aren’t perfect yet.

But once the product is live and customers depend on it, the work changes. Now bugs affect real people. Downtime costs money. Reliability matters. The backlog fills with maintenance requests, fixes to edge cases, performance improvements, and this adds to existing requirements like monitoring, and writing documentation.

Most companies don’t adjust. They keep hiring the same profile fit for a “fast-paced, innovative environment” even though the actual work has shifted to production stability and incremental improvement. Then they’re surprised when people who thrived in the early days start leaving, or when new hires struggle to engage with the current work.

The pattern repeats in reverse too. Mature companies decide to launch something new. They hire people who are great at maintaining stable systems, then ask them to build a prototype in three months with ambiguous requirements. The engineers are capable, but they’re uncomfortable. They want to slow down, plan properly, and build it right the first time. The company interprets this as “not moving fast enough” when really it’s an archetype mismatch.

The Hiring Honesty test

One of the clearest signs that this matters, is that companies routinely misrepresent the work in job descriptions.

They say “fast-paced, innovative startup environment” when the actual job is maintaining a mature codebase and ensuring production stability. They say “cutting-edge technology” when the stack is five years old and the work is incremental improvements. They emphasize “building from scratch” when most of the work is fixing technical debt from the original build.

This isn’t ill-intended. Everyone wants to sound exciting and attract strong candidates. But it backfires. You attract people who are energized by the work you described, not the work you actually have. They show up expecting one thing, encounter something different, and leave frustrated.

The better approach: be honest about things. If it’s maintaining production systems with high reliability standards, say that. If it’s rapid prototyping with frequent pivots and low polish, say that. The right archetype will be excited. The wrong archetype will self-select out.

This also forces you to confront something uncomfortable: maybe the work you have doesn’t match the people you want to hire. If you’re a mature company with stable systems, you probably need more people who love optimization than people who love creation. If you keep hiring builders and losing them within a year, that’s not a retention problem; it’s a team design problem.

What to do with this

When you recognize this pattern, the answer becomes obvious: don’t try to force people into work that drains them. Put them in work that energizes them.

If you have someone who loves building new things, give them new things to build. Maybe it’s a new product line, technical initiative, or a greenfield project within your existing platform. If you don’t have that work available, be honest about it. They’ll probably leave for a company that does, and that’s better for everyone than pretending the mismatch doesn’t exist.

If you have someone who loves optimizing systems, give them systems to optimize! Explore functional areas like infrastructure, security, performance, and reliability. Let them make the existing platform better instead of asking them to prototype something that will change tomorrow.

And if your product is at a stage where you need both new features to build and existing systems to maintain, design your team structure around that reality. Put people who love creating on the work that requires creativity. Put people who love optimizing things on the work that needs reliability. Don’t force everyone to rotate through both and assume they’ll all be equally engaged.

This connects directly to how we think about the Position Blueprint. When you define what someone should obsess over, you’re creating intentional tension between different people who care deeply about different goals. A product manager obsessing over user outcomes, a designer obsessing over craft and usability, and an engineer obsessing over reliability will naturally pull in different directions. That tension produces better outcomes than having everyone agree on everything, but only if people are in roles where they’re energized by what they’re asked to obsess over.

When you’re hiring, be clear about what the work actually is. Don’t just define the role, make sure you specify the type of work. If it’s mostly maintenance with occasional new features, say just that. If it’s rapid experimentation with frequent changes, say that. Let people self-select based on what energizes them.

And be careful not to use this framework to excuse mediocrity. “I’m a builder, not a maintainer” isn’t a valid reason to write sloppy code or skip documentation. Both archetypes should demonstrate the core traits that predict success, like ownership, judgment, collaboration, and learning agility. They just express those traits differently. A builder takes ownership of shipping quickly. A maintainer takes ownership of long-term quality. Both are valuable. Neither gets a pass on doing work poorly.

High-performing teams aren’t built by hiring good engineers and hoping they adapt. They’re built by putting the right people in the right seats to do work that energizes them. Sustained high performance requires energy and engagement, and those only come from doing work that fits.

If you’re building a team and want help thinking through what archetypes you need, or if you’re struggling with performance issues that might really be archetype mismatches, reach out. We’ve spent years helping companies navigate exactly this type of challenge.

‍