Locate and schedule your COVID-19 vaccination at a pharmacy near you.

Find Now
  • Rally
  • Five pieces of advice for new technical leads

Five pieces of advice for new technical leads

By Dan Staley | July 5, 2018


After successfully delivering some amazing code into production on your last project, your manager has offered you a new role, a technical lead! But what does that mean? What can you do to help a team if you aren’t coding?

If this sounds like you, first off, congratulations! At Rally we separate the role of a “tech lead” from “team manager” and though they may often be held by the same individual, today we will only focus on talking about the former. During my tenure at Rally Health, I’ve been afforded the opportunity to work on a large variety of projects in various roles ranging from the sole engineer on a team, to technical lead of a team of amazing engineers, to a director over several projects, each with their own capable lead. Of those transitions, the one that required the biggest mental shift was transitioning from a developer (aka an “individual contributor”) to a tech lead.

Unsurprisingly, I often get questions from colleagues asking if I have any advice for people looking to make or who are currently making similar transitions and find myself hitting on similar themes.

If there is anything I try to preach to teams I work with (probably a bit too often if you ask them), it’s that proper documentation and knowledge sharing is key to a successful project. In that spirit, I’ve documented five of the common themes I find myself discussing with new technical leaders at Rally in hopes that it will help others looking to make similar jumps. Additionally, I’ve added a “TLDR” at the bottom of each section for those of you that only have attention spans for sentiments shared in 140 characters or less. =).

1. Your work is no longer about “you”

I can not stress this one enough. Often times in blog posts on this topic you will see similar advice around training yourself to no longer use “I” or “me” pronouns and consciously replacing them with “we” or “us” in all communications. This is great advice, but it is really just hinting at what you should be focusing on.

You are now in charge of a project and (likely) a team of engineers. You are no longer solely responsible for writing code, but instead should be working to enable those who do. Your primary focus every day should be figuring out how to keep your team free of distraction, motivated, and efficient . If you give your team the direction and runway they need, you are enabling them to design and deliver a successful solution with confidence.

Luckily if you are reading this, you have some experience being an individual contributor / engineer and you know how to help! Think about the last project you worked on directly. What distracted you from being able to get things done effectively? What caused you to waste time going down a wrong implementation path or rabbit hole? What did you find demotivating about the project?

Answering these questions is key to being a good technical leader. Watch for a time when your team stagnates on locking down requirements, context switches to take a meeting that isn’t productive, or becomes demotivated due to office politics or project ambiguity. These are all opportunities for you to step in and help the team focus. Good leaders should always be working in the periphery of a project, empowering their teams to be more successful.

TLDR: Focus on unblocking and enabling your team. Empower them and trust them to deliver when the path is clear.

2. Stay positive and develop relationships

Your team, as well as other leaders within the company, are looking to you to set the tone and tenor of the project. No one wants to work on a team where everyone is angry, defeated, or depressed, nor will anything get done if your team is combative towards others. Keeping a positive and collaborative attitude is key not only for the productivity within your team, but even more importantly outside of it. Every project will be fraught with frustrations and potential pitfalls. Your attitude and approach can change those issues from morale-deteriorating slogs to team building challenges.

Spend time to develop relationships with other teams and people throughout the company. At Rally, we are fond of scheduling regular “1 on 1” meetings both between individuals and their managers but also between peers and colleagues to help foster these relationships and conversations. As a leader, you are always focused on your team’s goals first and foremost. However, you should also be mindful of how those goals affect others within the company, how the project is perceived by others, as well as how other projects or work may affect or benefit your team.

If another team hears about something your team worked on and wants to use and build on it to the benefit of both teams, would they be likely to do this if your team is viewed as uncooperative or combative?

What happens when someone from another team builds a similar service or library as one that your team is working on without knowing or collaborating? Eventually the two projects will collide and work will be thrown away or duplicated, leading to wasted time and effort. Be on the lookout for (as much as I hate to say it) “synergy” between your team’s goals and other teams working to solve similar issues. Working together or defining boundaries early will save duplication and headaches later.

TLDR: Foster a positive attitude and collaborative relationships not only within your team, but also to other leads and teams. It will pay dividends in future collaboration.

3. Preach confidently why; ask inquisitively how

Let’s talk about leading a new project, and how to involve your team early and often.

As a tech lead, it’s your responsibility to understand the “big picture” of what the team is working on. Do the research up front and try to drill down and get answers to some of the hard questions that you know your team is going to ask. Now when the team goes to start work on it, explain (with confidence!) what the goal is, and, most critically, why it is important and what it will impact for the business.

If your team understands the importance and what the work will enable, it allows them to be accountable, proud of the work, and make more relevant decisions during implementation. You should essentially be selling the project and its goals to the team. If you aren’t excited about the project and its impact, why would your team be?

Once you have given the team context on why, now you need the team to be aligned on “how” it will be done. I’ve found that the best way to do this is to start the conversation with a suggested implementation or high-level flow diagram (I love flow diagrams) that the team can discuss. Remember you have the context for the dependencies and if other teams or services may need to be involved (you investigated that up front, right?). Pitch a starting point or “direction” for the technical implementation to get to the solution. It doesn’t have to be detailed or solve all the issues but getting everyone on the team aligned to a direction is key.

Your team should then feel comfortable riffing off of that, suggesting different solutions or figuring out a more detailed plan to implement. Don’t be defensive of the direction you proposed. The goal is to have the team come up with a plan they are comfortable with executing on and you are providing a starting point for that conversation. As those discussions continue (or after the solution is in place) be sure to validate with the team how it meets the goals you outlined and make sure you understand the approach to the level of detail where you are comfortable.

After this, you should have asked enough questions and understand the implementation plan well enough that you can confidently discuss it with other teams (who should be coming to you for any dependency questions). Trust in your team to deliver on the details, but drive and understand the direction.

TLDR: When kicking off a project, “sell ” the project to the team, propose a technical direction to start the discussion, and understand the final approach enough to feel comfortable explaining it to others.

4. Define team process and push for standards

One of the goals for any well-functioning engineering team should be that they are efficient and hold each other accountable. To do this, as the lead you should be helping define processes and team standards as early as possible to give the team guidelines on what expectations are.

Examples of the types of things you may consider defining early:

  • What are the standards for code conventions on the team?
  • Are there standard processes that can be followed for common development tasks?
  • How are releases staged, communicated, and handled?
  • What are the expectations for unit testing, release testing, and load-testing?
  • How are code reviews handled and what gates must be passed before code can be merged?
  • And most importantly: Is all of this documented somewhere?

Your team is going to be focused on executing on features and solving issues in code. If you and the team have already agreed to and defined standards for development, it will keep the team moving to the same beat and allow for everyone to hold each other to the same expectations.

For example if you see the team having a conversation about the structure of a REST API path, take the opportunity to propose a team standard they agree to and document it! Now everyone is aligned on what should be done for the work at hand and the documentation can help new team members identify the team expectations up front. (Bonus: this will help cut down on the onboarding time of future engineers!)

In addition to development standards, don’t be afraid to define process where helpful. Having a reproducible set of steps documented to accomplish a task (a release, prod support, or an API upgrade, for example) helps things run smoothly and allows for consistent capacity planning. If team members have a standard or process defined up front for an effort, they can more accurately size and estimate how long that work will take.

Of course, this doesn’t mean that there can never be innovation or derivation from these standards, but when there is it should be a conscious decision discussed and agreed on by the team because the process is changing, not something ballooning out of scope unintentionally.

TLDR: Define quality and process standards up front so the team can hold each other accountable and march to the same beat. Detailed documentation and consistency is king.

5. Communicate status early and avoid surprises

Now that you’ve got your project defined and your team is functioning, what’s next? One of the most important roles of a technical lead is to be mindful of and guide the team towards deadlines that are looming. At Rally, the technical lead of a project is expected to work in tandem with their counterparts in Product and Project Management to properly lead the team. The three together are expected to determine the next priorities for the team, define a technical plan, size out the work, and finally put together and communicate a timeline for delivery.

Once in motion, it is critical that the leaders of the team are communicating in tandem and keeping stakeholders updated on the progress of the project against the committed plan. The project manager is going to be the primary point of contact for this, but as a technical leader you need to be in sync with the status and helping make sure the project plan reflects the reality of the work.

At Rally we communicate project status with colors that indicate the relative wellbeing of a project. Green indicating that all is going according to plan, Yellow if the project is taking an unexpected turn or is potentially off track, and finally Red if the project is at risk of not completing on its current trajectory. As with all metrics, we encourage all leads to message out and record reality, not what people want to hear (See: Sam Freund’s Blog Post). It is not necessarily a bad thing to communicate out Yellow or Red for a project.

It IS a bad thing to message out Green when a project is decidedly not.

If your project is going south, it’s imperative to realize it, track the issue, and come up with a plan forward. I encourage technical leads who work with me to message out early if something is off track, but always with a plan on how to get it back on track. Messaging a Red status with a concrete plan to get back to Green is a much more useful communication than “solving it yourself”. It allows other stakeholders to understand the areas that they can assist you and your team. If you message proactively in this way, there should not be surprises to those who have dependencies or business deliverables based on your team’s work. Even if there is an issue, everyone will be aware and should be helping the project succeed.

If you find your team in a spot where they are not set up to succeed, raise the flag early indicating the issue and define a plan or path to fix it. There should never be a case where your team waits until right before a deadline to raise a timeline or scope issue for the first time. The tech lead should be working with their leadership counterparts in product and project management to keep stakeholders informed of progress and, in the case of a project that is heading off track, helping to solve potential delivery misses by (for example) re-aligning project expectations, requesting more team members to increase project velocity, or unblocking issues well before they become blockers to a committed deadline. Essentially, work with your counterparts to keep track of your team’s progress and clearly communicate status. If the project is off track, communicate that status and what actions you are taking (or planning to take) to get it back on the rails. Even if you don’t have a full solution yet, keeping stakeholders updated with what your plan is will allow them to assist where they can. Keeping alignment between everyone involved will pay off in spades.

TLDR: Once a project is moving, keep a close eye on scope and progress and be honest and clear in your communications. Call out issues early but always with a path to resolve issues. Avoid surprises to your stakeholders.

That’s it! While all of these tips may not be relevant to every organization or team, I’ve found that they should be constructive to any engineer looking to make a jump to “technical lead.” As you take on this new role and responsibility, just remember first and foremost to ask questions and get the support you need. It may be appealing to go it alone, but your organization is putting you in this position to help you grow and learn. Find a mentor or someone in the organization who you feel comfortable asking questions and “rubber ducking” solutions with. Schedule time with them regularly. You’ll be surprised to find how often issues or difficulties you are facing have been shared and worked through by others who will be happy to offer advice.

Dan Staley

Keep Exploring

Would you like to see more? Explore