Managing people I understand

Content warning: this may be (even) more philosophical than usual.

What triggered those ramblings is me sharing something I often say "I cannot imagine managing a sales team" - as in "I can only see myself managing people doing a job I know - ie: software development".

Fact is, the friends I shared this with are both project managers (or product managers, does not matter here) of software teams, and none of them are coding.

They are also clearly successful - as in: they have earned the respect and trust of their developer colleagues, their customers & management, and are driving project home.

In another recent experience in a "CTO meet CEO" kind of "matching" event, I was told by one of the "CEO" people that out of the 7 people the've met that night on the "CTO" side I was the only one able and willing to code - which baffled me, especially in early stage startup - what are you doing to do as a "CTO" if you don't build?

So a bunch of feelings about this:

It's about me, it's not a rule for the world

First thing first - I could not see myself managing a team of people doing sales or bioengineering or something other. It does not means I think it's inherently bad for someone to do so.

I've seen people doing a really good job there (including the two friends I mention)

In other words: it's a rule for me, not for the world.

Software development is not (only) programming

Teams I work in/with are generally those kind of small mutlifonction teams - ie they include programmers but also designers or others.

To be more precise they include more functions than programming - usually product management, design, business analysis and a few other.

This may be a remain of the industry I started with - where all this roles were actually expected from a developer - or a trust that under a certain size teams of generalists tend to outperform specialists (due to being more flexible and requiring less steps between need and feature).

So - when I say jobs I understand it does not limit itself to "people writing code" - which also means I'd have no qualm with a software team being led by a devops or a designer either.

There is something weird in our industry

Look around. Medical teams are led by... doctors. Law firm have partners that are... lawyers. Architect offices are run by architects.

Programming teams are led by... project managers.

Why? Why is our industry so different than it can't promote or be led by one of their own? Are we programmers too stupid, too narrow minded, too introvert to do so?

I don't have the answer there, but you have to admit it's pecular.

Why it matters to me?

There are several aspects to this:

• Understanding: Having been there (and often still being there) means that when a colleague share a struggle I can at least say "I understand" - and mean it. It also mean I can help (even if I generally have other tasks).
• Qualified Opinion: When there is a decision to take, I can have a qualified (personal) opinion on the topic - instead of just having to rely on "who do I trust the most" or basic logic. It does not mean I don't listen to the team (I've often said "I prefer the 'green' option but Sonia thinks the 'red' one is better, and she's the specialist on this so I'd go with her opinion over mine") - just that I have something to bring to the table too.
• Technical representative: When I'm in a meeting with business people or management, my team trust me enough to represent them as being "one of them". I can also sometime directly give the technical view/consequence of a business decision (at other time I'll go back to the team to get more precise information).

This of course also make sense with my "pendulum" career (moving back and forth between developer and tech lead) - but that's not a necessity.

50 shades of team lead

Obiously, not every aspect of the "leadership" part is technical - far from it. Generally my role is about people management, priorization ("context and clarity") and technical autority. Only the third one requires that knowledge - but that means that if you are leading a team without technical knowledge, you then need to delegate that part to a technical person.

It does not seems as a problem, but I rarely see it done explicitely.

In the end

In the end - if it works, it works. "It works" meaning here the project goes forward and the various stakeholders (including the team obviously) are happy with it.

I could not imagine working any other way - but other people are different & have ways that works too. I've seen people that should not be leading dev teams due to their lack of technical skills - but again I've probably seen more people that should not be leading teams at all due to their lack of empathy - so it's may not always be the most important aspect

Opinions? Let me know on LinkedIn!