I've done a signficant number of different things in my (software) career, but I tend to generally come back to two closely related roles:

• "One man product team" - joining a company either at the very start or at the start of their software development, with a job that is a combination of product owner and lead (solo) dev.
• "Techical Team Leader" - I make a difference between that role and something like "manager" as team lead implies that you work with your team, they are not just working for you. In my case, than means coding/doing technical stuff.

The fun thing is that those jobs are by nature ephemeral.

It can go two ways.

As a "one man product" team, either the project fails to find it's market/revenue - and then it stops and I leave - or it start getting traction, and it means we're going to hire some help, moving the job in the second category "Technical Team Lead".

As a "tech team lead", it's pretty much the same - if things go badly, well the team will shrink (back to "one man product team") or the project will stop. If it works, we'll hire more, and at some point the job will move more and more toward management.

The inevitable path

I've been there before, several times. I like to think of myself as a reasonably good developer (I know people much better than me, but I've no imposter syndrom either - I've seen I can provide good value there) - but as the team go from one to three then five then eight, the difference I make with my coding capabililty is going to shrink. I may represent 50% of the "firepower" in a team of two (more or less depending on the skills of the other person and how much time I spend on "non development activities") - but this will shrink to only 16% in a team of six.

Adding the fact that as a team lead, you have other tasks (product related, team related, documentation related or others), it's actually generally less than a simple porcentage of the team size.

Combine that to the fact that leading more people requires generally more time (at least if you care about the team - if not, well, find another job), the "good" path invariably lead to progessively dropping the "Tech" part.

I tend to see the inflexion point at around 5 people - more than that means you are leaving the coding space.

It does not means it's bad

Like, managing a team of developers as a 'former' developer is still both fun and useful to both the team and the company - it's just another job. If you have a team of 5 but that your own coding capabilities are still critical to the team/company success, you did something wrong:

• You did not hire good/senior enough people
• You did not share unique/specific knowledge you have
• You did not invest in your team capabilities

So at that point, a lot of other tasks/activities open about providing the context & clarity needed for the team to produce a maximum of value - and then leave them the space to do their job. Working on them will lead to much bigger results that working on your own technical skills.

The Last Feature

I've a mixed feeling about that transition. I love both sides of my job - that's why I select those kind of positions, so looking around and understanding it's time to transition comes with a bittersweet taste. It's generally a sign of success (bad products/businesses does not lead to bigger teams), but that comes at the cost of "letting go" things I really like - hence the ephemereal nature of the job.

As stated before, it's no more a new situation, with means I recognize it. Finishing a feature or the last fixes following a review and realizing "Well, this is probably my last feature".

Opinions? Let me know on LinkedIn!