Being a team lead is not necessarily something that every developer wants to — or has the opportunity to — experience in their career. However, Yevhen Andreiev, an iOS software engineer at TomTom, who spent time as a project-based team lead for a distributed team says that while the experience was really challenging, it changed the way he communicates as a team lead, but also as a developer. In this conversation, he shares three key lessons that he picked up during his time as team lead that have impacted his communication and empathetic skills as a team member.
TomTom is a location technology company that develops navigation products ranging from map data and traffic services, to autonomous driving. Yevhen works as an iOS engineer, and his team sits on top of the TomTom stack. In some cases, their dev teams rotate having specific engineers lead a project- or feature-based fleet. Yevhen had the opportunity to lead one of these teams, and found the experience to be a huge learning curve.
Although he’s had some experience with leadership before, being team lead like this was a completely new and challenging experience for him. He explains: “Code is not the most challenging part of your job as an engineer. This experience showed me that there are product-related communications I didn’t really understand — like, how do I explain my solutions as an engineer? — and also people-related communications, like having more empathy, for example.”
This sense of ownership has impacted the way he communicates and thinks about building software as part of a development team, even as he’s moved on to new projects:
“It helped me a lot with communication, even after the project was done. I was able to understand that you need to see things from other people’s point of view – you need to understand what’s going on with the other person. Instead of relying on my assumptions, I now approach people and ask how they’re doing or if they need some help.”
In this article, Yevhen shares his experience as a first-time tech lead, and discusses what he learned about engaging with team members more effectively.
#1: Different people need different information
With a new feature build, and an API that was constantly moving as they were developing, part of Yevhen’s role as project lead was to communicate decisions with the management and executive teams. As a developer, he didn’t have to do this:
“I didn’t have any experience in selling the prototype, the features, or the solutions to product people. But here, you have to, because every feature could bring more value, or less, and you’re the one who provided the data to product management.”
Yevhen quickly found that what he communicated, and how he communicated it, depended heavily on who he was communicating with.
“You need to know how your data can be presented to management, because they don’t always understand it — some of them don’t have a technical background, for example. That part was quite hard for me.”
To get this right, he adapted his communication based on what was most important to the person in front of him:
As a project lead, Yevhen spent most of his time communicating with product managers. So, instead of architecture, he shifted his focus to the business impacts a new build would have: “From a product manager’s perspective, they don’t care about architecture, because they trust your developers. What they want to see is how a feature reflects on the user, and whether it takes two months to develop.”
#2: Being a leader doesn’t mean making hard trade-offs alone
When leading a team, Yevhen also realised that the stakes are much higher when needing to make trade-offs: “For example, I knew we could bring a certain feature in, but we’d need to refactor a lot of code for that; or, we could do something like alerts for speed cameras and traffic, and that would also bring a lot of value — which do I commit my team to for six months?”
However, after going through a few round of hard trade-offs, Yevhen learned that being a project lead didn’t mean he needed to make all the hard trade-offs on his own:
“For me, it was about constantly brainstorming with product management, and trying to understand what brings value and seeing the bigger picture. This change of mindset helped me focus on the things that actually mattered.”
Keeping a strong line of communication with his product managers meant that Yevhen not only made decisions more confidently, but also more quickly. Having more expertise weigh in on a decision helped Yevhen see things he missed or didn’t think about, and make trade-offs with a clearer idea of the impact they would have on his team, and their product.
#3: Just because it works for you, doesn’t mean it works for someone else
Some of Yevhen’s team was in Amsterdam, and the rest was in Serbia. He realised that each team had their own way of working, their own expertise, and their own preferred working culture — and his way was not necessarily the best for everyone:
“You get used to the way you work, and it’s sometimes hard to remember that other people work differently. That part took a lot of time for me to change, but it was mostly trying to understand each person’s approach to working.”
In order to do that, Yevhen had to consolidate what each team needed to do their best. Yevhen was based in Amsterdam at the time, so the first thing he did was fly to Serbia and work with the team for a week: “I got to see how they work, and how they think. What I saw was that the communication patterns are different between the Amsterdam and Serbian teams.”
Whereas his Amsterdam wanted a higher-touch relationship with him as a project lead, the Serbian team preferred to unpack the focus of the task right at the start, and then be left alone to develop that feature.
Understanding this enabled Yevhen to find an approach that worked for both teams: “We tried merging these two approaches, so that the Serbian team could still work on their own.” He explains: “In our case, we used dev-only standups to create synchronous alignment between the two teams, where they could ask questions, where each feature was discussed, and where challenges were raised so we were at least aware of them.” Yevhen also says they re-evaluated how they used JIRA to make communication more transparent. “We did this by asking more questions on JIRA tickets during refinements, mentioning the go-to person for the architectural help, explicitly mentioning edge cases etc.”
Even though Yevhen isn’t a full-time project lead, these lessons have all impacted how he interacts with his team and thinks about software development in his day-to-day role as an iOS engineer. Getting to experience what it’s like to lead a team was useful because, as Yevhen learned, it’s easy to get ‘stuck’ in your own ways of thinking and working, and that doesn’t help you grow. Stepping outside of that every so often can dramatically improve the way you develop, and the way you communicate with your team.
If you’d like to reach out Yevhen, find him on LinkedIn!
