(“This Week in Glean Data” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. You can find an index of all TWiG posts online.)
Recently I’ve been granted the role of “tech-lead” of the Glean SDK, where I find myself responsible for more of the direction and communication regarding Glean. As part of my continuing professional development, I sat down to read “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change” by Camille Fournier. The book focuses on several aspects of technical management up to and including managing several teams. I’d like to focus on the things that I took away from the book through the lens of my new role as tech-lead in this blog, most of which come from a couple of chapters in the book. Don’t take that as the rest of the content not being anything less than really good, only that I’m choosing to take a narrow focus. I felt it was more appropriate and personal to share what I took away from it related to my new responsibilities. I highly recommend this book to any contributor, management or otherwise, as it can give you great insight into what good (and bad) management looks like, with some really good examples that delineate the idealistic views from the realistic views of different situations. So, without further ado, let’s get started with the things I gleaned from this book through the eyes of a new tech-lead.
The definition of “tech-lead” offered in the Tech-Lead chapter was one I both liked and agreed with. Basically, tech-leads aren’t necessarily the most senior person on the team, they are someone willing to take on the set of responsibilities of representing the team to management, vetting plans, and dealing with project management details. Tech-leads focus on these things so that the team as a whole can be more productive. Now that I find myself the tech-lead of Glean, my productivity comes second to the overall team’s effectiveness. The book suggests that the best trick a tech-lead can learn is the ability to step away from the code and balance their technical commitments with the needs of the team. This balancing act is something that I’m still working on, and has meant being more deliberate in managing my schedule and including focus times to get things done.
Another topic from the same chapter is the defining characteristics of the role. This, unsurprisingly, includes the importance of communication. This is something that I already knew from past experience, but the book reiterated to me that taking the time to explain things and listening can be extremely helpful, even in roles with newfound expectations of our expertise. It also includes having a thorough understanding of the architecture of the project so that you can make informed decisions that take the project as a whole into consideration and be able to offer more constructive feedback to changes. This allows the tech-lead to be able to “lead” the technical decisions rather than “make” all of them. Sometimes a tech-lead isn’t the expert in a particular aspect of the project. It falls on the tech-lead to understand who on the team has the context and knowledge to make the best decisions and empower them to do so. The final key characteristic of a tech-lead is that they are first and foremost a team player. They shouldn’t be doing all the interesting work themselves, they should instead be looking at the tricky and boring things and figuring out how to get them unstuck. But they also shouldn’t be doing only boring work, either. Being a tech-lead does mean less time to work on code some days, so knowing what you can (and can’t) commit to is also vital; being able to delegate effectively is critical.
The book points out that being a tech-lead is about managing projects as well as the team’s efforts towards them. The distinction the book makes between these is that managing projects tends to be more about managing time and complexity, while managing the team is more about trust and mentoring. Both have a strong overlap on communication being a key part of the formula for success. A tech-lead needs to be able to communicate about projects to different stakeholders, both in a way that management understands and in the more technical communications with the theme. Being able to break down complex work into a series of deliverable tasks is only part of the picture. Knowing the level of detail that a particular project needs also plays into this because not every project needs the same level of project management. Ultimately, a tech-lead’s project management duties are about developing the discipline to think about something before diving into it and understanding how to structure the work so the team can better deliver on it.
Another chapter that I found tied in well with the tech-lead content that I’ve focused on so far is the chapter on “Mentoring”. Being a tech-lead is also about helping those around you reach their own goals, which means keeping up with regular one-on-one meetings with team members so that you can be aware of the challenges that they are facing and the successes they are having. This allows you to be able to provide guidance early and help unblock the team and to be able to call out these successes to management and peers. Being a tech-lead also means being open to the idea that you are now a source of feedback on career growth for your team. A willingness to share your insights into things that have helped you grow can help your teammates to identify areas they could potentially grow.
Finally, in the chapter on “Managing People” I found additional helpful information that tied in nicely with the other concepts that resonated with me in this book. This chapter mostly focuses on the importance of building relationships through trust and rapport, and how to clearly communicate your expectations. There’s also a ton of tips on how to improve these skills as well as how to structure and schedule your one-on-one meetings for success. I really appreciated the chapter mentioning how important it is to create a culture of continuous feedback. All of this points to the importance of communication and provides several useful examples of how to do it more effectively.
Like I mentioned before, the whole book is really well written with a great flow that builds upon each chapter. Each chapter is filled with great information for anyone in or considering a lead or management position. There’s a lot of very helpful communication and time management wisdom, even if you aren’t considering a leadership direction for your career. This blog post was purposefully scoped to my experiences, but I hope it was enough to encourage you to consider reading “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change” by Camille Fournier, it’s definitely worth it!
Categories:
Uncategorized