Swarmia

Improving the quality of your daily stand-ups might only require one change: focus on the work, not the people. Here’s how to do just that.

If you’re struggling to come up with questions to ask in your next developer experience survey, check out this blog post where we share our research-backed 32-question survey framework.

When leaders are frustrated by the productivity of engineers, they may not realize that they're contributing to the problem. Who here *hasn't* worked at a place that has separate product and engineering OKRs? Or a place where delivering a project is priority 1, but so is security, and also stop having so many production incidents please? Part of being a leader is deciding what's important, AND WHAT IS NOT. They are hard decisions! But when you don't establish clear priorities, engineers will start work that never gets finished; the work that does get finished will take longer than if priorities were stable. Steering the overall direction of an org is a leader's job, but when they ask engineers to steer in three different directions, and one of those directions is off an SLO cliff ... it's easy to empathize with the devs who are being pushed to be "more productive."

As your software organization grows, it can start feeling like engineers, product managers, and designers have less and less influence on what they’ll work on next. In this episode of Engineering Unblocked, Ben Vinegar, former VP of Engineering at Sentry, explains how they handed more decision-making power back to the teams as the company grew. Catch the full episode wherever you get your podcasts.

Working agreements increase accountability in engineering teams. Getting started is easy. All you have to do is: 🔹 Involve the whole team in coming up with a list of shared working agreements 🔹 Start small — you can always add more agreements later 🔹 Document the agreements in one place 🔹 Review the agreements frequently and make it easy to propose changes 🔹 Share the list with new hires to help them with onboarding For more tips and concrete examples, check out our ultimate guide to working agreements.

Most software development benchmarks we’ve seen: ❌ …are too broad. With ~20 metrics, how are you supposed to know where to start? ❌ …encourage optimization far past the point of diminishing returns. If your average pull request cycle time is 22 hours, does it really make sense to try to get it down to 20? That’s why we took a pragmatic approach to benchmarks. We zeroed in on five metrics that are so fundamental to engineering effectiveness that if your organization lands on the “needs attention” range on any of them, you’ll immediately know where to start. Check out our benchmarks and start improving the metrics that matter.

Are you still using spreadsheets to manually track the progress of cross-team engineering initiatives? If the answer is yes, this post is for you.

“Even if your software engineers are loving their work and building new things fast, neither of those things matter if they’re building the wrong things.” Luca Rossi invited our Field CTO Rebecca Murphey on the Refactoring podcast to talk about the three pillars of engineering effectiveness: 🔹 Business outcomes 🔹 Developer productivity 🔹 Developer experience Check out the full episode on YouTube: https://swarmia.co/4dLNOMJ

New in Swarmia: 🔹 Estimate the end date of your initiatives with the new initiative forecasts. 🔹 See the number of PR comments in code review notifications. 🔹 The past four full quarters have been added as presets to all time selectors throughout the app. 🔹 Use the new tooltips in the PR throughput graph to look at the number of contributors per week and the number of PRs per contributor. Read more in the changelog 👇

Most software organizations with a dedicated platform team wish they had started one earlier. In this blog post, we explore why the best time to start a platform team is ~now.