My leadership philosophy

What is this?

This living document is intended to capture my beliefs as a manager. It has two broad audiences—myself, to force myself to process my own beliefs; and peers, direct reports, and bosses, as a starting point for conversation.

First, two important caveats. The first is that this is not an immutable document. Like my views on management, this document is a continuous work-in-progress and changes often. I’ll learn and adjust as I go! The second caveat is that none of this is novel. This is built upon things I’ve learned from others, books I’ve read and other sources along the way. I’ll try to note them when possible.

As a reader, let me know what you think and let’s talk!

1. Service-oriented leadership

This is the classic one. Traditionally this is called servant leadership, but I prefer the service label. Slightly different word, same meaning. What does this mean to me?

• It means that I am here to serve my team. My fundamental purpose as a manager is to elevate my engineers and the team to have an impact and be happy. Some of the core ways I do that are by removing the team’s roadblocks, providing the team guidance and direction, and assisting the team in fulfilling their career ambitions, among other things. Notice that every role I mentioned there concerns the team. Without a team to support, I am unnecessary.

• It means that I am only successful when my team is successful. I should be measured by the success of my direct reports and team as a whole. Keeping my team happy with their work life—with the support needed to enable a productive work environment—is my number one priority. Anything that gets in my team’s way of being happy and productive is where I should focus my efforts. As Andrew Grove said in High Output Management:

  [T]he performance rating of a manager cannot be higher than the one we would accord to (their) organization

• It means that I am against process that only serves me. I’ve been on teams before where I have been asked to follow process that only seems to benefit the manager and not the individual contributors on the team. The most common ask is around reporting. If I’m asking my team to do something out of their way just so I can measure or report on something that only management cares about, it is likely not in the best interest of the team to use their time on that. I’ll do my best to do this for the team myself or shield the team from the request in some other manner.

2. Grow and celebrate

I aim to be intentional about career growth and celebrating wins (both individual and team) as they happen. A core portion of my job is to help engineers on the team realize their potential. What does this mean to me?

• It means that I give my direct reports feedback early and often. Evaluation feedback should not be infrequent or greatly surprising. If an engineer on my team is surprised during an evaluation period, I’ve done a poor job of communicating and collaborating on their performance. I expect myself to check-in with my team frequently and communicate clearly how they are doing. Kim Malone Scott describes the value in this in Radical Candor:

  Giving guidance as quickly and as informally as possible is an essential part of Radical Candor, but it takes discipline—both because of our natural inclination to delay/avoid confrontation and because our days are busy enough as it is. But this is one of those cases where the difference in terms of time spent and impact is huge. Delay at your peril!

• It means that I give my team opportunities to grow. It can be frustrating as an engineer to feel stagnant. I give my team actionable feedback to achieve their goals and assist them in finding opportunities to demonstrate those behaviors. This won’t always be possible—perhaps the company’s needs and the engineer’s goals are not directionally compatible. In these cases, I’ll be honest about the lack of opportunity. This might be where the next point comes in to play.

• It means that I support career transitions. I want my team to feel comfortable discussing a potential future not on my team or in a different role if there are ways they want to grow that are not supported by their current team. I support engineers and help them grow, regardless of whether it’s possible on my team or not.

• It means that I celebrate wins by preference and never provide constructive criticism publicly. I always defer to an individual’s level of comfort when celebrating wins. I’d love to share them publicly, but If the engineer doesn’t want to share them publicly, I won’t! I never provide constructive criticism about performance or mistakes publicly—that’s toxic.

• It means that I give my full attention in 1:1s. 1:1s are important report-driven meetings that should not be attended carelessly, or frequently canceled/rescheduled. If for some reason there is a production fire or other interruption that prevents us from having a meaningful 1:1, I’d prefer to reschedule over only partially being able to pay attention to my team. In practice, I strive to keep 1:1 rescheduling for conflicts on my side to a minimum. I strive to be on time and attentive during 1:1s.

3. Lead and defend

This section is about respect. I am to exemplify behaviors I want to see out of the team—it’s hard to respect a leader when they’re asking you to do things they either can’t or won’t do themselves. I’ll respect their time and make sure we’re using it in the best way possible. What does this mean to me?

• It means that I lead by example. I do not ask my team to exemplify behaviors that I do not show. If I want my team to have high ownership, I’ll exemplify that ownership. If I want my team to be accountable for their word, I’ll be accountable for my word. I join in frontline engineering work where appropriate, while also acknowledging that it’s easy to get in the way as a manager due to time constraints—it’s a balance.

• It means that I protect my team from unnecessary requests. One function of a manager is to protect their direct reports from incoming requests that are not high priority. I will protect my team from requests that don’t serve to move our team towards its goals. When possible, I will gather as much information about a request and its purpose before bringing it to the team so that there are meaningful actions we can take on the request.

• It means that I am transparent everywhere I can be. By default, if I can be transparent, I will be. Hiding information from my team does not make the team better. I will properly qualify when I don’t know an answer fully.

• It means that I am equitable and inclusive. I will treat everyone equally. I will treat my engineers with respect. Diversity makes us stronger. I will hold the team accountable for being inclusive.

Conclusion: my promise as a manager

My promise as a manager is that I will strive to do these things and more. I am always open to being wrong. I will never stop growing and improving myself. This document will grow and change over time as I do. Thank you so much for reading through this—let me know if you’d like to talk about it!

Appendix: Influences

I intend to flesh this section out a bit more with the why and how, but here are a few books that have influenced my way of thinking as a manager. Listed from most-to-least influential on my beliefs.

• Radical Candor by Kim Malone Scott
• Peopleware by Tom DeMarco
• High Output Management by Andrew Grove

Have a recommendation? Let me know!

Appendix: Things not yet discussed

My list above is not exhaustive. I’ve noticed it excludes these topics—among others certainly—

• The role in setting direction
• The role in challenging situations