Welcome!
This exists to give you some insight into how I think about leadership, what to expect from me, and a bit about what I expect from you. Most of this will come out organically as we get to know each other. This serves as a place for me to gather my thoughts and share them succinctly.
One of the most important parts of my role is to maintain and elevate team culture as culture is what drives us. Likewise, it is equally important that I have deep domain/technical knowledge of my teams' products. This allows me to properly ensure my teams are charging in the right direction and making good progress.
I'm a firm believer that work is a function of people and environment. Therefore, my main job is to make sure the team has the "right" people and an environment that supports them to do great work.
Who's the "right" person for a team? In short, an ideal team player is what I mean by "right" - that's someone who's humble, hungry, and smart (EQ). I'll take an ideal team player without relevant experience over a non-ideal team player with relevant experience any day of the week. The hunger alone will help that ideal team player bridge the gap in short order, elevating the team, whereas the non-ideal team player may be able to hit the ground running but will bring down the rest of the team over time. Another way to put this - no brilliant jerks!
The work environment is primarily made up of a set of behaviors, and culture is the byproduct of the behaviors you tolerate. Therefore, I work to discourage negative behaviors such as gossip and to encourage positive behaviors such as public praise.
A quick note on gossip: You should pass negatives up (to your manager(s) privately) and positives all around (share with everyone publicly). Sharing positive comments with coworkers helps foster more positivity. Sharing negative comments with coworkers will help foster more negativity, and, furthermore, generally your coworkers can't help resolve the conflicts. For instance, if you have a problem with your computer, chances are the coworker you're complaining to won't be able to help, but if you let your manager know about your issue, he/she can (and is motivated to) work to resolve the issue. This is more about comments or gossip than feedback. There's a whole section on feedback below.
This one is pretty obvious as it facilitates many of my responsibilities. I need to have deep domain knowledge in order to hold my team accountable, guide the technical direction, and advise on the technical feasibility of new features/products.
"Guide" is the key word here. I need to make sure we're headed in the right direction and setup guardrails where necessary. When I see us going off course, I'll make suggestions and nudge us to get back on track. Sometimes, I'm the sanity check (and other times I need one - ha!).
I'm a fan of using OKRs (Objectives and Key Results) to accomplish this. They help us to set goals and evaluate our progress and success.
As the team is "heads down" on new features and daily deliverables, I work to keep my head up to see what's coming and make sure we're heading in the right direction. Sometimes I'll run out ahead to scout the area to see which way we should go.
This doesn't mean I won't involve the team in direction. In fact it's quite the opposite. I seek feedback, suggestions, and ideas from everyone on the team.
Additionally, while working with stakeholders, it's imperative for me to know if a suggestion or new feature request is technically feasible. Likewise, if there's a question on how something works, I should be able to explain it in low level (or close to low level) detail. This allows the team to stay focused and not be answering every little technical question. Similar to "Keep my Eyes on the Horizon", this doesn't mean I won't involve the team in stakeholder and business meetings. I believe in giving engineers ample opportunities to get in front of stakeholders. However, it is important to find the right balance of meetings and development time.
At its base, servant leadership is about leading with others in mind - thinking "you" not "me". This also means that I won't ask you to do something that I'm not willing to do myself.
I believe in empowering my team through providing a clear roadmap, vision, and context. You're the main character in this story (while I'm playing a supporting role - think "guide"), and I want to make sure you have everything you need to succeed.
Also, I trust that you don't need me involved in every decision. You have the day-to-day context and, if I'm doing my job, the global context/vision required to make most decisions. That said, there's a balance here, there are some decisions I definitely need to be involved in, and there are some where I may not need to be involved but I should at least be aware of the decision. In the beginning, we should lean more towards keeping me aware of most decisions with that diminishing over time. This goes hand-in-hand with building an Intent-Based Environment.
Davidson's Basketball Coach Bob McKillop gives his players a talk about his "canoe theory." Growing up camping, backpacking, and canoeing, it stuck.
As a team, we need to act like we're all in the same canoe out on the water. If we want to go anywhere, we need to be paddling in the same direction. If we want to go anywhere fast, we all need to be paddling.
Likewise, team ownership is shared. We win or lose as a team. To take this analogy further: I can't see everything in the water at the same time. If someone sees a rock up ahead that isn't called out, call it out. Otherwise, we may hit it and sink our canoe.
It's easier to be kind to one another when we know we're all real, live humans. Sounds simple right? Well, when we're just a name behind an email address or slack handle, it's pretty easy to forget that there's actually a person behind that name. Spending time getting to know one another not only helps with this but can also improve communication in everyday work as you will learn each person's personal communication style.
Whether you intend to or not, everyone brings non-work "stuff" to work, and that's perfectly normal and expected. If you didn't, you'd be a robot. So, if you have any non-work "stuff" that's affecting your work, please let me know. You don't have to share the details, but simply saying something like, "I've got some personal things going on that are making me grumpy today." helps me to know it's not me, a coworker, or your current project making you grumpy (if it is a coworker or current project, please do share those details!). Likewise, let myself and the team help celebrate your non-work wins as well!
Now that we're all treating each other as humans, last but not least, I'm a firm believer that everyone has the right to be included and that we're stronger together. Everyone has a unique background, and each unique point of view ensures that we can arrive at the best possible solutions.
If you don't know something, ask! I would much rather have you ask about something you don't know upfront than to find out weeks later that you didn't ask about something you were unsure of. You'll often hear me say something like "Silly question but..." or "I may be behind the times here..." or "What's that acronym stand for again?"
You have to get out of your comfort zone to grow. I've found that the times when I've had the most explosive growth in my career have been when I don't have a clue what I'm doing, but I dig in anyway.
Your career path is yours to own. I'm here to help guide and facilitate. My aim is to give you big opportunities to stretch and grow you towards your goals, but I can only do so if you share those goals with me.
I'm a big fan of pair programming. No matter who I pair with, whether it's a junior developer or the most senior person on the team, I always learn something. Sometimes it's a new keyboard shortcut, and sometimes it's a new pattern to go research. Working together makes us better!
I find that curiosity drives innovation. A lot of patterns in software engineering come from other industries. Thus, diving into something that's not software related can be more than just a "distraction." Likewise, in software engineering, asking why something is built the way it is or asking for motivation or reasoning for something can lead to better outcomes. When the answer to "Why?" is "Well, it's always been done that way." that's a signal to take a deeper look.
I'm super curious by nature. This drives me to ask questions like, "Why did you do X?" I'm looking for insight into your decision making process. I find this also helps me to develop a better understanding of best practices as our tech ecosystem evolves.
We're all human, which means we're going to fail - mistakes happen. Failure is even more certain when you're experimenting. If you're not experimenting or getting out of your comfort zone, you're not growing. So, it would be illogical to not expect some things to fail. Just like Thomas Edison said, "I have not failed. I've just found 10,000 ways that won't work."
Now, we should not fail due to negligence, and when we do fail, we should make sure to learn from it to keep from failing the same way continually.
So, if we're not failing, we're not trying hard enough.
I'm a huge fan of Agile and teach an introductory course on it. Instead of being strict to a certain process (ie Scrum), I'm a believer in the principles from the agile manifesto and the software craftmanship manifesto. I'm flexible on how the team applies those principles. Similarly, I'm very fond of Kanban principles as they can be applied to any process. You'll hear me repeat these often.
Last but not least, I believe we need to have fun. In order to maintain a consistent velocity, we must enjoy ourselves and what we do. So, don't take yourself or your work too seriously. It doesn't mean we're never serious. For instance, keeping PII secure is no laughing matter.
I will always make myself available if you need something. Feel free to slack, email, text, or call - anytime. Likewise, I will generally slack you for anything. If it's not urgent or I know you're probably not on slack, I'll most likely email you. If it's after hours, I do my best to set a reminder to message you on the next business day.
If it's urgent (after hours or not), I'll start with a slack and escalate to text/call if necessary. Generally speaking, this shouldn't happen. If we have the need for after hours support, we should already have an on call rotation.
I do my best to live my life as an open book. If you ask me about something even if it's personal, I'll probably answer it.
I'm a big believer in being radically candid - from Radical Candor by Kim Scott. Here's a great article on First Round Review that sums it up. Two requirements for being radically candid are for us to have psychological safety and for the feedback to be real-time. In short, to create psychological safety, my aim is for work to be a place where you can be fully you.
Another aspect to creating a psychologically safe environment has to do with how we handle positive and negative feedback. In general, feedback should be shared privately in real-time. Similar to my gossip note, positive feedback is generally okay to be shared publicly. However, negative feedback (or feedback that could be perceived as negative) should never be shared in public - always share this privately.
1 on 1 time is your time. We can use it however you'd like. If you don't have anything, I'll have some questions or meaty conversation starters to get us going. Spending some of the time talking about non-work topics is great too as it helps to build the relationship.
Generally speaking, I like for us to meet weekly at first, then every other week as we get going (assuming I'm pretty well plugged in with the team). I'm flexible on this.
My dad was in leadership positions for most of his career. From watching him while I was growing up, I subconsciously learned many things from him. One of the things that's stuck with me is a simple "success" framework he created that he would share with his teams. Here are the steps:
- Show up - That's it, just show up! If you show up, you're doing better than 78% of people (fairly certain he made up these percentages, but hey, seems legit, right?).
- Show up on time - This means you may have to routinely get in early to ensure you're there on time. If you do this, you're doing better than 82% of people.
- Start work when you get there - When you get to work, do you first take time to check your personal email or grab breakfast or coffee? That's great, not a problem, just make sure you're there early to do those things before the workday starts. If you do this, you're doing better than 93% of people.
- Work the full day - This doesn't mean you shouldn't take breaks or have celebrations with the team. It does mean that you should spend your work time, working. I've found that by working all day, you can amaze yourself with how much can actually be accomplished in a day, week, month, etc.
- Don't lie - It seems like this should go without saying. I can't accurately assess the situation or a host of other things if I don't know the truth. So please tell the truth, and I'll promise to do the same.
When I first started getting into leadership, I felt out of my depth. So, I started reading. In no particular order, these are some of the books I highly recommend:
- Leadership and Self-Deception: Getting Out of the Box
- and it's companion book (same overall story, different vantage point): The Anatomy of Peace: Resolving the Heart of Conflict
- Turn the Ship Around! A True Story of Turning Followers into Leaders and other material by David Marquet
- Extreme Ownership: How U.S. Navy SEALs Lead and Win
- Material and books by Patrick Lencioni:
- Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations