Building Cultures That Invite Contribution: A Blueprint for Thriving Teams

At our first Bridges Summit, we brought together thought leaders from research and software industry communities to reframe “Developer Productivity”, to clarify the vision of what we are truly aiming for, and create new possibilities for getting there.   We kicked off the event with an opening keynote panel discussion on the problems and constraints of our real world, featuring thought leaders across research and industry:

From industry: Kent Beck, Dave Thomas, Dormain Drewitz, and Chanté Martinez Thurmond

From research: Tom Zimmerman, Marian Petre, and Gail Murphy.

The Bridges Triangle gave us a starting point for discussion, a compass describing our aim as three integrated lenses: Developer Experience, Software Excellence, and Thriving. In a collaborative, cross-disciplinary discussion, community members gathered around virtual tables, brainstorming ideas on sticky notes to clarify the vision of what we’re aiming for.

Bridges Triangle of three integrated lenses reframing the goal: Developer Experience, Software Excellence, and Thriving

As a final article of the series, capturing key insights from software industry and research at Bridges Summit, this article summarizes the community discussions on problems and constraints that get in the way of people, teams, and organizations thriving.  We augment the insights from this discussion with research on high-performing teams and developer thriving to paint a picture of what thriving teams look like, and help us take practical steps toward building thriving teams.

Theme 1: Bridging the Gap Between What’s Measured and What Matters

Many community members described environments shaped by what gets measured—productivity, utilization, and performance always under scrutiny.  Teams are under intense pressure.  Community members described teams run at 100% utilization with no slack.  One community member described how without time for understanding, much of software development is full of fear and anxiety.   Other members wondered how you build confidence in yourself as a developer with all the uncertainty around how “productivity” is being measured and how you are being evaluated.  Several community members mentioned the struggle with imposter syndrome as well as an overall lack of trust.  With all the focus on productivity and performance, the resulting experience is a lot of anxiety and self-protective behavior aimed at making the metrics look favorable. 

Leaders desire objective metrics to inform decision-making—yet the essence of what matters for long-term success isn’t easily measured. Community members described the distortions created by what’s measured and how activities like learning, training, planning, and onboarding new teammates can feel like "wasted" time because no lines of code are written.

Leaders desire objective metrics to inform decision-making—yet the essence of what matters for long-term success isn’t easily measured. 

In the opening panel discussion, Marian Petre shared about her 30 years of software research into high-performing teams, specifically researching what distinguishes high-performing teams from all other teams.  She described a central glue of shared purpose— that through a shared caring about the product and building a product fit for purpose, the team aligns around a shared sense of what matters.  When we are evaluated on performance, we become anxious and self-protective. When we are oriented toward contribution, we become collaborative and purpose-driven.

High-performing teams emphasize critical-thinking, looking for what isn’t there, looking for what doesn’t match, and looking for misconceptions.  Instead of jumping immediately to solutions, the teams maintain alternatives, contrasting different tools and processes to create options.  High-performing teams have lots of dialogue so different perspectives can come into the room, all while keeping the critical-thinking going and keeping an ear open for the thing that doesn’t fit.  This doesn’t mean high-performing teams don’t face the challenges of differences in perspective, language, values, and goals. Rather, high-performing teams are able to address these differences better than anybody else.

The first part of the thriving team blueprint is this central glue: aligning around building a product fit for purpose. By inviting contribution and cultivating shared purpose, we can better align around what truly matters. It’s a seed—not a silver bullet—but a potent one.

Theme 2: Reweaving Purpose Through Connection and Clarity

In the last theme, we explored the shift from being performance-oriented to contribution-oriented—aligning around building a product fit for purpose as the glue that holds high-performing teams together.  When this sense of purpose is missing, it can be difficult to feel motivated. What we heard from the community was a deep ache—the felt experience and longing to feel connected to something that matters.  Community members highlighted the lack of connection with real users, and not getting to see the impact of their work.  Others felt an overall lack of purpose and a lack of context for why their work mattered.  One community member spoke of not feeling appreciated.

What community members are really asking for is purpose they can feel—a throughline from what they do to why it matters.  In a recent developer study by University of Victoria, one developer (P06) shared their felt experience of the magic that happens when there is excitement around building the product: "When we got the MVP working, people saw the potential, and that's when everyone got excited. 'Can we do this? Can we do that?' And I was like, 'Yes! We can do this. Yes! We can do that.' And it just became this.. really, it moved beyond just coding. It moved into this team experience—where people were contributing who wouldn't normally contribute to the code.  They weren't coding, but they were having a direct influence on what we were building.  And as the people building it, we could rely on them to be part of that process—to be a positive contributor to making it a better product."  This is what contribution-oriented teams look like in practice.  Not driven by anxiety about performance, but pulled forward by shared excitement in building the product.

"'Can we do this? Can we do that?' And I was like, 'Yes! We can do this. Yes! We can do that.' And it just became this.. really, it moved beyond just coding. It moved into this team experience." 

One insight we had while discussing the stickies shared in the summit is that sprint demos are actually quite important. Taking a moment to show off the cool feature you made, especially when you have a chance to connect your work with impact, that feeling of "Look, I made that!" is a joyous feeling.  It’s great when we get to share it with others, and helps to cultivate a sense of connection.  Even if you were the developer that did the backend data, the team still knows the importance of the contribution, and they’re celebrating you too.  After the demo is also a great time to lead a discussion about the product— to learn more about the customers, what’s working and what isn’t, and collaborate on building a better product.  We can practice at the skillset of high-performing teams and having generative effective dialogue.

When we don’t know who we’re building for or why decisions are being made, it’s easy to lose our sense of direction. But when we can see how our work fits—when there’s clarity in the context, who the customer is, and the vision of what we’re building and why—we can move forward with purpose.  Reweaving purpose doesn’t happen in a single meeting or by writing a mission statement. It happens when we restore the threads of relationship:

• To the people we’re building for

• To the team we’re building with

• To the context and values shaping what we build

It’s not just “purpose” in the mission statement sense. It’s a lived purpose, felt through context, relationships, feedback, and impact.

Theme 3: Creating Slack as Strategic Capacity

When we asked the community to name problems and constraints that keep individuals, teams, and organizations from thriving, another theme came up repeatedly: There’s no slack. Community members shared how their teams were run at 100% utilization, with no time to learn, no time to onboard other team members, and no time to fix what you just tripped over.  One member highlighted how tracking utilization increases the pressure to operate this way–that it’s too easy to remove slack and resilience in pursuit of getting more features done. Inevitably, there’s issues that come up that need attention, and if there’s no slack there’s no time to deal with it.

When everything is go-go-go, ironically, the constant push to maximize productivity becomes self-defeating.  What’s worth highlighting here is that when you remove slack, you’re not just removing downtime—you’re removing the system’s capacity to evolve.  Without slack, even thinking about doing something in a better way feels forbidden–you're just trying to stay afloat. This leads to brittle systems, disempowered teams, and a reactive culture.  We treat slack as optional, but when it's gone, so is our ability to reflect, adapt, and care.

When you remove slack, you’re not just removing downtime—you’re removing the system’s capacity to evolve.

Slack isn’t idle time–it’s time when team members have the agency to choose what to focus on.   Slack is a type of strategic capacity that creates the conditions for:

• Reflecting on what’s working and not

• Smoothing out friction in the system

• Mentorship and learning

• Developer agency and intrinsic motivation

• Reconnecting to purpose and vision 

If the team is engaged with building a product fit for purpose and in a contribution-oriented mindset, the choices for what to do with the slack available are likely to be in alignment with a genuine caring about the product and success of the team.  Taking a moment to reflect, to think about ways to help, and having some room to take action on those ideas, is what slack is all about.   We’ve framed slack as waste, but it’s actually the space where resilience, quality, and care are born.

In one of the thought leader talks at Bridges Summit, Cat Hicks shared her research on the Developer Thriving Framework, highlighting the research-backed conditions that make thriving possible– learning culture, agency, motivation, and belonging.  In a study with 1282 developers, she also showed how investing in these factors predicts long-term productivity, and suggests actionable strategies for improving these factors.

While Cat’s research outlines the conditions that make thriving possible, community members named the absence of slack as a barrier. The challenge is, the conditions of thriving also need space to take root.  This is where slack comes in.  It’s not the end state—it’s the starting move. Without slack, there’s no room to learn, no time to reflect, no capacity to support one another. The framework can feel distant when teams are underwater—but creating slack is the first act of reorienting.  It’s how we make thriving not just an aspiration, but something teams can actually grow toward.

An Invitation: Shared Purpose and the Spiral Toward Thriving

We don’t build thriving teams by mandate. We build them by invitation—an open door, a gesture of trust, a shift in posture.  Thriving isn’t something we enforce; it’s something we create space for.

It starts small.

You can start with a single reimagined meeting, the sprint demo.  Gather your team, not just to present, but also to celebrate the contributions, connect, and have a rich discussion on how to build a product fit for purpose.  Make space for curiosity, for feedback, for shared excitement about what’s being built and why it matters. Center the conversation on the people you’re building for. Ask what’s working and what isn’t. Invite perspectives from across the room.  From here, you can start practicing the skills of high-performing teams—getting better at rich, generative dialogue.

This one move can shift the air in the room. It rekindles a sense of purpose. It brings back the joy of building together. And it lays the groundwork for deeper trust. And when trust takes root, it becomes easier to make the next move: create time for slack.   Then, as you see the team caring, learning, and making improvements—and that more resilient kind of productivity takes root—the rebuilding of trust cascades.

That’s how thriving begins. Not with pressure, but with an invitation.