Manager vs. Tech: the dilemma

Where do I come from?

My professional life started after my graduation in 2002 at a computer science school named EPITA. I started as a backend developer for various French web companies. At that time, server-side code was cgi-bin in C, mobile development was mainly WAP and xHTML, iMode was a revolution coming from Japan, SQL queries were built "by hand" without any ORM and our versioning control tool was CVS or SVN for the luckiest one (but nothing about Git). We were also dreaming of this brand new ADSL technology that will provide us unlimited internet bandwidth (much more than we will ever need, they promised...)

This is NOT me...

In a nutshell: paradise! It was my daily life and I enjoyed it! Building backend for fast-growing B2C websites was quite exciting and provided a lot of fun:

• Being stimulated by new technologies;
• Show creativity (we tend to underestimate how creative is a developer's job, but there are so much different paths to develop a feature...);
• Feel the pleasure of delivering concrete things (I will come back on this later... 😉).

Of course, as a coin always has two faces, there were also some drawbacks being a backend developer: the pressure of delivery, extinguishing a fire in production on weekends or late at night, having to follow some silly decision from a Project Manager (I'm sure you know what I mean...)

After a dozen of years learning new things and improving skills in different companies, a small seed started to grow in my mind: how can I have a bigger impact?

Embrace the management track

I had always been interested in human interactions and how they can make a difference in a team on a daily basis. Create a trusting relationship within a team, make sure that tech and product/business can understand each other, get feedback from our users and translate it into improvements, etc. In a word: becoming the oil in the engine!

At that time (around 2007-2008), it was quite a big move to go to the management side of the force, as it was much more difficult than today to embrace both technical and management tracks. It was kind of a divisive choice: no way back! 😨

The good compromise for me was to start management scope in a company where I was a developer for a long time: knowing by heart the technical environment helps in terms of legitimacy. On the other way, it could be harder to manage people that were your peers before.

Starting as a manager at this time was very different from today. Agility was only a skill developed at the gym and waterfall was the top-notch way of organizing projects... (Don't say I'm old. We tend to say "experienced"...) But even in this context, it brought a lot of interest and fun:

• Have a wider impact, at the team scale (on decisions, organization, etc.)
• Make people grow, in their soft or hard skills
• Being in touch with other teams or departments and having a wider understanding of the business

It went pretty well and I enjoyed those new responsibilities. But time flies and after a couple of years, I moved into another company with a solid management experience to value.

Leaving aside the tech skill

As you spend more and more time on management topics, you obviously spend less and less time on technical practice and the inevitable happened: you are not sharp enough on tech. Don't get me wrong: it's not necessarily a problem to do your job. As soon as you accept it and take it into account.

It means you should go further in your delegation role. As it's not reasonable anymore to build a technical strategy or a global architecture by yourself, you need to gather different tech experts to build such things. Your responsibility is now to bring a crystal clear vision of the business (and all its constraints) and let them decide the technical path to support it.

But a persistent question was remaining in my mind: "Could I be a great technical leader without being hands-on anymore?"

The doubts...

I'm not the only one concerned about this issue. It has been raised for a loooooong time and there is no definitive answer to this. It really depends on your own strength, the kind of company you work for, your own motivations, the business you are developing, etc. Each and every situation is different.

This question often comes with its henchman: the Impostor Syndrome that we all meet at least once in our life. Ask people around you, they probably already had this feeling and if it's not the case, they will one day... 😅

So when I received a proposal from Padok to join them as a VP of Engineering, it was a mix of excitation and doubts. Excitation for the project, my desire to give a hand to this team and help them to go further, and my doubts about my legitimacy to do so. How could I do a good job as a tech leader in a company dealing with infrastructure and cloud when I come from the backend ecosystem (and quite a long time ago...)?

The reboot

As a Padok newcomer, you always start with a 3 weeks onboarding program including various things such as introductions to the working methodology, the tools, the HR process, etc. (pretty usual) but also the reading of the book "5 dysfunctions of a team".

One of the values at Padok is: The desire to progress

Meaning getting out of your comfort zone to progress and make others progress. So Aurore, our CTO, proposed to me to go back to tech infrastructure basics. "This can be a real benefit to do a better job," she said.

As you can imagine, It's not an easy move to go back to basics after a couple of years without coding in a professional manner. First, because your brain is not as flexible at 40 than at 20 (don't laugh, young reader, it will be your turn one day...) but especially because you have to reveal to your workmates that you are a bit rusty, in front of people that are smart and with a high level of technical skills...

On the other hand (in my own situation) it is probably easier to reconnect with a technical domain that was different from my former developer experience. Of course, I knew about the general concepts and tools from the infrastructure world, but not in detail. If I had to reconnect with backend development, it would have been harder to integrate today's practices without the biases of my former knowledge and reflexes.

Fortunately, as Padok is following the Lean way of thinking, and particularly its precept of learning, Padokians are very kind to people who want to learn, so I never felt a condescending attitude from any of them. Trust is the rule here.

So here I am, just starting the Padok's technical onboarding: containers with Docker, Kubernetes, Infrastructure as Code with Terraform and Helm, CI/CD, etc. A brand new restart from an (almost) blank page, with a lot of practice and exercises!

The cherry on the cake: Aurore also told me that I will be staffed full-time on a real project as the only ops 😱. Then she added that there will be also a Lead Ops part-time on it. I avoid a heart attack in extremis...

Isn't it too fast to get there? Could it be a risk for the success of the project? Welcome back my dear Impostor syndrome... 😉

The rebirth of the phoenix

(Hmm... Well not the phoenix, but at least the tech persona inside me...)

Being the hands-on ops for a real project was a jump in the deep end, but it taught me a lot of things. Before that, I had a tendency to idealize my former developer life (the human mind is pretty well made), by only keeping in mind the good things: creative work, achievements, tech expertise, etc. The reality is slightly different.

From a practical standpoint, I was fully assigned to the project. But after a few days, the daily load for the remaining external VP stuff was too high to let me focus enough on the project so we had to "clean" a bit of my schedule. If you plan to do the same, don't neglect this step as it could really put in danger the success of the project and therefore the experiment. So we decided to postpone what could be delayed and keep the minimal set of tasks that could not.

Throughout the duration of the project, I enjoyed the time spent with the lead on the weekly technical workshop to drill down into user stories, set the technical tasks to implement it, and prepare the acceptance criteria for our PO. The further we went, the easier it was then to do the tasks. We avoided so many pitfalls with this...

The project went by in a flash. But did the results deserve the initiative? Let's go straight to the negative points:

1. Pressure on doers shoulders. As ops, we have a commitment with our clients about what we will deliver in our sprints. It doesn't let so much room for imponderables so it means there is a quite steady pace.
2. Harder to take a step back. We mainly focus on short-term tasks and we always tend to foster short-term vs. long-term.
3. In the first line. An emergency on the platform? You are the one to tackle it. To balance this, it's also frustrating as a hands-off manager to not be able to help in such a situation. So I guess it's an acceptable trade-off.
4. Tunnel effect. You know, when you have 2 hours to do something, but after this time, you still need 20 minutes to finish it... And another 20 minutes... And so on. You KNOW (as a former developer or as a manager) that it's a risk and that you should not do that. But you fall into the trap... 🙃

But from my experience there are many more positive points:

1. Understand the tools. How they work, what's their strength and weakness. The positive side-effect of this is also to understand what our tech people are saying. Basic.
2. Behind the curtains. See how projects are running on a daily basis. What should I then focus on as a VP of Engineering? For example: how could we optimize the short time or our client's? Avoid duplication of information between our tools and clients' tools? How to share knowledge with other teams that have already gone through the same issue we have?
3. The power of andon. In other words, the possibility to ask anyone in the team to unblock you on something. This is powerful to see where the expertise is, avoid pitfalls, and progress smoothly. It's also very satisfying after some time to be able to help the others your turn.
4. Bond with people. Linked with the previous one. As an ops, I had the opportunity to build another kind of relationship with other team members. My belief is that those links are stronger than those I could have had as a VP only...
5. Fast reward. There is nothing such as the satisfaction we can feel at the end of the day when we solved a tricky problem or just accomplish something useful. Don't get me wrong, it exists also as a manager, but this kind of feedback is much more long-term and you can wait for months to see the results of your actions.

So what's next?

You would have understood it with this experiment, all of this is not to become again a technical expert in infrastructure. I will never spend enough time to get there and we already have those high-level people at Padok.

So what's the point then? Was it essential to go through all of this to succeed as a VP at Padok? I strongly believe it's probably a prerequisite. Why? Because thanks to this back-to-basics phase, I have learned a lot on two different things that will help me to do a proper job:

• understand how our tech ecosystem works
• Live a project from the inside, understand the mechanisms in place and add oil where necessary

I realize also it was a brand new opportunity to be able to take this time to enter into the role as most of the companies expect from you that you bring value starting day one. It's a bet on the future and I will make sure it will be valued. So now the next step will be to nurture my VP job with all of those insights and try to change little by little some of the things we want to improve. To keep it up, Aurore and I plan to reproduce this experiment on a regular basis and make back-and-force between management and ops. This will be a good opportunity to see the changes from the battleground. It's an ambitious initiative, but it can make a difference!

So stay tuned for the rest of the story!

By the way, I'm pretty curious about your feedback on this journey and your own experience as a manager or individual contributor on this concern. You probably have an opinion on that as there are as many situations as readers so don't hesitate to contact me on Linkedin!