Big Companies have management who cash in at the expense of young exploitable engineers.
Personally I'd like to see the top management get fired.
Engineering management lessons (2014)
51–60 of 112 posts
Re: Engineering management lessons (2014)
#52Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
It's not that you don't code...you need to code to stay relevant. It's that you shouldn't code serious production features/issues. As a manager, you're context switching constantly and it's very difficult to achieve the necessary quality. You'll never get the uninterrupted time necessary to do anything big. 5-10 min fixes are good targets for a manager, as are projects that would otherwise distract the team, like spikes on potential new technology. You should use your coding to further your overall goal of keeping your team focused and you should limit your coding so that all the major accomplishments of the team belong to the team members and not the manager.
Re: Engineering management lessons (2014)
#53The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills.
Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though, i should note were related to inexperienced product development - so if you're a first-time product leader, get an experienced mentor.
Re: Engineering management lessons (2014)
#54Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. H…
Where have you worked during your 30 years of experience? Big/small companies? What sector?
Re: Engineering management lessons (2014)
#55The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…
> lowering our bar for hiring
Let me guess, Amazon?
Re: Engineering management lessons (2014)
#56The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…
> lowering our bar for hiring Let me guess, Amazon?
Why would that be your guess?
Re: Engineering management lessons (2014)
#57+ a meta-point: Learn these through experience, not in a classroom. Having managed engineers in industry and also gone through a masters program in engineering management, 90% of what makes me a decent manager/leader/coach today can be attributed to the former.
The dirty secret is that 90% of all formal education is a waste of time, and is just signalling hoop-jumping.
I thought it was helpful when I was doing it the first time. I saw things it made the human capital and self assessment courses much more useful to everyone when I could ask meaningful questions. So really I see leadership masters being helpful when you're first attempting to manage not later or before.
Re: Engineering management lessons (2014)
#58Earlier quoted context omitted.
> Protect your engineers' attention. Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
I've never been an engineering manager so this is my perspective as a software engineer: My attention is my ability to concentrate on what I need to do right now -- not what the company needs in a broad strategic sense, not what the stock is doing, not what might be on the horizon in a few weeks. All of those things are important to me but my attention can only be on one at a time. And I think the reality of serious…
That's what I thought you were getting at. Thanks for elaborating.
Re: Engineering management lessons (2014)
#59Earlier quoted context omitted.
I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. H…
Where have you worked during your 30 years of experience? Big/small companies? What sector?
Education, Research (CERN), Shipping (Harbour IT), Telecommunications (CRM, Mobile Operators, OEMs), Life Sciences, Manufacturing.
Mostly enterprise size companies.
Re: Engineering management lessons (2014)
#60Question: It says at point 8: > Don't supervise the quality and volume of people’s work. And I agree with the argument following that sentence. On the other hand, 2 points above that it says: > Do enforce behavioral and performance standards. Fire bullies and underperformers. So how else do I recognize underperformers without taking note of quantity and quality of people's output? Surely I can't just take someone els…
I was initially confused as well. Would be interested in an authoritative answer from the author, but this is what I came up with upon reflection: the behavioral and performance standards he's talking about are the ones that are primarily social and relatively objective. So, for instance, if one of your team members is prone to shouting at colleagues, it's the manager's job to explain that he expects everyone to act civilly. If the team has decided to adopt code style rules or test coverage requirements, and someone frequently flouts those rules, it's the manager's job to tell them they have to follow the team rules or find another team. Stuff like that.