Reflections on Being a Team Lead
A year ago, I accepted a team lead position. As I wrote at the time, I have had a number of opportunities to be a team lead, but I have always declined them, choosing a more technical role, to become a better engineer. In this essay, I will reflect on my first year being a team lead. As I described a year ago, I accepted this role with my eyes wide open. Being a team lead is something that I have thought about, and prepared for, in various ways, for years. This essay, therefore, will not be full of realizations about how leading a team is hard work; or that managing people is as important as, or more important than, participating technically; or that good communication is critical—I was well aware of these demands before accepting the role. Knowing that I would need to dedicate a significant portion of my time to these aspects was the main reason I resisted accepting a team lead position in the past, preferring to focus on the engineering challenges.
In hindsight, there were no major surprises over this past year—it has gone pretty much as I expected. It has been busy, challenging, hard to balance, and, at the same time, extremely rewarding. I have enjoyed being a team lead in terms of the opportunities for leadership and mentoring, but, at the end of the day, I still really want to be an engineer and contribute technically. For the most part, I think I struck the right balance between being a "manager" and remaining technical. I still feel a part of the team. I am pleased with how we have come together and hit our stride. I am very proud of the work we have delivered over the past year and I am grateful to be surrounded and challenged by great friends and colleagues.
My blog has been a great outlet for communication. The essay that I wrote a year ago is the essay that I have personally shared the most with others. I asked all of my teammates to read it, and we reflected on it together. I have also shared it with potential hires and interns. It has been really useful for communicating my thinking and approach, in detail. I think my teammates appreciated these insights—I know I would appreciate the opportunity to understand someone I was working with in as much detail. If you lead a team, I encourage you to write down your philosophy and share it with your teammates, either publicly, or privately. This exercise will clarify your values and clearly articulate them to others.
Being a team lead has provided a lot of inspiration for the blog articles that I have written over the past year. Many articles evolved from wanting to explain technical subjects, for instance, acceptance testing, Reactive Streams, or the dangers of calling blocking code, to some of my teammates. Some non-technical articles, like my thoughts on meetings and my approach to using Quality Views, evolved from opportunities that I saw to improve communication and the quality of our work.
My blog has also been an escape for me, a place where I can focus on my work, achieve a state of flow, and derive satisfaction from the quality of my work. I will explain more in the next section.
As anticipated, my opportunities to contribute to the hands-on, technical work, on a daily basis, have diminished significantly. The majority of my time is now spent planning, coordinating, communicating, attending meetings, managing deployments, and so on. I know that I cannot fight this—it would be futile and irresponsible. Setting a clear direction and objectives for our team, communicating these effectively, and facilitating collaboration with colleagues and stakeholders is the most important work that I can be doing—I want to do a good job at this.
What I miss, however, is working deeply on problems for hours, or days, at a time. I rarely get an opportunity to do this anymore, and if I do, it is never during the workday. My blog has been the most reliable outlet for me to continue to explore technical subjects, in depth. I often write about my experiences researching approaches that I find interesting. Some of these approaches end up influencing the work of my team, which is very satisfying. Since I mainly work on my blog on the weekend, the downside is that it feels like I am always working and that I never have downtime.
Certainly no management position is easy. As a Product Manager, Director, or Vice President, you make critical decisions as to the direction of the business. The responsibilities are enormous. Much of the actual execution of the work, however, is delegated. Once my team commits to some work, on the other hand, there is no more delegation. The team is where the rubber meets the road, so to speak. When you are an engineer, you tend to just put your head down and focus on your work. I work best in this manner, focused on an objective and engaged with my teammates. When you have to lead a team of engineers, however, you have a constant stream of interruptions for status updates, coordination meetings, release planning, code reviews, course correction, and so on. So it unfortunately becomes a constant battle between flow and interruption.
Over the next year, I am going to try and intentionally dedicate some time each week where I can work on a single task, without interruption, and enjoy being in a state of flow. Perhaps by blocking out Thursday afternoons, for example, closing my email and chat client, and refusing to schedule meetings or deployments during this time. Since I cannot afford to be a bottleneck on any time-sensitive work, I will try and focus on prototyping or experimenting with approaches that may influence development directions and engineering decisions. This should give me some time each week where my work is not reactionary, allowing me to engage more System 2 thinking. It should ultimately make me more productive and creative and allow me to deliver more value.
I am an intuitive thinker. Intuitive thinkers make up a fairly small percentage of the overall population. I find that I am often misinterpreted, or misunderstood, since I think differently than the majority of the people that I interact with. I think being an intuitive thinker has been one of the biggest challenges of leading a team.
What is intuitive thinking? I tend to be more abstract than concrete. I focus attention on the big picture, rather than on the details, and on future possibilities, rather than immediate realities. I avoid repetition of explanations and definitions, assuming what is obvious to me is obvious to others. My thought is deductive—from the general to specific—and my speech is speculative, laced with inquiry, possibilities, hypotheses and theorems—with data playing a supportive role. I like to keep my options open, and follow an idea where it leads me. I am eager to provide reports on what I am engineering, but I am not at all eager to tell others what to do. I prefer focusing on functionality and devising prototypes, and I am quite disinterested in clerical or maintenance operations. I am also skeptical. I believe error lurks in what appears true and what appears false, having doubts about just about everything that I propose, or what is proposed to me.
This presents challenges when leading a team, where I need to communicate clearly with teammates, and stakeholders, on our projects. A couple of my colleagues think much more concretely than I do. They want the details first, appreciating how the details might fit into the big picture later on. They want a plan, and they want action, whereas I want introspection and options. My preference for working from the general to the specific can also lead to some tension with stakeholders who want specific release plans and timelines. I wish it was different, but a lot of the work in being a team lead is clerical work, like creating tickets, approving vacation, and scheduling releases. I can be good at this type of work if I put my mind to it, but it doesn't energize me, and it is not what I want to be doing on a daily basis.
Since I have an awareness of my personality preferences that I have just described, I think that I have struck a reasonable balance in communication. A big challenge has been that in the past year, our priorities have shifted a lot based on evolving business objectives, changes in staffing, and through acquisition. This has made long-term planning pretty fruitless. I am fine with this uncertainty, but not all of my teammates embrace it. I can certainly do better explaining why, giving context, and presenting more of a concrete plan, even if the plan is uncertain. Over the next year, I hope to communicate our short to medium-term goals more clearly and more often, even if I feel I am repeating myself. I hope to become more efficient and disciplined at some of the clerical work, most likely dedicating a day a week where this is my focus, rather than sprinkling it throughout the week.
I try and have regular one-on-one meetings with everyone on my team. There is no agenda for these meetings, it is just a chance to talk. I generally try and let my teammates dictate the agenda. To keep these meetings informal, I prefer to go for a walk, or go for coffee, rather than booking a meeting room.
My first observation with regard to one-on-one meetings is that you should have them, religiously, even if you think there is nothing to talk about. You have no idea what will come up and it is often quite surprising where the conversation goes. It is a great way to facilitate regular two-way communication, feedback, and understanding.
By far the hardest thing to do in a one-on-one meeting as the manager, but also the most important, is to resist talking. Ask something like: What is the most important thing that we can talk about? Then just sit back and wait. The silence will feel like minutes are passing. You will want to say something to diffuse the silence, but resist saying anything, otherwise you, as the manager, will end up controlling the conversation. You want to give space for your teammate to say what is on their mind. You want to see what comes up, and if you resist talking, what comes up might surprise you.
In these meetings, people will inevitably mention things that they want to change, goals they want to achieve, or skills they want to improve. Often these objectives are somewhat abstract, like: I want to get better at functional programming. An invaluable question to ask the person in these situations is: How will we define success?
Shortly after joining our team, one person mentioned to me that he wanted to understand the entire system that we are responsible for. I asked him: How will you know when you understand the whole system? He defined success as having enough understanding to draw the entire system on a whiteboard. Later in the year, we revisited this and he was comfortable drawing the entire system, since he had contributed to most of the components. After reaching this milestone, he said he wanted to develop his intuition for complex, distributed systems. I asked him again: How will we define success? He figured being able to evaluate each component in the system in terms of its quality and utility, including which components might be augmented, replaced, or even eliminated moving forward. For such an abstract goal, it would be hard for me to define success, but asking him to define success in his own words, provided much more insight and understanding.
My Questions for You
In my essay last year, I asked the reader to consider two questions that I wanted to revisit on a regular basis. The first was: What's your rhythm? The second question was: What's your narrative? I have asked these two questions to everyone on my team on at least two occasions in the past year. I was somewhat surprised at the responses.
The first question is about how the person strikes a work-life balance—essentially, verbalizing what is important to them in their personal life, such that if work starts to interfere with it, they feel resentment. Everyone misinterpreted this question. They thought it was more a question about the work itself, not work-life balance. I always had to redirect and remind them that it is a question about balance. Even after redirecting, I was surprised that most people had a hard time pinpointing something. I expected people to mention things like avocations, travel plans, or family obligations. Almost universally, people mentioned just being able to get away from work at night, or on the weekends. This is fine—I get it—but I expected more passionate and categorical answers to this question. It may be that everyone on my team is relatively young. I certainly think that having a spouse, children, aging parents, or a new-found hobby as one gets older, tends to clarify the answer to this question. But, even so, when I was a teenager, my answer to this question would have been as clear as it is for me now. I am going to continue to ask this question and I am going to try and help people develop more specific answers to it.
The second question is about understanding the person's unique contribution, and where they see their career evolving, in their own words. I was also surprised by the answers to this question. Most people identified with very specific and recent accomplishments, rather than broader contributions. One person identified somewhat shamefully as a "generalist". With regard to career direction, most people just mentioned learning new things and becoming more accomplished. Few had specific answers to where they wanted to grow. More than anything, this question is about engagement. The answers I got all demonstrated engagement, so perhaps this is enough, but as I ask this question moving forward, similar to the first question, I will encourage people to reflect more and give more specific answers. I think it is important that people identify and verbalize specific domains in which they excel and bring value.
I have probably thought more deeply about these questions than my teammates. Perhaps they are also just more meaningful questions to me. That said, I am going to keep asking them. I think people really appreciate the questions and the opportunity to respond to them, as it helps establish mutual interest and understanding. Perhaps continuing to revisit these questions will allow people to reflect on them more and lead to more considered and refined answers.
I am grateful that I have been able to be a team lead, yet remain in a fairly technical role, as I find that I am most creative and effective remaining hands-on in the day-to-day technical work. Many organizations claim to have a technical track and a managerial track, yet I have never seen this play out terribly effectively. Typically, if you want to participate in shaping the decisions and direction of the organization, you need to be in a managerial role. The technical track is often not well defined, or is underdeveloped and underrepresented in terms of the traditional managerial track. I would be grateful if we, as an industry, could find a solution to this and allow our best engineers to be in leadership positions, without having to assume all of the administrative burdens of management or technical project-management.
Over the past year, I believe my team has been going fast, while, at the same time, delivering very high-quality work. We have made major strides in improving our continuous-integration and continuous-delivery pipelines. We have also significantly improved our tools for systems testing. These investments have been critical to our success over the past year, as we have improved the reliability and scalability of the platforms we deliver. We have done well applying the Boy Scout Rule and empirical approaches to continually and incrementally improve our systems. Finally, we've done well working together, embracing our differences, and being vulnerable with each other.
The past year has been very rewarding and a lot of fun. I am very proud of how we have grown as a team and of the work that we have accomplished together. It has been great getting to know my teammates better, as we have tackled some extremely challenging and rewarding engineering problems. I am not sure what the future holds—only time will tell—but I do know that we have some of our most challenging and interesting problems still ahead of us.