Reflecting on past projects: Lead Software Developer

I’m aware this topic is as old as there are software developers around in this world. But I don’t want to write about “what makes a good lead software developer in general”, but just reflecting what it takes for me to position someone as “good”. Or at least acceptable.

Because at least I know, I’m not.

Spoiler: I believe my current is no good lead, but I’m not sure about the why.

Also, I have a couple of projects and experience to take in for this.

As a wrote parts of the following things I got aware of the fact, that not many projects had a lead whatsoever. Or need one. I think this has something to do with that it makes only sense to have such a position if the team itself reaches a critical size, and/or the project has a high fluctuation with a small, steady core.

At the beginning of my career, I didn’t even know that there was a title like that. I thought there were only developers, developers with more experience, and team leads.

The concept of “lead developer” came over time, more indirectly than directly.

There was always someone who had the most insight into the current project. How it was built, what concepts are used. Sometimes only from a technical point of view. Sometimes also with the actual product in mind.

Let us go back for about 10 years and see what we’ve got there:

There was a project with a bigger team (~12 Devs) in an even bigger parent project, which was managed by a large-ass company. The team members were mostly freelancers. The appointed lead, also freelance, wasn’t hired as a lead. He was appointed to this position more or less because he had the most experience in the technological area we worked in.

He didn’t do a lot of coding. Instead most of his time he did the work nobody of the devs “liked” or shouldn’t care about: running meetings, e.g. to clarify specs or provide a status update for relating teams. Also, prepare on a technical point together with the product owner, the to be delegated actual work, handle open (conceptual/technical) questions, did overall QA, handled the final release process.

He was the go-to person for every one of the dev-, QA-, PO- and foreign teams.

I believe he didn’t liked this position, because it was a lot of pressure. But surprisingly (also for him) he is very good at this position because he knows that, in such a large team, delegation is more important than the own coding ego.

So next one is … well, me in some parts. At least for the domains, I was responsible for.

But as said before, I’m aware that I’m not very good at this.

For one single reason: I’m terrible at communicating with other developers.

So, moving one :P.

There was a project with a small team. I believe around 5 devs. There was no dedicated lead developer. But as it happens so often, der was an in-official one: the one with the most experience in the project. Not only in the code but also in its product history.

A coder by heard and choice. As he wasn’t aware of his position, he didn’t do the expected things like directly delegating todos, enforcing design decisions, and so on.

Instead, as he was the one with the most experience in the code and product, he was the go-to person for most of our questions. And that he handled very well. Always open-minded, even for recurring stupid questions.

I wonder sometimes if his supervisor was aware of this value.

The next one is my personal favorite until now. Very similar to the first-one i mentioned: knowing when to interfere, and knowing when to delegate. Having the product (with all its aspects) in mind.

Having a very well concept-thinking, as well hands on coding skills.

Very good in communicating between all factions (dev, design, QA) thanks to knowing what “language” to choose when communicating with either faction.

Also, a big nerd.

Always fun, productive, and not frustrating to work with him.

The last one is the total opposite. Besides being also a big nerd.

Small team, again the “most experience”-pattern reason.

Fixated on “how he would do things”, terrible in delegating and communicate things which he believed only he good solve the way it should be. Resulting in situations that he rewrites already resolved things the way he understood it.

Had the (technical) product itself in mind, but not the growing team.

Terrible working environment.

5 different leads in the last 10 years. Not always extremely different to each other.

How do we stand with the current situation? I’m not sure yet, but maybe it helps to read this monologue here a couple of times again later and compare it with the upcoming experience.