Hacker News Reader

Comment by ilovecaching | Hacker News Reader

We don't let managers code where I work. We also don't let them do anything technical besides match employees to work they want to do. Your manager is just there to make sure you can focus as much as your time as possible being productive.

I really like this approach, it's extremely bottom up. It's not that I think our managers don't have technical skills. They all have impressive backgrounds as SWEs etc, but this setup is for the best. The alternative at other companies I've worked for ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions, and managers who intertwined their management success with the product and drove it to ruin because they weren't making the best technical decisions for the product.

So please, if you're a manager, stop coding. Manage people, unblock them, make sure they are happy. Empower them to do the coding for you.

View on HN

"We don't let managers code where I work."

"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"

There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.

I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.

We don't want managers steering anything. That's either the job of the group or the tech lead. The manager is supposed to manage the team the same way a managers manages a baseball team. You get the right people, give them the right tools, and let them play the game.

Exactly, this feels right to me. A manager's job should be to keep track of things but without micromanaging too much (a good example was checking being able to build your team's code on occasion etc.) and also providing the tools and protection they need from upper management so that the team can play the game.

In my previous team, I essentially had the tech lead role in the team but that role wasn't acknowledged with a title, although the entire team was very aware of it.

Ended up getting too much friction with the new manager and I left.

I got a job almost simultaneously as I left. It is much shorter commute, it pays more and it is more exciting. However it is unfortunate I had to exchange 3.5 years of rapport I've built at a place for these.

> "We don't let managers code where I work."

That leads exactly to the situation you described below.

> "...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"

I recently left my job at a respected social network over my new manager lacking the proper technical skills yet not accepting more reasonable solutions.

Case in point: imagine you have an API endpoint you normally hit with your service, periodically. We make a GET request to this endpoint but it also supports POST. The parameter sent is q=<some_long_string>.

It comes to my attention that this long string can get over 1MB long, at which point it causes issues with our service.

I bring up in a meeting that we should just POST to this endpoint instead of doing GET at all times because the data could be larger than 1MB at times. Makes sense, right? Well, my manager without the proper technical awareness basically pushed for us to check if the query is larger than 1MB and POST if and only if it is larger than 1MB.

I gave my two weeks a week after that and made it very clear to the upper management that this manager was the reason I was leaving and I felt like I was being stifled by having a manager like this.

But your manager was doing what I said he shouldn't do which is butt in on technical decisions. You should have talked to your skip and your team mates about your manager stepping over the boundary. You should have also told your manager you wanted to switch teams. There are plenty of other managers who don't work like that.

While that would satisfy the immediate problem of not having to personally work for such a manager, it doesn't solve the problem that the company has such managers.

Better to leave.

As long as the company has clearly defined the roles in the way I've described there is no reason to leave. There will always be outliers who are not working as intended. That's human nature for you. The real solution is to try and help those people understand their role better, and if that fails, then get rid of them.

There is at least one bad egg almost anywhere.

I mean no disrespect, but if you quit every time you have to work with a bad/obnoxious/egotistical/incompetent/delusional manager (or project manager), you'll never remain long in one job.

yes, to you and the other sibling, i didn't mean one bad apple ruins the bunch. i assumed reasonableness of the GP in that he didn't experience once bad interaction and bail, and that he left out all those details for the sake of brevity. because you know, most people are (by definition) reasonable.

i thought it would have been too much to qualify my remarks but i see i should have.

i only meant, if this is the norm for a company, leave post haste.

thank you for challenging my comment, it was well deserved.

As others have said, a good manager shouldn't have got involved at all with this discussion beyond "figure it out!". Technical decisions aren't their job anymore. They are there to solve people and organizational problems now--not technical problems.

I've had a primarily technical career so far and am working on switching to engineering management in the foreseeable future.

Once I'm done with that switch, I don't want to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.

I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.

But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.

One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.

When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.

That's the kind of mentor I'll want to learn from as a manager.

> I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say

A lot of stress has been created for teams I'm on by semi-technical managers chiming in. By telling yourself you'll remain technical enough, I'd encourage you to define what that actually means. Thinking you know stuff that you actually don't is going to be a huge pain in some one's ass.

I once had a boss who kept pushing for us to to do things in a certain way using a remote API, but the API client didn't support the features needed to do the things my boss insisted we use. The boss wouldn't allow for a discussion on extending the API client because he was 100% certain he was correct when he was in fact 100% wrong. I started looking for a new boss after that.

Completely agreed. Knowing the limits of one's knowledge and accepting feedback when one is misinformed are important skills. I believe I already do that and I certainly don't plan to stop.

If I have a competent tech lead under me, I wouldn't be pushing for a certain technical way to do things except if the requirement came from some external constraint like the business or another team, and I would accept the limits of technical possibility.

I might share my technical input if it happened to relate to my area of expertise in a way that wasn't otherwise sufficiently present, but I want my team to know their stuff, not to defer to my technical knowledge out of some personal need to be the expert. Also my input != final decision, with respect to technical decisions, if I'm not tech lead on the task.

Even if I had to push for or against something, I'd do my best to defer to my tech lead (i.e. not me) to actually come up with and lead the solution. It's not a manager's place to prevent a tech lead from conducting a discussion on technically how to achieve the goal within the applicable constraints.

> One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.

I don't mean to create a debate around sexism in the workplace, but could this be because in general in the US, we expect males to have a big ego while for women its OK to be not have one? As a male, I've had trouble with my ego getting in the way pretty often but I try to recognize that and be better about it.

You're right about the general pattern in the US, but that isn't the explanation in this case.

She made sure there were plenty of technical managers under her (she was a VP). The problems that really needed fixing were organizational, not technical, and she did something that a manager with a more technical skew of skills might not have known how to.

The managers in that company who tended to be good and well liked didn't have a big ego regardless of gender, even if (as in her case) she was appropriately aware and confident of the areas in which she was strong.

The role of a project manager is to have someone who can represent the user. The project manager should be talking to users, soliciting product feedback, getting bugs filed, and feeding this to the team.

The role of a manager is to manage the people on the team. That means helping them grow their careers, help them switch teams if they find something that would be a better fit, promote the teams work, unblock people, give feedback on how team members are communicating, manage meetings and fill in for team members so they can spend more time coding that sitting in meetings.

Basically a people manager is like a boxing manager. He gets the champ into shape, puts him in to the ring, and cheers him on. When the champs not fighting he makes sure the champ can focus 100% on training.

I think you mean "proDUCT manager" – a project manager usually focuses on schedule, balance of work, bottlenecks, and maintaining (but not defining) priorities.

It's pretty common for an engineering manager to do project management, and to some degree it's necessary: people management and priority management are closely related.

> So please, if you're a manager, stop coding.

Not a fan of this advice at all. My best managers were also fantastic engineers that actively contributed to the project. They were better at handling escalations, better at making technical decisions, got more respect from their reports, and were fantastic for team morale.

If you have a bad manager, it's not because they're coding, or too technical, it's because they aren't good managers. Good managers also know how to motivate, delegate, support, and lead. They know when to get their hands dirty, and when to let their teams fail and learn. And most importantly, they understand engineering tradeoffs, and when to make them.

Most top tech companies have very technical managers, and even though they're not always great, I'd take a random tech manager over a random non-tech one any day.

There’s only so many hours in a day. The time you wasted coding could be spent much more productively doing your actual job which is managing.

They're not supposed to make technical decisions. What you're talking about is one person wearing multiple hats. Sure, some people can do that. But the end goal is to have a manager that manages as his sole job. Getting your hands dirty is a bad thing. That means your spending that time doing technical work when you could be reducing friction for the team and promoting their work.

If you go too far down that road, you wind up with Dilbert-style PHBs who know nothing about the work their team actually does. I'd rather someone who can get their hands dirty, help out the team if necessary.

Sorry. I guess I straight up disagree with all of that.

I also disagree with the notion of "sole job", which inevitably leads to "that's not my job", a common response at ossified organizations. IME, well-functioning companies are made up of flexible individuals with good judgement.

Obviously, there must be a "main job" for every individual -- I think that's absolutely required. I really wish more managers would actually get their hands dirty.

Imo getting your hands dirty is a prerequisite to understanding your team... and for me it's something you have to keep doing. I agree you shouldn't be the one making technical decisions, but wouldn't say DON'T get your hands dirty as a manager

How big are your teams? This probably makes sense for a larger team where the person is less technical and more people focused. In most small companies, this would not cut it.

I worked with another team (6 people, 1 manager.) Their manager did NOT code and he was not well respected at all. It caused a ton of morale problems, complaints, etc.

That's about the maximum number of people a manager should be managing.

The biggest issue I see is managers who don't code making technical decisions. Like I said in my OP, managers are supposed to unblock people. The team or a tech lead should be making the technical decisions.

That makes sense too - as I see it depends a lot on how big the team is that an engineering manager works with, as well as if the team is a product or a platform team, among other factors.

Our teams have a hard size limit, after that we split and get a manager for the other team. If a manager is managing more than a handful of people, he can no longer give members the attention they need.

A lot of companies do not have the foresight or resources to simply split a team though.

There's lots of way to organize teams as well. At previous companies we've organized yes around products, or around skillsets, for instance.

I don't understand the second paragraph; how did a manager that codes fossilise? Conversely, how do your current managers not?

Fossilizations happen more so because companies treat manager as a promotion rather than a separate track for engineers who want to focus on people. You have managers who are used to solving problems with a skillset that's probably been outdated by the pace of technology, who no longer have the time to invest in keeping current since they're essentially wearing two hats now and they have more going on in their lives.

Reply on news.ycombinator.com