This is a living document and will be updated as things change.
This document is a summary of how I lead and what people can expect when working with me. It is written for candidates, colleagues, and peers who want to understand my leadership approach.
You will not find a “What I expect from you” section. Expectations are not one-size-fits-all. We define them together in context, in our collaboration, and in our 1:1s. I also don’t include a section about my personal quirks. You’ll notice them naturally as we work together. If any of them ever get in your way, let me know. I don’t always see it from my side.
This README is not a shortcut for trust and not a substitute for working together. It simply reduces ambiguity about how I operate as an engineering leader.
Clarity comes before speed.
If we do not understand the problem or our goals, we end up going fast in the wrong direction. I make sure we are aligned before we move.
Short feedback loops reduce risk.
Working in small increments helps us learn faster, avoid unnecessary complexity, and make better decisions with less risk. I prefer progress through iteration rather than big, speculative moves.
Ownership enables great work.
I give people room to solve problems and make decisions. My role is to remove blockers, not to micromanage how you work.
Psychological safety is essential.
Questions, concerns, disagreements, and mistakes are welcome. Good teams depend on an environment where people feel safe to speak up and learn.
Transparency builds trust.
I say what I mean, kindly and clearly. When I have context, you’ll have it. If I agree, you’ll know. If I disagree, you’ll know. I don’t hide my views, sugarcoat, or play politics.
Continuous improvement.
Good engineering comes from steady, thoughtful improvement. It’s part of how we grow as individuals and as a team.
I create the conditions for people to succeed.
In experienced engineering teams, problems usually come from the surrounding system, not from the individual. I assume capability, potential, and positive intent by default. If something in the environment is unclear or blocking progress, I surface it early and work to improve it.
I collaborate across functions, not in silos.
I work closely with product, design, data, operations, and any other partners who help us succeed. Effective collaboration comes from shared understanding, aligned goals, and direct communication, not handovers or isolated responsibilities.
I help you think things through.
I do not prescribe solutions. I ask questions, explore tradeoffs, and seek to understand systems deeply before helping you think things through and decide. How hands-on or decisive I am depends on your seniority and what you need at the time. You set the pace for how much guidance or freedom you need, and we adjust together based on what helps you succeed.
Own your work.
Ownership is something we share. Title does not decide who owns something, initiative does. If you see something that needs ownership, take it. I will support you and help you succeed.
Ask, don’t command.
I work best when communication is collaborative. Clear, respectful requests with reasoning are far more effective than being told what to do without context. I hold myself to the same standard.
Experiment, don’t speculate.
Discussion is important, but clarity comes from doing. When a problem is ambiguous, I prefer small, low-risk experiments and fast feedback over long theoretical debates. We learn faster and reduce risk by validating assumptions early.
Let’s continuously improve together.
I believe in fixing small problems before they become big ones. Quality is part of how we build, not something we tack on afterwards. Steady improvements to tooling, code, process, and product compound over time into better velocity and more reliable systems. This includes non-functional quality such as clear documentation, thoughtful abstractions, tests that give us confidence, strong performance characteristics, great usability, basic accessibility, and secure foundations.
Gain a shared understanding of quality
Quality does not mean the same thing in every organization or team. What level of quality we aim for depends on factors such as company stage, team composition, risk tolerance, and engineering culture. Misaligned expectations about quality often lead to friction, rework, and frustration. Because of that, it is important to me that we explicitly build a shared understanding of what "good" means for us in a given context.
Calm, predictable leadership
You can expect steady, predictable leadership even when priorities shift. When things change, I explain why, what changed, and how it affects the work. I don’t micromanage, but build teams that can operate confidently and independently.
Direct, respectful feedback
I give clear, respectful feedback focused on impact and expectations. I address issues as soon as I’m aware of them and offer support where needed. Feedback is about clarity, growth, and helping you succeed, never about blame.
Psychological safety in practice.
I create an environment where people can raise questions, voice concerns, challenge ideas, and share perspectives without hesitation. I make sure quieter voices have room to speak, and I value thoughtful disagreement as much as agreement.
Psychological safety applies to me as well. If something I do creates confusion, slows you down, or doesn’t match how I aim to lead, you can bring it up. I may not always see the impact of my actions from my side, and I take that kind of feedback seriously.
A focus on continuous improvement.
I look for ways to improve how we work and the quality of what we build. I see improvement as a shared responsibility: reducing friction, refining processes, and strengthening our systems step by step.
Flexibility around working hours
You can Slack or email me at any time, but my flexibility is not an expectation for anyone else. I sometimes work outside typical hours because of life responsibilities or focus time preferences. This is my choice, not a signal that you should be online. If I message you outside your working hours, you can safely ignore it until you're next working. I don’t expect instant responses, even during working hours. I trust you to respond in a reasonable timeframe based on the context and your workload.
I hold regular 1:1s with everyone I manage. The cadence depends on my team, your needs and seniority and the pace of work. If one of us needs to move a 1:1, we reschedule — we don’t skip.
1:1s are your space. They exist so you have a safe place to talk about what matters to you. A 1:1 is not a status meeting. Bring whatever is on your mind: progress, challenges, decisions, questions, ideas, or concerns. We use this time to:
Provide context.
I share relevant information early. This includes company direction, organizational changes, upcoming priorities, or anything that helps you see the bigger picture. If you need context I have not shared yet, ask. It is always welcome.
Align on expectations.
Expectations are shared understanding about what good looks like in your role and seniority and how your work connects to team and company goals. We use our 1:1s to foster that shared understanding so you never have to guess.
Set goals.
If you want to grow in a certain direction, develop new skills, stretch into a role, or take more ownership, this is where we talk about it. Goals should be realistic, meaningful, and connected to the work rather than a checklist.
Give feedback.
I use this time to give you feedback that helps you grow, unblock, or adjust direction. If you have feedback for me, this is also a good place to share it.
Remove blockers.
If something slows you down, bring it here. My job is to improve the environment, not to push problems down to individuals. We will work together to surface and resolve systemic issues.
I lead remote and distributed teams, so communication, clarity, and thoughtful collaboration matter deeply. Our ways of working evolve with the team, the product, and the organization, and parts of this document will naturally change over time as we learn together.
My goal is to build an environment where people grow, support each other, and build long-lasting software they are proud of.
This README is not a contract, but a snapshot of how I think about leadership today. The real understanding comes from working together, giving each other feedback, and adapting based on what helps the team succeed.