How to Improve Developer Experience in Teams

One of the most effective ways we've built product ownership and accountability at Human Managed is also the most straightforward: put developers in the room with customers throughout the build lifecycle -- during discovery, POC, and demos. Too often developers get handed requirements, rarely witnessing the impact of what they build. We've been there before. In setups like that, teams optimized for velocity rather than value, decisions got made without real context, and the product was never quite right. When we shifted our engineers to hear the problem firsthand -- to see the friction, feel the moments of customer delight vs. confusion... When they have to answer customers' questions directly... When they experience their demo land (or miss) -- it shifts the mindset from features to outcomes. I shared this in a recent Forbes Technology Council expert panel on developer ownership -- and am glad to see it included among other practical ways to foster a culture of autonomy and accountability. 📸: a snap from a recent customer session -- our dev team, on-site, absorbing user feedback firsthand. 👇 Link to the article in the comments.

That "clear, direct feedback" you gave in the PR review? There's a 65% chance it landed completely differently than you intended. New research on 94 developers analyzing real communication from GitHub and Stack Overflow reveals something every engineering leader needs to understand: perception gaps aren't edge cases—they're systematic and predictable. Developers split into distinct perception groups. The same message that one group reads as professional and informative, another interprets as cold or dismissive. That casual "nice work! 🎉" you think builds team morale? To others, it reads as unprofessional and distracting. Here's how that difference in perception can impact engineering productivity: 🔴 PR cycles stretched by unnecessary clarification rounds 🔴 Context-switching overhead as engineers parse tone instead of solve problems 🔴 Eroded trust from repeated "miscommunications" that are actually perception mismatches 🔴 Productivity loss that compounds across every async interaction Here's whats working for high-performing teams: 1️⃣ Match communication density to interruption cost. Architectural decisions and blocking issues deserve information-dense, formal communication. Low-priority updates need explicit tone signals ("FYI, non-blocking:" or "Quick win:") so engineers can triage without friction. 2️⃣ Coach your reviewers on style adaptation. Your most senior engineer's terse technical feedback might be efficient for them but creates multiple context switches for others who need more context to understand intent. The teams that acknowledge these perception differences stop burning cycles on conflicts that aren't technical disagreements, just communication style mismatches. How are you handling communication norms on your teams? What's worked (or hasn't)?

💬 Most leaders think they’re having enough conversations with their teams. They’re not. Annual reviews catch issues too late. Quarterly check-ins miss critical moments. Weekly meetings focus on tasks—not people. The teams that perform and stay have leaders who ask the right questions every month. Because in just 30 days: • Priorities shift without clear communication • Innovation gets buried under busy work • Small blockers turn into major delays • Stress builds quietly • Wins get forgotten Monthly conversations change that dynamic. Here’s how to make them count 👇 1. Start with genuine wellbeing checks. Show your team you care about them as people, not just about their output. 2. Identify what’s blocking progress. Most obstacles are easy to solve—when they’re caught early. 3. Reconfirm priorities. Misalignment wastes more time than any other factor. 4. Recognize what’s working well. Reinforce success patterns to make them repeatable. 5. Ask where support is needed. Top performers often struggle to ask for help. 6. Create space for new ideas. Those closest to the work often see opportunities leaders miss. 7. Turn challenges into learning moments. Growth requires reflection, not just action. This isn’t about adding more meetings—it’s about having better conversations. Monthly is the sweet spot: ✅ Frequent enough to maintain momentum ✅ Spaced enough to see progress ✅ Consistent enough to build trust Your team has insights you need, challenges you don’t see, and solutions you haven’t considered— but they need you to create the space for those conversations. Stop assuming everything is fine because no one’s complaining. Start asking questions that invite real answers. The best teams aren’t built on perfect execution— they’re built on consistent, meaningful dialogue. #LeadershipDevelopment #PeopleFirst #TeamCulture #Communication #LeadershipMatters

Systems Thinking: The Productivity Paradox Imagine a riverside town struggling with seasonal flooding. To mitigate, they build higher levees, allowing them to expand housing and businesses into previously flood-prone areas. At first, flooding stops, and the town thrives. But over time, wetlands downstream erode, and floodwaters have nowhere to spread. When a major storm overwhelms the levees, the flooding is worse than ever. More levees and expansion seemed like progress… but the system fought back. Now, imagine a software company struggling with slow delivery. Customers complain. Revenue and reputation are at risk. Executives need a fix. Their answer? Hire more developers. At first, velocity increases. Features ship faster. But soon, delivery is slower than before the new team members were hired. Adding devs was supposed to speed things up (and did, briefly). But… the system fought back. Why Adding Developers Slows Things Down Fred Brooks wrote, “Adding manpower to a late software project makes it later.” Why? Communication grows exponentially. With 5 devs, you manage 10 communication links. With 10, it’s 45. At 20, it’s 190. More meetings, more dependencies, slower decisions. New hires aren't immediately productive. Senior devs have to help with onboarding. As the team grows, more code is written, leading to merge conflicts, longer pull request cycles, and WIP stuck in queues. More teams means unclear ownership, more handoffs, and more rework. What's The Solution? 1) Reduce WIP Too much WIP slows teams down. Before hiring, ask: Are we prioritizing finishing over starting? Can we reduce batch sizes? Can we use Kanban and/or Scrum to improve flow without adding people? 2) Think Structure, Not Size More devs means higher coordination costs. Instead, use Team Topologies. Stream-aligned teams own end-to-end delivery. Enabling teams improve developer focus. Platform teams reduce cognitive load. 3) Automate and Improve Code Quality Don't maximize team size, optimize the pipeline. Faster CI/CD reduces delays, automated testing prevents bug creep, and refactoring improves maintainability. 4) Use Modular Architecture A tightly coupled system slows everyone down. Shift to microservices or modular monoliths (single deployable units), use feature flags for incremental deployment, and apply domain-driven design (DDD) to define team boundaries. 5) Measure Outcomes, Not Headcount Leaders may wrongly assume more developers means more output, but real productivity is about flow efficiency. Instead of team size, track: Cycle time (how long it takes to ship), Deployment frequency (how often we deliver), and Lead time for changes (how fast we adapt). Systems, Not Silos When teams slow down, hiring feels like the obvious fix. But it should be the last resort, not the first instinct. Without systems thinking, hiring may have unintended consequences that ironically make things worse. Rethink how your system works... before the next storm.

Critique this (real) team's experiment. Good? Bad? Caveats? Gotchas? Contexts where it will not work? Read on: Overview The team has observed that devs often encounter friction during their work—tooling, debt, environment, etc. These issues (while manageable) tend to slow down progress and are often recurring. Historically, recording, prioritizing, and getting approval to address these areas of friction involves too much overhead, which 1) makes the team less productive, and 2) results in the issues remaining unresolved. For various reasons, team members don't currently feel empowered to address these issues as part of their normal work. Purpose Empower devs to address friction points as they encounter them, w/o needing to get permission, provided the issue can be resolved in 3d or less. Hypothesis: by immediately tackling these problems, the team will improve overall productivity and make work more enjoyable. Reinforce the practice of addressing friction as part of the developers' workflow, helping to build muscle memory and normalize "fix as you go." Key Guidelines 1. When a dev encounters friction, assess whether the issue is likely to recur and affect others. If they believe it can be resolved in 3d or less, they create a "friction workdown" ticket in Jira (use the right tags). No permission needed. 2. Put current work in "paused" status, mark new ticket as "in progress," and notify the team via #friction Slack channel with a link to the ticket. 3. If the dev finds that the issue will take longer than 3d to resolve, they stop, document what they’ve learned, and pause the ticket. This allows the team to revisit the issue later and consider more comprehensive solutions. This is OK! 4. After every 10 friction workdown tickets are completed, the team holds a review session to discuss the decisions made and the impact of the work. Promote transparency and alignment on the value of the issues addressed. 5. Expires after 3mos. If the team sees evidence of improved efficiency and productivity, they may choose to continue; otherwise, it will be discontinued (default to discontinue, to avoid Zombie Process). 6. IMPORTANT: The team will not be asked to cut corners elsewhere (or work harder) to make arbitrary deadlines due to this work. This is considered real work. Expected Outcomes Reduce overhead associated with addressing recurring friction points, empowering developers to act when issues are most salient (and they are motivated). Impact will be measured through existing DX survey, lead time, and cycle time metrics, etc. Signs of Concern (Monitor for these and dampen) 1. Consistently underestimating the time required to address friction issues, leading to frequent pauses and unfinished work. 2. Feedback indicating that the friction points being addressed are not significantly benefiting the team as a whole. Limitations Not intended to impact more complex, systemic issues or challenges that extend beyond the team's scope of influence.

If you work on developer experience and you want to improve the ability of developers to focus on their tasks, think about things like: * Do my tools force developers to engage in some complex task that isn’t coding, testing, or debugging, while they are doing those tasks? * Are we ensuring that developers have multiple uninterrupted hours to focus on coding? * Do my tools, systems, or processes do something that’s so frustrating to developers that it breaks their focus? Another key point here is: do developers clearly know the purpose of the work they are doing and have a clear direction to go? That is, have I been given a clear task where I know why I’m doing the task, who it’s for, and what the intended result is? Otherwise, my own confusion will frequently break my focus. I’ll have to keep asking my co-workers what I’m supposed to be doing. I’ll sit there and wonder about my task instead of actually doing it. Plus, I probably won’t build the best possible thing, since I don’t have all the data I need to make good decisions about it. Focus is another area where you want to put clear information right in front of people that they can use to Observe, Decide, and Act. Don’t make them interrupt their work to go hunting for the data they need right now. Sometimes, “I’m going to go learn about something” is a developer’s whole task, and in that case, making them search for information isn’t an interruption, as long as they can easily find what they are looking for. But if they are coding and they just need to know something like “what does this function do,” that information should be available directly in their editor as fast as possible. #developerexperience #devex #dx #focus #flow

Only a few years ago I was jamming work into every waking minute. Today, I accomplish much more by working less. Here are the strategies I’ve found to be effective after dealing with intense burnout periods. 01/ Busy ≠ Productive The myth that more hours equal more output is costing tech teams their best talent. At G2i, we’re having better results with flexible work weeks capped at 40 hours than traditional mandated 40-hour schedules. Here's what we've learned: → Developers work better and faster when well-rested → Shorter focused days produce more value than standard five 8 hour days → For teams requiring five-day coverage, two half-days work wonders → Breaks between intense work improves problem-solving, creativity, and more The real metric isn't time spent working -- it's the quality of the work. 02/ Build the space for deep work Developers need uninterrupted time to enter a flow state and produce their best work. I do this myself and communicate it to my team: → Designate 2-3 hours daily for focused work → Mute notifications, calls, and Slack messages → Block specific "no-meeting" times ⁣ 03/ Cut the Zoom madness Your team’s time is too valuable to waste on constant sync updates. This is what we do at G2i: → Use loom for async communication → Reserve meetings for complex collaboration and discussion → Document decisions and action items asynchronously 04/ Slow down to speed up ASAP EOD NOW The rush to deliver often backfires. It seems like everyone eventually learns this the hard way, but when we slow down, we can actually move faster: → Fewer mistakes requiring rework → Higher-quality code from the start → More sustainable product development Demanding great output while pushing a "work until you drop" mentality is counterintuitive. Cultural change requires 100% commitment from leadership to see progress. Anything less and these attempts will be short-lived.

One of the biggest challenges on technical teams isn’t a lack of skill. It’s how safe people feel asking questions. When questions are met with impatience, sarcasm, or “you should already know this,” people adapt. They stop asking publicly. They start second-guessing themselves. Decisions move into side conversations or get made quietly just to avoid friction. That’s not a people problem, it’s a team dynamic problem. Senior developers have a lot of influence here, often without realizing it. Tone, body language, and how we respond in moments of uncertainty can either invite collaboration or shut it down entirely. Experience isn’t just about having answers. It’s about making room for curiosity, learning, and discussion, especially when someone doesn’t yet have the context. The teams I’ve seen thrive are the ones where questions are welcomed, uncertainty is normal, and “Let’s figure it out together” is the default. When people feel safe to speak up, better decisions get made and they get made in the open. Just a reminder I’m trying to keep for myself too. #EngineeringCulture #DeveloperExperience #PsychologicalSafety #TeamDynamics #LeadershipInTech #SoftwareDevelopment #ContinuousLearning #TechCareers #HealthyTeams #InclusiveWorkplaces #CollaborationOverEgo #BuildBetterTeams

I had an eye-opening chat with our VP of Engineering about a challenge every tech leader faces: developers living in their code, disconnected from the actual product. We've all been there. Your engineering team writes beautiful, elegant code... that solves the wrong problem. After scaling multiple software companies, I've learned that transforming code-focused developers into product-minded engineers comes down to six fundamental shifts: ⚡ Push them to ask "why" before writing a single line of code ⚡ Get them listening to actual customer calls ⚡ Include them in product planning ⚡ Give them true ownership of features ⚡ Make product usability the north star ⚡ Embrace simpler code over complexity Real example: One of our teams spent weeks optimizing a dashboard that looked amazing and performed great. Only problem? Users didn't need it. A simple conversation with customers beforehand would have prevented this. Here's the hard truth I've learned: You can write the most elegant code in the world, but if users don't need the feature, it's worthless. The best developers aren't just great coders – they're great problem solvers who understand their users. What's your experience helping developers think beyond their code? Full details and a link to the interview on YouTube in my newsletter: https://lnkd.in/g_nBfQ5G

Designers and developers speak different languages. But when they listen early, magic happens. A few months ago, we kicked off a new product build. The usual setup: designers finalize flows, hand off to dev, then... endless Slack threads, clarifying questions, and "this isn't what I expected" moments. Sound familiar? This time, we took a different approach. Instead of working in silos, we brought everyone into the same (virtual) room—from day one. We ran cross-functional workshops: 👉 Designers walked through their thinking 👉 Developers flagged edge cases early 👉 Everyone had a say in feasibility before pixels were polished We used Figma’s handoff tools—not just as a delivery method, but as a shared language. And we held quick weekly syncs to stay aligned, not just at kickoff. The result? ✅ Build time dropped by 25% ✅ Fewer bugs ✅ Zero surprise revisions ✅ And... team morale? Way up. Here’s what I learned: When design and dev teams collaborate early, they don’t just move faster—they trust each other more. And that trust? That’s where the real magic starts. 👥 Tag a designer or developer you love working with. And share your best tip for making the collaboration smoother.