Hacker News Reader

Comment by nudgeee | Hacker News Reader

IMHO engineers should also (and should be expected to) lead through influence. In my mind, as engineers grow they should be expected to tackle problems and influence solutions of increased scope, complexity and ambiguity.

Junior engineers should be able to drive smaller, well scoped projects.

Senior+ engineers should be expected to tackle complex, cross-org, ill-defined technical challenges, examples include technical mergers of company acquisitions, large scale migrations of business critical systems, technical design of big bets (also analysis on which big bets to take), evaluate new technologies/platforms, dev tooling to multiply productivity, etc

A lot of this requires buy-in and stakeholder management to succeed.

View on HN

Overall I agree, but it's important to realize how easily the impact metrics are gamed. Sometimes the hard parts are in the technical details of programming a specific problem, and doing large scale cross-org collaboration is far more well defined. Or even worse, cross-org collab can just be pure noise by people with no technical understanding defining goals and projects and promoting each other.

So much damage is done by the wrong people being constantly rewarded and promoted for creating noise by "leading" large pointless projects instead of doing the real work. Sometimes I've seen the new hire engineer solving the critical issues like problems in a data pipeline by collaborating across teams is actually having more impact that any of the senior engineers or management bsers.

Right, and in my company that is a manager. An engineer who is good at leading through influence. I am confused as to what other kind of management there is. I guess there is people management, hiring and firing kind of things, but I think that is not what we are talking about on HN.

Things off the top of my head:

- Alignment / priority management / keeping team focused

- Saying yes/no to projects

- Medium term planning, resource balancing

- Helping to set team vision and mission

- Reporting to upper management (up)

- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)

- People management (career, performance, strengths/weaknesses etc)

- Spotting and creating opportunities for the team

- Often acting as a tie breaker for decisions (including technical)

- Often involved in steering technical design and solutions

- Help keep the team productive and happy

- Probably a ton more I’m forgetting

Tons of finesse and strong communication skills required for this as well as strong technical experience.

And then there’s project management which I haven’t touched on — either can be done directly by engineers (personally I enjoy it, some don’t which is fine), engineering managers or dedicated technical project/program managers.

The difference from project management I understand, but a lot of what you described regarding keeping the progress going seems to be a SCRUM master's job. Would you say that is also management? Its all a bit fuzzy to me, because for example these are still engineering tasks for me:

>- Saying yes/no to projects

>- Medium term planning, resource balancing

>- Helping to set team vision and mission

>- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)

>- Often acting as a tie breaker for decisions (including technical)

>- Often involved in steering technical design and solutions

I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.

> The difference from project management I understand, but a lot of what you described regarding keeping the progress going seems to be a SCRUM master's job. Would you say that is also management?

These are my rough notes on project management (from an engineer’s lens):

https://docs.google.com/document/d/1XFdBUfi3MvQuh9NTFBJMQFA0...

Lots of blanks to fill still, but I am a proponent of engineers owning their own project management.

> I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.

100% agree, lots of overlap between responsibilities and often a good thing! Roles from all parts of the org coming together to solve problems is the ideal situation.

My first approximation is that engineering managers are responsible for the team health, whereas engineers are responsible for project health, or at least raising issues when things aren’t so healthy.

> An engineer who is good at leading through influence.

That's rare. In most companies managers aren't engineers, don't understand the craft and are picked by their buddies. They also have completely different incentives which allows them to throw engineers who spent ages to master the craft under the bus without any regards/regrets.

My hot take on this is craft is not the most important thing in engineering. Especially if you are making anything remotely significant in size. As soon as more than one person is involved in the work, ability to actually collaborate becomes more important than how brilliant each individual contributor is. The myth of genius asshole is my biggest pet peeve, if you are an asshole on purpose (like because you dont care how the other person feels) your genius is not useful and doesn't belong in any decently sized organization.

The point of my comment was that in most companies the managers are the jerks, not engineers. As a VP I had to shield individual developers from some insane managers that got kicks from the tiny power they had.

Reply on news.ycombinator.com