I've had a few opportunities to be a team lead, but I've always declined these opportunities. Sometimes it was because I felt the project or the timing just wasn't quite right, but, as much as anything, it was because I wanted to keep developing my technical skills by doing the hands-on work. At smaller, under-staffed, and growing companies, team-lead roles often involve managing people and providing technical leadership, while also continuing to deliver some of the technical work. I saw my friends in these roles and I saw that, even with good intentions, after taking care of the people management and technical-leadership roles, there was little or no time left for them to contribute to the actual work. I've also worked for managers where managing people was part of the responsibilities, but they didn't have the time or the interest for this aspect of the role, neglecting it to focus on the technical work instead. Predictably, this wasn't sustainable and would end with poor communication and an unhappy team.

This doesn't mean that I avoided leadership positions. I have lead a few projects as a technical lead and I've also participated in formal and informal mentoring to offer support and guidance to my colleagues. I've always felt that I could be an effective team lead, as long as I dedicate the time to supporting the people that report to me and realizing that I can't participate as much in the day-to-day technical work. Now I'm going to find out if this is true. I've been asked to assume a team lead role. This will include recruiting and forming a team, having direct reports, setting the technical direction for a number of projects that are critical to the business over the next year, as well as continuing to contribute technically, developing code and automated tests, performing code reviews, improving our continuous-delivery pipeline, and so on.

The kind of team that I want to be a part of and the kind of leader that I want to be are two things that I've thought a lot about for many years now. I want to write this blog post to share with you some of the ideas that resonate with me. I want to set my stall out so that you can understand the kind of team that I want us to have, so that you can understand me better, and to open a discussion around these ideas.

What's in a Title?

I do not want to be your "boss", dictating decisions or telling you what to do. I also do not want to be your "manager". I find the idea of engineers needing to be "managed" distasteful. I don't think engineers generally need a "manager". Engineers are naturally self-motivated, curious, driven, passionate, and engaged. If they are not, the "managers" need to ask themselves why this is the case, rather than question the motivations of the engineers.

Rather than being "managed", I think engineers benefit from mentoring. Good mentoring is something that can happen throughout your career, no matter how advanced you become in your field, and it can happen in both technical and non-technical aspects, basically in any area you find interesting and want to explore. The mentoring can come from peers and teammates, as much as it comes from individuals in positions of leadership. I have wonderful mentors that have helped me become a better engineer, as well as understand myself better on a personal level, to experience life more fully. I hope to facilitate good mentoring for you, as well as provide the opportunity for you to mentor others.

Engineers also need clear communication. People thirst for context. Always explaining why you are doing something is extremely important. As organizations grow, not everyone can be a part of every discussion or decision and formal communication structures become a necessity. Part of being a team lead is just representing our team in these communication structures. I hope to foster open and clear communication with our team, as well as within our team. Rather than prodding or directing, I would like to see a lot of this communication come in the form or feedback loops—like automated acceptance tests and good monitoring of our production systems—so that we can see results, experiment, learn quickly, and focus on our long-term success.

As much as anything, I hope to establish the conditions for us to feel motivation and satisfaction in our work. I love Dan Pink's book Drive and his RSA talk on the same subject. He believes that autonomy, mastery, and purpose are the critical factors for us to be engaged in our work and feel fulfillment from our accomplishments. His ideas really clarified why I'm engaged in my work and why I enjoy my work. I hope to establish autonomy, mastery, and purpose as the foundation of our work. If you have not read his book or watched his talk, I encourage you to do so.

So, I'm comfortable with the title Team Lead. It suggests I'm still part of the team and contributing to the team, striking a balance between being a peer and providing leadership and mentoring based on my experience. I would much rather this than being a competent "Manager".

Our Team

I want our team to have a reputation for delivering very high quality software systems and, at the same time, being very aggressive in evolving the systems to deliver valuable innovations to the business. This can't happen without the right investments in the technical practices that lead to good software development: intentional design, code reviews, pair programming, static analysis, automated testing, automated deployments, monitoring of production systems, and so on.

A big part of our success will be in writing effective automated unit and integration tests, so that we can iterate quickly. As software developers, we will be responsible for writing and maintaining these tests. I want us to enjoy developing tests, using them as an opportunity for experimentation, to understand the systems we work with more deeply and as a means of achieving better designs. If you do not have a lot of experience with automated testing, I think Erik Dietrich's blog series on unit testing is a great introduction. He demonstrates a number of practical techniques, like how to name tests, how to organize tests, and how to put tests around legacy code, but he also explains the business value in writing tests. Erik turned these blog posts into a book. I encourage you to read it.

Developing automated tests to assure the correctness, performance, scalability, and security of distributed systems can be as difficult, often more difficult, than developing the systems themselves. I've written a few articles on some techniques that I've found effective for writing reliable and efficient tests for distributed systems and I plan on writing more on this topic in the future. Automating systems tests will be critical for developing our continuous delivery pipeline. We won't necessary release every commit directly to production, but we will use our continuous delivery pipeline to qualify each commit and assess whether or not it can be deployed to production. I agree with Dave Farley that the vast majority of people in our industry have never seen what a good software project looks like and that if people have grown successful careers doing the wrong things, they will continue doing the wrong things. Please watch his talk. This is the continuous deliver pipeline that we are striving for. Dave also has an excellent talk on writing automated acceptance tests for systems. I worked on one team that really got this right and it made working so much fun, because we could deliver features very quickly and we could be very adventurous in evolving the platform and know that we could deliver very high quality work at the same time. In many ways, the continuous delivery pipeline becomes the product manager and the release manager for the platform.

I want us to take an empirical approach to evolving the systems that we develop. Rather than evolving a system on intuition alone, when we make changes that should improve the performance, scalability, reliability, or security of the system, I would like us to form a theory, implement the changes, and observe the results relative to our theory. When something doesn't make sense, I want us to understand why, continuously improving our understanding of the system. I tend to hold on to my ideas, so if you can show me that I'm wrong, rather than just tell me that I'm wrong, that will really help me.

Whenever we work on something, I would like us to follow The Boy Scout Rule. The Boy Scout Rule is the idea that you always leave something a little better than you found it. This might mean fixing the formatting of a file, deleting code that is no longer used, improving the organization of a module, or fixing an unreliable test. Improving what we are working on incrementally, day-by-day, leads to impressive results over time. If we don't to this, the systems deteriorate, the work isn't as fun, we are less adventurous and less productive. Employing the Boy Scout Rule also means that the software systems are cared for by the team as a whole, rather than just individuals caring for their own little part. Which brings me to the character of our team.

As teammates I want us to be very supportive of each other and I want us to really enjoy working together. If you've ever worked on what the software engineering classic Peopleware calls a jelled team, you know it is an amazing experience. Productivity is high and the work is extremely enjoyable. There is no secret formula for creating such teams. Team formation is a fragile thing. Two of my favourite ideas from this book are that you cannot be a member of more than one team and that you cannot negotiate quality with a team—the internal quality bar for an effective team is so much higher than what the business can perceive, that if you try and dictate quality, you will drive out pride-of-workmanship, the team will be unhappy, and you will lose the team. Joel Spolsky says, "Peopleware is the one book that everyone who runs a software team needs to read and reread once a year." Please read Peopleware and watch Tim Lister's talk at Google exploring some of the same subjects. This is the kind of team that I want us to have.

Lastly, when we are engaged in our work, when we are working closely together, when we are developing mastery, when our work is creative, this makes us inherently vulnerable. We will have differences of opinion. We shouldn't look to necessarily resolve or retreat from these differences. Indi Young reminds us that pushing back on a request is not rebellion, it is the first tiny step in collaboration. Being open and accepting of our differences will make our souls more complex and spacious. It is fine to sit with uneasiness and uncertainty, holding open our differences and accepting new ideas. We need to allow ourselves to feel what we feel, without pushing others away. We need to work on reserving judgment and being with people fully. This will allow us to develop deep, meaningful, and rewarding friendships. Of course, these are not easy subjects to explore. I encourage you to start with Brené Brown's TED Talk on The Power of Vulnerability and her book Daring Greatly. The book Please Understand Me is also excellent resource for understanding how you think, how others think, and how others perceive your thinking.

Some Questions for You

There a few things that I've always thought I would do as a team lead. The first is a regular one-on-one meeting with each person. This meeting will have no agenda. It will just be some time that we can spend together each week to facilitate communication, connection, and understanding. Sometimes we might talk about a challenging problem that we are trying to solve. Sometimes we might review some code. Sometimes we might talk about career development. Sometimes we might just talk about sports, economics, or psychology.

In these one-on-one meetings, there are a few questions that I would like us to visit on a regular basis. The first is related to Marissa Mayer's philosophy on burnout. She believes that people can work really hard for an arbitrary length of time on something that they care about, as long as they don't feel resentment. Resentment develops when someone sacrifices something that is important to them, especially when this isn't recognized, or happens too often, or for too long. To avoid this, she asks the question: What's your rhythm? The answer to this might be something like "Making sure that I leave the office by 5:00 PM on Thursdays so that I can make my ultimate frisbee games." With this understanding, Marissa would do whatever it takes to make sure you do what is important to you. She provides the following example.

Katie is a soccer mom. She was running Google Finance and her team was in Bangalore, India, and she kept doing conference calls at one in the morning. I was really worried about her hours, and she said, “Don’t worry about the 1 a.m. calls to Bangalore. I love my team. It doesn’t bother me a bit. What bothers me is missing soccer games or having my child see me walk in late to the recital.” From then on we’d be in meetings and Katie would get up to leave, and people would say, “Oh, Katie, can’t you just stay five more minutes? We’re so close.” And I’d say, “No, Katie has got to go.”

That was her rhythm. For me, my rhythm is playing my bagpipes. I try to play an average of an hour a day. I get most of my playing in on the weekend, but I need to make sure I'm playing my pipes a couple of times during the work week. If I'm getting to the studio for a practice session a couple of times during the week, then I'm happy. I also play in a pipe band. The bulk of our competitions, including The World Pipe Band Championships, are in the summer months. In the summer, I need to make sure I'm practicing with my band on a weekly basis and making all of our weekend competitions. This makes my summer schedule a little more erratic, but it is this rhythm that energizes me at work the rest of the year.

The next thing I want to understand is: What's your narrative? This is an idea inspirited from Eric Dietrich's article on How To Keep Your Best Programmers. In essence, it is the answer to two questions: What are you contributing? Where are you heading? The first question allows you to describe the focus of your work from your own perspective, helping me understand how you view your contribution to the team and the organization. If you don't have a clear and passionate answer to this question, then that is something that we need to talk about. The answer to the second question gives me perspective on what you are working towards—your career path, if you will—but I like how the question is removed from any formal career-development path. In other words, I expect the answer to the second question to be something along the lines of "I want to be an expert in web-application performance", rather than "I want to be promoted from Software Developer II to Software Developer III"

My answer to the first question, at the time of this writing anyway, is, I design, build, and maintain scalable, secure, and reliable infrastructure systems for real-time streaming data. With regard to the second question, I want to get better at leading, mentoring, and communicating with my colleagues as I assume the role of team lead. I want to continue to improve my technical skills in designing, building, and testing distributed software systems for streaming data. Finally, I want to work across teams to help improve our continuous delivery processes, improve the effectiveness of our system and integration testing, and provide leadership in software security. (Perhaps, I should add, I also hope to avoid the Peter Principle).

Put some thought to your answers to these questions. To help ensure that you are happy, engaged, appreciated, and challenged, let's reflect on them on a regular basis, not just once a year in some awkward performance review, and let's see how the answers to these questions evolve, or not, over time.

Onward

I hope that sharing some of these ideas that have resonated with me will give you some perspective on my approach and the reasoning behind it. I love reading about and reflecting on the dynamics of teams, so be sure to let me know what resonates with you as well. I'm looking forward to being a great team, evolving together, and doing some great work.