Engineering Leadership: My User Manual

Summary: I am a collaborative TL who thrives on clear communication, preparation, and teamwork. I have my quirks and weaknesses like anyone else, and I openly acknowledge them. By sharing this user manual, I hope you have a clearer idea of what it’s like to work with me - and I invite you to hold me accountable to these principles. Together, let’s build amazing things!

Non-technical

Culture is what happens between the lines of code

• Open sharing of ideas & inclusion. I think ideas get better the earlier they’re shared. I also believe the best ideas come from a room (or thread) full of voices, not just the loudest one. I’ll often ask for input from folks who haven’t spoken yet, because silence doesn’t mean agreement. I see my role as a facilitator as much as a decision maker.

• I encourage questions and ask for help. I’d like to make sure nobody should feel stuck or alone on a problem (for too long). If you are blocked, confused, or just curious, I’d rather you ask than spin in circles. Asking questions is not a sign of weakness - it’s a sign of learning and collaboration. I may say things like “If you are not sure, let’s figure it out together” to lower the barrier. The faster we surface challenges, the faster we can solve them as a team.

• I like motivating and empowering the team. I want people to feel ownership. I’ll try to make sure you get tasks that stretch your skills (but sometimes situations won’t allow) and align with your growth. And when you do something awesome, I’ll highlight it - in team syncs, in updates to leadership, wherever it needs to be heard.

• I’m not always right about technical things. We are surrounded by the best. Everybody’s work gets better when other smart people catch errors and help to fix them, so if you see me making a mistake, please let me know. I’ll try to fix it! Often you will have information I do not, or I made an inappropriate assumption. Sharing that is great.

• Feedback is a gift. I’ll give you feedback directly, often via doc/code comments, and I want the same from you. I mean it when I say I’d like to hear what I can do better - because I genuinely believe feedback helps us grow.

• Make meetings productive. I will try to keep meetings purposeful and on-topic. I’ll usually come in with an agenda, make sure we stick to it, and redirect if we drift too far. The goal is for everyone to leave knowing what was decided, who owns what, and what’s next - not just feeling like we “talked”. Meanwhile, I have the same expectations on meetings I attend as well.

• Life is more than just work. I try to remind the team (and myself) that while our work matters, it isn’t everything. Burnout helps no one. I encourage balance - whether that’s taking time off, protecting focus hours, or just stepping away to recharge. I want people to have spaces for family, friends, hobbies, and health. A well rested engineer is not only happier but also more creative and effective.

Technical

Good engineering is disciplined communication with machines and people alike

• Preference for documentation and preparation. I like to read design docs or proposals before a meeting. It gives me time to process and annotate, which makes our discussions more focused. So if you want input, sending me something written (even if a draft) works really well.

• Good design docs save time and effort. I believe a solid design doc upfront is one of the highest-leverage things we can do. A clear doc helps align everyone, reduces back-and-forth later, and prevents wasted work on misunderstandings. It’s much cheaper to change a paragraph than to rewrite a service - so I push for thoughtful design docs as a way to save the team energy in the long run.

• Clarity in design (data & interfaces) is important. I care a lot about clear boundaries and clean interfaces. To me, half the battle in building reliable systems is making sure every component has a well-defined contract and data flow. When APIs and schemas are clear, everything else becomes easier - integration, debugging, even collaboration between teams!

• I like hands-on code reviews and prototyping. I’m not just a “slideware” TL - I enjoy staying hands-on. You’ll often see me in code reviews leaving detailed comments or sometimes writing a quick prototype to test an idea. For me, code reviews aren’t just about correctness - they are also about clarity, maintainability, and a chance to teach and learn together.

• Execution with data-driven decisions: I have a bias toward execution - I love turning plans into shipped products - but I balance that with a data-driven mindset. I encourage the team to use clear metrics and evidence when making decisions or evaluating progress. For example, rather than guessing which part of the system is a bottleneck, I’ll suggest measuring it or examining logs/metrics. If we are discussing a feature’s priority, I’ll ask what data (user feedbacks, KPIs, etc) support the decision. I also value clean implementations that include observability (logging, monitoring) so we can see how our systems behave in real-world use. This focus on execution with data means I might push to get an MVP out to gather feedback, and then iterate based on what we learn.

My failings

Confidence is the feeling you have before you understand the situation. - Janice Thompson, Picture Perfect

• I make mistakes (and I own them). Despite being experienced, I am definitely not infallible. I’ve made my share of bad calls - whether on timeline or tech choices - and I’ll admit when I was wrong. Owning mistakes is important to me; I don’t want to set examples where people feel like they can’t.

• Thorough decision-making… Sometimes too thorough. I have a tendency to dig deep and understand things fully before making major judgments. In general, it is a strength - it means I consider options carefully and the decisions are often well-founded. But it can also be a weakness - I may take longer than ideal to make a decision, especially if I feel I don’t have enough data. This can be frustrating if you are waiting on me for a green light. In this case, a gentle nudge, perhaps a comment like “we might be overthinking this,” is often very helpful and greatly appreciated.

• I prefer async communication… Sometimes missing quick sync. I lean on written communication and preparation, I sometimes miss the chance for quick, real-time alignment. For example, I might defer a discussion until I’ve read something, when a five-minute chat could have cleared it up. This is partly my style (I think through writing), but I know it can be a drawback in a fast-paced environment. I’m trying to be more aware of when a situation just needs an immediate conversation or a decision on the fly. If you feel like we’re emailing too much and not resolving an issue, suggest a quick meeting – I’ll likely agree it’s a good idea. Additionally, because I value focus time, I sometimes get engrossed in deep work and might not respond instantly on chat. I realize that can hold you up, and I’m sorry when I cause delays. I’m not ignoring you – I probably just want to give a thoughtful answer. A nudge like “quick input needed, can you advise now or should I proceed on my best guess?” will help me prioritize. Essentially, I’m working on balancing my preference for planned, written communication with the need for agility and fast feedback loops.