Most software leads started their careers as software engineers who sought out, fell into, or got tricked into leadership. Do you see yourself in any of the following?

• You had a great idea, started a company, and are now leading a team of engineers building a product. However, you are struggling with scaling your time.
• You’ve wanted to be a software lead for years, and an opportunity has arisen. You are now stressing about how to prove yourself without screwing up.
• You are the most competent or reliable member of your team. Your current lead quit, and boom, you are now the new team lead. This isn’t your jam, but how do you get started?

Most leads that I’ve mentored have asked (in one form or another) for a “handbook to leadership.” While the best version of this is probably an Elegant Puzzle, I wanted to provide people a framework that was easy to recall in a day-to-day setting. I’ve boiled leadership down to three pillars:

• feedback (growing your team’s capabilities),
• structure (the architecture of both the code and the team’s operations), and
• direction (where your team is going and how they are going to get there).

This framework covers the majority of leadership responsibilities in an easy-to-remember pattern. If you are a new team lead and aren’t sure where to start, determine which of these three supporting pillars you are weakest in and make improvements accordingly.

The rest of this post discusses how to think about these three aspects in more detail. It mostly takes a people lead perspective, but if you want a technical lead perspective, you should check out Staff Engineer by Will Larson. Will does an excellent job explaining this topic.

If you like this post, please 👏 , subscribe, or follow me on medium or LinkedIn to let me know I’m on the right track!

• Framework: Feedback, Structure, and Direction
• Feedback
  - Work product vs work execution feedback
  - Business-impact-driven feedback
• Structure
  - APIs for teams
  - Architectures for teams
  - Follow existing design patterns
• Direction

Framework: Feedback, Structure, and Direction

As illustrated above, leadership is made up of the three pillars of feedback, structure, and direction. Your role as a team lead is to ensure that all three of these pillars are strong. If you are inheriting a leadership role, you may find that some are already stronger than others. In larger, more mature organizations, much of the groundwork may have been laid for you, but you’d be surprised how many times an “established” team has significant gaps.

If you are in a new role and feeling overwhelmed about where to start, I recommend focusing on feedback first, then structure, then direction. This order parallels how most software engineers initially build up their base skills.

• As a new engineer, you primarily write code and receive feedback on the code through code reviews and project retrospectives.
• As you grow, you begin learning about design patterns that help structure your code and architecture patterns that structure the team’s code. These patterns are like highways that enable people to move quickly and safely.
• As you master your craft, you begin seeing further into the future and set the direction of the team with a technical vision or roadmap.

You can follow the same pattern as a new team lead. Focus on creating a culture of egoless feedback in both the short and longer term with a focus on business impact and career development. Follow the existing structure of the team for a month or two before you begin making adjustments. Think about how to create highways that enable people to move quickly and freely but keep them safe from derailing. Finally, you are ready to start thinking about where you want the team to end up and can start building in that direction.

It’s worth mentioning that it’s your responsibility as the team lead to ensure that both people and technical leadership are being performed within your team. Early in your career, you can often wear both hats, but most people ultimately choose to hone their craft as either a people lead or a technical lead. In most organizations, team leads leverage staff engineers to provide the technical lens.

Next, let’s dive deeper into feedback, structure, and direction to better define your role as a leader.

Feedback

Here’s the quick version: feedback can be divided into work product feedback and work execution feedback. Work product feedback involves critiquing the concrete output, and work execution feedback involves critiquing the path the person chose to get there. The work product and the work execution combine to create a project’s impact.

Work product vs work execution feedback

The work product for most engineers is the bug fixes, features, documentation, or debugging that their company needs completed in the unending quest toward increased revenue. Work execution describes the path that a person takes to achieve a goal and is highly connected to how an individual works as a member of a team. An individual’s code could be well-written, but if they require significant hand-holding or create a hostile work environment, this severely diminishes the overall impact of the individual as a team member.

I split up these forms of feedback because, generally, technical leads are very comfortable giving feedback on a work product but are less comfortable giving feedback on work execution. This isn’t meant to be a perfect framework, but simply a quick reference you can use when preparing to deliver feedback to team members.

A good way to further break down feedback is to think about it in terms of time, as in the table below.

The longer the time horizon, the more you can talk about the concrete impact of someone’s past work. The shorter the time frame, the more feedback tends to focus leading indicators of future impact. In other words, the feedback given on day-to-day interactions has consequences in mid- and long-term results.

Helpfully, many of these feedback cycles may already be incorporated in your organization. You are probably already doing a 1:1 with your direct reports, and there will be an HR-mandated annual or biannual performance evaluation. Your job is to identify and shore up the gaps.

In a future post, I’ll write more about how to effectively give feedback, but it’s not in the scope of this post.

Business-impact-driven feedback

My belief is that all feedback should relate back to business impact. With a magic crystal ball, you could map everyone’s work back to a concrete number against the company’s bottom line. In theory, you are paying everyone less money than they earn/save for the business and more money than it would cost to replace them with someone that delivers a better delta. This sounds cold, but it’s just being honest about the function of a for-profit business. Using your crystal ball, you could look at your team like this:

Somebody reading this is going to try and pick apart examples where this model falls apart, but I want to reiterate that it is an over-simplification that depends on perfect knowledge of the cascading aftereffects of all actions.

Now, nobody actually has a crystal ball, so your ability to perfectly calculate value generated, total compensation, and replacement costs is a fantasy. However, that doesn’t change the company’s expectation that your goal as a lead is to

1. maximize the value generated and
2. minimize the delta between total compensation and competitive salary.

The reason this mentality is so powerful is that it encourages you to focus on providing the right feedback. An effective lead keeps their feedback focused on changes in behavior that will result in maximum impact aligned with the desired growth path of an individual. The lead is then able to reward tangible progress with tangible increases in compensation.

Structure

Next, we will cover the second pillar of leadership: structure. Any engineer with industry experience should have a deep appreciation for the value of good architecture and APIs. These practices enable experienced engineers to create productivity highways that enable safe and rapid development for a broader group of engineers.

Take Terraform, for example. Hashicorp created a base framework that sets the rules for how to perform model infrastructure as code. The framework enabled developers around the world to easily expand upon it. Now, thousands of other companies follow that framework to solve complex problems with ease.

Architecture controls how code is written, deployed, and scaled. APIs determine how external services integrate with code to accomplish their intended functions. You can model teams in the same way. The architecture is how you internally organize the team in order to build and support your product, and your team’s API is how external teams interact with your team.

APIs for teams

Just like in the real world, changing the API of your team is more (socially) complicated than changing your architecture. Outside of your team, no one cares how the sausage is made; they care about what APIs you expose for them to call and how the results will be messaged back to them. When you think about designing your team’s processes for interacting with other teams, try to copy the same techniques that apply to good APIs. These include the following.

• Simplicity: Interacting with your team shouldn’t be complicated.
• Well-documented: Clearly defined inputs/outputs enable external teams to provide the correct inputs to receive their desired outputs.
• Rate-limiting: Your team can’t do infinite work, so how do you communicate capacity limits?
• Stable: Be selective when making updates to your external processes. Reliability trumps speed.
• Gather consumer feedback: Have a way for people to request new or modified functionality.

In practice, APIs are how your team

• responds to requests for new functionality,
• supports existing functionality,
• performs capacity planning, and
• interacts with dependent teams (design, QA, etc.).

New leads tend to focus entirely on their team’s internal architecture and are surprised when they have difficulty engaging with external teams. As with coding, if you don’t have a great API, external teams will end up building integrations directly against your “database,” creating a highly coupled environment. For example, external teams may reach out directly to engineers to get tasks done, disrupting your engineer’s state of flow.

Try evaluating your team from an API perspective, and see if you could consider your team’s API endpoints to be well-made.

As a side note, in larger organizations, your team is likely expected to fulfill a common API (department-wide quarterly planning). Instead of seeing these processes as a drag, think of them as the abstraction layer that enables people to have base expectations of your “service.”

Architectures for teams

Your team’s internal architecture includes the processes, ideals, and roles within the team that enable the sustainable building and support of your product. There are certain processes that every team needs.

• Cycle planning includes the brainstorming sessions that prep the team for the next X weeks of work.
• Coordination is how the team communicates and shares knowledge.
• Roles are especially important for cross-functional teams where people have different skill sets and resulting responsibilities.
• Support describes how you respond to events (ranging from critical to trivial).
• Reflection and feedback allow the team to self-critique and improve.

A good architecture is scalable and stable. When you evaluate your team, can you say that your team’s architecture has those qualities? As the team lead, you are the architect of your team’s process, so consider building and improving on the team’s architecture in the same way you’d improve your technical architecture. Draft RFCs, gather feedback, and perform retrospectives. Consider documentation, onboarding guides, success metrics, and other techniques that apply to traditional software architecture. This includes scaling limitations and avoiding pre-optimizations. Finally, determine the size and complexity at which you’ll re-evaluate your process.

Follow existing design patterns

Code design patterns simplify complex code and reduce the magnitude and frequency of critical mistakes. Team design patterns do the same for your team. As an illustrative example, take your team’s support process.

Option A: Everyone on the team is responsible for responding to support tickets.

Option B: A single person (on a rotation) is responsible for support tickets.

The design pattern of a rotating engineer performing a weekly support cycle is well-established in the software industry. It solves problems such as bystander syndrome, burnout, and knowledge siloing while improving team focus. Like a design pattern, this is a safe bet that has been proven over and over again to be a scalable system. Before inventing your own convoluted pattern, start with the industry standard.

Direction

Setting the direction for your team is arguably the most difficult and impactful of the three pillars. A great structure will enable your team to move quickly and safely, and a great feedback cycle will create a constantly self-improving machine. However, neither will save you from heading in the wrong direction. Most of the time, it is better to head slowly and inefficiently in the right direction than to head in the wrong direction at breakneck speeds.

So why leave direction for the last pillar? Because it is the most difficult and has the most severe consequences if chosen incorrectly. When people first start their software engineering careers, they learn how to participate in feedback cycles. As they grow to become senior engineers, they learn how to work with and apply new design patterns. Finally, as staff engineers, they begin setting the quality direction and creating a quality vision.

Many team leads end up finding their strengths in team management over technical management at the senior engineering level, so I think there is less common ground in explaining team direction in terms of technical direction. As stated before, I highly recommend reading Staff Engineer to learn more about setting technical direction.

The direction of a team can be broken up into three parts as listed below.

1. Team vision: What should the team look like in one to three years?
2. Team roadmap: What are the major milestones between today’s reality and the vision?
3. Team principles: When given a choice between tradeoffs, how should people bias themselves?

I like to think of direction in terms of a hiking metaphor, so let’s use Lord of the Rings.

The vision was Gandalf telling the fellowship they were going to destroy the one ring in Mount Doom. This vision was clear, measurable, and compelling. Barring all else, Frodo knew what his goal was, even though he didn’t “know the way”.

The roadmap was where Gandalf failed as a leader. A good roadmap includes a path of milestones that lead to the vision being achieved. It should include alternative paths and options that the team can take depending on what the future brings. Maybe if Gandalf had done this, Frodo wouldn’t have taken the dangerous and time-consuming path through Shelob’s lair and instead would have simply flown to Mordor with the giant eagles

Gandalf’s core principle was secrecy. The fellowship chose walking instead of riding horses, took the less-traversed path of Moria instead of the heavily watched Gap of Rohan, and sent two hobbits instead of an army all in the interest of stealth. When given multiple options, the bias was always toward secrecy. Again, the entire team knew the principle, and the members were able to make decisions even without Gandalf being around.

Silly metaphor aside, every leader needs to set a vision, a path to achieving that vision, and a set of guiding principles that enable people to make effective tradeoffs.

Wrap-up

As a new team lead, it can take a while before you feel comfortable with your role. If you are struggling with how to get started, try analyzing your team in terms of feedback, structure, and direction.

• Feedback includes both work product and work execution feedback. Remember to tie everything back to impact.
• Structure describes the architecture and API for your team.
• Direction includes the vision, milestones, and operating lens that enable your team to make appropriate decisions.

If you came from a software engineering background, you can find many parallels between your growth path toward technical expertise and your new path toward excellent team leadership. For example, the qualities that make code reviews effective can also be applied to help a team member achieve their dream career.

Ultimately, your goal is to maximize the business value your team achieves by bringing out the absolute best in your people.

Interested in other leadership topics? Hit me up over LinkedIn. Thanks go to Keegan for editing.