[meagher]

One thing missing from my recent engineering managers is lack of relevant coding experience.

You don't need to be an great engineer to be a good manager, but it definitely helps when your manager knows enough about the battles fought in the trenches and can offer actual feedback/support instead of nodding for 30m, then going to another 1:1.

[kemiller2002]

At my last job I had an interesting (nice) experience. My boss wasn't an engineer, he was a project manager, but that didn't hinder him. I think what made him successful was that he cared. He'd say over and over, "I'm not a developer, I need help understanding." We would sit in a meeting and walk through problems. He was very calm and patient and acted genuinely interested in what the problem was. He would ask questions about what he didn't understand, and trust us on the things that we would say. It was a great experience. When we said we had a problem, he tried to understand and relay that to the necessary people. When he couldn't we'd accompany him to explain the details.

[nicoburns]

Yeah, I've definitely worked with non-engineers (project managers, designers, QA, etc) who are more than capable of understanding technical issues even if they don't get the details. They're usually great people to work with, and I try to extend the same courtesy to other parts of the business that I work with.

[rurp]

My current manager is a lot like this. He has never written a line of code but is surprisingly good at scoping work and understanding how important various tasks are. I think that any manager who is smart, cares about the work, and has good discussions with their engineers can develop a solid understanding of software projects.

There's no magic to it but, sadly, that combination of qualities is a lot less common than I would like.

[wolfgang000]

My current and former manager are exactly like this, except that both of them do know SQL, really great guys that try their best to help guide the project.

As a little anecdote, my first boss was a technical manager with many years of experience in programming but unfortunately not very good managerial skills. The biggest problem was that he had a clear image of the big picture but when we try to explain to him that "No, we can't do X because Y" then he said, "what are you talking about? Of course, we can It's a simple queue/query/function call", and he would not listen until we show and explain him the code or he tried to do it himself.

It's definitely better to have an empathic and cooperative manager even if he or she lags the technical knowledge

[Timberwolf]

Companies really struggle with this, and in both directions. Startups and scale-ups tend to overcompensate to the point management hires get interviewed as super-ICs, where they'll be expected to answer technical stages at (or even above) the company's top IC standard, but only get a couple of basic scenario questions about management that anybody could answer. Sometimes you get lucky and they're good at both, but it's a big source of the "management by yelling at people" and "I can't have a 1:1 with you, I'm fixing a production issue" schools prevalent in such environments.

It's rare to find a company balanced in the middle where they're looking for someone who clearly "gets it" and can talk about technical solutions, but also has the ability to solve the people problems. (Often good managers were also skilled ICs before they made the jump, but lack of everyday practical use leaves them with a layer of rust. In an hour interview with someone you've never met before it's hard to tell the difference between "rust" and "has heard of the concepts but doesn't really understand them" though)

[rhn_mk1]

What's IC?

[ownagefool]

Individual contributor.

Obviously there's a spectrum of management that an IC can undertaken, but this is typically based around their good will and soft powers, but the wider point is they're not supported to have direct reports.

[Timberwolf]

Sorry, jargon: Individual Contributor, meaning someone who works on things directly and doesn't do any management.

[systemvoltage]

I think that would be covered under the idea "Lead by example". When the manager is competent to understand, console and provide guidance to the team when they're struggling - even slight slivers of technical skills and knowhow, the rapport they build is unbreakable.

The idea is to genuinely belong to a team, not just on an org chart. When troops are in the battle field, they form unbreakable bonds because they have trust, got each other's backs and there is absolutely nothing artificial about it - life is on the line. More often than not, I've seen managers appear genuine but are not internally so and it will surface in future if not now.

Also, corporations, midsized companies and even small companies have this idea of not speaking the mind. Instead, massive amounts of bullshit corp speak and lipstick is put on the pig to do a quick dog and pony show for the upper management. Managers that suck up to upper management lose their support from the troops. Once that's done, there is no going back.

[ed312]

This is a really tricky thing to nail down as an EM. My first eng leadership role I was promoted out of the team. Everyone already knew I had what it took (I was one of the core group pushing hard to get the product out the door) so "engineering respect" came naturally. Fast forward to being hired as an EM - I realized I had to earn this all over again AND I couldn't do it just be being another peer in the trenches. Being an authentic leader is _hard work_, but it pays off when you see your team succeed.

[systemvoltage]

Curious how you define a team’s success?

[ed312]

Sorry for the late reply, but for me: 1) ICs happy, learning, w/ good work/life balance AND 2) project work delivered at high quality in a reasonable time frame. Personally, when in doubt, I sacrifice #2 for a while.

[_y5hn]

Everyone pulling in same direction and getting good traction.

[annexrichmond]

I've had EMs who who really well versed in the team's technical work, because they were an IC on the team, and the complete opposite: EM was external hire

One downside of relevant coding experience is that the EM will get involved in more and more little technical details, which bleeds into micromanagement territory.

[sidlls]

Yep, that's what I'm experiencing. There isn't a requirements analysis or design review where he doesn't insert himself into the low-level details, right down to class/data specifications and even lower. Instead of bringing his knowledge of how our stuff has to integrate with other teams' work to inform the design, he acts more like an IC colleague participating in its construction. Then, when engineers come to design reviews with designs that are relatively under-specified (knowing he'll just start making decisions during the meeting) he complains.

It's a bit grating to be told that "you're the expert, I expect you to decide these things" and then have every detail nitpicked over and argued with anyway.

[_y5hn]

Tell him to do the work if he's interested in all the details.