A Running Checklist for Software Team Leads

I’m fortunate enough to be starting my first position soon as a software team lead. I’m very excited – and a small bit terrified.

I’ve been thinking a lot about continuous improvement over the past few weeks , and it occurred to me that most times I’ve been critical of management, it’s because they seemed to lose touch with (what I deemed to be) important values / insights. It makes sense that this would happen – someone only has so much attention span and willpower. Things are bound to fall by the wayside. The question is, how can I avoid that?

Between my terrible memory and love for good process, I tend to rely on checklists. I got to thinking: if I could articulate some of these concepts, I could provide myself with a reference that I could glance at, which could help keep me focused on making small improvements in some area every day. The goal is to not lose sight of the big picture and the responsibilities of leadership. I plan to try to reflect on at least one of these items each day.

Below is my compiled list with a rough categorization. Feel free to discuss and suggest your own!

On People / Team

• Who / what are my “bus factors”? Roy Osherove did a great post on this topic. It’s important to have a good inventory of who (person or role) could sink a project if it suddenly went away, and to take steps to open up that knowledge, while ensuring that nobody feels threatened or replaceable as a result.
• Does my team know that I appreciate them? How have I shown that? As a team lead, your team needs to know that you’re confident in them and believe in their ability to deliver. Have you hovered/micromanaged too much lately? Have you been sparse with compliments? Take steps to remedy that. If your team knows that you trust them and believe in them, they’ll deliver even more.

@sjkilleen Your inherited team is the best *@#$ team on the planet & make sure they know it. Adjust to reality from there.

— Matthew Martin (@mistersql) December 7, 2015

• Who have not I not tried hard enough to learn something from? Everyone has something to offer. If you haven’t learned anything from someone lately, you haven’t been listening. Get an idea of who you could gain something from and make an effort to listen to them and ask questions that will let them show you their expertise.
• Who do I wish I understood better? Communication isn’t always easy. Do you have a team member or colleague who you always seem to not quite get, or who doesn’t seem to get you? Take some time to analyze it. Think about your Myers-Briggs type (and if you don’t know it, I definitely recommend finding it out). Are there any common communication issues with those who are your personality type? What could you do to better understand this person? Would they be open to giving you feedback on what you could do to better understand them? If so, take advantage of that. Better communication will pay dividends over time.
• Which two team members could work together better? Have you noticed team members who avoid each other or always seem to be at odds? Nobody has to be best friends at work, but sometimes friction between team members can indicate a larger problem or something that can be resolved by the team lead. Make some time to dig into this and explore what a better relationship between the two might look like. Note: it’s important to make sure you’re aware of any biases you bring to the situation and to do your best to leave those out of the equation.
• Is there someone I haven’t given enough credit to lately? People need to be recognized for the good work they do, and recognized in a way that’s most comfortable for them. Some team members might prefer positive feedback in one-on-one sessions, while others might prefer praise in front of the group. Assuming you’ve learned the most effective feedback mechanism, think about who hasn’t seen that love lately and make sure they know you appreciate them. Chances are everyone on your team has done something worth appreciating lately.
• Do I think anyone is looking for a job? Would I be looking for a job if I was anyone on my team? Why? It’s a seller’s market, folks. If anyone leaves for another job, it shouldn’t blindside you. You should know what your team is looking to get out of their work and what they want their next steps to be. Are they looking for improvements in salary, in title, in ability to contribute at a higher level? Know when the organization isn’t in alignment with these things. If you would be looking for a job, chances are they are too. See what you can do to help that situation.
• Who is in need of any constructive, quality criticism? Just as team members need praise, I believe they also need constructive feedback to continue to grow (and whatever they might need in terms of criticism, believe me, you as a team lead need double or triple that.) Figure out the best mechanism to deliver this feedback in a positive, forward-thinking way, and deliver it in small increments that are easy to digest. Similarly, know who is more open to feedback and who gets defensive and work toward helping team members receive this feedback (and give it back to you).
• What is my team too dependent on me for? How can I help them self-organize? Are you the bottleneck on any processes? Are there things you feel that only you can do? Do you find yourself making or communicating the same decisions? Try writing these things down and communicating them widely. Ensuring that your team can self-organize gives them the capability to make decisions in your absence that align with your vision, and allows you to focus on more pressing issues that will help the team overall.
• What stage are we in? Firefighting/Survival? Self-organizing? Why do I think that? Could I be wrong? Would my team agree? A tip of the hat again to Roy Osherove who wrote on this topic as well. A self-organizing, mature team needs a different style of leadership than a team that is struggling to keep its head above water. Think about what stage of maturity your team is in, what factors influence your decision, and what some steps are that can get them to to the next level.
• Is this the team I need? Why or why not? Teams have blind spots and gaps. What are yours? Are the team’s skills properly utilized? Are you missing an important piece of knowledge that could be brought in from elsewhere in the org or outside? What topic do you wish you had a coach for? Think about the make-up of your team and whether it’s able to execute on its purpose.
• Are there any quieter voices I should highlight? Personally, I’m a pretty extroverted and theatrical person. As such, I tend to overlook introverted or quieter people. It’s important for me to remember to encourage contributions from people who may not make them in the same way I would, and to highlight their good ideas the same as others, in a way that helps them remain comfortable and makes them want to contribute more.
• Is anyone afraid of me? I tend to speak matter-of-factly and with certainty/authority, even as I readily admit I don’t always know what the heck I’m talking about. I expect to be challenged and love changing my mind, but it’s no surprise that others may find that difficult to do when I’m in a position of authority. If anyone seems timid or afraid of me, I should look to help them be more comfortable offering feedback in front of the group, or in private, and I should go out of my way to thank people for offering critical feedback.
• Is anyone bored? Boredom is death to a software developer. If someone is doing repetitive work or is stagnating in terms of their skills or daily activities, can I help them by taking on some of that burden or pairing them with someone who’s working on more exciting or different work? Can I help them to automate the most repetitive / boring parts of their work? The opposite is sometimes also true – developers may find comfort in repetitive / easy tasks. In this case, can I help provide them with that comfort while preventing stagnation?
• Does my team know what I expect? Can I make the implicit explicit? If I want the team to succeed, I need to paint a good picture of what good work and success looks like to me. The more explicit I can be about these things, the better – and I should remember to keep an open mind as they evolve.
• What new thing have I learned about my team members or my client lately? At a previous job, I learned by accident that one of my teammates was an great piano player and had a band that performed around the region. Find out these tidbits about your team members or when you come across one, write it down. Knowing your team and doing your best to remember these things can help them feel appreciated when it matters most. Also, people are awesome outside of work too; it’s important to remember that.
• Does my team have diversity of thought? At a previous gig, I once attended a seminar on diversity of thought and it really struck with me. A group of people from diverse backgrounds often finds more novel solutions to a problem and is likely to have a wider range of experience which can help connect you with your end users and customers. The more insight you can get, the better. If your team is too homogenous in terms of thought to background, seek to augment that as much as possible.
• Are there toxic elements on my team? It’s a tough question to ask but so important to check in on this regularly. If someone makes others uncomfortable, makes off-color remarks, or is openly negative/hostile without reason, it will demoralize the entire team. Some people call it the “no asshole rule”, but if you have a toxic presence on your team, it’s important address it as swiftly and directly as possible. A healthy work environment is paramount – it’s the first item on the hierarchy of needs in my opinion.
• What should I be insulating my team from? Where should I reveal more? It’s important to shield a team from work or politics that don’t directly affect them and could cause anxiety or a drift in focus. Conversely, your team needs to feel connected to your and the company’s overall vision, and they should always have an idea of what’s on your radar looking forward. Always work to tweak the balance between these items and think about whether there are some things you’d want to know if you were on the team.
• What’s our biggest failure recently? What did we learn? Hopefully you’ll have a continuous dialogue with your team when something like this happens or at the end of a sprint/project/effort, but regardless, keep a list and encourage your team to participate regularly. This helps the team learn from their mistakes together, while understanding that this sort of thing should be blameless and that the key is growth.

On Introspection

• What frustrates me lately? What can I constructively do about it? Everyone gets frustrated. Do I feel like I’m banging my head against a wall? Is a technique not working? Is there an issue around office politics? If so, how can I adjust my approach or lead to get past it? Articulating individual frustrations goes a long way to avoid them snowballing into an overwhelming feeling of anxiety or defeatism.
• What am I too sure about? I’m a confident person. It usually works out well but as you might not expect, it’s not always a good thing. What items do I hold to be self-evident? What aspects of my job and my approach to development am I too religious about? I should question these thoroughly and seek outside opinions to ensure I remain practical and am not stifling innovation around those ideas.
• What parts of our code (or even my code) do I know the least about? Is there any “magic” in the codebase for applications? Answer: yes, there is; if you haven’t seen any yet, you’re not looking hard enough or learning enough. Find a piece of code or concept within your application(s) that you don’t understand fully and get clarification. Read up on the technique/pattern and the language/framework feature that enables it. At some point, this piece will break or need to be changed, and you’ll be thankful you have a larger depth of understanding.
• Am I the right leader for this team? Why / why not? This is a tough but important question to ask. While I wouldn’t harp on it, it’s important to take stock and understand whether your team is truly well-served by having you in your position. Are you able to get them what they need? Are you able to elevate them? Are you able to keep growing their skills and your own? Are you able to truly help them deliver? If not, it may be time for a change.
• What’s my biggest failure recently? What did I learn? Keeping a running list of lessons learned is important for growth, I think. A little reflection reminds you that it’s okay to fail, and also reminds you to avoid specific mistakes going forward.

On Process

• What can I unblock at a small level? At a big level? Hopefully your process will automatically highlight these things and present possible solutions (e.g. a kanban board might show where work is blocked), but it’s important to look beyond your current process to make sure there aren’t blockages you’re missing. Solicit feedback from your team on anywhere they might be blocked/stalled that you’re not aware of.
• What project/general knowledge do I have siloed intentionally or unintentionally? How can I share those? Find the tidbits of knowledge you keep to yourself for whatever reason. Then, write them down and put them somewhere that people can find them – in a team meeting, an e-mail, a word document somewhere, or as notes on a process. Putting these things out there will free you to keep contributing at a faster pace and will help others do the same. Your job security comes from empowering people across the whole organization – embrace that first instead of privatizing knowledge.
• What tools / processes are my team missing that could help them be successful? How do I advocate for these? Oftentimes team members may give you a head start on this by offering ideas on improvements or something they need. Ensure that you’re helping your team do their best work by empowering them with tools and a process that enables them to accelerate.
• Is code quality getting better or worse? How can I actually tell? If you’re not in the code as often as you’d like to be, this can be difficult to tell. If you can’t immediately answer this question, get involved in code reviews, talk to your team about areas of technical debt they may have seen, and think about different metrics that you can glean from the code itself. However, remember when dealing with metrics that they can only ever be guide-posts and will never give you the whole story. Relying solely on metrics (e.g. test coverage) is a path to ruin.
• What’s something that could be automated? Have you repeated anything lately? Has your team? How can you make sure that thing doesn’t get repeated anymore?
• What do the people supporting the app know that my team doesn’t? If your team doesn’t act as the front line of support for the code they write (something I recommend rotating team members on), then it’s important to have a good understanding of the challenges that the support team faces. What are the trends in issues and requests that they’re seeing? What areas do they think are the most used? Can you find any parts of the application where 20% of the work can get you 80% of the benefit?
• What personas does my team’s app service? Has anything evolved about them? Are we leaving a persona out? Oftentimes teams use personas to define certain stereotypical user/customer behavior across the application (e.g. a technical novice, a power user, etc.)
• Is there an unpleasant task I could take off of someone else’s plate? As a team lead, you don’t only get to do the glamorous stuff – it’s your job to help your team with the crap work. Find someone who has some crap work, and take it off their plate for them. They’ll likely be thankful, and you’ll be that much more motivated to automate or reduce the strain of it in some way.
• What would I improve about how our code makes its way to production? This is a more specific piece of process improvement, but one that’s important to consider separately. Is there a place where things take a long time? Is the build clunky? Does the team tip-toe around certain parts of a release? Does something feel fragile about it? Is anything stopping you from feeling good about continuously deploying? There’s room for improvement there.

On Skills

• What new technology am I behind on? You don’t have to master it, but you should know what’s out there so you know when to dig deeper.
• Would I know how to troubleshoot my team’s app(s)? At some point you’ll have to – best to understand it early so that you can do it as effectively as possible. If it’s hard to debug or test the app for failures, fix this ASAP.

What do you think?

I’d love to hear your opinions and enhancements in the comments. Is there anything you disagree with? A personal tidbit that you’d put on this list? Let me know and if I add it, I’ll be sure to provide you with credit and a link!