What does it mean to be an engineering leader?

As an engineering leader, you have an important role to play in the growth of people, products, and the organization.

Your job is not to manage people, but to manage processes and lead people.

You manage processes on how you expect work to be done, where each person's responsibilities start and end, how their careers are made, and how all this can be discussed, and/or changed.

You lead people by example and through empathy. They have goals, fears, motivations, and lives outside of work. Act as you would want them to act if the roles were reversed.

Working with your engineers

Align on “why”.

As engineers, we tend to focus on the “how” – the implementation details, the technical solutions – but it’s equally important that your team members understand why they’re building what they’re building. Ensure they have a clear picture of how their development work fits into the rest of the platform and the organizational strategy; understanding the “why” leads directly to better decision-making and more thoughtful solutions. Assume (and encourage) positive intent.

Trust, collaboration, and psychological safety are essential for innovation and problem-solving. When team members believe their colleagues are acting with good intentions, it reduces misunderstandings, minimizes conflict, and encourages open communication. Ensure you and your team focus on solutions rather than assigning blame, and create an environment where constructive feedback is embraced.

Give (and receive) timely, candid feedback.

Honest feedback allows individuals to identify blind spots, refine their skills, and align their efforts with team goals. It fosters accountability and ensures that issues are addressed promptly, preventing small problems from escalating into larger ones. Leaders who encourage a culture of candid feedback create an environment of mutual trust, where team members feel empowered to share insights and challenge ideas, driving innovation and excellence. Meet regularly with your engineers, both as a group and in individual 1:1s, to create consistent opportunities for open dialogue. Set clear expectations, and expect the same from your team.

Create a safe environment.

Treat failures as learning opportunities rather than occasions for blame. Team members are more likely to share concerns or report issues early when they know they won’t face punishment for doing so. Encourage team members to suggest new ideas or alternative approaches without fear of judgment. Run blameless postmortems and retrospectives to analyze challenges objectively, focusing on systemic improvements rather than individual fault.

Create a productive environment.

Equip the team with the best tools and resources to succeed, while shielding them from organizational distractions and unnecessary politics. Put performance over presence, and quality over quantity, to ensure that efforts are impactful rather than merely visible. Minimize interruptions, and be mindful of timezones and external obligations when scheduling meetings. Encourage team members to actively participate in conversations. Work with engineers to define a viable career path and create opportunities for learning and advancement, and periodically look at your team to make sure we have the right people in the right roles.

Encourage continual improvement.

Technical debt is inevitable: requirements and business needs change, legacy code ages, and bugs are patched quickly and not always cleanly. Encourage developers to improve the application while working on their projects. Turn copypasta into reusable objects, and break up large objects that are difficult to maintain and reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. Recognize when a codebase has exceeded its useful lifespan and move to replace it with something better.

Fixing tech debt isn’t a standalone project – if you treat it as such you’ll eventually find a reason to abandon it entirely because it’s impacting deadlines. It should be something engineers do all the time during their normal development activities.

Working with the organization

Share your team’s solutions and practices.

Make sure other teams know what your team is working on to avoid duplicated effort. Sharing solutions doesn’t just save time; it can spark new ideas. Sprint demos are a great starting point for showcasing your work, but look for other ways to connect, like cross-team meetings, shared documentation, or informal discussions, to ensure everyone is aligned.

Understand solutions built by other teams.

Stay informed about what other teams are building and how their work might complement your own. Whether it’s tools, processes, or features, leveraging their solutions can save time and resources while strengthening collaboration across the organization. The more you understand what’s happening across teams, the better positioned you’ll be to avoid duplication and maximize efficiency.

Share your perspective with your team’s leadership group.

Your technical expertise offers valuable insights. Share your perspective with your team’s product, project, and program managers to highlight low-hanging technical opportunities they might not be aware of. Similarly, they may have product or roadmap knowledge that can help inform your own decision-making.

Working with your upstream management

Ensure management understands the value of the software the team creates. This includes demonstrating team's work and showing incremental improvements. Ensure your team’s efforts support organizational goals (and work with your leadership to understand those goals). Regularly communicate the team’s achievements in terms of business value, such as increased efficiency, enhanced user experience, or revenue growth, to bridge the gap between technical efforts and strategic goals.

Challenge the status quo.

Always be on the lookout for ways to make things better – whether it’s improving workflows, upgrading tools, or cutting down on inefficiencies. Keep an eye on infrastructure costs and find smarter ways to spend without sacrificing performance. Pay attention to what’s slowing engineers down, and look for ways fix those pain points.

Working with your customers (internal and external)

Bring customer feedback to the team.

Every bug ticket or feature request is a chance to refine your product and better meet user needs. Share this feedback with your team to help them understand the real-world impact of their work and prioritize fixes or enhancements that matter most.

Ensure top-level support and uptime.

Keeping our products reliable and running smoothly is non-negotiable. Take charge of observability to monitor performance, detect issues early, and respond quickly when problems arise. Own the process of software upgrades to ensure your applications are always operating on stable, supported versions.

Build tools for internal customers.

Empower your internal teams by creating tools that make their jobs easier and more effective. Whether it’s analytics platforms, dashboards, or customer support tooling, these resources help teams make informed decisions, streamline workflows, and provide better service, which ultimately drives the success of the entire organization.

Understanding success as an engineering lead

An engineering lead's success can be measured by their agreement with the following statements:

• I and my team understand what we’re building, and why it matters to the customer and to the organization.
• We understand how our projects mesh with other teams' work, and how they fit into the organization’s overall goals and strategy.
• My team members volunteer new ideas and suggest alternative approaches to their tasks. I help my team make decisions; I don’t make decisions for them.
• My team is reliably able to predict the duration and complexity of a given task. We understand the requirements clearly before we start building. We routinely meet our sprint commitments and neither over- nor under-commit.
• Our code is readable, stable, and maintainable. Everyone on the team has the ability to recognize what mediocre, bad, or excellent work looks like. We take ownership of, and pride in, our work.
• When something goes wrong, I learn about it quickly – whether via observability tooling or by a team member raising the issue before it gets that far.
• We are able to remedy problems without panic or excessive disruption. We work to ensure that the same problem will not occur again.
• I understand each of my team members' strengths; their weaknesses; and their career goals. I’m also aware of my own strengths and weaknesses, and help my team in ways that play to my strengths.