Best advice I would have to give is to simply... be an engineer yourself before attempting to manage some.
The best engineering managers I've met were simply brilliant engineers, that inspired devs around them and starting managing without having the official tittle: folks would naturally come to them for guidance. The hardest part was to get them to accept that the scope of what they were working on simply went beyond one human's ability to code it himself. But I've seen them break out debuggers and debug issues right in the middle of meetings.
On the other hand, I've met handful of "career managers" that weren't qualified as engineers and, well, frankly they didn't understand the engineering and got no respect out of the organization. No wonder Nadella, Pichai and Cook are all engineers.
Maybes there's something in having to be brilliant in general but idk about this blanket statement. At least when I have had engineers turned manager as my manager, a lot of the time they seem to not be able to turn off the engineering. There's always something to tweak or be hands on with or experiment, except its not code they are messing with, but people. Our team structure, meetings, lets measure stuff, change our process etc.. and it ends up being a distracting drain. Engineers don't seem to be able to not mess with things. But maybe that goes with brilliant? Brilliant engineers know when to tweak and not to.
But that doesn't seem fair, yes brilliant people will always be good, you can't count on having brilliant people
> be an engineer yourself before attempting to manage some
I honestly think this is a luxury for a lot of companies that are trying to transform themselves into a tech company.
When I took time off from my first failed startup attempt, I ended up working for a fintech and it was obvious that a lot of the "tech managers" were not technical people themselves. The challenge for this fintech, which had close to 1 trillion dollars in assets, is they couldn't really attract engineering managers and they had to make do with the people they had.
This is why "engineering metrics" is currently gaining a lot of steam. A lot of managers and organizations are suddenly finding themselves having to manage techies and they are desperately looking for ways to compensate for the fact that they aren't tech people themselves. This is why when companies see solutions like GitPrime, GitHub Insights, and other similar solutions, they get very excited because they feel they found that magical translator that can help them better manage tech employees.
> This is why when companies see solutions like GitPrime, GitHub Insights, and other similar solutions, they get very excited because they feel they found that magical translator that can help them better manage tech employees.
If you promote people based on metrics from GitHub Insights you will end up with an awful organization. Employees are not stupid, they can manipulate any metric you use to measure their performance.
For example, if you promote the engineers that get the most commits, then people will conspire to delay code reviews so that only their friends get their commits merged in a timely manner. Or they will break their deliverables into an absurd amount of commits so that they get credited with the most commits.
> I honestly think this is a luxury for a lot of companies
No, it's not. The real luxury is hiring entire teams of capable people and then ask someone that has no clue about what's going on to tell them what to do. Not only it's a waste of time for every engineer, it's a waste of time for the engineers families and the education system that made their formation possible.
Learning about differential and integral calculus, differential equations, mechanics, electromagnetism, thermodynamics, discrete mathematics, theory of computation, compilers, databases, programming languages, data structures and algorithms, cryptography, information security, operating systems, networking, how to make a computer from scratch from logic gates, etc... only so that in the end you have to talk to a completely clueless guy that has no qualifications whatsoever but has "managerial soft skills" (psychopathic traits).
> they couldn't really attract engineering managers and they had to make do with the people they had.
How comes?
> A lot of managers and organizations are suddenly finding themselves having to manage techies and they are desperately looking for ways to compensate for the fact that they aren't tech people themselves.
There are now MBAs that are tailored specially for that [0]. If people think they can just eyeball it with "Engineering metrics", they should read this [1].
Politics, workers rights and so forth. You really can't just fire hundreds and potentially thousands of employees without cause. A lot of companies will have to provide a career path for many of these managers.
> If people think they can just eyeball it with "Engineering metrics", they should read this
I think we both know this, along with many people here at HN, but HN doesn't reflect what I've personally seen. I'm trying to advocate for "Developer First Software Metrics", which is what my tool is focused on, but I've had far too many conversations with potential customers that wants to sum up a developers worth with a simple chart.
In the business world, we don't assume business intelligence will come easy, which is why we hire business intelligence specialist. However for engineering metrics, this attitude isn't quite there yet and many and I mean many companies with non-traditional tech backgrounds want to believe they can easily quantify a developers worth with superficial metrics. Because in a lot of ways, they see developers like factory workers, where their unit of work can be easily quantified.
MBAs make companies less competitive. When American companies were led by engineers, American companies were #1. Now, thanks to MBAs and decades of emphasizing short-term vision, every major American company is being eaten alive by the international competitors they helped create.
Seems like there would be a benefit to having a manager that is actually further from the problem itself. Less precious about details and more focused on universal principles.
What ex-engineer managers had was respect for the craft itself. You can respect the work of the team without doing it in the past.
I used to assume that. Until I met folks who seemed to be able to switch from micro details to macro "big picture" rather seamlessly. The extreme example of that is a Gates review[0]. Maybe that's why John Sculley never stood a chance.
It's more than respect for the craft, it's understanding the problem space.
Strong disagree. Many hospital directors still have enough respect for themselves and their profession to see patients. Engineering managers should be no different.
A manager who can't deeply understand what their team is doing has no business overseeing any work they do. They could be replaced with a non-technical BA who can do one-on-ones and approve vacations. The only way to deeply understand the work is to do it daily.
A hands-off engineering manager instantly starts to lose value as their skills degrade rapidly.
A hands off engineering manager is like an editor-in-chief of a newspaper who doesn't think they should have to read and write to be "an effective leader". That is the absurdity of an engineering manager who "stops coding to focus on management."
The idea that management is some higher calling beyond lowly technical skills is marketing sold by business schools to justify minting graduates completely unprepared for real leadership. It's a salve to tell their students it's ok they aren't willing to put in the hard work to become technical experts. I can't tell you how many former CS majors who, after switching to business, laughed that they'd be my boss one day, only to find themselves doing retail and office work while I was an becoming an engineering director.
Funny you mention healthcare because I work in healthcare and you’ll be hard pressed to find a hospital administrator with a clinical background or one who still sees patients. Now medical directors sure but their patient load is minuscule and everyone in healthcare knows that the best care is from the person who does the procedure everyday vs once in a blue moon.
You’re simply conflating project/product managers with engineering managers. The very best and highest compensated engineering managers do not code anymore and are excellent at managing people and making them productive.
I'd like to see what data you use for the claim that the very best engineering managers do not code any more. The idea the person who is chosen by the company to assess and compensate highest performers is also rapidly losing the ability to understand deeply the work being produced seems like a perfect recipe for producing random results.
An editor in chief who stops reading and writing to focus on "managing" a bunch of writers cannot effectively know which ones are producing poor work, other than by asking the rest of the writers in a Survivor-style "who gets voted off" competition.
Many times in my management career I've seen engineers who weren't really very well liked be my best performers, but I only knew that because I could actually understand exactly what they were doing and why. They weren't liked because they made everyone else look bad. Had I been code illiterate (a process that takes maybe five years, tops) my only option would have been to listen to the rest of the team and push them out. And this isn't about lines of code, or tickets finished, so it can't be easily measured with Jira.
If an engineering manager is spending so much time "managing" that they cannot write code to stay current then they are in crises: either inherited, self made as job security, or just lack of skill.
I used to think that. As long as I can write code when I need to and I can inform designs and architectures, my company gets all the benefit of my programming skills as well as my team building skills.
i actually this is also the most productive way to use a senior developer : have him focus on helping the team design and architect software instead of coding everything himself, and help other people grow to his level.
The best engineering managers I've met were simply brilliant engineers, that inspired devs around them and starting managing without having the official tittle: folks would naturally come to them for guidance. The hardest part was to get them to accept that the scope of what they were working on simply went beyond one human's ability to code it himself. But I've seen them break out debuggers and debug issues right in the middle of meetings.
On the other hand, I've met handful of "career managers" that weren't qualified as engineers and, well, frankly they didn't understand the engineering and got no respect out of the organization. No wonder Nadella, Pichai and Cook are all engineers.