I've been a "development team lead" for probably half of my career now (so about 10 to 15 years), the other half being a mixed bag of development, consultant or (gasp) C-level manager.

What I'll call "development team lead" here is leading a relatively small (let say 2 to 8) developers in a position that is a mix between technical, people and product role.

Reading other people blogs, I'm always impressed by the amount of "programming principles" that people developed over the years that feels like they can apply everywhere - my own experience has been generally so mixed that there are very few (if anything) I would stick to on the technical side as in "apply everywhere every time".

What I did realize is that I do have some - on the team lead part. Nothing earth breaking, but things I've not seen applied that often so that are probably worth a post.

So, without further ado, here are my

Development Team Lead Principles

(in no specific order)

Delay decisions

Facing a choice or something to decide, whether it's a feature to pick or a design decision or an architectural choice, first ask yourself if this decision can wait.

Generally speaking, the more time pass, the more you know about your app, context, customer, etc, so the easiest it is to pick the "good" one. That means that waiting to decide / going for options that does not fork immediatly is generally a good idea.

I wrote a blog post about it a while ago.

The only people with a right to decide how to do something are the people doing it

That's a bit long but I could not make it shorter. The idea is that the group of people directly doing the work should decide how to do it. That does not means "only the developer doing it" but more "developers should decide how development is organized/done/etc". In other words: you don't get a vote if you are not part of the team doing the work.

That's not specific to development - I would not dare go to the sales team and tell them how they should work - I sure hope they know better than me.

That also means that if you manage a dev team without being actively coding yourself (or reviewing, or having some kind of stakes and knowledge there), I think you should leave technical decisions/organisation to your team (but nothing wrong in facilitating their process).

If it's not broken, don't fix it

This one come directly from Havelock Vetinari a fictional character created by Terry Pratchett who has it as a family motto.

My experience as a developer is that pretty much everything can be changed/improved - but generally should'nt. Fixing something that is not broken feels like a very very low impact activity, which means you have probably better things to do.

I love ideas - but I'll always ask "how will the customer (or us) benefit from that?". If there is no tangible answer, maybe we just need to leave it there and move toward more impactful activities.

Try trumps Talk

Facing decisions, either technical or process related, discussion about the benefits of one technology/library/process over another can quickly become tedious. My usual answer is if the change is not dangerous to simply try it for let's say two weeks (if it's a process) or on a branch/dedicated feature (if technical), then have a look together and decide.

The catch is that in the technical case, if the decision ends up not going that way we may have to throw away some code. That need to be clear from the start to not anger the colleague doing the trial.

My experience with this is that the "decision" phase become obvious extremely fast - benefits are more visible when doing it than in the abstract, and idea that looks good in theory but are cumbersome in practice will be easily discarded.

Long form writing is underused

We've all heard the "this meeting could have been an email". The easy answer is when information needs to be communicated to a group of people to just... write it down. In an email, a Slack message, a notion page - whatever. The meeting can still happen if it need to be discussed, but at least everyone will have the information.

This applies to a lot of other situations. I love chat (as in a immediate/short/non blocking way of communication), but long form with clear context is an extremely efficient and underused communication media.

As a tech lead it's one of my primary tool, and a reason our "team meetings" are generally not about me talking - if I have information to pass, I'll just write it down before.

Someone did something interesting? Write it down. A feature is more complex than it appears? Write it down. We need to decide between two options? Write them down.

Discuss and decide together

This is something I've evolved on. The more time pass, the less decisions I take "on my own" even when I do have the "right" to it (by seniority, rank or both). Writing about it, outlining options then discussing with the team should almost always lead to a better decision than the one I could take alone. It generates more perspectives, open options I did not know about or reasons not to use one I could not see.

This does not means it has to be a democracy - just that decisions are discussed together. In my experience, consensus often happens, and if not it generally means it's worth digging - maybe specific people will be impacted more than others? At the end, a decision needs to be taken and it can still be a dictatorial one - but it will be taken with much better context.

Boring is good

Technologically wise, going for mature, boring languages, frameworks, approaches is generally very good for the company. The underlying hypothesis is that your team is not facing a completly new technical problem or context - ie people have the same somewhere else. It's the case for 99% of the companies.

You want the business to be disruptive - not the technology.

Mature/boring tech works, has people mastering it you can hire, blog post and documentations you can read, stackoverflow answers on your problems, etc.

Most companies can succeed or fail with pretty much any language. The only mistake is to use something niche - even assuming the niche tech is better (it usually is not), it won't be worth the maintenance headache.

What is the job actually?

Management has evolved (or should). In teams like the one I have, what your job is'nt is pretty clear: your job is not to tell people what to do.

On what the job is I'll just refer to Claire Lew that wrote the most interesting things about leadership I ever read.

The part that stuck the most with me is "provide context and clarity".

• Provide context so that people can take good decisions, instead of telling them what to do (using context you don't provide)
• Provide clarity on the goals, priorities

"Ensure psychological safety" should be a prerequisite more than a goal, too.

Pitch

If this resonate with you, let me know. If your team can use some of that kind of advice, have a look at the services I offer.

Opinions? Let me know on LinkedIn!