My first experience as a Tech Lead

Hello Everyone! After a period of absence from writing, I’m back, trying to get back into the swing of things. I want to emphasize that the experiences shared in this space are based on my academic and professional experiences. Therefore, it is important to remember that what is described here may only represent a fraction of reality and should not be interpreted as a definitive formula for specific processes, procedures or services.

I am currently very excited about this new phase of my career. I have learned a lot and would like to share some of this journey with the community. I hope that the information presented here will be of great value to readers.

People First – The importance of Soft Skills

When I participated in my first selection process, a few years ago, I clearly remember the almost boring steps I went through: interview with HR, practical test, interview with the technical leader and, finally, interview with the manager. Throughout my career as a developer, I have participated in several interviews with different models. At that time, I always felt uncomfortable interviewing with HR people. I didn’t quite understand why, thinking: “If I can do what is required in the technical test, I am already showing enough competence for the position.”

When I took on my role as technical development leader, one of my responsibilities was to collaborate with HR (yes, the same people with whom I didn’t understand the reason for participating in the selection process) in preparing a technical test and defining the interview format for two candidates starting in the backend area. I thought I already knew what a beginner developer in the backend area should deliver and what would be considered a differentiator in the test. However, what I didn’t expect was that, despite the importance of the code, other demands arose beyond project delivery: *how to evaluate candidates in terms of communication? What is their interest in the position? And how can the context they present influence their suitability for the proposed position? These and other questions turned out to be as relevant as the code presented by both candidates, something I had not previously considered in my early years as a developer. *

I remember sitting at the meeting table to make the final decision and being a little surprised to realize how little was discussed about each candidate’s technical skills. Part of this was due to the fact that they were entry-level candidates, so it was to be expected that their technical skills would not be as developed, and this was not the main focus of the discussion.

However, even for more advanced vacancies, especially for senior-level positions, it is crucial to consider skills such as communication, documentation, adaptability, proactivity and other skills often mentioned. These soft skills are fundamental and can be decisive for success in the role, in addition to technical skills. In fact, this is my next point.

The line between Junior and Senior (No, not mid-level).

I know there’s a lot of discussion about the meaning and classification of terms related to experience levels, like “senior.” Some say that “senior is defined by years of experience”, others claim that “in some companies, you gain senior experience after a year”. There are also those who say that “there is no clear distinction between junior and senior” or that “seniors only do code reviews and approve PRs”. Some of these statements are comical, others have a grain of truth. The fact is that the concept of “senior” is quite varied and it is not up to me to define a universal standard, but I can offer some guidance to understand this classification in a more individual way.

Being a senior is not just about technical knowledge, although this is undoubtedly very important. A true senior, or at least a good senior, is someone capable of solving complex problems in terms of both code and systems architecture. Maintaining code quality, following good development practices and having knowledge of project management are crucial aspects.

The key difference is that a senior must be able to execute all of this autonomously and, more importantly, collaborate with teams from different levels and sectors to deliver the best project possible. Furthermore, a real senior (or at least the best ones) not only leads and guides the team, but also develops and prepares other developers to take on new positions and responsibilities.

My first experience leading a project

When I took on my first project, my boss knew that I hadn’t previously led any other project. I just participated in the development and worked out some things that would facilitate development in terms of communication with management. The first question he asked me was: “How many people and what kind of will be enough to complement the project.” I didn’t know the answer right away, it was a very complex question. Because the project was only in the outline, we had no idea of ​​the stack, how much time it would take to complete each task and other metrics of interest to the people above. I did a complete study to be able to deliver the next day on several project management methodologies: Pert, Planning Poker We collaboratively chose the one that was best suited and the challenge began. for each member of the team, what is the best development platform, what is the best stack to use, how the system architecture will work, studying other solutions on the market, monitoring the level of each developer, meetings, meetings and more meetings with the management.

When I least realized it, I was increasingly distant from the code. My role became to suggest improvements and fix some critical bugs so that the project could work, or at least provide a solid foundation for the developers to start. The rest of the work involved communicating with the developers, dividing tasks, monitoring of metrics and, basically, one eye on Asana (to estimate project delivery time) and another on Meet to make sure my microphone wasn’t on and nothing unwanted was “accidentally” slipped through.

Conclusion and a look at the past – to the master with affection

I started my career as a development intern and, interestingly — and you might find it a little contradictory on my part — I didn’t have any concrete experiences (at least not formally recorded in my employment record) that would classify me as a junior, full or senior developer. Much of the experience I gained came from personal projects and research at college. It was a gradual process until I realized that my skills had evolved since those early days.

But yes, I worked intensely as a developer at different levels and had the opportunity to meet different types of senior professionals throughout my career:

1. The very competent and effective senior, but uncommunicative, who solved problems without providing explanations about his approach.
2. The senior is excellent at communication and teaching, but often overwhelmed with urgent tasks and no time to teach.
3. The senior who was enthusiastic about over-engineering and centralizing technology, but who met deadlines and delivered what he promised.

The most important thing is that, despite their justifiable flaws (although it is possible, it is very difficult to balance demands), all of these professionals had something valuable to teach. These experiences helped shape my career and gave me a clear view of what works and what doesn’t in systems development.