Best Practices for Leadership in Software Development

Only 26% of leaders create psychological safety in their teams*. This means just 1 in 4 leaders are truly tapping into the full potential of their people. Psychological safety is the secret ingredient that turns good teams into extraordinary ones—and it doesn’t require grand gestures. It’s the small, often overlooked actions that make the biggest difference. See the examples: 1. Admit your own missteps: 🗣 Example: "Last quarter, I missed a key detail in our strategy, and it led to a delay. Here’s how I’m adjusting my approach." 2. Ask for feedback, then act 🗣 Example: "After hearing your thoughts on our meeting structure, I’ve decided to shorten our agenda and focus more on discussion." 3. Show that asking for help Is normal 🗣 Example: "I’m struggling with this new software—can someone show me how to use this feature?" 4. Celebrate the journey, not just the destination 🗣 Example: "The presentation wasn’t flawless, but the way you tackled the research was impressive." 5. Give permission to challenge 🗣 Example: "I want someone to play devil’s advocate—how could this plan go wrong?" 6. Create space for dissent 🗣 Example: "Before we finalize, let’s hear from anyone who sees this differently." 7. Reframe failure as growth 🗣 Example: "Our experiment didn’t yield the results we hoped for, but we now know what to avoid next time." 8. Demystify decision-making 🗣 Example: "We chose this vendor because they align with our long-term sustainability goals." 9. Reward curiosity 🗣 Example: "That question opened up a whole new line of thinking—thanks for bringing it up!" 10. Spotlight the quiet contributors 🗣 Example: "I want to highlight Anna’s work on the backend—it’s crucial to our project’s success, even though it’s often behind the scenes." True trust doesn't come from protecting your people from conflict or tough conversations. It’s born from inviting in every voice, especially the ones that challenge the status quo. If you're not making space for diverse ideas, you're not just missing out—you're holding your team back. * 📚 Study source: McKinsey & Co., “Psychological safety and the critical role of leadership development,” 2021.

𝐘𝐨𝐮𝐫 𝐛𝐞𝐬𝐭 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐲𝐨𝐮𝐫 𝐛𝐢𝐠𝐠𝐞𝐬𝐭 𝐫𝐢𝐬𝐤. You know the pattern. One developer who knows everything. Who can fix anything. Who works faster than anyone else. Leadership loves them. They're the hero who saves the release. On the surface, they're your safety net. Underneath, something else is happening: Knowledge is concentrated instead of spreading. Others stop learning because "Alex will fix it." Documentation doesn't happen because Alex just knows. Code becomes increasingly dependent on context; only Alex has. And then Alex leaves. Suddenly, you realize: Alex wasn't accelerating your team. Alex was masking systemic problems while creating new ones. The anti-pattern of the genius developer isn't about the individual. It's about the organizational dynamics that reward heroics over systems. That celebrates crisis response over crisis prevention. That mistake is an individual output, not a team capability. High-performing organizations don't need heroes. They need systems that make heroics unnecessary. If you recognize this pattern, start here: pair Alex strategically, rotate ownership, and make documentation part of the job, not a nice-to-have. The question isn't "how do we keep Alex?" It's "Why does our system require an Alex to function?" What systems would break if your best developer left tomorrow?

After 5 years at Amazon, I found 1 practice that builds the best software teams: I call it knowledge distribution. ► If your team relies on "tribal knowledge": ↳ Onboarding takes months instead of weeks. ↳ You're always one resignation away from disaster. ↳ Your best engineers burn out from being constant bottlenecks. ↳ Critical systems become "no-fly zones" that only a few understand. ► If your team is good at sharing knowledge: ↳ Bus factor becomes a strength, not a risk. ↳ New hires become productive in days, not months. ↳ Any engineer can debug any system (without pinging "the expert"). ↳ Your top talent can focus on hard problems instead of answering the same questions True engineering leadership does not mean you must be the only one knowing it all. It means ensuring everyone knows enough to make you redundant. The choice is yours: Be the engineer who's constantly needed Or build the team that doesn't need you. How does your team handle knowledge sharing? ~~~ 👉🏻 Join 50,001+ software engineers getting curated system design deep dives, trends, and tools (it's free): ➔ https://lnkd.in/dkJiiBnf ~~~ If you found this valuable: 👨🏼💻 Follow Alexandre Zajac 🔖 Bookmark this post for later ♻️ Repost to help someone in your network #softwareengineering #coding #programming

7 ways to get ahead of most tech leads: 1. Pick problems that matter. Find the bottleneck that’s costing real money or blocking real growth. Manual processes burning 20 hours of engineering time weekly. Focus on high-impact infrastructure work that drives business results. 2. Build relationships. Your skip-level manager often has significant input on promotions. Understand their problems and priorities. Collaborate effectively with product, sales, and other engineering teams. The people who get promoted valued by multiple stakeholders across the organization. 3. Protect deep-work time. Guard your focus ruthlessly. Block calendar time for thinking, designing, and coding. Don’t lose the technical edge that made you valuable. Say no to non-essential meetings. The best technical decisions require uninterrupted thinking time. 4. Translate technical decisions into business impact. That refactor didn’t just reduce technical debt – it prevented potential system outages and reduced maintenance overhead. Learn to communicate the business value of your technical work. 5. Develop someone publicly. Have them present the solution they built. Call out their growth in team meetings. Champion their promotion. Your ability to level up talent demonstrates you can handle bigger teams and responsibilities. 6. Lead cross-team initiatives. Security improvements, platform migrations, developer tooling – projects that put you in front of senior stakeholders and demonstrate your ability to coordinate complex work beyond your immediate team. 7. Build external credibility. Speak at conferences, write technical posts, contribute to open source. External reputation reflects back internally and provides leverage during compensation discussions. But always ship first – external work should complement, not replace, strong internal delivery. Technical leadership is ultimately about multiplying human potential. The companies worth your career understand this.

Having developers doesn't mean you have technical leadership. Here's what technical leadership actually looks like: They challenge solutions, not just implement them. Your technical leader should ask "why" before "how." If your team only asks how to build what you've specified, you're missing critical product thinking. They think about scalability from day one. Developers might build what works today. Technical leaders build what will work when you 10x your customer base. They own outcomes, not just output. A developer delivers features. A technical leader delivers solutions that move your business forward. I often see companies confuse development resources with technical leadership. Then they wonder why their products aren't succeeding. Here's the reality check: Five developers without direction ≠ One focused technical leader Perfect code without purpose ≠ Good technical decisions Meeting requirements ≠ Solving problems Your technical leadership should be able to: 🟢Evaluate architectural decisions 🟢Guide technology choices 🟢Ensure quality standards 🟢Challenge product assumptions 🟢Lead development teams effectively Because at the end of the day, technical leadership isn't about writing code. It's about turning your business vision into technical reality.

🚀 Transformational Leadership Practices For Tech 🌟 Middle-aged startups like Akka face unique crossroads: balancing a legacy of innovation with the urgency to adapt and grow. As CEO of a developer-led business undergoing profound transformation, I’ve been learning what it takes to guide a company through change while honoring the foundation that brought it this far. The practices I’ve leaned on aren’t just for CEOs—they’ve helped leaders across our organization, from architects and revenue leaders to individual contributors. While these lessons stem from my experience in a developer-driven environment, I believe they can apply to most tech businesses and beyond. Here are the approaches that have worked for me: • 𝗘𝘀𝘁𝗮𝗯𝗹𝗶𝘀𝗵𝗶𝗻𝗴 𝗮 𝗰𝗮𝗱𝗲𝗻𝗰𝗲: Building predictable rhythms that bring clarity, structure, and predictability to everything. • 𝗣𝗿𝗼𝘃𝗶𝗱𝗶𝗻𝗴 𝗮𝗯𝘀𝗼𝗹𝘂𝘁𝗲 𝘁𝗿𝗮𝗻𝘀𝗽𝗮𝗿𝗲𝗻𝗰𝘆: Sharing raw insights—even on undecided strategies—because alignment thrives on openness. • 𝗙𝗶𝗴𝘂𝗿𝗶𝗻𝗴 𝗼𝘂𝘁 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻: Taking the time (and sometimes a few tries) to deeply understand who your customers are. • 𝗛𝗼𝗹𝗱𝗶𝗻𝗴 𝘀𝘁𝗿𝗼𝗻𝗴 𝗼𝗽𝗶𝗻𝗶𝗼𝗻𝘀, 𝗵𝗲𝗹𝗱 𝗹𝗼𝗼𝘀𝗲𝗹𝘆 𝗼𝗻 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆: Testing bold strategies with passion but staying open to better ideas when they surface. • 𝗣𝗮𝘆𝗶𝗻𝗴 𝗮𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝘁𝗼 𝗱𝗲𝘁𝗮𝗶𝗹𝘀: Diving into specifics to ensure alignment, not to micromanage, because small things matter. • 𝗦𝗶𝗺𝗽𝗹𝗶𝗳𝘆𝗶𝗻𝗴 𝗰𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆: Asking hard questions to streamline brands, products, and processes, even if it means letting go of historical favorites.   • 𝗡𝗼𝘁 𝘄𝗮𝗶𝘁𝗶𝗻𝗴: Acting decisively on tough decisions, even when the path is controversial.   • 𝗖𝗼𝗻𝗱𝘂𝗰𝘁𝗶𝗻𝗴 𝗼𝘂𝘁𝘀𝗶𝗱𝗲-𝗶𝗻 𝗮𝗻𝗮𝗹𝘆𝘀𝗶𝘀: Learning from competitors and adjacent industries to stay ahead of the curve. • 𝗟𝗲𝗮𝗱𝗶𝗻𝗴 𝗯𝘆 𝗲𝘅𝗮𝗺𝗽𝗹𝗲: Striving to embody the qualities I hope to see in others—work ethic, adaptability, and a commitment to continuous improvement. • 𝗦𝗼𝗿𝘁𝗶𝗻𝗴 𝗼𝘂𝘁 𝘄𝗵𝗼 𝗶𝘀 𝘁𝗿𝘂𝗹𝘆 𝗰𝗼𝗺𝗺𝗶𝘁𝘁𝗲𝗱: Recognizing and coaching those who align with the mission and addressing those who don’t. • 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘂𝗽𝗼𝗻 𝘁𝗵𝗲 𝗰𝘂𝗹𝘁𝘂𝗿𝗲: Embracing and enhancing the values that have driven past successes while adapting them for the future. These aren’t prescriptive rules—they’re practices that helped me and our team navigate some challenging but exciting times. 💡 What about you? • How have you navigated cultural shifts in your organization? • What practices have helped you balance legacy with change? • What lessons have you learned about leading through complexity? I’d love to hear your thoughts and learn from your experiences. Let’s exchange ideas and keep growing together. 👇 #Leadership #Transformation #DeveloperLed #Innovation https://lnkd.in/gr2cuj2w

Every leader talks about teaching AI to their team. But the truth is: I'm learning just as much from them. 6 months into our AI "transformation"... → Our best lessons didn't come from the top down. Here's 9 key lessons my team taught me: 1/ "Perfect" AI policies kill innovation ↳ My team found workarounds we never imagined ↳ They discovered use cases we missed ↳ They built workflows that actually work 💡 Pro Tip: Replace rigid policies with principle-based guidelines. Let teams interpret them based on their needs. 2/ Junior team members spot opportunities first ↳ They're closest to daily friction points ↳ They experiment without preconceptions ↳ They share discoveries peer-to-peer 💡 Pro Tip: Create "reverse mentoring" sessions where junior team members teach leaders about AI tools. 3/ Shadow AI isn't always bad ↳ It reveals real process gaps ↳ Shows where official tools fall short ↳ Signals what teams actually need 💡 Pro Tip: Don't shut down unauthorized tools immediately. Study why teams chose them first. 4/ Best practices emerge organically ↳ Teams create their own guidelines ↳ They self-regulate effectively ↳ They teach each other boundaries 💡 Pro Tip: Document and share team-created best practices in a living playbook. 5/ Innovation needs psychological safety ↳ Freedom to experiment ↳ Permission to fail ↳ Space to share concerns 💡 Pro Tip: Celebrate failed AI experiments as much as successes. They're equally valuable lessons. 6/ Cross-pollination complements formal training ↳ Peer learning sticks better ↳ Solutions spread naturally ↳ Best practices evolve faster 💡 Pro Tip: Host weekly "AI wins" sharing sessions where teams demo their discoveries. 7/ Small wins compound quickly ↳ One team's solution inspires others ↳ Micro-improvements add up ↳ Success breeds confidence 💡 Pro Tip: Create an AI wins leaderboard that tracks time saved and problems solved. 8/ Resistance often signals wisdom ↳ They see risks we miss ↳ They protect critical human elements ↳ They maintain necessary boundaries 💡 Pro Tip: Turn your biggest AI skeptics into your advisory board. They'll spot blind spots. 9/ The best ideas are unexpected ↳ They come from anywhere ↳ They challenge assumptions ↳ They create real change 💡 Pro Tip: Set up an anonymous AI suggestion box. Some won't speak up otherwise. The biggest lesson? Stop trying to control every aspect of AI adoption. Instead: → Create clear ethical boundaries → Give teams room to explore → Learn from their discoveries → Scale what works Your team knows their work best. Trust them to find the right AI solutions. What unexpected AI lessons has your team taught you? Share below 👇 __________ ♻️ Repost this if someone in your network needs this reminder. Follow Carolyn Healey for more content like this. Sign up for my newsletter: https://lnkd.in/gyJ3FqiT

Design taught me how to lead. I started my career in design thinking my job was to make things look great. But great design isn’t about polish, it’s about problem-solving. You listen before you act. You test before you commit. You iterate until it feels right. The best designers I’ve worked with aren’t chasing perfection, they’re chasing understanding. They slow down long enough to uncover the real problem, not just the visible one. They ask questions that reframe the challenge, and they don’t get too attached to their first idea. That approach changed how I think about leadership. That mindset has shaped how I lead. Here’s how it shows up: 💡 Listen first, then decide. The best ideas often come from the people closest to the problem. 💡 Prototype decisions. Try something small before rolling out the big change — the same way you’d test a new feature before shipping it. 💡 Solve for the root problem, not the symptom. When something’s off, I ask why five times before suggesting a fix. 💡 Iterate fast. Perfection is a moving target. The goal is progress, not polish. In product design, success sounds like someone saying, “Oh, of course that’s how it works.” In leadership, it’s when someone says, “Oh, I get why we’re doing this.” Both take patience, empathy, and a willingness to keep learning. Whether you’re designing software or leading people, the goal’s the same: to bring clarity where there’s confusion, and momentum where there’s friction. What’s something outside of leadership that’s shaped how you lead?

In tech, your most valuable asset isn't your latest gadget—it's your mind. But here's the thing: most of us aren't using our full mental capacity. We're running outdated software in our heads, relying on gut instincts when we should be leveraging critical thinking. Consider this: - 75% of successful IT projects had leaders with strong critical thinking skills. Only 25% of failed projects did. (Harvard Business Review) - 85% of tech leaders say critical thinking is the #1 soft skill for success, but only 30% feel adequately trained. (Global Knowledge) - Poor decision-making costs businesses 17% of revenue each year. (McKinsey) These aren't just numbers. They're a wake-up call. So, how do we upgrade our mental operating systems? Here are five strategies: 1. Cultivate Curiosity ↳ Ask the tough questions, don't just nod along. ↳ Challenge assumptions, especially your own. ↳ Poke holes in ideas like you're testing software. ↳ "What if...?" is your new default response. Use it often. ↳ Curiosity is for leaders who want to stay ahead. 2. Embrace Diverse Perspectives ↳ Seek out views that make you uncomfortable. ↳ Build a team that doesn't just echo your thoughts. ↳ The best solutions often come from unexpected places. 3. Practice Reflection ↳ Set aside time to review your decisions. ↳ What worked? What didn't? Why? ↳ Reflection isn't a luxury—it's a necessity for growth. 4. Develop Systems Thinking ↳ Everything's connected. ↳ Start seeing those connections. ↳ Map out problems. Visualize solutions. ↳ The big picture is made up of tiny pixels. See both. 5. Combat Cognitive Biases ↳ Slow down. ↳ Our brains love shortcuts, but shortcuts can lead to errors. ↳ Actively seek evidence that contradicts your beliefs. ↳ The most dangerous phrase in business? "We've always done it this way." Here's the challenge: Pick one of these strategies. Implement it this week. Then come back and share what you learned. Remember, in an AI-driven world, critical thinking isn't just a skill—it's your competitive edge. Are you ready to think differently? To lead differently? The future of tech leadership isn't about having all the answers. It's about asking the right questions. What's your next question?

The winner for best slides at #LeadDevBerlin came from 🐱 Denise Yu from HashiCorp, who spoke about levelling up your entire team, and avoiding “superhero” development. ⬇️ “Level Up the Whole Party, Not Just the Hero” • Uses the Pokémon metaphor of training one Pokémon vs. a collection: good leadership is a series of repeated and consistent behaviours. A well-balanced team is more effective than a single code hero. • Final Fantasy VII team reference: each team member has their own strengths, and 3 out of 4 would suffer if forced into one mould. • A balanced team includes varied demographics, thinking styles, experience levels, motivators, etc. • Take stock of your desired end state: your team should include a good mix of styles like teachers, specific tech stack expertise, carers, doers, etc. Create a map of needed expertise. • Expertise: “Novices only see what is there; experts can see what is not there” (Gary Klein quote). • Re: Expertise, Denise likes to ask: “How much cursed knowledge do you have?” (knowledge you gained without wanting to! 😅). • Theory of Proximal Development: do tasks you can accomplish with some assistance (not tasks you can already do or ones you can’t complete at all). • Identify where an engineer is now and where they want to be; map their progression with steps that involve only changing one thing at a time. • Go through a career matrix with each engineer, assessing their self-evaluation of abilities; set goals based on agreed gaps. • Use everyday decisions to incrementally advance your team. • Work distribution options: free-for-all (everyone picks tasks) vs. assigning every individual ticket. Best option: create norms around ownership, with initiative-based leads who can self-organise. • Assigning work is like giving experience points to different team members (RPG metaphor). • Repeatedly giving one star member the same tasks means losing opportunities to develop that skill in others. • Be willing to accept short-term slowdowns to achieve long-term speed and a balanced distribution of skills and expertise. (notes cleans up by ChatGPT) —— I loved Denise’s video games metaphor and found it enjoyable and impactful. I am to always lift up the team as well as the individual, but her reminder to not just lean on the same team member for the same tasks was something I will definitely carry forward. Thank you Denise for a great presentation!! Unfortunately I didn’t get many photos of her amazing Charmander slides but suffice it to say they were awesome! #EngineeringManagement