Having a transition period to lead teams together with a mentor helped Dan Persa to have a smooth switch from senior software engineer to engineering lead. At Codemotion Amsterdam 2019 he shared some of his experiences and learnings, in order to inspire other developers to take the leadership path.
"It was hard to know exactly what to expect when I became a lead", said Persa. "I knew that it will not be easy and that I have to learn lots of new things". He mentioned that he also needed to forget some of the basic things he knew from software engineering, like the "don’t repeat yourself" principle. "When dealing with people, repeating is essential to make sure everybody is aligned", he said.
What was really clear to him was that it was his responsibility to set himself up for success, said Persa. He asked for help from many people, including his leads and the head of the department, and was surprised by the fact that everybody was really open to helping him go through this transition.
Persa mentioned that the most important thing for him was having a three-month transition period to lead teams together with a mentor. He learned a lot by shadowing his mentor, and having discussions about his thinking process and about how he makes decisions. Persa said that having this support helped him to have a smooth transition and kept him from feeling lost. He stated: "I can’t imagine going through this transition without a mentor!"
With his talk on "First Steps as a Lead", Persa wants to set the right expectations for the developers who want to do this switch, in the hopes that they will have a smoother and successful transition. He mentioned two main reasons why the switch could fail:
- Unhappiness is brought on by the fact that there is a mismatch between what somebody expects a leader to do, and what’s happening in a concrete company. It’s really important to read the job description and to make sure it fits your expectations, said Persa. Try to answer important questions, like will you continue to write code? Will you lead the architecture efforts in your team? Would you rather define your own role and deal with more uncertainty, or have a clear, well defined one?
- Lack of support and mentoring from the other leads in the company. That’s why Persa thinks a prerequisite in this career switch should be finding somebody who agrees to provide mentorship and support.
If things don’t work out or when someone finds out that they aren’t happy in a leadership role, then there is always a way back, said Persa. And even if somebody temporarily switches to leadership, there are benefits, as it helps that person to better empathise with their leads; being a lead teaches you how to be a better follower, he said.
InfoQ spoke with Dan Persa, engineer lead at Zalando, after his talk at Codemotion Amsterdam 2019.
InfoQ: What made you decide to switch from being a senior software engineer to becoming an engineering lead?
Dan Persa: It was a process which took some time, but was essentially triggered by the fact that I got inspired by the people around me: by my wife, who used to be a software engineer and became a lead before I did. By talking to her I became informed about the interesting people problems leads have to solve. I realized that dealing with people problems is much more challenging than dealing with computers. There is much more unknown, more unpredictability, but still high impact.
One of my friends and former colleagues inspired me as well. He’s the best individual contributor any company can hire! He also became a lead before I did. When I asked for advice on whether or not I should follow his steps, he told me: "If I were you, I wouldn’t do it; the leading role we have in our company doesn’t really fit me. I’m a hands-on person, and the role involves too little coding!" That’s when I realized that this will not be a regular promotion as before, from junior engineer to middle and then senior, but rather a career switch.
InfoQ: How did you prepare yourself for your new role as engineering lead?
Persa: A source of learning was applying what I read in books. Notice that I didn’t say only reading books; I don’t think this is enough. The most efficient thing which worked for me was reading a book, deciding what from that book fit my leadership style, reflecting on how I could apply it to my specific case and just then putting it to practice. One book I really enjoyed as a beginner lead was Switch, by Chip and Dan Heath. As leaders, it’s important to be able to introduce change into our teams and organizations. The book presents a framework on how to change things in a lean and natural way, by taking into account how people behave. What I enjoyed the most is the fact that there are plenty of examples to get inspiration by.
Another source of learning and inspiration came from my former managers. I tried to remember and reflect on their good and not so good behaviors; how did they manage to motivate me in the past? How did they provide constructive feedback and help me grow? What did they do wrong? What did I swear I’d never do, if I ever became a lead? After some reflection, I realized transparency and predictability are key to creating a culture of trust, where individuals are able to unleash their creativity and innovate. I’m a big fan of the Principle of "no" surprises, which says that all of your directs deserve to know, at any time, where you think they are in terms of performance and career development, so that at the end of any evaluation cycle they are not surprised by the results of their performance review. I wrote more on this topic in an article on Medium: The Principle of No Surprises.
InfoQ: What have you learned? Can you give an example?
Persa: Here is one of the most important lessons I learned while doing this switch: in order to successfully go through big changes, you need to be a Zen master. What does this mean? For me, it means three things:
- Allow yourself to fail - acknowledge that as you’re doing this for the first time, the chances of some failure are quite high. In case of failure, don’t be too hard on yourself, but also don’t forget to reflect on what went wrong and learn from it. Use failure as an opportunity to learn and for each action you take, create failover plans in order to better mitigate the risks. It’s the same story when dealing with distributed systems: things will eventually fail, so we need mechanisms to recover fast.
- Don’t underestimate the stress you will experience when going through big changes. Instead, manage the stress:
- Make sure you disconnect once in a while, by taking long vacations
- Plan ahead - Control your calendar by blocking slots in advance to make sure you don’t feel overwhelmed. When things are planned in advance, you gain more confidence so you’re less likely to get stressed
- Use stress as an ally: stress is one of the ways in which our body and brain react when we’re dealing with new things, or extreme situations. It helps us focus on what’s important. Acknowledge that, and allow your body and mind to keep you focused.
- Empathise with the people around you; try to understand the point of view of your customers, the upper management and your directs as well. Ask questions and try not to rely on assumptions. We are all on the same team and want to be successful, but different people think differently. Not acknowledging can bring about lots of frustration.
InfoQ: What’s your advice to people who have a technical role and are aspiring to a leadership role?
Persa: I think the most important advice I would give would be to try it for a while and see if they like it. Also make sure they manage their own expectations, by for example watching my talk and reflecting on the points there. While moving to leadership definitely is an interesting problem and there are plenty of things to learn, they need to be prepared to get out of their comfort zone and give up certain things, like coding every day.