Reflections on my first year of team leadership

It’s been a challenging year for me. I quickly went from being a part of a team, to leading one. For people with an aspiration to leadership in tech, I can personally warn you that leadership is a different beast entirely. The set of skills needed for leadership is highly divergent from those needed for individual contribution. In many ways, you will have to break habits you built up over the course of your career as an individual contributor.

No one is like you

Surprise surprise - the path that you personally took to success won’t work for anyone else. Your individual situation is unique, and, in turn, so are your reports’. Effective leadership and career coaching is heavily reliant on understanding the other person. What are their motivations? What brought them to your company, and why are they still here today? Answering these questions will give you real insight into the other persons’ career. Without it, you will just be guessing based on your own experience.

Personally, I consider my own experience and path in my career to be perhaps the least helpful. I know that my own experience has been retconned by my mind and is heavily reliant on factors that may simply not be present in a given person’s current career. Even generic advice can be poorly applicable to someone else… so I suppose you should take this post with a helping of salt. Nonetheless, going in to any conversation with a direct report with an open mind and the cue to “listen and ask questions” will be helpful.

Delegation and trust

The first thing I had to learn as a leader was how to delegate. I knew how to ask others to do things, but I didn’t know how to tell them. When delegating, it’s easy to think that others will approach problems the same way you would. You assume they will follow your example, or that they will go through the same thought processes you would. This couldn’t be farther from the truth. The more people you have look at a single problem, the more possible solutions you will find. When delegating, the most important skill I have learned is to clearly define the problem and the expected output. The middle part is what varies.

Technical tasks, whether code, design, or otherwise - can and should be broken down into requirements. Being clear on the expected output and deliverable, while still allowing for creativity in the middle, can be a challenging balance to strike. Each individual will need and want a different level of direction from you. They will each have their own perspective on what’s important, what needs to get done, and how it should get done. An individual being able to do more with less is a key sign of growth in my mind, so helping to move people in this direction is important. However, too little context and definition will result in disappointment for both you and your report.

This was trial and error for me. As I continue along this path and get to know my reports better, I have built up a better understanding of how they best work, and also what limitations they have. This is both a good thing and a bad thing. Settling in to a pattern may be helpful for immediate delivery, but without a solid push to improve, your report may stagnate and ultimately feel disappointed. This is why it’s so important to ask questions and work to understand your report’s goals and aspirations.

A simple formula for defining a deliverable

1. Frame the context of the problem to understand both the reason for the request as well as the source of the request.

2. Describe examples of a finalized design, hitting a few points about how you think the problem should be approached at a high level. Try to play with the amount of precision in this step to be tuned for each person.

3. Precisely define the expected deliverable in terms of given/when/then style requirements, test cases, or in the case of non-technology deliverables, stakeholder communication and documentation. Try to avoid precise solutions, simply providing the highest level functional requirements regardless of implementation methodology.

Flexibility and accountability

Defining the delegated task will greatly improve the accountability factor by tracking it and being clear about expectations. However, there still may be plenty of room for interpretation on how or what is to be delivered. It’s important to communicate openly about what’s being delivered throughout the process. While yes, some tasks may be able to be completed without any external communication, I always encourage my delegatees to reach out to all of the stakeholders for a given task. For example, if it’s a technical task, the client who will be using the new feature, the relevant architects and/or product owners, and perhaps others should all be kept in the loop (a simple email or IM will suffice) as to how the task is progressing and what the plan is. Perhaps most importantly, these people should also be notified once the task has been completed and functionality delivered, and if it is taking longer than expected.

Speaking of taking longer than expected, you will need to learn to be flexible on delivery dates. Between illness, unexpected urgent tasks, miscommunications / changes in requirements, and many other such ‘unknown unknowns’ which may come into play, a task will almost always take longer than expected in the best case scenario. Allowing your reports the wiggle room to work out these issues is important, but an urgency must still be present in order to prevent tasks from taking up more than the time that is needed to complete them. This is where consistent updates help quite a lot - it prevents unnecessary scope from creeping in and provides a reputational driving force to complete the task in a timely manner.