[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.