Let’s talk about something that’s been on my mind for years—and even more so over the past few months: Leadership. Leadership. Disclaimer: This is my personal take, based on my experience. No universal truth here—and definitely no checklist. Disclaimer: I’ve read a lot of books and articles on leadership. Many of them are filled with phrases like “you should,” “you must,” or “this is the way.” This post isn’t like that. I’m not writing a guide. I’m sharing a feeling. A lived-in philosophy. Some of it might resonate with you. Some of it might not. That’s totally fine. What I’ve learned comes from being in the middle of it—not from the outside looking in. The topic of leadership keeps popping up in my bubble lately. Maybe because I’m actively looking for it. 😅 But what I often find missing in books and articles are specific examples or solutions. So, here’s my attempt to contribute my own perspective—and my story. My Story Back in 2017, I had the chance to start leading a small team—just four people, with interns joining now and then. I was new to leadership, so I started reading everything I could find about teams, leadership, and organizations. Some books were incredibly valuable. Others had conflicting views. That’s okay—I do too. What mattered most to me from the beginning was creating a place where people actually wanted to show up. A culture that made work feel energizing, even when the project, the weather, or the world outside wasn't. I wanted work to feel like playing in a band—everyone in sync, creative, focused, and having fun. Because, let’s face it, most people spend more time with their colleagues than with their friends. To support that, I introduced rituals and organized after-work activities like movie nights (yes, with tech documentaries!), game nights, or a relaxed evening at the bar. It was never mandatory—just something people genuinely enjoyed. That was my first step into building culture. And the first lesson I learned: if you want your team to show up, you have to show up. So I did. I made time. I was present—for questions, for fun, for support. I was lacking some skills and wasn’t the most experienced or confident, but I made myself available—investing time to make up for what I lacked. Sometimes being present is what matters most. you Over the years, I improved through reading, watching, and often trial and error—gradually building up the skills I didn’t have in the beginning. Not every idea resonated. For example, I often came across comparisons between software teams and sports teams. But that analogy never really sat right with me. I wasn’t trying to coach from the sidelines—I wanted to be in there with my team, supporting them side by side. Eventually, I was leading multiple projects at once—sometimes up to seven. 🤯 I had to rely on my team. And I learned that the only way to truly do that was through honesty. I admitted my mistakes. I took responsibility. And by doing so, I created an environment where others felt safe to do the same. Slowly, we built a culture that embraced failure as part of the process. Still, I had to learn the hard way that trying to be involved in everything doesn’t always help. I struggled to fulfill expectations and handle all the tasks I took on. Sometimes I slowed things down instead of speeding them up. But when I found the right balance, I could give the project a real boost. That lesson taught me to trust the team more—to stay close, but not too close. Support without blocking. This trust became the foundation for everything. We discussed every big topic as a team. That built transparency. Transparency built ownership. And ownership lead to commitment—even to the boring or painful tasks. If someone asks me how well I’m doing, my answer is always: as good as my team. as good as my team. Working on the team is working on myself. Every investment pays off. If I follow a rule—like writing clear commit messages, documenting features, or describing issues properly—I do it for my team, not just to fulfill a policy. A good policy should serve the team, not the other way around. That may sound radical. But in a great team, these practices become a shared act of respect—not because they’re enforced, but because everyone wants to support each other. What Came Next By 2024, I'd developed most of my leadership philosophy. Despite continuous efforts to improve the situation for myself and my team, I was facing challenges beyond my control—things I couldn't influence or change, despite my best efforts. I never wanted to leave my team behind. I tried everything I could before making the tough decision to move on. Leaving wasn't easy, and it certainly wasn't a decision I made lightly. But I left with a strong opinion about what great leadership can look like. Even though there were tough moments, I remain grateful for the people I worked with and everything I learned. Here are a few of my key principles—things that aren't always found in management books but make all the difference for me. Note: While this is based on my experience in software development, I think most of it applies to any team-based, creative work. Note: While this is based on my experience in software development, I think most of it applies to any team-based, creative work. Everyone Has Everyone's Back The most powerful (and simple) rule: teammates support each other. It should be more important to help a teammate than to finish your own task. That’s how you build a team that’s greater than the sum of its parts. Support builds trust. Trust creates communication. And communication ensures no one feels lost. We've all had that bug or feature that made us feel dumb. "Why is this so hard for me? Am I the only one struggling with this?" In the right culture, you can ask "dumb" questions (spoiler: they’re usually not dumb), and you quickly realize others face the same challenges. I’ve been there more times than I can count. And more often than not, as soon as I shared my struggle, I heard someone say, “Oh, I had the exact same issue last week.” That’s the moment you stop feeling alone. Especially in remote teams, you need transparency without having to explicitly ask for it. Seeing how others work, knowing that they also get stuck, take breaks, or need to talk something through—these unspoken insights matter just as much as the scheduled syncs. It’s about feeling you're not the only one struggling. That said, this kind of openness doesn’t come naturally to everyone. Some teammates may ask for help when they need it—but others might keep quiet for too long. That’s where gentle nudges can help: a simple "Hey, you've been working on this for a while—want to talk it through?" can open doors without pushing. It’s not about control. It’s about caring enough to check in. Transparency matters—not just across hierarchies, but within the team. within the team. Build Space For Human Moments People perform better when they’re not carrying emotional weight. That’s why it’s important to make space for conversations beyond work. Offices often have kitchens or game rooms for this reason. But what about remote or hybrid teams? When the pandemic hit, my team went fully remote. And our culture, which had relied heavily on office interaction, started to slip. The quick question in the hallway, the chat at the coffee machine, the post-lunch laughs—gone. We had to rebuild. First, we encouraged non-work conversations in our chat tool. Then we set up a persistent video call with themed rooms: focus, casual, do-not-disturb. It reminded me of old-school gaming setups like TeamSpeak or Discord servers. Back in the day, my friends and I used to hang out on those voice channels even when we weren’t actively playing—just chatting, sharing ideas, or doing our own thing together. We recreated this feeling at work. Some people didn’t show up every day. But most days, we saw and heard from each other without needing a meeting. That helped to keep us connected. And connection leads to better collaboration. Let’s Talk About Remote Work Remote teams can absolutely work. But it takes effort. In an office, human interaction happens naturally. Online, you need to make it happen. Here are a few ideas: Don’t timebox every meeting. Leave room for chitchat. Create off-topic chat channels. Play online games together now and then. Host a video call with no agenda. Add recurring meetings—even when there’s nothing new to discuss. Don’t cancel them just because there’s no update. These meetings can still serve as a moment of presence, a ritual that keeps the team connected—even if it's just to say hello and move on. Don’t timebox every meeting. Leave room for chitchat. Create off-topic chat channels. Play online games together now and then. Host a video call with no agenda. Add recurring meetings—even when there’s nothing new to discuss. Don’t cancel them just because there’s no update. These meetings can still serve as a moment of presence, a ritual that keeps the team connected—even if it's just to say hello and move on. Google, Apple, and others built entire campuses to spark creative collisions. That’s not a coincidence. You can recreate some of that virtually—but only if you try. "But what about the flow state?!" "But what about the flow state?!" I hear you. This doesn’t have to kill flow. A strong team will protect each other’s focus time. Let people mute channels or skip meetings when needed. Flow state1 is ideal—but it’s not the everyday reality. It’s something we should always strive for, but not chase at the cost of collaboration, communication, or the team's health. A team isn’t just a collection of individuals in flow. It’s a system that works best when connected, supported, and aligned. 1 Lead By Example No matter how flat your hierarchy is, people will notice what management does. If you talk about culture but don't genuinely embody it yourself, people won't fully buy in. Be a role model and lead by example. If you don’t show up to the rituals, the meetings, the informal moments—others won’t either. If you say culture matters but don’t live it, people won’t buy it. Leadership is an active part of your job. And that should be recognized—especially by companies hiring or promoting someone into a leadership position. Often, mid-level managers are expected to lead while still carrying a full load of specialist work. But leadership isn't a side task. It's a full role in itself. As a leader, you're responsible for your team's success—and their struggles. If someone on the team fails, it's not just their failure. It's on you too. Maybe the expectations weren't clear. Maybe the support wasn't there. Maybe you didn't step in early enough. That doesn’t mean taking the blame for everything—but it does mean owning your part in it and creating a space where people can grow and learn without fear. Your job is to do the things nobody else can do. Not because you’re the smartest—but because they’re busy being experts in their field. You take care of everything else. Should managers still code? It depends. Managers can—and sometimes should—actively contribute to larger features or dive deeply into the code if that's what the team needs most. It helps build trust, proves you know your project well, and keeps you connected to the reality of the work. But if your coding starts to block progress or prevent others from doing their best work, that's the moment to step back and focus on enabling your team in ways only you can. Understand the project. Stay close to the work. But always ask: What does my team need most from me? What does my team need most from me? And remember: you’re part of the team. you’re part of the team. Also worth noting: in my opinion, leadership and management are not the same. They are often combined in the same person, yes—but leadership is about connection, guidance, and culture. Management is about structure, delivery, and operations. Both matter. But they’re not interchangeable. Get Your Hands Dirty One of the most powerful ways to build trust is to stay close to the work. That doesn’t mean you have to be the best coder on the team. But it helps when your team sees that you understand the product, the codebase, the tools, and the pain points. Sometimes, the best move is to just jump in and fix that one annoying bug yourself. Not because no one else can—but because it shows that you’re not above it. You’re in it together. When your team sees you solving a real issue, struggling with the same environment quirks or debugging the same weird error, it levels the field. You’re not just “managing.” You’re contributing, even in small ways. It makes your feedback, questions, and support feel genuine—because you're not observing from a distance; you're right there in the mix. Plan Plan together. Planning might sound like a dry or overly technical topic, but for me it's deeply connected to the core mechanics of a working team. In software development, the act of planning isn’t about creating the perfect roadmap—it’s about surfacing blind spots early on and thinking things through as a group. Even the most experienced developers overlook things. That’s why it’s valuable to talk through features and architectural decisions together before anyone writes code. before Eric Evans talks about the "ivory-tower architect" in Domain-Driven Design2 as a cautionary tale. That kind of top-down decision-making often creates distance. In contrast, cross-functional teams thrive when everyone participates in shaping the solution. Domain-Driven Design 2 Sometimes, people might disagree—and that's completely normal. In a trusting culture, disagreement isn’t a threat. It’s an invitation to dig deeper. As a lead, you may have to make the final call, but most of the time, if your team is working well together, consensus will emerge naturally. I encourage team members to bring well-prepared thoughts: even a short write-up or sketch can help explore the tradeoffs. Often, just articulating an idea reveals whether it holds up. It’s not about arguing to win—it’s about finding clarity. Are conflicts good? I’m not sure. But respectful disagreement? That’s where the real growth happens. Agile Teams & Bounded Freedom Agile isn’t new. But many teams still don’t fully commit to it. You always need a strategy. One crucial thing I’ve learned: you can only truly prioritize one topic at a time. Trying to work on multiple priorities at once just doesn’t work. In my experience, tasks can only have two priorities—either it’s a priority, or it’s not. The only real exception is a blocker: a bug that breaks your system. Everything else should wait its turn. Why? Because unclear or competing priorities confuse the team. Tasks stay open for too long. Things start to drag. When you fully commit to finishing one thing before jumping to the next, your team moves with much more clarity and confidence. Now, I know it’s not always possible to follow this strictly. Some projects demand flexibility, or bring unexpected challenges. But whenever you can, it helps to work toward this model. Try to stay focused. Prioritize clearly. And wrap up a topic before moving on to the next. It also helps when the whole team is working on related topics. Context switching is expensive. When everyone is spread across unrelated domains, you lose flow and focus. But if the team—or at least pairs—work together on similar types of tasks, it builds shared knowledge. People help each other more easily. Everyone is pulling in the same direction. Bounded freedom3 is the key. 3 Without structure, chaos is exhausting. But micromanagement kills ownership. Here’s one model I’ve used: Two backlogs: one for bugs, one for features/maintenance. Bug backlog is filled from anywhere: tickets, coworkers, support. Feature backlog is created by the team, product owner, or stakeholders. Two backlogs: one for bugs, one for features/maintenance. Bug backlog is filled from anywhere: tickets, coworkers, support. Feature backlog is created by the team, product owner, or stakeholders. The team should be involved in refining and prioritizing both—but as a lead, you're responsible for keeping things moving. That means stepping in when there's confusion or conflicting input. If you're also in a manager role, it's your job to align with stakeholders and help set clear priorities across the board. If an issue isn’t well-defined, it doesn’t move forward. The team should always have insight into a clear set of prioritized tasks to choose from. That way, every iteration or working phase includes a healthy mix of task types: bugs, features, documentation, tests, and maintenance. Sometimes, it can also be helpful to do focus sprints—like a bug-fixing-only week, or a documentation round. But most of the time, maintaining a diverse backlog keeps the team flexible and balanced. When the team pulls work, let them choose. Some days people want deep work. Other days, a simple fix feels right. I know for myself, there are days I just need a small win—fixing a bug or writing documentation helps me reset. And sometimes I need to dive deep into a problem and stay in flow for hours. Bounded freedom means: pick from the pool, but pick what fits you right now. That builds trust and ownership. you Still Learning – Things I'm Working On One thing I’ve learned about leadership is that you never stop learning—and you never stop working on yourself. For me, one area I’m constantly reflecting on is my gut feeling. Sometimes I sense something early, but I hesitate to act on it. Every time I’ve ignored that internal nudge—because it felt uncomfortable or too vague—it’s come back around. Another thing is my optimism. It’s one of my biggest strengths, but it can also make me too quick to trust, or too eager to move forward. That can sometimes lead to decisions I should have spent more time questioning. But at the same time, that optimism is part of what helps me build open, positive, trusting environments. I don’t want to lose that part of myself—I just try to stay aware of when it helps, and when it might get in the way. And to all the teams I’ve worked with—thank you. You’ve helped shape how I lead, how I learn, and how I show up. Every team, every project, every conversation has left a mark. I’m carrying that with me. And to all the teams I’ve worked with—thank you. Why I’m Writing This Why I’m Writing This This isn’t just theory—I’ve lived this. And I believe deeply that this kind of leadership creates better teams, better work, and happier people. I want to prove that it works—not just in theory, but in practice. I love fully committing to a team, a product, a shared vision. When I can identify with the mission, the people, and the energy—it brings out the best in me. That kind of enthusiasm is contagious. It builds momentum. It creates a place people want to be. What I’m looking for now is simple: a team I can believe in, and one that believes in each other. A place where we show up as humans first, and do great work together. A creative, performing team. An organization where people are seen. Where they love their work. Where there’s no emotional gap between free time and work time. Like a band. So let’s rock. 🤘 Conclusion Conclusion Wow. That was a striptease. I didn’t expect it to go this deep. Writing it all down—getting it out of my head—feels like a relief. Like I finally said the quiet part out loud. If something resonated with you—whether you're building a team, leading one, or just reflecting on what leadership could mean for you—I’d genuinely love to hear your story and connect. You can reach out on LinkedIn, Bluesky, or at [the-great.dev](https://www.the-great.dev) LinkedIn Bluesky https:// Let’s swap stories. Or ideas. Or just say hi. Footnotes Flow state—a state of complete immersion in an activity, characterized by a feeling of effortless control and enjoyment, often accompanied by a sense of time distortion. Domain-Driven Design by Eric Evans Bounded freedom—A concept I use to describe the balance between clear structure (priorities, guidelines) and autonomy (personal choice, flexibility). Too much structure kills creativity and motivation; too little leads to chaos. The sweet spot is giving the team clear boundaries but freedom within those boundaries to make their own decisions. Flow state—a state of complete immersion in an activity, characterized by a feeling of effortless control and enjoyment, often accompanied by a sense of time distortion. Flow state Flow state Domain-Driven Design by Eric Evans Domain-Driven Design by Eric Evans Bounded freedom—A concept I use to describe the balance between clear structure (priorities, guidelines) and autonomy (personal choice, flexibility). Too much structure kills creativity and motivation; too little leads to chaos. The sweet spot is giving the team clear boundaries but freedom within those boundaries to make their own decisions. Bounded freedom
