Over the past year, I’ve been privileged to work with our incredible founders and the Product and Engineering teams at Afriex. It’s been super challenging, but also one of the most fun experiences I’ve had since playing professional basketball in Europe. Our Afriex product involves many complex pieces; ranging from mobile apps (iOS and Android), an administration panel (an internal web application to assist Customer Care teams), APIs to power these experiences, and integrations with funding partners that allow us to move money across currencies and geographies.

Our business requires us to move quickly. However, in order to earn and keep customer trust, we have to continuously improve our software delivery performance. On a flight from Ethiopia to San Francisco, I decided to read a book called Accelerate: Building and Scaling High-Performing Technology Organizations. The insights from the book left a powerful impression on me and changed how I now view software delivery performance at Afriex. At a high level, we can simply measure software delivery performance in these four ways:

• ‍Frequency of delight: How often are we able to deliver new experiences of value to our users?
• Speed of delivery: How fast are we able to deliver new experiences of value to our users?
• Reliability of service: How infrequent is our service unavailable to our users?
• Quality of service: How infrequently do new changes that we make cause issues for our users?

Deployment pain

As a young startup, we experience a fair amount of what I call "deployment pain." This exploration was a fantastic opportunity to improve software delivery performance, organizational performance, and our culture.

If you ever want to know how painful your deployments are, then as our team what specific things cause that pain. Things might stand out, such as whether deployments have to be performed outside normal business hours or off-peak times, which could be a sign of architectural problems that need to be addressed. Previously, I worked at Slack (now acquired by SalesForce), and we invested heavily in large-scale systems, which allowed for fully automated deployments with zero downtime. Deployment didn’t feel like something to dread. Many small startups have deployment problems caused by a complex and brittle process.

Software at these companies expects its environments and dependencies to be set up in a very particular way and does not tolerate any kind of deviation from these expectations. In order to reduce deployment pain, we need to:

• Build systems that are designed to be deployed easily into various environments, detect failures, and have many components of the system updated independently.
• Ensure that production-like environments can be quickly reproduced in an automated way from the information in our version control tool.
• Build intelligence into the application and our platform so that the deployment process can be as simple as possible.

Without these things, we experience significant deployment pain, and the consequences of this can lead to burnout or fatigue. And we love our team too much for that to happen 🙂.

Burnout

Burnout is the physical, mental, or emotional exhaustion caused by overwork or stress. Burnout can make the things we once loved about our lives seem insignificant and dull. Research shows that stressful jobs can be as bad for physical health as secondhand smoke (Goh, Pfeffer, and Zenion 2017) and obesity (Van Der Valk, Savas, and Rossum 2017). Job stress also affects employers, costing the US economy over $300 billion per year in sick time, long-term disability, and excessive job turnover (American Institute of Stress). Thus, besides being the right thing to do, it also makes economic sense for Afriex to have a duty of care for our team members and a fiduciary obligation to ensure staff do not become burned out. Research also shows that burnout and fatigue can be prevented or reversed, and DevOps can help out with that. Managers like myself might be tempted to address specific individuals struggling with burnout while ignoring the work environment that got everyone there. However, long-term success would mean focusing on changing the environment, thus concentrating our efforts on the following areas:

• Fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming.
• Communicating a strong sense of purpose.
• Investing in employee development.
• Asking employees what is preventing them from achieving their objectives and then fixing those things.
• Giving employees time, space, and resources to experiment and learn.
• Employees must be given the autonomy to make decisions that affect their work, particularly in areas where they are responsible for the outcomes.

Solutions to combat burnout

According to Accelerate, focusing on these five areas can dramatically reduce burnout and fatigue on your engineering team.

• ‍Organizational culture: Pathological, power-oriented cultures produce strong feelings of burnout. Although it seems obvious, managers are responsible for creating a supportive and respectful work environment that allows people to learn from their mistakes without blame but not without consequences. We need a little skin in the game 🙂.
• Deployment pain: Complex and painful deployments that must be performed at irregular times contribute to high stress and a lack of control. With the right processes in place, deployments don’t have to be stressful events because of adequate testing and automation.
• Effectiveness of leadership: Responsibilities of the team leader might include limiting work in the process and eliminating roadblocks for the team to get their work done. Reducing the amount of unplanned work decreases the variability that can lead to stressful situations.
• Organizational investment in DevOps: Organizations that invest in automating manual tasks for engineers demonstrate the value placed on employees’ time.
• Organizational performance: Lean management and continuous delivery practices help improve software delivery performance, which improves organizational performance. This includes giving employees the time and resources to experiment and improve their own work. This should not be on their own time but during the work week. Some of the most innovative ideas can originate from a hackathon or a “think day.”

If you’re interested in learning more about how to reduce deployment fatigue as well as how to improve software development performance, I would highly recommend checking out the book Accelerate - Building and Scaling High Performing Technology Organizations.