Are We Expecting Too Much?

…is the big question that Heiðar Eldberg Eiríksson, team leader at APRÓ, raised in a presentation of the same name at the UT-messan.

We sat down with Heiðar to recap the lecture and learn more about DevOps, the increase in burnout within IT, and why solutions should always revolve around people.

„Efficiency is the basic prerequisite in software release processes. However, it often happens that the pursuit of efficiency turns into its opposite - and can even cause burnout among staff,“ says Heiðar, pointing to recent studies[1][2] showing that IT professionals are often under immense pressure, especially following the Covid pandemic.

In his presentation, Heiðar addressed how to respond to this issue. Among the ideas discussed were Richard Seroter's concepts on „Shift Down,„ but Heiðar also introduced his own variation of the same philosophy, which he has named „Shift Out.„ This is an approach that APRÓ's experts have developed and are currently implementing with both great success and satisfaction. But let's start at the beginning.

Where does the pressure come from? And is too much being expected?

„For the past decades, 'agile' has dominated the organization of software projects,“ says Heiðar, adding that „..this methodology is sometimes given other names, such as Scrum or DevOps, but in reality, much of it stems from the same roots.“

According to Heiðar, the main goal is to shift more and more aspects to the left in the software development value chain. This is intended to empower each individual team to handle all aspects of the value chain and remove obstacles in software delivery.

The waterfall flowing

By way of explanation, Heiðar describes the workflow commonly practiced by many IT companies today: 

„Let's imagine a traditional and linear process in software development, often referred to as a waterfall. Let's assume there is a specific problem or unmet need, and based on that, requirements are outlined for what a solution might look like.
Next comes analysis, where the potential solution is evaluated on its merits, e.g., what kind of users would use the solution, whether there is a market for it, and so on. Typically, product management and/or sales teams handle these aspects.

From there, developers take over and design the system, translating requirements into system architecture. Then, programming of the solution begins, followed by testing by QA to verify that the system meets the pre-defined requirements.
Finally, it comes to release and general use - assuming everything went reasonably well. At that point, the system is handed over to system administrators for operation and maintenance.“

Shared goal - different responsibilities

This setup can work, but the reality is often different, as Heiðar points out:
He mentions that product managers and sales teams are generally in a position where they try to speed up execution as much as possible, as the primary goal is to deliver value to the customer in the shortest possible time. 

Heiðar continues, noting that the developers who take over next naturally also want to create value for the customer, but they also need to ensure things are done correctly.
„Care must be taken with system architecture and data structures to avoid running into trouble later down the road.“ 

QA testers do their best to ensure the product is as bug-free as possible, whereas system administrators might think first and foremost about uptime and security:

„Everyone has the same goal, to release good software as efficiently and quickly as possible, but because these are separate teams with separate responsibilities, friction can build up between them,“ says Heiðar.

Heiðar describes the friction that often arises: „In some cases, developers have to hold back product management that wants to move faster, but then they also have to push QA testers who, in a way, are holding back the developers.“ 

He says it is natural that testers want to do a thorough job in an attempt to prevent a critical bug from escaping to the user.

Once the testers have finished, they join forces with developers and product management in wanting to get the release out as soon as possible. At that point, it is the system administrators who stand in the way of release with their change management process, in an attempt to minimize the risks of the release regarding system security and uptime.

Image: UT-messan

The core chronic conflict

„A heavy change management process encourages batching more changes together, which increases the likelihood of release issues, which in turn leads to stricter controls,“ says Heiðar.

He mentions that more changes mean more testing, which extends the test cycle, which in turn encourages developers to make more and more changes concurrently, creating a vicious cycle. 

„In DevOps theory, this tension is called 'The Core Chronic Conflict,' and the inertia that increases between teams when the response to problems that arise is to slow down is called 'The Downward Spiral.'“

Various agile methodologies have emerged to eliminate this friction by shifting the responsibility of tasks as far to the left in the value chain as possible. 

Heiðar explains that the most common practice is to combine developers and testers into one team, thereby shifting the testing responsibility to the left. This results in a single team that designs, writes code, and tests.

It is also common, he says, to use practices like „Continuous Integration“ to increase the feedback loop and enable the team to make more frequent, smaller changes rather than fewer, larger ones.

The bottleneck shifts

However, the bottleneck between the development team and system administrators remains, and that is where the DevOps methodology comes in.
By bringing the responsibility for deployment, operations, and maintenance into the team, developers are incentivized to solve common operational issues with automated solutions and increasingly better feedback loops.

By focusing on the three core principles of DevOps (Flow, Feedback & Continuous Learning and Experimentation), the team is motivated to maximize efficiency in detecting and fixing defects. This reduces waste and rework, increases product quality and security, and improves uptime. Even if a problem arises, the time to detect, respond to, and resolve it is minimized.

„Of course, this is a massive simplification of a comprehensive methodology that is best explored in The DevOps Handbook,“ Heiðar says, while also encouraging readers to study the roots in Lean, Toyota Production Systems, and more.

The benefits of DevOps

The benefits of working according to this methodology are quite clear, with research[3] showing that companies:

• Are quicker to release software, thereby speeding up time-to-market and responding faster to market changes.

• Discover bugs earlier, minimizing negative impacts and lowering costs.

• See increased reliability and automation, which likewise improves efficiency and limits rework and waste.

• Improve product quality because problems are identified and resolved earlier, and ownership is better because responsibility for maintenance does not shift between teams.

The annual State of DevOps Report, created by PuppetLabs and Google's DORA (DevOps Research and Assessment) team, shows similar results year after year, Heiðar says, where „companies working with DevOps methodologies are many times more likely (at least 1.35 to 2 times more likely) to meet their targets, whether those targets relate to:

• Profitability

• Productivity

• Market share 

• Number of customers 

• Sales numbers of products or services

• Operational efficiency 

• Customer satisfaction

• Quality of product or service provided 

• Achieving company/organization goals

  
  

Heiðar states that this applies equally to profit-driven private enterprises as well as non-profit organizations, including educational institutions and public agencies[4].

A careful implementation and correct focus reduce the risk of burnout.

Various other statistics have emerged, Heiðar says, indicating that how this is implemented is of key importance: „How you approach shifting tasks and responsibilities to the left. We must not forget the risks of overreaching in that area, whether it is called Agile, DevOps, or something else.“

Heiðar quotes Richard Seroter, Chief Evangelist at Google, on the subject, who says:

„Certainly, shifting left - the practice of integrating security and quality checks earlier in the development lifecycle - makes perfect sense. But over time, more tasks that have not traditionally been part of a developer's job description have been shifted left in the name of empowering 'full stack' developers.“

Seroter goes on a brief „rant“ to support his point:

“There are about nine actual 'full stack' developers on Earth. Virtually nobody writes frontend in React, deploys Kubernetes, configures RabbitMQ clusters, provisions space on a SAN, and racks a physical switch.
Today, developers are expected to know web frameworks, architectural patterns, testing methodologies, build systems, multiple database types, caching, automation tooling, container orchestration, L4-L7 network concepts, SaaS APIs, monitoring systems, numerous public cloud services, and yes, maybe some AI. I was browsing through Indeed.com, and it's remarkable to see what we are demanding from junior and senior developers.

It's too much.”[5]

Where does the responsibility lie?

According to studies by the Upwork Research Institute[1], it is noted that:

• 71% of full-time employees show symptoms of burnout

• 96% of executives want to leverage AI more, but 47% of employees don't know how to do so

• 77% say AI tools have actually increased their workload

  
  

The Upwork Research Institute's findings thus indicate that the issue lies in the working methodology and its implementation - and so-called top-down performance measurements.

In Heiðar's view, top-down performance and progress monitoring by management run directly counter to the philosophy of Agile and DevOps, which emphasize team autonomy to measure, evaluate, and take responsibility for their own output.

Another interesting study Heiðar refers to is by Tulili, Capiluppi, and Rastogi, titled “Burnout in software engineering:

A systematic mapping study,” which attempts to draw insights from a total of 92 studies on burnout in the global IT sector going back to 1990. It shows that over 80% of IT professionals experienced or currently have symptoms of burnout post-Covid-19.[2]

In their study, Tulili et al. examine how burnout in the IT sector has been researched so far, whether lessons can be drawn from those studies, and if diagnostics can be improved, for instance, with the help of artificial intelligence or machine learning.

„One of the most remarkable things I found in the study was their attempt to synthesize the lessons from all these papers into a kind of causal flowchart of burnout, where we see clear patterns that deserve attention,“ Heiðar says, summarizing a few key points.

„As individuals, we bear responsibility for ourselves. It is possible that the biggest risk factors for burnout are our own personality traits, as burnout is often called the disease of the conscientious. So we need to be aware of and in touch with ourselves.“ 

Heiðar continues and adds that if people experience symptoms of burnout due to stress, he strongly encourages them to seek help.

But managers also bear responsibility, Heiðar says. Work demands and pressure must be realistic, and it has also been shown that communication between managers and their staff is of great importance.

Heiðar notes that it is vital for staff to feel they are getting sufficient and accurate information from management, whether it concerns the job, the company's status, or anything else, so that employees feel they are hearing the truth.“

Additionally, there is the implementation of so-called agility practices, and Heiðar mentions that it is important that roles are clear, saying: 

Burnout is costly

The total cost of burnout is largely unquantifiable, Heiðar says. That is, if around 80% of IT staff feel burnout, one can infer that their productivity has decreased by some X%, but that is incredibly difficult to measure.

However, we can look at the operations of VIRK (Vocational Rehabilitation Fund) as a benchmark. The benefit of its operations is estimated at 19 billion ISK annually, and clients from the IT sector, alongside public administration, financial services, and general office work, rank at the top as VIRK's largest client group.[6]

What is the solution?

Heiðar points back to Seroter, who has proposed an idea he calls „shift down“ as a potential solution to this problem. Seroter explained the solution as follows:

„As an industry, we need to help. First, instead of telling developers (and their managers) to shift everything left, we need to encourage them to shift down by fully leveraging the technology available to them and moving more work down onto the platforms they are already using. Consolidate your tech stack. Don't force people to know so much just to do their job. Offer platform abstractions.”[5]

Here, Seroter is referring, Heiðar explains, to an evolution in DevOps methodology called Platform Engineering. This is about abstracting the complexity of implementation, integration, and operations, making it easier to leverage capabilities within the software development value chain.

This trend of building platform engineering teams has gained traction recently, Heiðar points out. According to Gartner, about 80% of companies plan to have a team dedicated to Platform Engineering by 2026[7], following the example of companies like Google.

And Seroter continues:

„At Google, we offer platforms for coding, testing, building, releasing, deploying, hosting, alerting, and more. Specialized teams from Google support these critical platforms so that our product developers can focus on what they need to do without having to know or operate a 'full stack' of infrastructure. Every organization should do the same.”[5]

While agreeing with the philosophy, Heiðar points out that this is not realistic except for larger companies like Google, saying:

„It is not realistic for a small development team of maybe 4-6 developers to build an entire platform team to support them, let alone multiple teams for different parts of the platform.”

However, Heiðar suggests that specialists and managers in Iceland should not discard the philosophy.

According to Heiðar, the solution lies in utilizing a purchased platform that meets the current needs of the development environment and value chain to achieve success.

APRÓ has recently developed such a platform for the Icelandic market called the APRÓ Accelerator. This allows smaller companies and institutions to access extensive experience and top-tier tools without heavily increasing staff workload or skyrocketing development costs.

The APRÓ Accelerator

„The APRÓ Accelerator is developed in collaboration with Icelandic companies and institutions, and is largely about gathering and formalizing what we know has worked well over the years,“ Heiðar says, also pointing out that massive economies of scale can be gained by participating - across companies and institutions. 

The accelerator offers the possibility to utilize and jointly develop a platform tailored to the needs of Icelandic enterprises and public bodies, instead of everyone working in their own silos to solve basically the same core problems.

Heiðar says that the Apró accelerator is a way for companies to outsource complexity and a large portion of the workload to a partner whose core business is solving these issues.

„Meanwhile, our clients' development teams can focus on creating value for their business without compromising on development speed, monitoring, uptime, security, or anything else. That is our core business.“

Heiðar also points out that they at APRÓ see an increasing need in the corporate environment to utilize AI securely, but at the same time, we see that this introduces extra pressure and complexity for development teams. This is where the idea of the Data and AI Accelerator originated.

„With APRÓ's approach, companies can securely leverage the possibilities of generative AI and modern data infrastructures without compromising on security.“

He explains that the AI models are run in a closed environment in a cost-effective manner, „which allows our clients to enrich the AI, even with their most sensitive data, while resting secure in the knowledge that nothing is passing through the systems of foreign tech giants.“

APRÓ AI utilizes AWS Bedrock services with an architecture where the infrastructure is separated from other APRÓ or AWS clients, and with encryption that meets the strictest security and quality standards.

More want to become part of the solution

Modern IT demands modern solutions and practices that foster job satisfaction and well-being as well as increased efficiency and economy - something that must not be compromised, Heiðar says. 

„Our methods are constantly evolving, but DevOps and Shift Out have worked incredibly well for us at APRÓ, and we believe in this solution.“ 

He adds that the more companies and institutions join the APRÓ accelerator, the better the solution becomes - making the platform sustainable in the sense that it grows stronger with increased participation.

All this leads to both better methods and, not least, improved well-being for those involved in the projects, with Heiðar adding final words:

„Our solutions will never be better than the people doing the work, and the key is to find a path that maximizes both aspects“ 

Want to know more about the APRÓ Accelerator? Click here

References and further reading

[1] Monahan, Kelly, and Gabby Burlacu. “From Burnout to Balance: AI-Enhanced Work Models for the Future.” Upwork, July 23, 2024. https://www.upwork.com/research/ai-enhanced-work-models.  

[2] Tien Rahayu Tulili, et al., “Burnout in software engineering: A systematic mapping study”, Information and Software Technology, Vol. 155, (2023)

[3] Rubén Grande et al., “Is it worth adopting DevOps practices in Global Software Engineering? Possible challenges and benefits.”  Computer Standards & Interfaces, Vol. 87 (2024),

[4] Dr. Nicole Forsgren, Jez Humble, Gene Kim, Nigel Kersten, et al. ”State of DevOps Report” 2013-2024 PuppetLabs, DORA,

[5] Seroter, Richard. “Richard Seroter on Shifting down vs. Shifting Left | Google Cloud Blog.” Google, June 8, 2023.

[6] Stefánsdóttir, Berglind, and Guðrún Rakel Eiríksdóttir. “Kulnun í Starfi.” VIRK Starfsendurhæfingarsjóður, May 23, 2022.  

[7] David Sandilands, Margarret Lee. ”2024 State of DevOps Report: The Evolution of Platform Engineering, Puppet by Perforce,