Throughout 2023 and 2024, I set out to discover books that would not only enhance my professional development but also be immediately applicable in my organization. One such book was “Software Engineering at Google.” Its description states, “This book emphasizes the difference between programming and software engineering.” However, upon completing it, I feel that this summary doesn’t fully capture its scope. It offers comprehensive insights into applied software engineering within an organization, covering aspects like leadership, culture, teamwork, knowledge sharing, code review, documentation, testing, deprecation, tools, CI/CD, and more.
While not everything from the vast and unique environment of Google can be directly applied to a smaller company, the section on leadership resonated with me and spurred me to write this article. It reflects my views and experiences on technical and organizational leadership, outlining the key challenges and skills needed for such roles.
Why not You?
“Why not you?” This question often arises when discussing leadership. Many counter with concerns like “I don’t want to drift away from coding,” “I fear becoming obsolete,” or “I don’t want to be bogged down in meetings.” In my view, these are responses from those who haven’t genuinely explored leadership, don’t understand what it entails, or have approached it incorrectly.
It’s an excellent way to scale our skills
But let’s first consider why one should lead: It’s an excellent way to scale our skills. No matter how good you are at coding, there’s a limit to how much you can write. Imagine mentoring and guiding a group of talented developers, setting quality standards. They could potentially write much more and better code under your leadership, accelerating progress towards objectives.
Once you have a team, you’ll encounter numerous challenges – technical, managerial, and interpersonal – that will contribute to your professional growth. As a developer, you might be tasked with implementing and testing the integration between two microservices via a message queue. But as a tech lead, your responsibilities are broader. You’ll need to define the architecture of the microservices, ensure asynchronous communication is appropriate for the use case, determine the data contract for events, choose the right message queue technology, and address resilience concerns like error handling and retry mechanisms. You’ll also be responsible for defining metrics, alerts, documenting these concepts, explaining them to your team, determining when a task is truly complete, and strategizing testing approaches.
You might even participate in some of the implementation or oversee it through thorough code reviews. Can all this be achieved by “staying away from coding” and “spending all day in meetings”? Unlikely. Your role is to ensure the implementation meets all aspects of your architectural design, and sometimes, you’ll need to code as well.
Now, imagine managing 3 or 4 developers with multiple tasks concurrently. Still think it’s feasible to be always in meetings and become ‘obsolete’? You wouldn’t be able to execute the architecture you defined. You need to find a way to, despite attending meetings, feel after 3 or 4 months of implementing features through your team that you were a direct part of it. You need to know as many details as possible, feeling like you’ve multiplied yourself and that the code produced is a result of a great team and your effective leadership.
This includes challenges like finding time to research whether to use RabbitMQ or Kafka, preparing meetings with product teams to discuss new requirements, reviewing other tasks, supporting team members, and addressing underperformance or personal issues. This only adds to the complexity of staying hands-on with coding, being current, and not spending all day in meetings.
The reality of Leadership
What am I trying to say? Leadership isn’t just about management, meetings, giving orders, guiding, or supporting. It’s about being what you were (a senior developer) but with the same amount of time and more skills to develop, both hard and soft.
So, you might think, “I don’t want to lead because I need to be equally or more technically skilled, prioritize, organize my time, be empathetic to my team, and be available to them.” That’s fair; everyone has their preferences. But it’s not about being drawn away from coding, becoming obsolete, or being stuck in meetings. It’s more challenging and requires developing more skills. Likely, you also have a leader who makes your and your team’s work possible, highlighting the necessity of such a position.
From my perspective, it’s essential as a leader to motivate other developers to acquire these skills. Why? To scale, offer opportunities to new developers to fill your previous individual contributor role, face new challenges, grow professionally and personally, mentor, and expand your circle of influence. You might even reach a point where you ask a team member, “Why not you?”
So, you’re convinced about leading, but how do you stay technically sharp, manage your time, keep up with technologies, and remain close to coding? The path to effective technical leadership is an evolving journey, rich with learning opportunities and challenges. This article is just the beginning. In my upcoming pieces, I’ll dive deeper into the nuances of leadership, covering specific strategies and skills that are essential for success in this role.
Stay tuned for these insights, as we continue to explore the dynamic and rewarding world of leading in tech.