Elephants and Developer Enablement
There is an ancient parable out of India about an elephant. It is a story of blind men that, never having come across an elephant, seek one to find out what it is like. Elephants are rather large though, so the blind men spread out to touch the elephant and share their thoughts.
Perhaps unsurprisingly, they each share a different perspective. One touches a tusk and thinks an elephant is like a spear. Another touches the trunk and thinks it is like a snake. And so on and so on. All six blind men report a completely different experience.
A non-blind observer off to the side can clearly see it is an elephant. The blind men however, going only by what they feel, insist their perceptions are the correct. Sometimes this parable is shared to describe how different religious traditions experience God, and the analogy has even been extended into the realms of quantum physics and biology.
Because each person’s experience is limited to just one part of the elephant, there is no consensus on what an elephant is like. They are encountering observer bias, leading to wildly different results. Perhaps German physicist, Werner Heisenberg, had it right when he said:
“We have to remember that what we observe is not nature in itself, but nature exposed to our method of questioning.”
In a similar way, our perception of how software development is done is colored by our experiences and where we are observing from. The developer wraps her head around the tools. The engineering manager wrangles with the processes. The CTO wrestles with organizational obstacles. They all touch software delivery, but they all feel the value chain differently.
You often hear the term developer experience to explain how developers do their work. In practice, developer experience describes the tools they use in doing work. Providers of developer tools have latched onto the term as a way describe how they deliver value to their customers through ease of use, documentation, support mechanisms, and advocacy
This is the outside-in perspective of the work developers do. It is driven by vendors or open source communities or content providers to help developers when coding. As we know from experience though, only a portion of the day is spent inside IDE’s and repositories and other tools. By some estimates, up to 68% of the day is spent in non-coding work.
Where are developers spending the bulk of their working day then? They are stuck in the Waiting Place. That is the series of delays and approvals and processes and searching just to get actual work completed. And the larger and more complex the organization, the more time developers spend in the purgatory of no progress.
We need another term then to describe this inside the organization view. Developer enablement is that insider, organizational perspective of giving developers the tools, processes, culture, and environment to be optimally productive. It is the entire accounting of tasks and engagement with the work of a developer in their professional assignment.
The reason developer enablement is important is that the components of enablement are key to understanding and unlocking productivity. But to what end? What does productivity even mean when it comes to work that is both creative and iterative? The best way to think about developer productivity is:
What percentage amount of time does a developer experience flow?
Flow is complete and dedicated focus on a task. It is like watching a top professional tennis player or a Grandmaster chess player or a concert cellist at the height of their career. They appear effortless in how they work to achieve outsized results. We also experience these brief moments in our work, school, or play when everything seems easy and just works.
Developer flow looks just as magical from the outsider perspective. You see this in fast clickety-clack of keys as lines of code stream across a screen. It almost feels as if developers can feel the code as they weave together complex algorithms and services that just work without bugs.
In the broader context of work, developer flow also affects things outside but related to code. It is state of joy when an employee feels most productive. When an entire team is hitting their flow stride, you observe better software delivery outcomes like higher quality code, fewer bugs, faster and more frequent releases. There are also side effects in that the team collaborates and shares more because they are all connected with their work and the goals of their work.
The next logical question then is how to foster flow state on engineering teams? If developer enablement is that mechanism, then what levers are available to unlock flow? Let’s look at several of the more critical components of developer enablement:
- Tool Choice — The technologies developers use do have an impact on productivity because it is hard to get work done if the tools are burdensome. More important though is giving developers the choice in what tools they use. This improves morale, and can use tools that best suit the work at hand and the skills on the team.
- Collaborative Co-creation — Beyond giving developers choice in tools, how are developers encouraged to participate in the product and feature creation process? Rather than getting a set of requirements thrown over a wall, developers should be invited to shape the design and understand the outcomes, in that way they can come up with better solutions and feel more ownership of the results.
- Supportive Learning– Though projects and tasks will always be a priority, what investments are being made to allow developers to expand their skills? Whether this is provided through dedicated innovation time or structured learning, this helps the team stay current on the latest technologies and capabilities while also giving developers time to stay relevant in their skills.
- Culture of Experiments — Is work merely tasks to get done or positioned as ways to learn faster and iterate? The best engineering teams frame their work as a series of continuous experiments and fast feedback. When an experience does not deliver the expected results, they have a no blame culture focused on helping the team improve rather than singling out individuals for shame.
- Lightweight Processes — Much of our day is filled with many small but time consuming roadblocks. Organizations need to expose and eliminate this invisible work so as to remove the things that needlessly take time. This means every work process should be free of dependencies, lightweight, incorporate fast feedback and response loops to enable further process optimization.
- Common Lexicon — While some things like tools choices should be flexible, there also needs to be a common methodology and internal language to enhance understanding and stamp out miscommunication. This does not mean implementing scrum or lean or an agile framework. Rather the focus is on actually being agile as a team and have ways of communicating that accelerate work.
- DevOps Automation — With the increasing complexity and volume of code, larger and more distributed teams, greater abstraction, and more service interdependencies and orchestration, DevOps is essential. This means full CI/CD automation (continuous integration testing and deployment) and building as much in code as possible including policies, security, risk analyses, and infrastructure. This eliminates failure points and reduces much of the tedious work that dragged out delivery and release cycles.
- Knowledge Architecture — A significant gap that leads to invisible work is the lack of any dependable source for documentation or information in the organization. Some of this can be found from outside source, but there is a vast amount of internal and proprietary knowledge that never gets captured. Finding mechanisms to capture, validate, categorize, and disseminate knowledge provides enormous value to developers and gives back a significant amount of their time.
- Communities of Practice — One aspect of supporting learning and building knowledge in an organization is through teams that can build, develop, and share knowledge and expertise with other teams. These are loose affiliations rather than formal teams, but work cross-organizationally to offer guidance and help in some aspect of technology. They also support the members in their community to further their learning and elevate their contributions across the organization.
- Engineering Effectiveness — These are aspects of engineering process that if realigned would unleash significant improvements in the effectiveness of engineering work. This means incorporating of observability to deliver real-time feedback to developers on code releases, use test driven development (TDD) to instill a testing and quality mindset, building loosely coupled architectures to avoid dependencies, and being rigorous in the use of version control & management for code & infrastructure.
These are options that may be available based on your situation that can have a direct impact on software delivery performance. In fact, the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim looked the question of developer productivity. What the book outlines are the results of research into software delivery performance that confirms that best in class teams implement most of the ideas under the banner of developer enablement.
So what are you doing to enable how developers work in a way that creates the best possible outcomes that encompasses value for customers, the team, the organization, and developers?
Episode #13 — Creating a transformative engineering culture with Josef Langerman
New episode of the Heretechs podcast is here! Co-hosts Justin Arbuckle and Mark Birch welcome guest Josef Langerman, Head of Engineering and Transformation, Standard Bank, to discuss creating a transformative engineering culture by demonstrating what’s possible.
Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!