5. Putting it all together

Now it’s time to take everything you’ve read and turn it into a plan. Your company’s size, age, and culture guarantee that your situation is unique, so we’re limited in making hyper-specific recommendations. Still, there are some proven patterns in structuring any organization for success, rolling out an effectiveness effort, and choosing and monitoring metrics.

In this chapter, we’ll share our experience with the foundational work of identifying and eliminating bottlenecks at the team level. Then, we’ll outline a high-level framework for implementing an organization-wide effectiveness effort. We’ll wrap up by talking about the challenges of managing change and sharing a framework for managing change-related feelings.

Identifying and eliminating delivery bottlenecks

At Swarmia, we’ve seen time and again that when teams focus on improving just a few key areas, the payoff comes quickly.

• Workflow. What does the flow of work look like for your team? Does everything take forever, or do things normally go fine, with the exception of some worrisome outliers? Do you routinely finish the things you start? How much time does work spend in a waiting state?
• Priorities & WIP limits. Does your team have clear, stable priorities? How many things does your team work on at once? Is it generally obvious to software engineers what they should work on next? Do you feel like your team is too busy to ever do anything well?
• Keeping the lights on (KTLO). How much time does your team spend doing chores or fighting fires due to past decisions? How does this affect your ability to deliver predictably? How does it impact morale?
• Manual work and toil. What does the team do manually on a somewhat predictable basis and why? Are your tests, deployments, and rollbacks all automated? Does your team planning include time to automate these tasks regularly?
• Decisions owned outside the team. How often does the team need to wait on someone on the outside to make progress with their work?

Here’s a closer look at each area, what it looks like when you have bottlenecks, and what to start doing today to get things on a better path.

Finding opportunities in these areas is usually painfully straightforward, and chances are good that engineers in your organization already have strong ideas about what to do. Acting on those opportunities will require finding ways to invest in the time and culture needed to implement solutions now and moving forward.

Convenient fallacies to avoid

Certain fallacies tend to come up whenever people talk about bottlenecks. In the course of your conversations, it will be tempting for you or someone else to say things like:

• “We aren’t doing enough up-front requirement-gathering.” Detailed up-front requirements aren’t just unnecessary — they can be detrimental when they restrict a team’s ability to adapt and evolve as projects progress. The most successful projects embrace evolving requirements, allowing for innovation and responsive changes. Adhering too rigidly to initial specifications leads to inefficiency and stifles innovative solutions.
• “What we really need is more people.” The notion that insufficient staffing is a primary bottleneck overlooks the underlying issue of WIP limits. Adding more staff to a project does not solve productivity problems; it often exacerbates them due to onboarding costs and increased coordination challenges. Effective productivity stems from ruthless prioritization and managing and optimizing the workload and capabilities of the existing team, not indiscriminately increasing team size.
• “We just need to plan better.” Extensive planning is often mistakenly idolized as the key to successful project execution. Over-planning can bind a team to a trajectory that may become irrelevant as project dynamics evolve. Effective planning requires balance — it provides direction, but not so much that it impedes flexibility and rapid response to change.
• “It doesn’t work that way here.” Perhaps when you hear this, you’ll have stumbled upon the exact problem, but it’s not one you can solve with code. Culture change might be needed to embrace all the recommendations in this book, and culture change is scary and hard.

Generally, be wary of claims that more processes will make things go faster, and be skeptical when someone suggests a headcount fix (unless they’re advocating for staffing a platform team, that is). Remember, any proposed fix that changes the size, shape, or remit of a team can affect productivity — positively or negatively — for months.

Keep effectiveness top of mind

An effective engineering organization is a differentiator in recruiting and retaining engineers and bringing value to your users. Engineering effectiveness should be an ongoing top-of-mind concern because it’s an engineering organization’s single best lever for delivering more and better business results.

Encourage your team to experiment with new methods, tools, and processes. WIP limits are especially interesting to experiment with if you haven’t done so before. Create an environment where process experimentation is allowed and part of the team’s culture. Whether it’s adopting new software tools or implementing automation, these experiments can lead to significant productivity gains.

Embed continuous improvement into your team’s routine. Regularly discuss topics like workflow, priority management, and automation opportunities. This keeps the team focused on productivity and encourages a culture of ongoing improvement. Use these discussions not only to identify areas for improvement but also to plan and commit to specific actions. Keep the focus on the team’s way of working, not on any individual.

Involve business stakeholders in your improvement initiatives. Their understanding and support can be pivotal, especially when changes impact timelines or require resources. Demonstrate with data that the proposed changes align with business goals, and lean on “the business” to support you with time, tooling, and training. Yes, this could be hard, but improvements in this space don’t come for free in the short term, even while they pay for themselves in the long term.

Alternatively, don’t involve business stakeholders if your reality doesn’t allow for it. You can make improvements just within your group team, without support from the organization or the business, but you may need to get creative in the short term. In the long term, demonstrated improvement might buy you the agency to make bigger changes with bigger results — or give you a great story to tell when you start looking for a new role.

Implement and track metrics that accurately reflect the team’s improvement over time. This could include tracking DORA, SPACE, or other relevant metrics. Regularly review these metrics to assess whether your changes are working. This data-driven approach not only helps to fine-tune your tactics but also provides tangible evidence of improvement, which can be motivating for the team and reassuring for stakeholders.

Know when to move on

As one bottleneck is addressed and resolved, it ceases to be the limiting factor in your workflow. The new bottleneck is in another area of the process. At this point, it’s time to move from actively working on the first bottleneck toward monitoring it to ensure there’s no backsliding.

By continuously moving the focus to the current bottleneck, you maintain a steady flow in your processes, enhancing overall efficiency and productivity. Identifying, addressing, and monitoring bottlenecks is an ongoing process — one part of an overall effort at continuous improvement.

Driving an effectiveness effort

Implementing an engineering effectiveness program is no small feat, and thoughtfully sequencing your approach will increase your chances of success. Here, we sketch a roadmap to guide you on this journey, broken down into six key stages: baseline, research, act, invest, normalize, and sustain (or BRAINS, for a memorable acronym).

• In the baseline stage, you lay the groundwork for your journey. Start with an inventory of the metrics you have today. Implement tooling and processes to understand the current delivery and team health situation.
• Next, immerse yourself in the environment of your engineering teams during the research stage, seeking to understand their challenges and victories first-hand through shadowing, interviews, and hands-on work.
• With this understanding, act immediately to implement small but meaningful improvements that can positively impact the team’s work.
• After tackling quick wins, it’s time to invest in longer-term improvements. Start standardizing processes and tools across teams to reduce complexity and improve consistency.
• Having implemented these changes, you can work to normalize the new processes across the organization, increasing adoption to maximize impact.
• Finally, commit to long-term investments in improving the developer experience in the sustain stage. The challenges you face will evolve as the company itself does.

Baseline

The first step is understanding your current situation.

Start from the table stakes identified in Chapter 1 (for organizations) and Chapter 3 (for teams). Does your organization uphold and support these table stakes? If not, as mentioned earlier, there will be a ceiling on the improvement you can achieve.

Take an inventory of the delivery-related metrics you have today and identify useful ones that would be easy to add. Take a moment to assess team health by considering satisfaction, attrition rates, and engagement levels. If you’re still small, this should happen organically; once you’re larger than 10 engineers, you may also want to create more intentional feedback mechanisms. Paint a picture of where things stand today for yourself and your stakeholders.

This is also a good time to consider implementing DORA metrics that accurately represent your software delivery performance. Getting these metrics in place demands developing a discipline (and systems) that you’ll be grateful for in the future.

Now is also a good time to routinely attach Balance Framework labels to your work items to start to paint a picture of where your time is going. You may want to build or buy a tool that makes this easier. Again, this is a practice you’ll be grateful for later.

Remember, the goal of this stage is not to create benchmarks for comparison between teams or individuals but rather to understand the present state so you can track improvement over time.

Research

Knowing how your engineering teams experience their work is essential to achieving real engineering effectiveness wins.

Spend time shadowing engineers, conducting interviews, and doing hands-on work. Understand their daily challenges, frustrations, and moments of triumph. Pay particular attention to their work patterns, collaboration habits, and pain points. Watch for systemic issues that might be slowing them down or causing unnecessary stress. This first-hand understanding will be invaluable in identifying effective productivity and experiencing improvements.

Now is also the time to review your early Balance Framework data. Where are teams spending their time? Are there any surprises in the data? What adjustments need to be made?

Act

Now that you understand your engineers’ current state and unique needs, it’s time to tackle the quick wins. These are small, relatively easy improvements that nonetheless have a meaningful impact on the daily work of your teams. They could be anything from streamlining a standard process to eliminating a manual task or addressing a common source of frustration.

Who’s going to work on these quick wins? For now, ensure that every one of your engineers knows they have permission to spend a little time making things better. Consider giving an engineer or two a few weeks on rotation to tackle an issue they’re passionate about. Publicly celebrate both large and small improvements, and publicize the biggest opportunities.

Invest

With the low-hanging fruit addressed, it’s time to focus on longer-term improvements at the organizational level. This often involves standardizing processes and tools across teams to reduce complexities and inconsistencies. Consider creating a dedicated platform team responsible for developing and maintaining shared tools and infrastructure. This investment in standardization can result in significant productivity boosts and make cross-team collaboration smoother and more effective.

Starting a team doesn’t have to be a big production; the team lead already works at your company and is looking for a new opportunity. They’re the self-directed, consistently high-impact person who’s been poking at flaky tests and exceeded expectations last quarter by automating the entire build and deployment. They’re a favorite collaborator among technical and non-technical folks alike, and they live for a good session of code archaeology.

The second engineer is also a colleague, and they were exceeding expectations within their first months. They’re a smart execution machine in need of a good mentor. They’re interested in humans and computers, hungry for challenging problems, and don’t mind if people in the real world don’t see their work.

You will be most successful if this team thinks of internal engineer platforms as products and understands that products have users — users whom you need to talk to and listen to, especially when they’re frustrated. A platform team’s ultimate goal is to help those users produce more value for the same amount of effort.

Normalize

Standardization only delivers its full benefits when it becomes the default. You want to create happy paths for common development tasks, like adding a new API endpoint or building a new feature in the user interface. Drive the adoption of these new processes, making it the new normal for how things are done. This step will require clear communication to explain the changes and their benefits, thorough training to ensure everyone knows how to work within the new systems, and incentives to encourage adoption.

Support development teams throughout this transition and be open to feedback and suggestions for improvement. You can form an adoption squad to help teams make the transition and understand the benefits. Whenever possible, automate these transitions. When that’s not possible, be sure to frame migration and usage instructions from the perspective of the platform user, not the platform creator.

Sustain

Maintaining and improving engineering effectiveness is not a one-off task but a long-term commitment. As your company grows, so will the complexity of your engineering effectiveness challenges. Continually invest in improving your understanding of these evolving challenges and devising innovative solutions. Set strategic goals that reflect this commitment and foster a culture of continuous learning and improvement.

Remember, you are focusing on improving the overall effectiveness of your engineering organization, not on specific tactics or short-term goals. This mindset will help you remain adaptable and responsive to the changing needs of your engineering teams.

Managing change

Introducing new ways of working can be a daunting task. To do it well, you need to be thoroughly familiar with the change and its reasons while also considering the human ability to have big feelings about seemingly small changes. If you simply show up one day and say, “We’re going to start measuring your work,” things probably aren’t going to go well.

Engineering leadership coach Lara Hogan writes and speaks about the BICEPS framework, developed by Paloma Medina, for understanding these human reactions. She emphasizes that everyone needs these six things to feel at ease about work and that any kind of change can suddenly disrupt any one of them.

With these core needs in mind, it’s easy to see that the first step in driving change is building trust with the people who will be affected. Trust, of course, has to be earned; even if you’re operating in a generally high-trust environment, a change perceived as substantial can make people uneasy. Especially in low-trust environments, trust-building activities are going to be essential to successful change.

There are a few things you can do to earn trust around a change effort.

• Offer social proof that this change has been valuable elsewhere. Of course, all businesses are different, but if other businesses in your industry or at your stage have embraced certain practices, that should carry some weight.
• Run a pilot or proof of concept with a small set of teams. Iteration within a small group will help you decide what you want to roll out more widely.
• Participate in the process you’re trying to improve and experience the difficulties first-hand. Share your learnings and let them inform your next steps.
• Celebrate successes widely and loudly, and incentivize the change you want to see.

Transparency likewise plays a huge role in how a change is received. Communicate clearly, frequently, and in multiple channels about why you’re making the changes and what outcomes you hope to achieve from them. Communicate about what’s working and what’s not. Communicate about how leadership is contributing to and supporting the improvements in substantive ways.

Many organization-wide changes can take months to roll out, and rolling out an engineering effectiveness effort is no different. Along the way, inform your next steps with feedback from the people impacted by the changes you’re making. As with any feedback, you don’t have to act on all of it, but be prepared to explain how you choose what to act on and what to set aside.

An engineering effectiveness effort can touch many of the BICEPS needs. For example, belonging can be affected if a person feels like their work won’t be as valued when people start looking at effectiveness metrics, predictability can take a hit as software engineers wonder how their performance reviews will be affected, and significance can suffer if people feel their contribution is being reduced to numbers.

Whole books have been written on managing change, so we are, at best, scratching the surface with the concepts discussed here. The most important takeaway is that change is hard and thus needs to be approached with care. While you can just flip a switch to introduce a new process, tool, or other way of working, it’s not likely to go well — a change of any significance needs thoughtful planning and communication.

What’s next?

Throughout your effectiveness journey, it’s important to focus on the ultimate goal: improving the experience and productivity of your engineers. This means avoiding getting too caught up in specific metrics or tactics at the expense of actual improvement.

This chapter provided a solid foundation for that journey, but once again, every organization and team is unique. Remember to remain flexible, responsive, adaptable, and cognizant of the changing needs of your engineering teams.

Further reading

• Leading Change, by John P. Kotter. Kotter provides an eight-step process for leading change with powerful insights and practical tools.
• The Goal: A Process of Ongoing Improvement, by Eliyahu M. Goldratt. This book introduces the Theory of Constraints, a methodology for identifying the most important limiting factor (i.e. bottleneck) in a process and systematically improving it.
• Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath. Offers insights into how to effect transformative change in organizations, which is useful for understanding and managing the human side of organizational change.
• Lean Thinking: Banish Waste and Create Wealth in Your Corporation, by James P. Womack and Daniel T. Jones. Provides a deep dive into lean principles, focusing on eliminating waste and improving efficiency, which are key to addressing process bottlenecks.
• Crucial Conversations: Tools for Talking When Stakes Are High, by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler. Valuable insights into handling high-stakes conversations.
• Core Needs: BICEPS, by Paloma Medina. A framework for thinking about human needs, informed by neuropsychologists, psychologists, and sociologists.