[noncoml]

“Leading” is such a terrible word to describe the job of most software engineering managers(at least the ones I have met in my career).

If it’s done correctly, in most cases it’s just firewall/interface between the rest of the company and the engineers of the team.

Dealing with upper management is not really “leading” imho. You are not leading the team unless you architect, design and code your team’s product.

Are you leading a team of surgeons if you haven’t seen the inside of a surgery room since you left school?

[alexgartrell]

I think the reality is that a manager’s job is alignment. Sometimes that is resetting the expectations of the organization, and sometimes that is redirecting the team or team members. Realigning without pissing people off is what leadership is.

Managers who only ever “interface” or act as a “shit umbrella” end up screwing the team over in the long run.

Your surgeon metaphor only stands up in a situation where 100+ Surgeons are operating on the same person.

[mlthoughts2018]

Anyone writing code is not leading. That largely goes for Staff Engineers and up, not just managers.

Architecture review, product strategy, ensuring knowledge transfer and robustness to turnover, developing hiring plans, and ensuring your people are set up for success and are set up for career growth - that is leading.

Leading by implementing is a nasty anti-pattern, like a player-coach. It just means you’re doing a poor job of both by not focusing.

[jariel]

Not sure about that.

In coding, leadership by example and mentorship are one of the most fundamental aspects of true leadership.

In fact, if you have junior devs, the most rapid way to make them more productive, is by putting them with senior devs with good habits they can lead from.

The article is also misguided: someone with 6 months experience can literally not 'lead' someone with 20 years experience in the hierachical sense. It's completely illegitimate.

They can however, manage staffers with senior abilities, in the same way you can hire contractors to build a house. The 'contracting' relationship implies a lot of trust across the boundary, which is what will have to be the case in a 'junior leadership' role.

In fact, they probably should avoid calling it 'leadership' in any sense of the word.

He is probably the 'team bus driver / manager / stock guy' compared to the senior devs, who are like the 'players on the field'.

[mlthoughts2018]

I think you have it very backwards. Coding leadership usually involves nearly zero coding itself. Rather it involves getting the other person to write down RFCs, tech specs, requirements, design diagrams, etc., and guiding them through how to think about macro structure of solutions and outcomes for specific product deliverables and business cases.

Training involves teaching specific tactics of coding, like a new technique of multi-processing, or an approach to refactor a legacy class implementation. Helping someone learn tactics is teaching or training, which is a different thing than leading.

A young person could lead an older, more experienced person. For example, they could drive them to outline a solution in architecture documents that better align with product management. That can be true even if there are no tactics of software design that the younger person can teach the more experienced person. So that doesn’t reduce credibility or anything in the leadership sense.

In general it’s important to separate these: mentorship, coaching, teaching / training, and leading. They are all very different things.

[jariel]

This statement trivializes far too much the mechanics of code and software.

The 'process requirements' like RFCs, tech specs and requirements, are important, but they're not generally that hard.

It takes 5 years of being surrounded by 'good devs' to understand the more material aspects of software - and the very long list of more mundane things.

It's like an apprenticeship.

There's just 'a lot to know'.

Basic style, approaches to solving common problems, getting comfortable with the toolchains etc.

On mobile, just knowing when to do something in 'native' on Android vs. not.

Just getting comfortable with git.

Every tech domain has a ton of 'know how', in the above example, it takes 6 months to really be comfortable with the JNI java bridge for example.

Good code review etiquette.

Being able to compile massive code bases and overcome the invariable problem on the different platforms.

Knowing how how to properly approach a bug fix, how much to test.

etc.

During this time, there's no way a 'young dev' can 'lead' a much more experienced dev.

A young person could certainly 'lead a project' but they'll have to depend pretty heavily on the professionalism of the senior devs.

FYI - if you're building basic CRUD apps on relatively established frameworks, and never need to go beyond that at all, a lot of this can be compressed.

[mlthoughts2018]

After 15 years as an individual contributor and five as an engineering manager, I have to say, you are flat wrong. Doing the work of implementation is a dime a dozen. Getting quality RFCs and prior alignment on solution architectures is at least an order of magnitude more difficult, more valuable and more rare.

Cocksure senior engineers who think, “RFCs are easy, this’ll be quick” are the single biggest source of money-wasting errors that I have to navigate.

I’ve implemented huge distributed applications serving machine learning predictions in global scale ecommerce products, real-time image processing, eventually consistent and SOX compliant billing applications and dozens of other similar solutions in my time as an individual contributor.

Being a manager responsible for not wasting hundreds of person-years on the wrong architecture is way more challenging. It’s not even the same sport.

[cbHAjd]

IOW, the "leader" lets the top "coder" do all the work, including writing RFCs, tech specs, design and coding but takes all the credit.

This is an accurate description of leadership or architecture as it is practiced in this industry.

I've only seen leaders who are intellectual vampires.

[noncoml]

The team leader/captain is a player not the coach. At least in “soccer”. Not sure about American Football.

[mlthoughts2018]

Correct, the captain is not a managerial or decision-making leader at levels higher than pure implementation.

The soccer captain might influence who takes the penalty shot, but they don’t choose the lineups, tactics, player recruitment, training workflows, etc.

The “lead” in “team lead” is not referring to leadership in the same sense of this discussion, only in a much narrower implementation-only sense.

[throwaway201103]

The coach is the leader of the team overall. The captain is the player on the field who leads the team on the field. The captain is not the one deciding the strategy for offense and defense; he/she is more responsible for exemplifying character, work ethic, motivating others and keeping up team morale.

[throwaway201103]

> Architecture review, product strategy, ensuring knowledge transfer and robustness to turnover, developing hiring plans, and ensuring your people are set up for success and are set up for career growth

Of this list, I would say only product strategy is leading. The rest is managing. Of course one role could and often does have elements of both. But leading means making decisions, rejecting some things and advocating for other things. Leaders have their butts on the line for their decisions. Managers are more the implementors of what the leaders decide.

[suyash]

Middle management is the worst, leading happens at the very top level.

[amelius]

Suggestions for a better word?

[quadrifoliate]

"Co-ordinator" describes the work that a lot of these managers do much better. A lot of my manager's work in spent in having meetings and such with other teams to find out things that would otherwise take the same amount of time out of 5 people's calendars.

[gabereiser]

Serving your team - is a better phrase for this interference running.

[jawns]

The description of the job in OP's post sounds like it's largely a project management role.

I ended up in a similar role during my first job out of college, with a fancy title, managing people who all had more experience than me.

I was chosen for the role because I was very detail-oriented and was willing to do the organizational work to make sure everything was running smoothly and on schedule. Not everybody enjoys that work; sometimes it can feel like secretarial work. But if you can do it well, it's a good way to start out your career.

[pmontra]

Making things easier for the team, solving problems before they become really problems, finding the resources. These sort of things.

[cortesoft]

Manager?

[sharadov]

You got me thinking.. "manager" truly means someone who should be managing resources and process, smoothing out the kinks and letting his team work like a well oiled machine. Unfortunately most managers are rarely this, they thrive on micro-management and road-blocking initiatives.

[cortesoft]

What are you basing the idea that most managers aren’t like this from? All of my managers in my 15 year career have been about managing resources and process. I have yet to have a micro-managing manager.

[frongpik]

Secretary? Some high level execs have such a secretary for scheduling stuff. In this case the team is that exec.

[ACow_Adonis]

beauracracy/politics shield?

[Guest42]

My best managers were experts at that. Didn’t realize how good they were until they got poached. It helped that they were able to push back on things above them they knew to be harmful.