How Organizations Can Add New Tech and Avoid Developer Burnout
Internal platforms as a means to maximize flow
Any new technology adoption impacts cognitive load of development teams. Cognitive load could be explained as the amount of mental energy required to perform a task. Too much of cognitive load can create overload for developers. It then causes slower flow of change and delivery bottlenecks. It can also increase likelihood of human errors, add frustration and stress or worse -induce burnout.
How do new technologies come to lives of developers an how does it impact their cognitive load? And what can we do practically to better manage unwanted effects of new technology to developer teams?
In this post I am going to look at the example of Kubernetes adoption in a typical team. I will discuss the mental overload teams face and how such overload could be addressed in organizations.
Costs of adding new technology
New technologies often benefit one or more IT teams and puts more complexity for the other team without visible benefit for the latter. Let’s take Kubernetes as an example. Kubernetes is a container orchestration framework. It puts container deployment, operating and scaling to another level for Operations teams. Without such a container orchestrator Operations teams would need to use custom automation, deployment, networking and cluster management scripts.
Kubernetes is a new(-ish) technology which targets many types of users. Cluster admins, infrastructure teams and advanced users use command line tools and scripts to manage infrastructure and applications using it.
Kubernetes is not developer-friendly. As it aims to be everything for everyone, it has lot of complexity which is not encapsulated well enough.
So what do developers get from using Kubernetes? Sure, deployments are more reliable and more automated. But this brings more benefits to Ops teams, right? And at what cost? Developers need to wrap their minds around pods, replicas, nodes, health checks, helm charts, command-line deployment tools and more.
Why should developers care about deployments at first place? Why should they care how applications behave in production? But these are “simple” questions which contradict “DevOps culture” and should not be asked openly.
Focus on value delivered
Now let’s explore the idea of “developers create value to users by adding/changing application code”. Not every code is valuable. Not every feature brings value to users. There is a big topic of outputs vs outcomes (e.g. features delivered vs. user value added) which I won’t touch here.
Relevant part from that big topic is a notion of feedback loops (especially user feedback). We cannot really always know if a feature or even a finished product will be valuable upfront. Marty Cagan calls it as one of two inconvenient truths of product management. According to him, at least half of our ideas about new products or features aren’t going to work. In Scrum methodology, this is popularized by the 80:20 rule.
Therefore developers need to receive feedback which confirms that the value they created has reached the users. Value delivery can fail at many levels. From an application crashing to users not knowing how to use a released feature. Thus if developers care that their work brings value to a user, they need constant value delivery feedback.
Such feedback may take many forms. Feedback that an application got deployed correctly, that it is running as expected, that users use that feature as intended, etc.
Again, I presume here that developers care about providing the value to the end user. To get feedback and avoid hiccups during value delivery process developers rely on help of operations teams. And operations teams need tooling to control deployment variability, automate manual configurations, or decrease times for failure recovery. They need something like…Kubernetes.
Here I reason that introduction of such a system like Kubernetes help developers to reach their goals. And, as I mentioned above, introduction of such system has cognitive load costs to the developers
But can we actually keep the positive part and decrease negative? Can we somehow manage that mental overload of developers?
Extraneous cognitive load
Skelton and Pais talk about three kinds of cognitive load in their book “Team Topologies” :
- Intrinsic (skills)
- Extraneous (mechanics)
- Germane (business value)
We are interested here in extraneous cognitive load as Kubernetes usage increases it. Extraneous cognitive load relates to the environment in which the task is being done (e.g. “How do I deploy this component, again?” “How do I configure this service?”). Skelton and Pais suggest organizations to attempt to minimize unnecessary extraneous cognitive load. By decreasing it, there is more space left for germane cognitive load (where “value add” thinking is).
Digital platforms to the rescue
Digital platforms is one popular way how companies introduce such new technologies as Kubernetes and at the same time keep cognitive teams of engineers at sustainable level.
According to Evan Bottcher, technical leader at ThoughtWorks, a digital platform could be described as
“A foundation of self-service APIs, tools, services, knowledge and support, all arranged as a compelling internal product”.
Digital platform aims to expose suitable level of abstractions of underlying tools and systems (e.g. Kubernetes) to a level of understanding suitable for developers of the organization. Needs of engineering teams vary in every organization and therefore such digital platforms should be tailored to those needs.
A dedicated platform team is a common way of building and managing digital platform. Product management principles should guide building it. The platform could consist of tools, automation scripts, documentation and tech support. By focusing on needs of engineers the platform team enables them to profit from technology and not to get overloaded by it.
Not having such internal platform leads to inconsistencies in the use of external services. It also leads to unreasonable demands on product teams that are already being pulled in many directions while ironically being pressured to deliver more feature faster, since they now have Kubernetes.
Thinnest viable platform
Digital platform size depends on the needs. It doesn’t have to be massive. Skelton and Pais recommend to always aim at “thinnest viable platform” to avoid the platform growth becoming an end-goal for platform team. According to Allan Kelly “Software developers love building platforms and, without strong product management input, will create bigger platform than needed”. Therefore the platform team should keep the focus on their user’s needs — the developers, and ensure the platform is built to serve those and elevate their value flow. The growth of a digital platform should be tied to the growth of technical needs the organization.
To conclude, by reducing cognitive load of developers, they are empowered to do what they do best — build and adapt features to bring value to their users. And a suitable internal platform helps to focus them on increasing delivery flow and be more effective. The key idea here is that such platform should be built for developers, their needs being primary driver of platform functionality and usage experience.
