How To Improve Collaboration In Software Development Teams

Let's be honest: extensive cross-team coordination is often a symptom of a larger problem, not an inevitable challenge that needs solving. When teams spend more time in alignment than on building, it's time to reconsider your organizational design. Conway's Law tells us that our systems inevitably mirror our communication structures. When I see teams drowning in coordination overhead, I look at these structural factors: - Team boundaries that cut across frequent workflows: If a single user journey requires six different teams to coordinate, your org structure might be optimized for technical specialization at the expense of delivery flow. - Mismatched team autonomy and system architecture: Microservices architecture with monolithic teams (or vice versa) creates natural friction points that no amount of coordination rituals can fully resolve. - Implicit dependencies that become visible too late: Teams discover they're blocking each other only during integration, indicating boundaries were drawn without understanding the full system dynamics. Rather than adding more coordination mechanisms, consider these structural approaches: - Domain-oriented teams over technology-oriented teams: Align team boundaries with business domains rather than technical layers to reduce cross-team handoffs. - Team topologies that acknowledge different types of teams: Platform teams, enabling teams, stream-aligned teams, and complicated subsystem teams each have different alignment needs. - Deliberate discovery of dependencies: Map the invisible structures in your organization before drawing team boundaries, not after. Dependencies are inevitable and systems are increasingly interconnected, so some cross-team alignment will always be necessary. When structural changes aren't immediately possible, here's what I've learned works to keep things on the right track: 1️⃣ Shared mental models matter more than shared documentation. When teams understand not just what other teams are building, but why and how it fits into the bigger picture, collaboration becomes fluid rather than forced. 2️⃣ Interface-first development creates clear contracts between systems, allowing teams to work autonomously while maintaining confidence in integration. 3️⃣ Regular alignment rituals prevent drift. Monthly tech radar sessions, quarterly architecture reviews, and cross-team demonstrations create the rhythm of alignment. 4️⃣ Technical decisions need business context. When engineers understand user and business outcomes, they make better architectural choices that transcend team boundaries. 5️⃣ Optimize for psychological safety across teams. The ability to raise concerns outside your immediate team hierarchy is what prevents organizational blind spots. The best engineering leaders recognize that excessive coordination is a tax on productivity. You can work to improve coordination, or you can work to reduce the need for coordination in the first place.

40-60% of your engineering delivery time is lost to handovers and coordination waste. Not to coding. Not to testing. Not to requirements. To waiting, asking, aligning, and passing work between people. The DevOps Handbook and Lean Software Development research make this painfully clear. Your biggest delivery bottleneck isn't technical complexity. It's the space between people. Here's what most organizations do: They add more process. More meetings. More documentation. More alignment rituals. And they wonder why things get slower instead of faster. What actually works? Eliminating the handovers entirely. Concurrent product development puts all the bright people working on the same thing, at the same time, in the same place. Requirements analysis, coding, testing, and documentation happen simultaneously, not sequentially. No waiting for specs. No waiting for code. No waiting for test results. No waiting for documentation. The Three Amigos approach (business analyst, developer, tester) working together in real-time on the same problem creates something you can't get any other way: shared understanding that doesn't need to be written down and handed off. The result? Teams that apply true concurrent development report what used to take 3 weeks being completed in a single day. Same people. Same skills. Radically different approach to how work flows between them. What percentage of your team's time is spent waiting for someone else? #ContinuousDelivery #TDD #ProductDevelopment

Pay close attention to the frequency of healthy debate, constructive challenge and openness to new and divergent ideas that takes place in your teams. If the frequency is low… …there is the risk of creating the illusion of performance because people readily ‘understand’ each other, agree on everything, collaboration seems to flow smoothly and there is a collective sensation of progress. However, the opportunity cost is teams gets trapped in their own paradigms, opportunities get overlooked, risks ignored - and ultimately their output becomes derivative not innovative, performance diminishes as opposed to improving and compounding. If the frequency is high… …there is a level of psychological safety that allows for team members to be more objective, to speak up with relevant ideas, to constructively challenge each other, and bring their diverse perspectives and experiences to the table - in the knowledge it won’t be held against them. This opens up the opportunity of reframing the paradigm, and connecting different perspectives and ideas. Ingredients for creativity, innovation, resilience and performance. You see homogeneous teams might feel easier, but easy doesn’t translate into Performance. Here are a few ideas to experiment with your teams… 1. Intentionally foster a team environment that replaces scepticism with intellectual curiosity, an open and learning mindset.   2. Consider how you can create a ways of working that allows all ideas and perspectives from everyone in the room to be heard. 3. Encourage dissenting perspectives. Surrounding yourself with people who are willing to disagree with you and challenge your perspectives and each other. 4. Consider whether you may need to invite others to that creative or idea generation meeting to ensure you get a broader perspective. 5. De-stigmatise failure through sharing past mistakes and celebrating lessons learnt. 6. Institutionalise a team culture of healthy candour. Candour is one of the key attributes to improving the quality of output, levelling up creativity and enabling effective collaboration. What would you add? 👇🏽 #culture

Early in my career as a software engineer, I was all about code. I thought if my code was perfect, success was guaranteed. But there was a piece of the puzzle I was missing: communication. Once, I was part of a project that was technically complex and challenging. I poured my heart and soul into writing the most elegant code. However, the project was struggling. Deadlines were missed, and the team was frustrated. I couldn't understand why until my project manager pulled me aside. He said, "Your code is brilliant, but your team is in the dark. They need your guidance and understanding, not just your code." That was my lightbulb moment. I realized that writing code wasn't just about communicating with machines but with people too. From that day on, I made a conscious effort to improve my communication skills. Here’s what I learned and practiced: 1. Breaking Down Complex Ideas: I started to explain complex technical concepts in simple terms that everyone on the team, from developers to PM, could understand. 2. Active Listening: I made an effort to really listen to my team's ideas and concerns, which helped in creating a more collaborative environment. 3. Regular Updates: I began sharing regular updates and insights, keeping everyone in the loop and fostering a culture of transparency. 4. Feedback: I learned to give and receive feedback in a constructive way, which significantly improved our projects' outcomes. This journey transformed not only my career but also how our team operated, leading to more successful projects and a happier workplace.Communication is the soft skill that amplifies your hard skills. Let’s code, communicate, and create the incredible. Because in the end, the best code we can write is the one that brings people together. #SoftwareEngineering #Communication #Teamwork

Cyber, DevOps, and IT’s “Blame game” often costs more than breaches while the system remains unpatched. Here’s how to stop the finger-pointing and fix risk at its root cause instead. The famous notorious “blame game”, who didn't see it firsthand? IT, DevOps, SRE, Cloud, Networking, and Operations teams are fingerpointing at Security, and Security blames them right back. This cycle is eating companies from the inside. It destroys trust. It slows down projects. It makes every incident worse. It’s toxic. But there’s a way out. Here’s how to fix it: 1) Shared Goals → Align all teams around one mission: keep the business running and secure. → Set joint KPIs that force collaboration, not competition. 2) Blameless Postmortems → After every incident, focus on what went wrong, not who. → Document facts, not opinions. → Make learning the goal, not punishment. 3) Cross-Team Standups → Hold regular meetings with all operations and security leads. → Share updates, blockers, and wins. → Build relationships before a crisis hits. 4) Clear Roles & Boundaries → Define who owns what, in writing. → Remove gray areas that cause confusion. → Update these roles as the business changes. 5) Shared Tools & Dashboards → Use the same monitoring and alerting platforms. → Give everyone access to the same data. → No more “I didn’t see that alert” excuses. 6) Executive Support → Leadership must model collaboration. → Reward teams for working together, not just for individual wins. → Make it clear: finger-pointing is not tolerated. 7) Continuous Training → Run joint tabletop exercises. → Teach teams how the other side works. → Build empathy and shared language. When teams stop blaming and start building together, everything changes. Incidents get resolved faster. Projects ship on time. People trust each other. The business wins. #StopTheBlameGame. Joining the movement today =)

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.

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.

Collaboration isn’t having everyone in the room — it’s making sure the right conversations happen in that room. I know you’ve seen it: UX, product, and dev are all in the same meeting — but no one’s on the same page or in agreement as to what should happen. Everyone’s talking about “the user” or “the customer…” but each with VERY different assumptions about what those users or customers actually want or need. Work gets approved… then sidelined or dismantled two weeks later. I am here to tell you, no matter what side of the house you work for, it does NOT have to be this way. Designers/UXers: 
You can help change this. Remember that your job isn’t just design, it’s translation. Facilitate. Clarify. Uncover blind spots. Ask: – “What do we believe the user needs here?” – “Why do they need that?” – “How does their getting it benefit this organization?” – “What does success actually look like?” – “What’s the risk if we’re wrong?” Product Leaders + Product Managers: True collaboration reduces churn and waste. Your UX and design teams can do a lot more for you than you realize — help you narrow down what’s worth doing (and what isn’t) and make you like like a hero at the end. But that only happens when cross-functional teams share: – Dept. and business goals – Time, budget and political constraints – Issues the executive teams are focused on – User or customer analytics and insights This mess we keep calling “collaboration” — it’s fixable. But only if we start talking TO each other instead of around each other. You’ve got the power to change that. You want fewer rewrites, better decisions and less finger-pointing? Then make the real conversations happen — the ones about users, risks and what’s actually driving business decision. Real collaboration isn’t about checking boxes — it’s about getting aligned, getting honest, and getting shit done. That only happens when we stop working in silos and start sharing what actually matters. #UX #ProductDesign #ProductManagers #SoftwareDevelopment #ProductImprovement

This team cut meetings by more than 50% and reduced escalations by 75%. That’s not from a calendar cleanse, that's the result of redesigning how the team works. And those results were not a one-off. This is exactly the kind of measurable change we see over and over again when teams take the time to clarify how they work across functions, across roles, and across distance. I am so proud of these results from a real-world program we led with a geographically distributed cross-discipline team at a global retailer. Pain points we were solving for: ➡️ unclear decision rights creating escalations ➡️ misaligned goals across disciplines ➡️ poor async info flow ➡️ too many meetings acting as a workaround for deeper problems Through our program, we helped the team do the hard and valuable work: 🚀 align on shared goals 🚀 clarify roles and points of contact 🚀 build practical communication norms that improved collaboration And yes, sometimes that work gets very tactical! 💻 MS Teams channels set up (don't know what a "channel" is? You are not alone!) 👀 Which emoji to set as the norm to quickly acknowledge a message The results were significant: ✅ 75% fewer escalations ✅ 50% fewer meetings ✅ Meeting effectiveness rose from 22% to 72% ✅ Team metrics awareness from 39% to 83% ✅ Info flow improved from 41% to 83% Do those pain points sound like what you're experiencing? What to dig deeper into how this team transformed? 📚 Brian Elliott does a great job unpacking the FULL CASE STUDY in his newsletter - link is in the comments! Sign up for Brian's newsletter for practical guidance drawn from cutting-edge research and real-world experience from innovative leaders. Link is in the comments.👇

Collaboration is not a group hug. Here’s a tale of two offsites that I think captures the problem: At one recent offsite, a participant said: “I feel like there’s tension in the room.” At the other, someone said: “I feel like there’s not enough tension in the room.” In both cases, the culprit? 👉 People confusing collaboration with Kumbaya. In Offsite no.1, people were worried things had gotten too direct, when it was in fact healthy disagreement. In Offsite no.2, they were frustrated that no one was saying what they really thought, because everyone was too focused on the happy vibes. In both offsites, people were confusing collaboration with being nice. But real collaboration isn’t about being nice. It’s about being courageous. It’s about saying: “I don’t think this idea is working.” “I think we’re solving the wrong problem.” “Are we actually having the conversation we need to have?” Collaboration, when it works, is: ✅ Constructive tension ✅ Trust that’s strong enough to handle a few sparks  ✅ Trust that’s strengthened by the way the sparks are handled 🤔 So how do you shift from polite to productive? Here are 3 ideas I use with teams to build real collaboration: 1️⃣ Name the need for tension. Start by saying: “We’ll probably disagree today. We should disagree today. That’s not a sign of a problem, it’s a sign of progress. That’s how we tap into value.” 2️⃣ Design for dissent. Ask: “Who sees it differently?” or “What’s the thing we’re not discussing?” Create roles like “valued challenger” to make challenge safe, and allocate time to airing differing viewpoints. 3️⃣ Debrief the dynamic. Pause mid-way and ask: “Are we having the right conversation? What’s not being said? What do we need from each other to make it safe to discuss that stuff?” This makes reflection part of the way you roll - not an afterthought. Collaboration done well should never be soft and fluffy. It should generate friction, from which value is discovered. Messy. Brave. Productive. So next time your team’s being unbearably polite, ask: 🤔 What are the conversations we need to be having, and how do we get to those quickly? _______ This year, I’m focused on helping my clients in 3 key ways: 🔥 Delivering meaningful leadership development programs for experienced leaders 🔥 Facilitating the conversations that matter most in leadership teams 🔥 Helping teams and organisations crack the collaboration code If any of those are on your radar right now, feel free to message me. Happy to chat. PS. If we haven't met before and you'd like to stay in touch, I welcome your connection request.