How to introduce transformational leadership traits:
- Establish and support a generative, high-trust culture.
- Support technologies that enhance developer productivity. Reduce code deployment lead times and improve infrastructure reliability.
- Encourage team experimentation and innovation.
- Collaborate across organizational silos to achieve strategic alignment.
How to enable cross-functional collaboration
- Build trust between teams by keeping promises, communicating openly, and maintaining predictable behavior.
- Encourage practitioners to move between departments.
- Actively seek, encourage, and reward work that facilitates collaboration.
- Create a training budget and advocate for it internally.
- Ensure your team has the resources for informal learning and the space to explore ideas—learning often happens outside of formal education.
- Make it safe to fail. If failure is punished, people won’t try new things. Treat failures as opportunities to learn. Hold blameless postmortems and help people feel comfortable taking reasonable risks.
- Create space to share information, such as weekly lightning talks, demo days, and forums.
- Ensure your team can choose their tools—this is a major contributor to job satisfaction.
- Make monitoring a priority. Collect meaningful data on the right services.
Managers and Leaders
Leaders and managers are two different concepts. Leaders inspire and motivate people around them, while managers make decisions regarding resources, staff, and priorities.
The real value of a manager or leader is measured by their ability to amplify the work of their teams, including the ability to deliver code, architect good systems, and apply lean principles to product development and work management.
Managers have the authority and budget to make large-scale changes that are often needed to provide air cover when transformation is underway.
What are the traits of a good leader?
- Vision – A good leader has a clear idea of where the team should be in the next 5 years. They deeply understand organizational goals and know how their team can contribute.
- Inspirational communication – A good leader makes people around them proud to be part of the team. They say positive things about people’s performance, notice individual efforts, encourage people to see change as an opportunity, and inspire and motivate their teammates.
- Intellectual stimulation – A good leader challenges followers to think about problems in new ways. They encourage people to rethink their basic assumptions.
- Supportive leadership – A good leader considers the personal feelings and needs of their teammates.
- Personal recognition – A good leader recognizes employees who perform above average. They acknowledge improvements in the quality of work and compliment outstanding efforts.
Employee satisfaction, identity, and engagement
Employee satisfaction, loyalty and identity are not just feel-good metrics, they are drivers of business outcomes: profitability, productivity, and market share.
These metrics can be measured by Net Promoter Score. NPS is most often used to measure how likely a customer is to recommend a product. However, in the context of employee satisfaction, NPS indicates how likely employees are to recommend their team or organization as a great place to work.
NPS is scored between 0 and 10. The results are grouped into three categories:
- The Promoters score 9 or 10 on the NPS scale. Promoters generate great value for the company by buying more products or services. They are easy to acquire and retain and generate positive word-of-mouth.
- The Passives score 7 or 8 on the NPS scale. They are less satisfied customers or employees who are likely to switch when something better comes along.
- The Detractors score 6 and below on the NPS scale. They are a dissatisfied group of people that are expensive to acquire and retain. They hurt the business through negative word-of-mouth.
Employees in high-performing organizations are 2.2 times more likely to recommend their organization and 1.8 times more likely to recommend their team as a great place to work.
Companies with highly engaged workers grew revenues 2.5 times more than their counterparts with low engagement levels.
The stock of companies with high-trust work environment outperformed market indexes by a factor of three.
In the context of DevOps, job satisfaction was strongly impacted by usage of the right tools and resources which enabled employees to perform their tasks effectively.
Burnout
Burnout is a serious threat to employees’ health. It manifests itself in helplessness, a loss of accomplishment, negative feelings from work spilling into personal life, exhaustion, cynicism, and reduced productivity. Burnout turns things you once loved into something dull and insignificant.
A pathological, power-oriented culture is often a primary cause of employee burnout. A defining trait of such an environment is a culture of blame, where individuals cannot rely on support from their community. To address this, organizations must first foster a culture that emphasizes learning from mistakes. This begins with recognizing that human error is rarely the root cause of failure; more often, it is flawed processes that are to blame.
Lack of control is one of the biggest drivers of burnout. Employees should have the authority to make decisions that affect the outcomes they are responsible for, ensuring alignment between accountability and influence.
Inefficient leadership is a major barrier to team performance and a contributor to burnout. Leaders should focus on reducing work in progress and actively removing roadblocks. By regularly asking employees what’s preventing them from achieving their goals, leaders can identify and address obstacles before they escalate.
Providing employees with the resources to improve their work lies at the foundation of lean management. This includes dedicating time and resources to experimentation and learning, embracing failure as a source of growth, investing in skills development, and providing timely, on-demand training.
Deployment pain has been identified as a significant cause of burnout among developers.
Other causes of burnout include insufficient rewards—whether financial, social, or institutional, injustice, and work overload.
Product Development
Four methods that make up the lean methodology proved to have positive impact on team productivity, organization profitability, market share. Additionally they improved team culture and reduces burnout.
- Work in small batches – Features should be reduced in scope until the point where they can be released weekly. Features should be small enough to enable validation learning.
- Make flow of work visible – Team members should understand the product’s status and significance, from its business context to how it is received by customers.
- Gather and implement customer feedback – Customers should be engaged from the very start of product development. Their insights on quality, usability, and satisfaction must be continuously measured and addressed from day one.
- Team experimentation – Teams should have the autonomy to respond to this feedback and adjust the product direction as needed.
Making work sustainable
We aim to ensure sustainable long-term performance through appropriate methodologies, rather than exhausting human resources for short-term bursts of increased velocity.
Deployment pain – fear and anxiety that engineers feel when they push to production tells a lot about delivery performance. In companies where code deployments are most painful you will find the poorest software development performance, organization performance and culture. Developers not knowing how deployment work is a big red flag that indicates that deployment process is too obscured.
Teams that implement comprehensive tests and deployment automation, use continuous integration, trunk-based development, bake security into the development process, effectively manage test data, use loosely coupled architecture, can work independently, use version control for everything required to reproduce environments declare significant decrease in deployment pain
How to reduce deployment pain?
- Build systems with deployment in mind, systems designed to be deployed easily into multiple environments. Systems that are build to detect and tolerate failures, where various components can be updated independently
- Ensure production system state can be reproduced in an automated fashion from information stored in version control. Ensure no manual changes have to be make to production environment as part of the deployment process. Avoid configuration drift – difference in configuration between environments.
- Ensure deployments are as simple as possible. Avoid deployments that require multiple handoffs between teams.
Information Security
practices should be baked in software development process. It should be easy for developers to “do the right thing”. When info-sec becomes a separate process it will most likely be performed at the end of software delivery cycle when it is expensive and painful to improve security.
Lean Management Practices
Lean management practices improve software delivery performance but only when they are combined together.
- Limit work in progress
- Use visual management (KABAN, Storybooks)
- Acting on feedback from production monitoring tools
- Lightweight change approvals
Lightweight Change Management
Change management improves performance only when performed within the team in form of peer reviews.
- Approvals from external body or change approval boards significantly decrease the lead time, deployment frequency and increase restore time. There was no correlation found between CABs and change fail rate.
- Approvals for high risk changes only were proved to not correlate with performance
- Peer reviews proved to be the only approval mechanism that improves performance as long as done by team members. Peer review satisfies separation of duties often required by auditors and certifications.
- No approvals performed similarly as peer-reviews
Architecture
According to the authors high performance is possible with all kins of systems (web apps, mobile, embedded systems, greenfield projects …) as long as teams are loosely coupled. This means that teams can easily test and deploy individual components or services.
The exception being main frame system, these as well as outsourced software development systems are more likely to be low performers.
(Conway 1968) ” Organizations with design systems are constrained to produce designs which are copies of the communication structures of these organizations”. This means that organizations should model their team structure to achieve the desired architecture.
Without loosely coupled architecture hiring more developers won’t improve velocity.
Loosely coupled architecture characteristics that enable high performance:
- Devs can run tests without integrated environment
- Releases can be done independently from other applications or services they depend on
- Deployments can be done on demand during normal business hours
- Teams can complete work without communicating or coordinating with people from other teams.
- Teams can make large scale changes to the design without permissions from outside of the team and without depending on other teams to change their systems
Tools
Teams should be able to choose tools that are most suitable for their particular needs. However it is a good idea to standardize infrastructure and configuration.
What tools and technologies you use is irrelevant if the people who must use them hate using them or if they don’t achieve the outcomes nor enable behaviors we care about.
Continuous delivery is characterized by set of capabilities that allow making changes to production safely quickly with sustainable pace. When implemented properly it improves delivery performance, quality, culture, reduce burnout and deployment pain.
- Build-in quality – Quality is a part of a culture supported by tools and people where issues can be detected quickly, so they are cheap to detect, resolve and fix.
- Small batches – Allow delivering measurable business outcomes quickly for the small part of target market. Small batches enable fast feedback that allow teams to correct course. They might cause small overhead but save work that delivers zero or negative value.
- Automate repetitive task – People solve problems, computers perform repetitive tasks. Things like regression testing or software deployments should be continuously simplified and automated.
- Relentlessly pursue continuous improvements – Improvements should be part of every day work. Never settle for status quo.
- Everyone is responsible
When implemented correctly, the process of releasing new versions to users should be a routine activity that can be performed on demand any time.
Configuration management – Tests, configuration of environments and software should be part of version control. Any change to environments should be applied by automated processes from version control.
Continuous integration – changes to software should be applied in small batches by means of short-lived branches that represent less than a day of work. Each commit to the master branch should trigger build & test process. Short lived branches reduce need for code freeze while long-lived branches discourage refactoring and intra-team communication.
Continuous testing – Testing should be integral part of software development. Developers should be able to run tests on their machines without external dependencies.
Fully automated tests, configuration and deployment reduces deployment pain and reduces team burnout. Including application and system configuration in version control has especially big impact on delivery performance.
Teams that scored high on continuous delivery also identified more strongly with the organization. They achieved higher delivery performance (lead time, MTTR, deployment frequency), decreased change failure rate and embraced generative, performance driven culture.
Developers accept responsibility for global outcomes such as quality and stability more likely when they are given:
- Tools to detect problems when they occur
- Time and resources to invest in their development
- The authority to fix problems right away
How to measure quality?
There is no single definition of quality – it means different things for different people. However we can measure proxy variables for quality
- How team building the product perceive the quality
- Percentage of time spent on rework on unplanned work
- Percentage of time spent on fixing defects identified by end users
Unplanned work indicates failure to build-in quality in your process and product.
Research shows that high performers spend 21% of their time to unplanned work while low performers need to sacrifice 27% of their time for the same purpose.
Team should strive to do the right thing the first time by improving the quality of the service they provide.
Automated tests should be reliable. Failed test should indicate real defect, while passing test guarantee correct behavior. Unreliable tests should be removed or moved to separate quarantine test suit.
Test should be developed and maintained by development team. Outsourced tests and tests created by QA team do not correlate to development performance.
Developers should have access to adequate data that allows them to run tests on their machine.
Ron Westrum typology of organization culture categorizes organizations based on internal flow of information.
Pathological organizations are power oriented. They are characterized by high amount of fear and threat. People hoard, distort and withhold the information for political reasons.
– responsibilities are shrinked
– failure leads to scapegoating
– novelty is crushed
Bureaucratic organizations are rules oriented. Organization protect departments and people in departments fight to maintain their “turf”. Processes are forced into rigid rules and regulations. Things have to be done “by the book”.
– responsibilities are narrow
– failure leads to justice
– novelty leads to problems
Generative organizations are focused on the mission. Everything is subordinated to good performance.
– risk are shared
– failure leads to inquiry (how to prevent it in the future)
– novelty is implemented and encouraged
In generative organizations people collaborate more, the level of trust is higher, the mission is the priority and the hierarchy is less important.
Information flows easily and makes the organization function efficiently.
High level of trust enable information flow while the availability of the information improves quality of decision-making.
Decisions are easily reversed in they turn out to be wrong. Problems are rapidly resolved thanks to openness and fast feedback.
Internal research at Google that involved 200 teams discovered that in high performing teams “who is on a team matters less than how the team members interact, structure their work and view their contributions”.
The impact of IT performance on organization is huge, it affects organizations ability to achieve and exceed at goals and key objectives. The high performers are twice as likely to exceed in profitability, market share and productivity than low performers. They are also twice as likely to exceed in objectives in quantity of goods and services, operating efficiency, customer satisfaction and quality of products and services.
The impact of software delivery performance is a strong argument against outsourcing the development that is strategic to your business and instead bringing the capability into the core of your organization.
However non-strategic software (office productivity, payroll systems) should be outsourced as e.g. SAAS.
DevOps can be draving change force for you organization. It effects can be visible and measurable also in other outcomes like deployment pain, team burnout and culture (yes, you can measure culture quantitatively)
Culture can be measured and changed, there are well defined scientific models of culture that we can use to evaluate a company.
According to E. Schein organization culture exists on three levels.
Basic assumptions are formed over time as members of a group make sense of relationships, events and activities. This is the least visible level of organization culture.
Values are social norms that shape actions and behaviors of the group and provide contextual rules. These rules can be discussed and debated by the members that are aware of them.
Artifacts are the most visible element of culture. These are written mission statements, technology, formal procedures, heroes and rituals.
Good performance measurement focuses on global outputs. Software delivery performance can be measured with following criteria:
– lead time
– deployment frequency
– time to restore service
– change fail rate
Lead time – The time it takes from receiving a request from a customer to this request being satisfied. Lead time is divided into two phases. First phase – design and validate is a highly variable process where hypothesis drive the design decisions. Second phase – delivery is the time it takes for work to be implemented tested and deployed to production.
Shorter lead times allow for faster feedback loops – thus more frequent course corrections.
Delivery lead time is the time it takes for code committed to the main branch to be running in production or to arrive in the app store.
Full feedback loop looks as following:
customer request > design and validation > software development > commit to main branch > delivery lead time > deployment to production
Delivery lead times fall under categories < 1 hour , < 1 day, 1 day - 1 week, 1 week - 1 month, 1 month - 6 months, > 6 months.
Reduction of batch size is one of foundations of lean paradigm. Since software development doesn’t have material inventory, the batch size is a measured in frequency of deployments. Buy reducing the batch size we can reduce cycle time, variability in flow and accelerate feedback cycle.
System stability is measured as time between failures. It indicates how fast the system can be restored.
Fail rate indicates how often changes to the system (e.g software releases or configuration changes) cause failure, degradation of the service or require remediation.
The studies presented in the book indicated that there is no tradeoff between speed and stability.
High performers maintain or improve the tempo and stability over the years while low performers stay on the same level or decreased both velocity and stability.
According to the studies high performers:
– deploy to production on demand <1h
– have lead time for changes below <1h
– mean time to recover is below <1h
– change failure rate is below 15%
Performance can be improved if each team focuses on their own capabilities.
Improvement should be continuous, never-ending process. What is today considered high performance next year will become a baseline or even low performance.
In order to improve performance, the first thing we need to do is to measure the current performance. This mean we need to know how and what to measure in the first place.
Often what is being measured are vanity metrics. Outputs that are easy to measure but give false results and incentivizes negative behaviors across teams.
Vanity metrics are for usually individual or local outputs:
– lines of code produces by developer. It incentivizes devs to write redundant code.
– velocity – amount of story points completed each sprint. It causes inflation of estimates and negatively impacts cross-team collaboration as each team is focused on their own velocity, often at the expense of other team
– utilization – a proxy for productivity. It can only be increased until certain level where no more spare resources are left. Additionally as utilization goes up as do lead times. “Queue theory in math tells us that as utilization approaches 100% lead times approach infinity”
What we should measure are global outcomes. Busy work that does not actual help achieving organization goals should never be rewarded.
Study shows that high performers in comparison to low performers have:
– 46 times more frequent code deployments
– 440 times faster deployment lead time
– 170 times faster mean time to recover from downtime
– 5 times lower change failure rate
Book authors conducted extensive research and recognized 24 capabilities that drive improvement. These capabilities were grouped into 5 sections:
– Continuous delivery
– Architecture
– Product and process
– Lean management and monitoring
– Cultural
The main thesis of the book tries to prove that software and it’s delivery is the main driver of acceleration in almost every industry, including banks, governments, retail and more.
Book finds valid ways to measure software delivery and development and correlates them with teams performance.
One of the important premises is that speed doesn’t come at the expense of stability. Rather the opposite is true. Teams the deploy more often produce fewer bugs and fix them faster.
Highest performing teams are able to get from commit to the main branch to production deployment in one hour while lowest performer take a month or more.
There is no shortage of great quotes in this book:
“optimize for speed”
“Start with one or two teams instead of boiling the ocean”
Accelerate is a book that I already read once but I want to give it a quick re-read but this time I will be taking notes. It is a very interesting book that shows how ease and frequency of deployments influence company performance and employee satisfaction.