So you decided to become a lead developer, or you just became one! Now what? Dan Persa is Engineering lead at Zalando. He spoke at Codemotion Amsterdam in 2019 and offers valuable insights and direction for new managers. Here are just a few things he had to say, you can watch his talk in full below:
As leaders, it’s our responsibility to inspire people to give them purpose, to show them how their effort contributes to a bigger cause something bigger than themselves to explain the why behind the how and what.
Each company interrupt interprets the lead developer role in a slightly different way.
In some companies, you’re a technical lead, in others, a people manager. In most companies, it’s something in between, and there are the rest of the companies which don’t have a well-defined role and tell you frankly, part of your job is to discover what your role is about.
It’s really important to read the job description and make sure it fits your expectations. It’s important to answer questions like, would you continue to write code? Will you leave the architecture discussions in your team? Would you like to define your own role and have less uncertainty?
Lots of companies like Zalando have two career tracks, one which allows engineers to grow their impact within the organisation as individual contributors and the other one to get into official leadership, both of these tracks rewarded equally. No matter the career track, going into your role is all about having a higher impact on responsibility and influence within your organisation. And this requires leadership skills.
You should not do lead developer alone
Dan shares: “You need support. It’s your responsibility to make sure you are set up for success and ask for help. In case you’re already a lead, offer your support to the developers who want to take the leading path is part of your role to identify and grow the talent in your company. “
Dan was fortunate to go through a three month transition period of intense mentoring. “One of the leaders in my company took the responsibility to mentor me, and I’d like to thank him for this. His help was priceless.
So many meetings
You will spend ALOT of time at meetings. According to Dan: “For an introvert like me in the first month, it was really hard to keep the pace. I was getting home with my energy drained, not wanting to speak with anybody for the whole evening. The good news is that with time I got used to having many meetings a day. I also got better at choosing the meetings I participate to, as well as the meetings I organise.
Tame your calendar
Blocks spots in your for individual work, ready emails and the unexpected
Read email only twice a day “I started doing this last month and it totally changed the dynamics of my day for the good, less distraction, more time to focus.
Career Switch
Dan shared: “The second thing which took me by surprise during the first week of lead developer was the fact that I soon realised that I was not going through a regular promotion process like I did before from junior engineer to middle and then senior but I was rather going through a career switch.”
The skillset required to be an effective leader is not a natural evolution of the skill sets required to be a successful developer. It was actually really important to forget some of the basic things I knew from software development. “For example, when you are a lead, repeating yourself is key. to make sure everyone is aligned.”
You need to be a Zen master
This means:
- Allow yourself to fail
- Acknowledge that as you’re doing this for the first time and the chances of having some failures are quite high
- Use failure as an opportunity for learning
- Don’t underestimate the stress you gain when going through big changes. Instead, manage the stress. Make sure you disconnect once in a while by taking a long vacation.
Manage your energy and check for burn out
As a lead, I need to be a role model for my team to motivate the team and this cannot happen if I’m Low in energy or even worse about to get burnt out.
He also shared that a mentor “helped me have a smooth transition and keep me from feeling lost. I cannot imagine going through this transition without a mentor.”
How much time will you spend with code?
This is a really hard to hard question to answer is it depends a lot on the setup. How big is the team What is organisation expecting from the lead, etc? I still try to answer it although it might be controversial.
“Engineering is not about code engineering is about solving problems. Code brings cost development costs, maintenance, cost operations costs. The bigger a codebase gets, the more expensive it is to maintain and run. The code is the necessary evil which allows engineers to solve problems for their customers. Everything is about the customers and their problems. If we are able to solve all of these problems without writing code is amazing. Every member of an organisation should optimise for impact should ask themselves what’s the most important thing I could do right now according to my role, in order to have the highest impact?”
What to prioritise as lead developer?
Priorities: Make sure that:
- The team has enough talented engineers and the candidates have a great experience.
- Members of the team are rewarded for the great job they are doing. Making sure the team is not blocked.
- Knowledge is shared within the team.
- The team has good communication with their stakeholders.
- The team has a clear motivating purpose.
Trusting somebody means taking the risk, to open yourself to be vulnerable towards the person you trust. Dan shares “Here are some of the things I’m doing. I’m trying to earn the respect of the team by leveraging the fact that before being lead developer, I was an engineer. I am aiming to do pair programming with the members of the team. And also, if possible do code reviews. Setting up regular one on ones is also really helpful. getting to know each other is important.”
Decision making and the importance of feedback
We are accountable for both the decisions we take, as well as for the decisions we decide not to take. Dan shares: “One example. is whether or not I should give constructive feedback with the one of the members of the team. And if I decide I should, when is the right time to do it. This is a really important but hard to take decisions because if I fail to deliver the feedback, the person cannot improve. On the other side, if I choose to deliver constructive feedback too often, the members of the team might have the feeling that I’m trying to micromanage them. finding the balance is crucial.”
