MS
Writing

Should an Engineering Manager Push Engineers to Grow?

Most managers don't even offer growth. My rule: I set the bar and I offer the path. The difference between the two, three engineers, and who decides when the risk is real.

By Maksym Shykov, Engineering Manager11 min read

In LinkedIn's 2025 Workplace Learning Report, only 15% of employees said their manager had helped them build a career plan in the previous six months. That is down five points from the year before. The top barrier to career development that respondents named was managers lacking support: 50%.

So it may be an odd moment to say this: I don't push engineers to grow. I set the bar, and I offer the path.

Those are two different things, and most arguments about pushing mix them up. This post is about the difference.

A disclosure first: I'm looking for an engineering manager role. This is how I work, and it is my opinion. The numbers come from LinkedIn and Gallup, and I include the parts that cut against me.

In short

  • The bar is the results and standards the business needs. Setting it and holding it is the manager's job, and it isn't optional.
  • The path is where an engineer wants to go next. It is theirs: the manager offers it and makes it real, within what the business needs.
  • When the business needs a skill, it stops being an offer. Risks go to the people with the authority to accept them.

The bar is mine. The path is theirs.

My rule is short. The bar is the results and standards the business needs. It is my job to set it, say it clearly, and hold it, and it is not optional. The path is where an engineer wants to go next. That one is theirs. If an engineer wants to move forward, I help them find the work, the feedback and the opportunity to do it in our context. If they don't, I don't invent a goal for them.

Making ten or twenty people develop because development is expected isn't management. A manager directs and helps. And engineers who are happy being very good at what they do are not a problem to solve.

Not forcing is not the same as not offering

This is where the rule is easiest to misread, including by me. I don't push can quietly become I don't bother, and that is exactly what the LinkedIn number describes.

Offering is work:

  • Asking, regularly. Not what training do you want? but what do you want to be doing in a year? I write the answer down.
  • Making the options visible. Engineers can't ask for an opportunity they don't know exists on this team.
  • Creating the opportunity when asked. A goal without a real chance to practise it is a setup for a failed review. I wrote about how to turn a goal into a plan in the PDP article.

LinkedIn's report names managers lacking support as the biggest barrier, ahead of employees lacking support (45%). If offering were free, that gap wouldn't exist.

Project Oxygen, the research I wrote about in Do Engineering Managers Need Technical Skills?, puts coaching first among Google's manager behaviours and career development sixth. Coaching means asking questions that help someone see their next step, not assigning the step.

Within the business frame

Asking is not the same as saying yes. The answer to what do you want to be doing in a year? is bounded by what the business needs. If an engineer wants to learn a new programming language or build games, and that doesn't serve what the company is doing, I won't approve it as work. I'll still ask the question, and I'll be honest about where the line is. An offer that pretends to be unlimited is worse than a limited one that is true.

The frame works in the other direction too. When the business needs a skill, it stops being an offer. The clearest case I've had is below.

The bar is not optional

Offering growth does not mean lowering expectations. What good work looks like, and what the business needs from it, is the manager's job to set, make clear and hold.

Goal-setting research points the same way. In their 2002 review in American Psychologist, Locke and Latham found that specific, difficult goals generally led to higher performance than do your best goals. The effect depended on ability, commitment and feedback, and performance leveled off or declined when ability limits were reached or commitment to a difficult goal lapsed. That supports setting clear, challenging goals and giving feedback and support. It is not a case for pressure for its own sake. Research links abusive supervision, meaning hostile behaviour by a manager, to poorer employee well-being and stronger intentions to quit; evidence on actual turnover is more limited, and the link with performance varies across outcomes and study designs. A high bar is not abuse, and abuse is not a high bar.

The founders famous for relentless pressure are a story, not data: we see the companies where that style worked, not the ones where it didn't. What they have that you can copy is the bar. What you can't copy is their ownership.

Three engineers

The one who asked. She came to me and said she wanted to become a senior engineer, and asked how to do it in a year. I proposed a six-month plan in the PDP format. The goal was not a promise to show senior competencies later but a report that proved part of them were already visible in daily work. First we took the middle-level competencies and checked that all of them showed up consistently. Then we took the senior ones and looked at which showed up and which didn't, and for each gap, why. The answers became the plan: the work was arranged so the missing competencies had a regular place to appear. Every month we met and looked at which tasks she had done and whether they matched senior competencies. At the end of six months there was a report with the work and the progress, and she was promoted to senior.

The one who didn't. A middle engineer, good at his job, who was comfortable where he was. He wanted more money and had room to move, but for several years he did not want the larger scope and harder problems the next level meant. The company was happy with his work and nobody raised the question of pushing him to senior. For the first three years, what he asked of me was to leave him where he was. Six years later, he is a senior. For the company, his choice cost nothing: he did exactly what the role needed. For him, it cost money and time without growth, and that was his choice to make.

The time help wasn't enough. In 2023 I hired an engineer and six months later I let him go. In the first three months he didn't do the basic work of the role. He explained the theory well and understood what was expected of him, but he did not do it. He passed probation on the argument that it had been a hard period in his life and that now he would show what he could do. Two months later, he got one more month to deliver results. He didn't, and we ended the cooperation. Nothing I did, involvement, kindness, understanding, support, saved him.

I made two mistakes, and the first was at the hiring stage. Three people interviewed him at the final round, and two of them said no. I said, I'm not sure, but I'll try. They told me he would be on my team, so it was my decision. I decided, and I lost.

The second mistake was waiting. The signals came early: after two months he still hadn't set up an environment to run the automated tests, and he spent part of a workday at a training session of his own. I was advised to let him go at the end of probation. I didn't, because I didn't want to admit I had been wrong. It ended when someone from another team told me he had failed on a task, and once I had a reason I couldn't argue with, I decided in a day. I should have decided on the signals.

Since then I follow two rules: if I'm not sure, I don't hire; and when the signals are there, I say so out loud the first time, not the third. I got this wrong early in my time as an engineering manager. Saying so isn't weakness. Not saying it is.

Whose risk is it?

There are two kinds of risk in this work, and who decides depends on whose it is.

Risk to the engineer's own growth, such as skills aging faster than they used to. Standing still is less safe in 2026 than it was, because the way engineers write and review code is changing quickly. My job is to name the change I see in their work, show where it touches what they do, and offer a path. The decision is theirs, within the business frame above, and not now is an acceptable answer. I ask again later.

Risk to the business, such as a process that won't survive its own success. Here the rule is different, and I'd put it like this:

The business says what we are going to do. I weigh the risks and discuss with the engineers what has to be done and which options we, as an engineering team, can propose. The final decision is taken by the team, if it has the authority to take it, or we bring it to the decision makers and they choose the best option.

Put as a rule: the manager's job is to make the risk visible, bring it to the people with the authority to decide, and create the conditions to reduce it. The engineer's job is to assess the technical options and recommend a response. The residual risk is accepted explicitly by the person who has the authority to accept it.

Two examples.

A process that wouldn't survive its own success. We kept launching new localizations in a product, not often, but each time with too much manual work: iOS and Android, new locales in the backend and in the internal admin panel (the UI for configuring the site), legal documents, the website. I pointed out to the engineer who owned it that if localizations became more frequent, we would drown in manual work. He proposed the solution himself, and we automated most of it. I made the risk visible and he owned the answer.

A direction the company set. When I joined the Goodly team in April 2026, the company was pushing hard for an AI-first approach: everyone should use AI, and the company was moving that way. This was not an offer. I told the three engineers that we either move with the times or we don't, and I drew the boundaries: what was expected, and what could happen if we didn't move. The how was theirs. Within three months all three had switched to writing code through agents, and had prepared the context the agents need: documents, rules, skills. By August 2026, all three wrote almost all of their code through AI. Every change that went to production still passed a human code review.

Both follow the same rule. The risk was named, the decision was taken by the people who had the authority to take it, and the engineers worked out how.

Frequently asked questions

Should a manager force an engineer to develop?

No. A manager can offer, create opportunities and remove obstacles. Forcing growth on someone who didn't ask for it rarely changes what they do and often costs trust.

Is it a manager's job to push?

On the bar, yes: setting clear, demanding standards and holding them is the manager's job. On the path, no: where an engineer wants to go next is theirs, and the manager's job is to offer it and make it real.

Is not forcing the same as ignoring development?

No. LinkedIn's 2025 report found that only 15% of employees said their manager helped them build a career plan in the past six months. Not forcing means the engineer chooses; it still requires the manager to offer and to make opportunities real.

How should a manager handle an engineer whose skills are going stale?

Make the risk visible without turning it into a target. Name the specific change you see in their work, show where it touches what they do, offer a way forward, and respect a not now. Return to it later.

Who decides when a risk to the business is real?

The people with the authority to accept it. The manager makes the risk visible and creates the conditions to reduce it, the engineer assesses the technical options and recommends a response, and the residual risk is accepted explicitly by the person who has the authority to accept it.

Sources