Looking at Stack Overflow’s 2024 Developer Survey, specifically the question about job satisfaction, we see a pretty sad story: roughly 80% of developers are either unhappy or just complacent at work. Think about that - only 2 out of 10 professional developers actually enjoy what they’re doing.

This feels really wrong. When you look at the factors that contribute to happiness and unhappiness at work, about 50% relates to things like improving code quality, learning new technologies, building environments, or working on architecture. My interpretation? People are bored. They’re unhappy because they’re doing the same things over and over, instead of making their work better, learning new things, building new solutions, or solving interesting problems.

Now, I’m not saying we should be doing exciting, innovative things all the time - that’s not what work is all about. But we need to have a mix. The fact that 80% of developers are either unhappy or just complacent suggests that something’s missing, and I guess that they’re not getting enough opportunities to solve interesting problems at work.

Possible remedies

Most problems don’t have a single solution, and developer happiness is no exception. This challenge - the lack of satisfaction among software developers - not only affects individuals but also impacts business outcomes. There’s no silver bullet, but there are several approaches that, when combined thoughtfully, can help improve the working lives of software professionals. Let’s explore some building blocks that can be mixed and matched to create better environments for development teams.

High performing teams

In his talk “The Science of High-Performing Teams”, David Burkus describes three key elements for high performing teams:

• Common understanding
• Psychological safety
• Understanding who the team is serving

Interesting is how “Common understanding” extends beyond creating a RACI (Responsibility Assignment Matrix). Instead, it invites us to learn more about individual team members needs and exercise empathy. This creates an important responsibility for everyone on the team: recognizing that the world isn’t black and white. An approach that works perfectly for one person might not suit another, and what succeeds in one scenario might fail in a different context.

For those interested in diving deeper into these concepts, the SCARF Model provides valuable insights into understanding individual needs and building psychological safety.

Team topologies and Better value sooner safer happier

In this video “Better Value Sooner Safer Happier (BVSSH) and Team Topologies (TT)", Matthew Skelton and Jon Smart talk about how to design better teams and the convergence of the two principles of BVSSH and Team Topologies, let me start with team topologies:

Team topologies book promotes some key work design considerations or principles:

• Four team types with three interaction modes
• Aim for fast flow, who likes to wait, eh?
• Care for the Team cognitive load, aren’t we all overloaded with information and complexity?
• Define the Thinnest viable platform, after all we need to agree as a team what is the minimum level of protection that we believe will allows us to move fast.
• Empower the Teams to adjust boundaries

In other words, recommends constraints to encourage emergent behaviours for fast flow. This reminds me the concept of emerging narratives in game design, where you create the necessary conditions with the game so players can come with their own way of playing, the same idea is applied here, stablish foundations that allow the team to find their way to a fast flow.

These are the team types proposed:

• Stream-Aligned Teams - End to end product development, with direct connection to user value
• Enabling Teams - Experts and SMEs with focus on filling gaps
• Platform Teams - Create solutions for the other team experience
• Complicated Subsystem Teams - Handle specialized, complex components shielding other teams from complexity

BVSSH Better value sooner safer happier is a collection of patterns, principles and anti patterns, that connect very well with the proposal from Team topologies, there is so much convergence that feels like one piece

Focus on Outcomes, Not Output

Instead of just asking teams to write more code, BVSSH focuses on getting real results. Companies should first think about why they do what they do, what they’re trying to achieve, and how they help their customers.

BVSSH looks at four main areas. First, Better Value means setting clear goals that help the business succeed. Second, Sooner means getting things done quickly so customers don’t have to wait. Third, Safer means building things the right way from the start, not just adding safety checks later. Last, Happier means making sure everyone benefits - customers, workers, the community, and even the environment. If everyone’s happy, the company is more likely to do well in the long run.

Learning Through Small Steps

BVSSH doesn’t believe in big, sudden changes across a company. Instead, it suggests making small changes over time, letting teams learn by doing. Teams get time and space to try new things and see what works best. The approach understands that people need time to both learn new ways of working and to let go of old habits that might not work anymore.

Leadership and Psychological Safety

Leaders are key to making changes work. In BVSSH, leaders need to create a safe space where teams aren’t afraid to try new things and make mistakes. Instead of just telling people what to do, leaders should show the way by doing things themselves first. They let teams come up with their own solutions based on what they learn and experience. Most importantly, leaders focus on getting people excited about change rather than forcing it on them, since real change happens when people want to change, not when they’re told to.

Common Anti-Patterns to Avoid

• Big Sudden Changes: Making huge changes all at once usually hurts the organization. When leaders force everyone to change at the same time or stop all work temporarily, it creates stress and makes people work extra hard just to keep up. It’s better to make small changes over time and let teams learn as they go.
• Forcing Change: When leaders order changes with strict deadlines without involving their teams, it usually fails. People need to be part of the change process and help figure out what works best for their team.
• Hidden Work: When teams can’t see how work flows through the organization or how different teams depend on each other, it causes problems. Instead of creating complex rules to manage these connections, it’s better to make teams more independent and solve problems at the smallest possible level.
• Looking for Perfect Solutions: Some organizations try to create perfect, unchanging solutions. This doesn’t work because business needs keep changing. Teams need to be able to adjust their work based on what they learn and what new challenges come up.

What’s Next?

These are just some ideas about how to improve teamwork and get better results. If you forget everything else from above, remember just one thing: try small experiments to solve your problems. To do this well, you’ll need a few things:

• A safe space where people aren’t afraid to try new things
• Clear goals about what problems you’re trying to fix
• Ways to work together and listen to what people need

Happy experimenting! 🧪😁