Hacker News Reader

Comment by kodah | Hacker News Reader

I've always been perplexed by tech's love of managers despite widespread complaints about them.

The people that are tech leads already do much of what is in these meetings. Whether it's team/product alignment or the one on one's, I don't see much happening here that isn't already covered by a leader on the team. The curious thing is that, often, the tech lead isn't working side by side with a manager -- they work for that manager.

I'll admit, I'm biased. I've never had very good managers in tech and most of them sound fairly clueless to me. When I have met good managers they were usually either people that by their very nature stayed out of my business and let me run the team as I see fit (within some acceptable bounds) or people who were very senior engineers and transitioned into management and let me run the team as I see fit (within some acceptable bounds) while being able to personally identify with why this Root Cause Analysis is totally useless.

View on HN

I don't care what my manager does all day, but I fully expect them to own the situation when things go downhill, to take responsibility and to make sure that the team is shielded from pressures from outside.

I feel like this is often the most obvious sign of a good manager. There’s a lot of variance in other areas, but if you’re on the hunt for a good manager to report to, look for the one that passes credit to their people and holds blame for themselves.

If your manager shields you too well, you may not know when potentially cataclysmic organizational changes are coming. Especially if this is paired with your manager falling out of favor with their manager.

It is your manager’s job to know when to shield you and when to bring you up to speed. A good manager never lets you get caught off-guard, because that is how you quickly lose great engineers.

I agree that having a good manager makes all the difference, but have never yet figured out a way to get assigned only to good managers.

Yeah, the only sure way is to "move jobs by manager." This is why employees will often follow good managers from one company to another.

A good manager manages up and manages down. What you're describing is someone who manages down but not up.

> A good manager manages up and manages down. What you're describing is someone who manages down but not up.

A good employee manages up to the extent the organization they are involved in permits, a manager is just an employee whose duties inide managing down.

But the truth of heirarchical organizations is that while managing down is universally expected (and is usually just called “managing”), managing “up” is...not (and, often, barely even tolerated), even among organizations where citing it as a way of victim-blaming is common.

Reading your first sentence, I was prepared to answer with "well you must have never had a truly great manager who cared about you as a person and helped you grow", but you revealed that later.

It's one of those Pareto principle things. I had 4 terrible managers, but my 5th one helped me grow in ways I wouldn't have alone, and taught me lessons I still carry today. There's no measuring an effective manager.

The ones that do it because it's a job or because they were Peter principled into the role eventually work themselves out of the role, thankfully (or at least out of the company).

Could you describe some of these lessons and events in detail made them so great?

> I had 4 terrible managers

I've fallen back in to "I've had bad managers" but do wonder how often I was the "bad managee". I know it was true in a couple of cases that were obvious to me. And... I can usually point the finger to "bad manager" when multiple folks in a group all had similar (bad) experiences. In other cases, it's not always so clear.

>The people that are tech leads already do much of what is in these meetings. Whether it's team/product alignment or the one on one's, I don't see much happening here that isn't already covered by a leader on the team. The curious thing is that, often, the tech lead isn't working side by side with a manager -- they work for that manager.

This is exactly right! A "Tech Lead" (i don't care about the label as much as the person's responsibilities) IS a "Manager" in any "Tech Company".

In a "Tech Company" there should be as few levels as possible between an Engineer doing the work and the CTO/CEO. The CTO/CEO should always have a "Open Door Policy" in actual spirit and deeds. This in turn implies that they are knowledgeable in Business/Technological/Communications domain (in other words; "earning their pay"). This is the only way to ensure that crucial information is not lost as it is compressed and sent up the hierarchy and the company/business objectives are very clear as it is sent down the hierarchy.

In my entire career i have had only two Managers (that i can recall) who i had judged competent and respected. All the others were mere "paper pushers" who i had just tolerated/managed to get my work done.

It just doesn't have to be this way if people realized that the need for "Standardized" Models of Management (ala Peter Drucker) does not exist for most "Tech Companies" below a certain size and where it is needed, has to be tailored to the Domain i.e. no "Cookie-Cutter" Management Techniques.

Could you really just not have managers in an org that reached a certain size? Past a certain point hierarchies and power structures are going to form, and an explicit management structure is way to make them clear and explicit.

I think in a lot of ways managers are just the glue that holds orgs together. Nobody at all might really want the glue a whole lot, but I'm not sure what not having glue would look like.

I think managers can be useful, but I am starting to think that maybe the issue is that managers don't have to share power with someone who has technical chops.

Line managers should definitely have technical chops.

I've rarely had managers that did not have technical chops.

Did they know the ins and outs of fashion in the latest JavaScript frameworks? Not always. Were they sometimes rusty remembering the method signature of standard library functions? Yeah.

But they typically had deep knowledge and experience with architecting systems, maintaining those systems, making important strategic tradeoffs, planning and estimation, reviewing code, and interfacing with the business.

Having a manager with these skills is invaluable for a productive team.

Most technical managers (like myself) come from a development background. I personally have a very strong fear of not having the technical chops to demand specific behaviours & actions; of being illegitimate. My group's staff developer was very close to taking the job that I now have, but decided he wanted to be a technical leader. I do all the stuff that gives him the time to do that.

Sounds like your team is lucky to have you. I know not all teams are in a good spot in this regard. As you mentioned, not all engineers want to end up in your role. Good managers create the conditions necessary for architect/staff engineer roles, and engineer career growth in general, in addition to achieving business goals.

Yes, see here: https://hbr.org/2011/12/first-lets-fire-all-the-managers

The experience at Morning Star (the company referred to in that link) is oft-quoted, but rarely replicated.

Neat! Never knew of this company.

Thanks for posting this.

I’ve read numerous of times that a flat organization will work in the early years of a company. But in the end it has to evolve into something more hierarchical.

So as an Engineering Manager I'm msot definitely bias, though sometimes even I question my own existence, but I have 7 leads who do a lot of this BUT (a) I do similar things for them, (b) I really help them transition from the direct doers to facilitators that even I once was, (c) I take on the higher-level concerns; ex: your leads might help you by doing a pairing interview but they certainly shouldn't be filtering the 5-10 people you interview before they get involved, or they may run a stand-up or planning session but they shouldn't be making the final call around what your flavour of dev processes look like.

> help them transition from the direct doers to facilitators

But why is this a desirable outcome? It sounds like failure to me. Or at least like retirement.

For an analogy with sports: Good athletes do not retire as early as possible to become coachs. They keep winning medals for as long as they can. When they cannot win anymore, they retire and become "facilitators" (after a significant pay downgrade).

> But why is this a desirable outcome? It sounds like failure to me.

"Why is this desirable?" is the wrong question to ask, IMO. It is not always desirable, as your analogy shows.But the higher value tasks in many business are often not achievable by a single person, like in individual sports. In those cases, it is very valuable to have a good facilitator, and no, they don't take pay cuts doing so.

The analogy does not work.

Athletes are seen perform, but not ICs at a company: nobody pays tickets to see John Smith, the TensorFlow master, at work at Google (and when they pay, like for "webinars", is to become like them, not to enjoy seeing them at work).

ICs and managers can move from domain A to domain Z, but you don't see someone playing (or coaching) football for 4 years and then when the stock is vested or whatever equivalent event indicating it is more profitable to move on, start coaching volleyball.

Also, managers, apart from some companies that have the double ladder--IC and leadership--, managers are paid more than ICs. That does not happen in sports, where the top players are certainly paid more than coaches.

The problem with this analogy is that athletes have particular physical attributes that cannot be taught or learnt, and their possession of those attributes and their ability to use them (while they're still young) is what gives them their value. The bell curve of athletic ability is a different one to that of coaching ability and there isn't a meta-bell curve that joins the two together.

Software engineering and software engineering management are both brain work that require a similar level of intelligence. It's the same bell curve if you zoom out a bit.

Also in some sports the coaches make more than the athletes, and in others the athletes make more than the coaches. You can't generalise.

Other people have answered this, but I think they've missed something. I'm not a manager because I'm a great engineer. I'm a good manager because I'm a decent engineer who has the skills necessary to be a good manager. There are plenty of engineers who should never be managers. In my opinion there are plenty of good managers who will never get to be managers because they aren't good enough engineers.

It's not that the most successful quarterback gets to become the coach. It's the running back who has insight into the strategy, the long term goals adn inter-personal dyanmics that ends up as a good manager.

Reply on news.ycombinator.com