Cracking the Code of High-Performance Tech Organizations
Have you ever wondered why some companies can effortlessly deliver software quickly and accurately while others struggle to make progress? What makes these top-performing companies different? The book "Accelerate: Building and Scaling High-Performing Technology Organizations" lays out research-backed strategies to build such organizations.
Initially, we thought the book would consist of a bunch of little tips and tricks that might be helpful. To our surprise, we found that it is much more than a collection of tips. Accelerate presents a full plan for transforming engineering organizations into high-performing teams. This article will cover some of our key questions and takeaways from Accelerate. From there, you can determine if the book is worth your time.
Q1: WHAT ARE MOST ENGINEERING ORGANIZATIONS DOING WRONG WHEN DELIVERING SOFTWARE?
Often, organizations face issues in the software development life-cycle (SDLC) without understanding why or how to fix them. The process can be complex, involving many teams, tools, and environments. Altering user-facing services can also bring about a fear of breaking the system. This fear-based mindset and inherent complexity often leads to bottlenecks and less visibility into the SDLC.
The authors of Accelerate explore these topics using research and practical lessons from high-performing businesses. They shed light on the common pitfalls organizations face. Some of those pitfalls include:
LACK OF FOCUS ON AUTOMATION
High-quality automation allows people to do what they are good at, reasoning instead of managing tasks. With automation, work becomes more sustainable for developers. The lack of high-quality automation leads to deployment pain caused by manual errors, slow deployment processes, and increased cycle times.
Automated deployment systems ensure that changes are consistently applied across different environments – leading to more predictable and reliable deployment outcomes. Automated testing enables quicker and more thorough validation of software changes. This combination of the two ensures that new code does not introduce unintended issues or regressions.
THE ABSENCE OF A COLLABORATIVE & LEARNING-DRIVEN CULTURE
The absence of a learning culture prevents teams from working together and receiving feedback from each other, slowing down deployment cycles. When a company has a learning-driven culture, teams focus more on personal growth. This includes more mentorship amongst developers to improve their skills and processes. As a result, deployments are indirectly improved due to improved processes, code quality, and collaboration.
NOT USING THE RIGHT METRICS FOR EVALUATION
Accelerate talks about the importance of measuring the right metrics to gauge team performance. The 4 DORA metrics open up a rich amount of insights in that area. However, the important thing to focus on is the 24 software capabilities; NOT the DORA metrics. For example, if most of your deployments crash production because you are doing a rush job to increase deployment frequency, you are missing the point. None of the four DORA metrics work alone. Each metric is supported by a number of capabilities. We’ll dive deeper into them later in this write-up.
Q2: IS IT POSSIBLE TO SHIP CODE FASTER WHILE REDUCING RISK?
The speed at which organizations can deliver new features and updates is critical to their success. However, many fear the risks that may be associated with fast deployment. The fear of compromising the reliability of production often leads to a cautious approach toward change.
With the right approach, frequent deployments actually decrease risk in more ways than they add risk. When you deploy more frequently, the size of the change gets reduced. As such, there is less of a chance that something goes wrong, and it’s easier to find and fix errors that are introduced. Additionally, when your teams deploy frequently, they get better at the act of deploying. The following allows organizations to ship code faster while reducing risk:
CONTINUOUS INTEGRATION AND CONTINUOUS DEPLOYMENT (CI/CD) PIPELINES
Continuous Delivery is getting changes into production quickly, safely, and automatically. The value of implementing CI/CD pipelines to automate the build, testing, and deployment processes not only reduces manual errors but enables faster and safer releases. Teams that do well at continuous delivery achieve:
MONITORING AND OBSERVABILITY
When monitoring & observability systems are in place, teams can detect and solve problems quickly. If a breaking change is introduced during deployment and an alarm goes off, triggering an automated rollback, the impact of that issue gets drastically reduced. Having these systems in place can give software teams the confidence to deploy frequently.
AUTOMATED TESTING AND QUALITY ASSURANCE
Investing in building a comprehensive suite of automated tests, if done correctly, can really streamline a team’s productivity. A good test suite ensures that new changes are thoroughly vetted before reaching production, reducing the likelihood of introducing defects. Furthermore, automated tests can catch bugs before they even get committed. If your teams are following a practice like Test Driven Development (TDD), many categories of bugs won’t even be possible anymore.
Q3: HOW CAN LEADERSHIP DIRECTLY IMPACT DEPLOYMENT SPEEDS?
Leadership plays a pivotal role in shaping an organization's software delivery performance. Accelerate talks about how improved leadership practices can directly impact deployment speeds. Some of the practices include:
Giving developers the authority to address issues reduces roadblocks. It also promotes a culture of autonomy. This culture shift breeds a sense of ownership and accountability, motivating teams to act decisively. As a result, teams tend to have faster resolutions and shorter recovery times.
Accelerate draws a clear correlation between deployment pain and poor software delivery performance. Understanding that deployment pain is fear and anxiety during the release process. These are some insights into reducing this pain:
Trunk-based development: Trunk-based development is an approach where developers continuously merge small and frequent code changes without letting individual branches last more than a day. It minimizes deployment pain by enabling developers to address issues faster and easier due to the small code updates.
Independent workflows: Independent workflows are used when different teams or developers work on distinct features or components. This approach reduces the chances of code conflicts, simplifying the deployment process.
Adopting a loosely coupled architecture: Loose coupling tends to improve deployability. These things enable us to move fast. One of the benefits is the independent deployment of components. This allows parallel development and faster, safer rollouts. A loosely coupled, well-encapsulated architecture with a healthy organization structure to match:
Q4: IN WHAT WAYS ARE SUCCESSFUL ORGANIZATIONS MEASURING THEIR TEAM PERFORMANCE?
Leadership often focuses on improving productivity metrics. Even when teams follow suit, and the metrics seem to improve, the actual outcomes haven't necessarily changed. Take Goodhart’s Law, for example, “When a measure becomes a target, it ceases to be a good measure.” Essentially, a hyper-focus on one goal often leads people to disregard the big picture. This can lead to a good-looking set of metrics and a less ideal set of outcomes.
Instead of quantifying and measuring team performance, opt for measuring team health. A healthy software team increases the probability of high performance. The research provided in Accelerate found four key metrics as indicators to measure team health called the DevOps Research and Assessment team (DORA) metrics.
The four DORA metrics are
领英推荐
The deployment frequency metric measures how frequently code is deployed to production. High-performing teams show the ability to release code frequently. They enable faster time-to-market and quicker responses to customer needs.
The lead time for changes metric quantifies the time it takes for code changes to move from development to production. Shorter lead times signify efficient development and delivery processes. This enables organizations to deliver value to customers swiftly.
The time to restore service metric reflects how long it takes for the system to be restored after an incident. High-performing teams excel in rapidly addressing and recovering from incidents. They minimize downtime and customer impact.
The change failure rate metric gauges the proportion of code changes that result in failures when deployed to production. Low change failure rates indicate the release process and quality assurance are optimized.
A healthy way to improve DORA metrics is to focus on the 24 software capabilities instead of focusing solely on improving DORA metrics (remember Goodhart’s Law). The 24 software capabilities contain practices that collectively contribute to enhancing DORA metrics. For example, a bad way to interpret slow lead time is by saying, “In order to increase the lead time, developers need to work faster”. This is not helpful as it assumes that the problem is the developer's speed without looking at a full view of the problem. Instead, leaders can evaluate the capabilities to identify if too much work is in progress. Maybe the system architecture is not loosely coupled, or the culture needs improvement. Using the DORA metrics alongside the 24 capabilities helps leaders measure team health, and indirectly, team performance.
Q5: WHAT ARE THE CAPABILITIES THAT DIFFERENTIATE HIGH-PERFORMING TECHNOLOGY ORGANIZATIONS FROM THEIR PEERS?
There are 24 capabilities that enable high-performing teams to excel. These capabilities, grouped into five categories, are crucial in driving successful software delivery:
Continuous Delivery: Incorporating continuous delivery practices allows teams to quickly release quality software.
Architecture: Strong team architecture skills lead to the creation of systems that can grow with the market. Systems remain easy to maintain and adapt to changes.
Product and Process: These capabilities focus on entrusting teams to experiment, innovate, and optimize their development processes. As a result, they deliver value to customers consistently.
Lean Management and Monitoring: Effective monitoring and feedback loops allow teams to identify issues and make data-driven decisions. This allows teams to drive continuous improvements.
Cultural: Leaders must promote a culture of collaboration, trust, and learning. It directly impacts an organization's ability to adapt and thrive in a changing environment.
The capabilities model presented in Accelerate stands in contrast to traditional maturity models. Focusing on capabilities allows adaptation in a changing market, whereas maturity models view the market as static. To maintain a competitive edge, organizations must recognize the need to adapt quickly and embrace change. By focusing on these capabilities, you can position yourself to thrive in the software industry. You can learn more about these capabilities by reading the book and/or by going to this website: https://cloud.google.com/architecture/devops
Q6: IS BAD LEADERSHIP THE LEADING CAUSE OF BURNOUT?
Accelerate covers the complex issue of burnout in the context of software engineering and leadership. While the book doesn't single out leadership as the leading cause of burnout, it provides valuable insights into the factors that contribute to this challenge.
Burnout is physical, mental, or emotional exhaustion caused by overwork or stress. Burnout in software engineering is a concern that can impact team productivity, morale, and performance. In certain instances, misaligned leadership practices can exacerbate burnout risk. These practices could be demanding unrealistic deadlines or overlooking team members' well-being.
The first step to addressing burnout is examining the contributing factors, some of which include:
Consistent time pressure: Tight deadlines are a constant pattern rather than occasional occurrences. Consistent time pressures can lower team morale and indicate a systemic issue that needs attention.
Lack of autonomy: When developers have greater control over their work, they experience higher job satisfaction. They are also less susceptible to burnout.
Lack of a supportive and inclusive culture: Developers who feel valued and supported are likely to experience lower burnout rates. They will also have higher levels of engagement, benefiting the organization.
To prevent burnout, leaders can take a proactive approach. Rather than just giving orders, they can talk to each team member and find out what challenges they are facing. By sharing these obstacles, leaders can strengthen their relationship with developers and spark ideas for overcoming the challenges. This simple action can go a long way in preventing burnout.
Leaders can also create a work environment where failure is not looked down upon but rather seen as a way to move forward. This will encourage team members to think about why they did something and feel more connected to their work.
Q7: WHAT ARE THE LEADING STRATEGIES USED BY SUCCESSFUL ORGANIZATIONS TO INCORPORATE SECURITY INTO THEIR SOFTWARE DELIVERY LIFECYCLE?
High-performing teams spend 50% less time fixing security issues compared to other teams. They achieve this metric by incorporating information security into the software delivery process. This approach, known as "shifting left," eliminates the need for a separate security phase that occurs after development – allowing teams to practice continuous delivery more effectively. Below are some shift-left strategies used by successful organizations.
TRAINING DEVELOPERS IN SECURE CODING PRACTICES
This strategy provides developers with the knowledge and skills to write code that resists vulnerabilities and threats. It is a proactive approach where security becomes an inherent part of the coding process. It also ensures that security training is not a one-time event but an ongoing process.
USING AUTOMATED SECURITY SCANNING TOOLS
Teams can identify vulnerabilities early in the development process with automated security scanning tools. These tools provide immediate feedback and help catch security issues before they enter into production. A quick google will point you in the right direction of some useful tools. GitHub also has built-in security features to scan code and check for vulnerabilities and errors.
CONDUCTING THREAT MODELING EXERCISES
Conducting threat modeling exercises early in the development process helps identify potential security threats and vulnerabilities in the application's architecture and design. It's a proactive way to identify weak points and design countermeasures before they are exploited by attackers.
IMPLEMENTING CONTINUOUS SECURITY MONITORING
Continuous security monitoring involves keeping a vigilant eye on applications and systems post-deployment. Companies can identify and respond to security threats in real-time, minimizing the impact of potential breaches. Monitoring for security threats and vulnerabilities aligns with the overall DevOps philosophy of maintaining a development and operations environment.
THE BOTTOM LINE
Accelerate: Building and Scaling High-Performing Technology Organizations is a great book for addressing many setbacks often experienced within organizations. Deployment challenges, measuring performance, building a generative culture, and much more are covered with detailed strategies backed by real-world research. Organizations are always growing and changing, so it is best for tech leaders to reference this book often and out of order. This will ensure that you have the information to keep your organization high-performing, despite inevitable changes. So, our final question is… do you think the Accelerate book is worth your time?