Home › Posts › Aug 07, 2024

My Values for Technical Leadership

When I joined a new team last year, I was charged with helping us define our team mission, vision, and values. I'll post about that process at some point but I wanted to share what I came up with as my own values to share with the team, adjusted a bit since it's been a year.

I don't memorize these or recite them in the morning to myself or tattoo them anywhere. I use them as general guidance when I'm stuck on a problem or if I can't decide on a direction. They are also helpful when I'm doing something with high visibility and anxious about the outcome. Once I've reviewed that document for the 10th, 100th, 1000th time, I go back to my values and make sure what I'm producing is in alignment.

Two quick things to note:

This list is non-exhaustive and is focused on values in technical leadership rather than general professional ones.
I can't think of one single thing on this list that I came up with completely on my own. My values are what they are by working with and around smart and talented people. Anything quoted is directly from someone else.

Access your beginner's mind

I wrote a whole post about this. In short:

Whether you're just getting started or a seasoned veteran, we need you. We need your experiments and your questions and your feedback. Your lack of understanding is a valuable attribute that goes away as you gain experience. Ask all the questions and give all the feedback because we're all better off for it. Your courage will be rewarded.

You've probably heard this phrased as "there are no dumb questions." Nod towards the need for psychological safety in order for this to feel comfortable.

"Write. It. Down."

I can't think of a better way to think than to write. I consider writing a superpower that anyone can develop and one that amplifies any other talent that you have. Even if you're not willing to put in the time to improve, putting your ideas into words is never wasted time. Even just taking notes while you work can lead to new insights, new connections, and better understanding.

Credit to Mark Voelker.

"Never judge a decision by its outcome"

The comic linked below says it all. Give yourself credit when you did all the research, talked to all the people, took as long as you needed to take, and did your best even if the outcome was a disaster. Unknown unknowns and unpredictable externalities can take control at any point. Use the outcome to improve your decision-making process, not to beat yourself for knowing something you couldn't have known.

Credit Work Chronicles

Get to the bottom of the request

I find this to be quite powerful when done correctly. If you're being asked to design or build a particular system that does a particular thing, you could quick just to the "how" without a second thought about the "why." That system you're thinking about has a purpose and the way it was initially described is one of many different ways to achieve that purpose. Understanding the purpose helps you work on the right things in the right order. Consider using the 5 Whys or simply asking "how will we know that this project was a success?"

Credit to Peter Fernandez and Keavy McMinn

Leave things better than you found it

AKA "Scout's motto." If every addition to a code base or body of documentation or data schema came with a small improvement, imagine how much technical debt could we save! There is a natural balance here with the scope of what you're changing but the effort to, say, rename a method to improve understanding or adding a clarification around a concept is much lower when the system is already in your head.

Credit to José Fernando Romaniello

Empower others

This comes in a lot of different forms and can be tough to practice if you're working in a toxic or unsafe work environment. That said, I have never once regretted taking time out of my own forward motion to answer a question, pair with someone, mentor someone, improve a document, provide feedback, or anything else that enabled someone else to move forward. This helps

Use data to answer important questions

Like so many things on this list, this is a balance. I hesitated using the term "data driven" here because, sometimes, you don't have good data to act on. The purpose here is to leverage the data you already have and add the data that you need. The questions to answer are:

❓Why are we building this system? In other words, what data points do we want to change?

❓How can we continually validate our initial assumptions? In other words, what data can we collect along the way?

❓ How will we know that this system is successful? In other words, what data do we need to start gathering before completion?

"Visit the engine room"

This is particularly for architects but is valuable for anyone that moved on to another role, like manager or product, after being a front-line engineer. If you have moved on from contributing code to a project but are still in a position to influence the direction, it's important to see how the parts are operating up close. This is not so you can sub in as an engineer if needed, but so you understand the system beyond just conceptually. Enjoy being wrong!

Architects must visit the engine room. Not to deliver code but to re-emerge with new insights.

Credit to Gregor Hohpe

Don't fear the organizational side quest

As soon as I heard the term "organizational side quest," my whole perspective on these types of situations changed. If you're blocked on a project and that block takes you to other teams, divisions, or even companies, pay attention. The organizational friction you're feeling is a path to growth and greater understanding. You could also say "the obstacle is the way" if you're feeling stoic, or "get curious" if you're feeling mindful.

Credit to Tanya Reilly