In the mind of a TechLead : kickoff

I started just a month ago to work as TechLead inside a developers team for a ambitious software project. (…) I would like to take the occasion of this new adventure to share some of my thoughts, trying to explore as many apsects of it as I can. That is, technology, of course. But also, self-confidence, communication, architecture, career paths, mentoring, politics…

[Access all articles of this serie in English].
[Accéder à l’article en français].

I started just a month ago to work as TechLead inside a developers team for a ambitious software project. This role isn’t entirely new to me, since I worked as « Head of Software » for a startup during 2 years. But at that moment, I was overwhelmed with all operational aspects of the « research and development department » (that is, 90% of the company at that moment). This time I can focus on that interesting role.

I would like to take the occasion of this new adventure to share some of my thoughts, trying to explore as many apsects of it as I can. That is, technology, of course. But also, self-confidence, communication, architecture, career paths, mentoring, politics…

(Just a bit of context: I’m 44. I’ve been starting my carreer as an astrophysicist, then switched to software development in 2011, worked for small companies and startups, as well as larger organisation. I did quite a lot of scientific coding, modeling, image processing, but also a professional desktop app, iOS apps, scientific libraries, app components, REST APIs and a front-end webapp. Whatever the details, I’ve eaten quite a few langages, in quite a few contexts, and most importantly delivered in production quite a few products.)

The first idea that come up to me, when I look back to this short month is: a TechLead must have an acute sense of balance. A lot of rational and less rational expectations are put on the shoulders of that role, both from technical and non-technical people. That was particlarly true when I arrived: the project has a team of 6 juniors developers, a scrum master, an architect, two product owners (and a project manager), and was already working since about 3 months. But everybody in the development team and the management around it shared the feeling that the project strongly needed some « seniority », given the contrast between the juniority of the team, and ambition of the project (a subject on its own).

Thus I quite strongly experienced the need of balance between various things. But let’s focus on the most relevant one for this special moment that the few first weeks are.

I mostly felt the need of an acute sense of balance between the urge of fiting myself into the new organisation on one hand, and using my ignorance of the details to challenge existing hypothesis, on the other hand. With a very open-minded management (a thing that I can’t stress more the importance), people are very keen to hear you about what they could have done better or even wrong. This is a power you have during the first weeks, and there is only a very short supply of it. You have to use it wisely to speak out and share your impressions carefuly.

It is also the occasion to provide already what you think will be the overall direction of your action. The latter point don’t make you fit into the role right away, but at least it helps you fill it.

In other words, if you enter a mostly problematic working environment (as it was, in my case), you should rapidly reveal issues (but without exaggerating them!) and draw possible lines of solutions (without imposing them!). That’s a very fine balance. If you insist too much on problems, or appear to be too rapidly emotionaly involved in these problems, it’s easy to understand you might not fit for the role, or that you won’t simply be part of the solution. The risk exists of being pushed out of the project right at the start.

Moreover, if you try to impose solutions, you rapidly loose credit: how can you have a sense of the big picture already now? Problems that haven’t been solved after a few weeks or months are necessarily interconnected with other forces and/or people. People that are certainly of good faith, trying to do their best. You cannot do more than suggesting solutions, and if possible, solutions that are based on hints the management might have given you, more or less explicitely (you are necessarily ‘utilized’ by someone to modify an existing state of things – this is normal).

If you invoke your « huge » experience to try to impose solutions, you appear to justify yourself, and weaken your position already. (Virility demonstrations in tech environments will require its own post.) And you must remain open to solutions suggested by others, and solutions that don’t make you necessarily happy, while at the same time you are still adjusting yourself to a new context, a new place, new people, new tech stack… It’s hard.

In the opposite case of a mostly positive environment, this time is good to draw long-term guidelines of your action too. In both cases, you can earn a large amount of credit if you manage to rapidly acquire trust from the team, and both provide rapid help for existing issues.

How to achieve this sense of balance? There’s no magic. Personally, I can see only two things: listen and sleep, from day one. Listening everything is key. Listen to everybody, pay attention a bit on the body langage, but mostly to confirm impressions, listen in every occasion, meetings, lunchs, listen all the time. This is exhausting. Thus make sure to sleep enough. You’ll probably have time to rest a bit more after a few weeks.


I hope you found this post interesting. It outlines a bit the subjects to come in this serie of posts: how to acquire trust from a team, how to deal with autoritative figures, the balance between being strong, and being a part of something you can’t control… Stay tuned!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *