MS
Writing

Do Engineering Managers Need Technical Skills? What Google's Project Oxygen Found

In 2008 Google set out to learn what makes a great manager, and technical skills came last of eight. Why that still holds in 2026, why it doesn't mean what people think, and what the job looked like across two companies and four products.

By Maksym Shykov, Engineering Manager10 min read

In 2008, Google set out to learn what makes a great manager. When the results were published in 2011, the list had eight qualities. Have key technical skills, so you can help advise the team came last.

I came back to that list by a roundabout route. At a recent interview, a C-level executive told me why she had invited me, even though she doesn't usually invite engineering managers with a QA background: the reactions to my LinkedIn post about leaving Headway. Several colleagues had written that they recommend me as a manager, and for her that said more than anything on my CV. It made me think about what the job of an engineering manager actually is.

A disclosure first: I'm looking for an engineering manager role, so I'm not a neutral party. What follows is my experience and my opinion. The research is Google's and LeadDev's, and I include the parts of it that argue against me.

What Project Oxygen found

Project Oxygen started because Google wanted to know whether managers mattered at all. They did, and the useful part was which behaviours separated the best managers from the rest. The first version, published in 2011, had eight. Coaching came first and technical skills came last.

In 2018 Google revised the list to ten by adding two behaviours at the end: collaborating across the company and making strong decisions. Its current re:Work guide (August 2025), built on more than 10,000 data points about Google's managers, lists them like this:

  1. Be a good coach
  2. Empower the team without micromanaging
  3. Create a team environment that values everyone
  4. Focus on productivity and results
  5. Communicate effectively
  6. Support career development and discuss performance
  7. Implement a clear vision and strategy
  8. Have key technical skills
  9. Collaborate across Google
  10. Make strong decisions

Technical skills sit eighth there, but only because the two new behaviours were added after them. The ranking that put technical skills last is the original one.

Two caveats, because this result usually gets quoted without them.

It shows what separates good managers from great ones, not what doesn't matter. Google's managers were already technical. When everyone in the pool clears the bar, the bar stops explaining the difference. Technical skill is the entry ticket, not the edge.

It is one company, and it measures perception. Google's engineers rated their own managers. That tells you what they valued, which is not the same as what every product company needs.

In July 2026 Google's Chief Learning Officer argued that teams need a transparent learner rather than an all-knowing leader. It's an essay, not a study, and it cites no data, so I read it as a direction rather than as evidence.

The 2026 data points the other way

LeadDev's Engineering Leadership Report 2026, based on 600 responses, found that the share of engineering managers doing more hands-on technical work than a year earlier rose from 20% to 35%. The report ties this to AI lowering the cost of turning an idea into working software.

The 2025 DORA report, from nearly 5,000 respondents, found that AI amplifies what a team already is: it raises delivery throughput, but also instability, and it exposes the bottlenecks in review and testing. Somebody has to see those bottlenecks, and that takes technical literacy.

So the answer is not technical skills don't matter. They are a requirement, and AI is making it cheaper to reach that requirement and to keep up with it. What stays scarce is the top of the Oxygen list: getting a group of specialists to move in one direction.

What the job looked like in practice

In four years as an engineering manager I've worked across two companies and four products: Setapp and Setapp Mobile at MacPaw, the Headway app and Goodly at Headway Inc. I didn't plan it and I hadn't read a framework for it, but the most important work was the same each time, and it was rarely in the code. It was in how the engineers worked with the people around them.

MacPaw, Setapp. One Friday I was the engineers' peer: they built a feature and I tested it. On Monday I was the engineering manager of nine of them. My goal for the probation period was to keep the team together. Some of the engineers were going through a hard stretch at the time, and it showed in their work. I agreed with the product side that communication with the engineers would go through me, so they could spend their week on engineering, and I gave the team a goal to rally around. Everyone stayed. Within four months we were estimating our work and hitting those estimates.

Headway, Foundation team. I took the communication with the business onto myself and explained the business in plain terms: what we were building, what success and failure looked like, and how to decide when two options competed.

Goodly. The engineers worked directly with the general manager of a young product that had to move fast. I took over that communication, as I had at MacPaw, and translated in both directions. After about six months I had positive feedback from both sides. The engineers had become product engineers: they shipped features across iOS, Android and backend, and looked into product questions through analytics and data before proposing what to improve.

I call the role glue: absorb the friction, translate in both directions, and tie the engineers to a goal they understand. None of it required being the best engineer in the room. All of it required the first items on Google's list.

Specialists, not copies

When the best mechanic in a racing team is put in charge of the garage, nobody has to teach them how an engine works. But someone else turns the wrenches now. Their job is the people, the plan, and getting the car out on time.

The same goes the other way. A mechanic who knows the gearbox better than anyone understands what the whole team is for: the car has to finish first. That goal gets broken down and handed to each department. Nobody expects the gearbox specialist to also design the sponsor campaign.

Companies drift into that expectation as they grow. In a team of ten, everyone does everything. In a company of fifty, you hire a marketer, a support lead and a customer success manager precisely so that engineers stop answering support emails. Expecting every engineer to think and work like a founder at that stage is a mistake: if everyone did, they would be running their own companies. The manager's job is the bridge. Take what the business needs, explain how the business works and where it's heading, carry that to the engineers in a form they can act on, and carry their constraints back.

I saw the same structure much earlier. In 2009 and 2010 I was a junior aircraft design engineer at ANTK Antonov in Kyiv, in the department responsible for the pilot's cabin. When an instrument went out of production, someone found a replacement and redrew the instrument panel around it. The drawings then needed signatures from 9 to 12 other departments before they reached the workshop. Nobody in that chain was the best at everything. Each department owned its zone, and the aircraft flew because the system worked.

Growth is offered, not forced

One part of the job I'm deliberate about: I help engineers grow, but I don't push growth on anyone for its own sake. If an engineer wants to move forward, I help them find the work, the feedback and the opportunity to do it in our context. Making ten or twenty people develop because development is expected isn't management. A manager directs and helps. Engineers who are happy being very good at what they do are not a problem to solve.

Why so many engineering manager roles now say hands-on

More and more companies want an engineering manager who is close to a tech lead and writes code for a large part of the week. Part of that is the AI shift the LeadDev data describes. Part of it, I think, is that a manager's effect on a team is hard to see. A manager costs a lot per month and seems to spend the day talking, while how much faster the team got is a number few companies track.

I write code, and I'll keep doing it: a lot of it at Goodly, and more now that I work with Claude, at work and on side projects. But the must have is a team that closes hard problems quickly without breaking production. For a team of ten I'd rather find a senior engineer to be the tech lead and own the technical decisions, while I take everything that isn't engineering: processes, stakeholders, blockers.

The test is the critical path. A manager who reads the diff has credibility. A manager who is the team's delivery bottleneck is an expensive engineer who isn't managing.

What technical skills are for

If technical skill is the entry ticket, here is what it lets me do:

  • Read the diff and judge the trade-off instead of taking it on faith.
  • See where AI-generated code piles up in review and testing.
  • Know when a decision belongs to the tech lead, and when it's mine.

It doesn't make me the strongest architect on the team. It makes me someone the strongest architect will talk to.

If you hire engineering managers

Test for what separates them. Five questions I would ask:

  1. Tell me about a team you took over during a hard stretch. What did you change first?
  2. When did you last remove something from an engineer's week that wasn't engineering?
  3. When the team and the business disagree, how do you decide?
  4. Whose growth are you responsible for, and what did you do about it that wasn't a training budget?
  5. What's the last technical decision you gave away, and why?

Frequently asked questions

What did Google's Project Oxygen find about technical skills?

In the original 2011 list of eight manager behaviours, have key technical skills came last; coaching came first. Google's current list has ten, with technical skills eighth because the two newest behaviours were added after it.

Does that mean engineering managers don't need to be technical?

No. The study shows what separates great managers from good ones, and every Google manager already cleared the technical bar. Technical skill is the entry ticket, not the edge.

Are engineering managers coding more in 2026?

Many are. LeadDev's 2026 report, based on 600 responses, found that the share of engineering managers doing more hands-on technical work than a year earlier rose from 20% to 35%, which it ties to AI lowering the cost of writing code.

How do you improve how engineers and product work together?

Put one person in between. In my case, communication ran through me, the engineers got their week back for engineering, and the team got a shared goal. It showed in the results within about four months.

Sources