As with software development, I find it useful to write down the principles that guide how I think about leadership and people management. These are not universal truths, but they are the foundations I rely on when building and leading engineering teams. By making them explicit, I aim to create clarity, alignment, and a shared understanding of how I see leadership, collaboration, and growth.
- People are not resources I don't believe in treating people as interchangeable units or "resources." People are creative, motivated, and responsible when given the right environment. My default stance is trust, not control. This aligns with Theory Y (Douglas McGregor): most people want to do good work if they are respected, trusted, and given meaningful challenges.
- Empower teams with ownership Teams work best when they own the whole problem end-to-end, from idea to operation. Ownership gives autonomy and accountability, while purpose provides alignment. An empowered team doesn't just execute tasks but makes decisions and cares about outcomes.
- Motivation is intrinsic The best results in knowledge work come from intrinsic motivation, not external rewards or pressure. As Daniel Pink highlights in Drive, autonomy, mastery, and purpose are the real drivers of excellence. My role as a leader is to foster these conditions, not to rely on carrots and sticks.
- Learning never stops Engineering and product work are constant processes of discovery. We optimize for fast feedback, safe experiments, and collective learning. Mistakes are not failures to hide but opportunities to grow. A learning culture is the foundation of adaptability.
- Enable experiments, eliminate waste, make quality inevitable My role as a leader is to create conditions for safe experimentation while relentlessly removing what doesn't add value. But more fundamentally, I must change the system so that working with quality becomes the most natural, simplest, and fastest path. This means building strong foundations, aligning incentives, and creating space for learning where teams ask "What's the worst that could happen?" with confidence. When quality is inevitable rather than heroic, we create virtuous cycles where technical excellence enables bold experiments and meaningful impact.
References:
