Heikki started as a regular developer but is now a Back End Lead. He helps Buutti’s clients to plan and implement their back end architecture. How did the transition happen, though? Did Heikki just wake up one morning with new responsibilities? As you guessed, it didn’t happen just like that.
There are decades of ICT hobbyism and years of work experience along Heikki’s path. He started programming as a 10-year-old, making applications with Delphi. The hobby also included some websites in the old way: with pure HTML. ”All my life, I have liked doing things with my hands,” Heikki explains.
However, the IT industry wasn’t where Heikki originally got his education. He spent a few years in a different field, but the hobby stayed. During the years, he kept programming from time to time, built dozens of PC’s and was the technical support for family and friends. Then, Heikki realised he wanted to make a career out of this hobby.
As a first step, Heikki got into the ICT engineering program of the Oulu University of Applied Sciences. From there, he got into a trainee position with automation testing, and the career switch was complete. For the next few years, Heikki worked in the ICT industry as a software developer. This was the case until Buutti’s sales manager, Jussi, called him with an offer he couldn’t refuse.
Buuting it up
The year was 2021, and Heikki headed directly to a Buutti’s customer project he is still working on. To be more precise, he started as a software developer in the back end part of an industrial client’s software. He was a part of a team that made features from the backlog and solved bugs. All was well: the organisation was genuinely agile and flexible.
Like in his years as an ICT hobbyist, Heikki still likes to do things with his hands. In a software project, this means trying new things, investigating options and figuring out how things work. He dived deeper into the customer’s codebase and learned to understand it better.
In time, Heikki realised some things in the code could be done better. He voiced his opinions in meetings, and the response was accepting. The customer started implementing things Heikki proposed, and he got more and more responsibility. Now, he is included in the architectural decisions and planning of the software. In other words, Heikki is a Back End Lead.
When asked about the most important thing in this journey, Heikki is very clear: it’s trust. He has built it bit by bit during his two years on the client’s project. Heikki elaborates: ”In the core are open communication and honesty. It’s important to communicate things clearly and also admit one’s mistakes.” It didn’t happen in one month, but doing things right adds up over time.
”I didn’t have much expectations originally, but I have enjoyed how my tasks have evolved,” Heikki explains his journey. New responsibilities have also brought him valuable lessons. Adding to the deeper understanding of software development, he has improved his managerial skills. These include better scheduling, understanding international work environments, achieving better compromises and teamwork skills.
How to do it?
Do you want to become a lead developer? Here is Heikki’s top advice:
1. Build trust
First of all, complete your assigned tasks carefully and professionally. Once you have established a good work routine, you can consider the bigger picture. An important part is also admitting when you don’t know something.
This is not only you telling other people how to do something. Yes, you must be clear and honest with your thoughts. But a good communicator also listens. Make sure you really try to understand what the other members of your team are saying. Ask them questions, give feedback and help.
3. Don’t rush things
Learning how things work and building trust takes time. If you suggest refactoring half of the project in your third week, the response will not be great. Consider the scope of your suggestions and how much good they can achieve. Start small and move up if things go well.
4. See the bigger picture
A lead developer should see how their work is a part of the larger context. This means both inside your team and as a part of the broader organisation. How do decisions affect other parts of the software or business outcomes? This also means prioritising: do the suggested changes help enough to justify their costs? Sometimes, it is better to use the existing solution after all.
5. Learn team dynamics
Becoming a lead developer is not just about deciding who is the best at coding. Often, the team structure won’t allow you to get to a lead position. The client may want to hold the reins, or they want your skills to be used in a very specific task. If that is the case, keep learning as much as you can. It may be that a lead position will be available for you later in another project.