Enablers of Developer Flow
Stop outsourcing the keys to greater engineering productivity
I often struggle with procrastination. Things are better now, but there are plenty of times when I still find myself absentmindedly doing things other than the work I am supposed to be doing. It reminds me of the classic Joel on Software post “Fire and Motion” and bouts of unproductivity.
In my younger days, I was notorious for waiting till the last minute to get something done. One memorable example was the time in ninth grade when we had a semester-long character study where the final project was an original short story. I came up with the character, filled in the backstory, and wrote the 12-page story from 2 AM till 8 AM when our literature class started.
This was my operating model for everything from tests to papers to my electrical engineering senior year project. I did this because I could get away with it, up until I started working in the real world. In my first real project, the initial demo of the software app I wrote for the sales team was an unmitigated disaster. The head of sales mercifully cut the demo short, but my boss was livid and nearly fired me that afternoon.
What I learned about myself is that while some of the things I procrastinated on were mundane or boring, the reason I had issues getting started was because I could never get into a flow. In college, it was usually roommates, dorm distractions, or parties. In my role as a developer, the issue was I simply didn’t know anything and had to learn on the fly.
I was fortunate enough to work at a pretty small company. In the absence of Stack Overflow or GitHub, I had ended up reading lots of docs and figuring things out from scratch. However, I could usually find someone to help with some code snippets, debug an issue, or answer my noob questions.
When I worked at bigger companies, the blockers for getting into my flow were different. I had more experience, but now the issues had to do more with the working environment. My days were filled with meetings. We would be stymied by dependencies on other teams. Important information would be hidden or lost. All of this cascaded into massive delays on deliverables.
I just chalked this up to big company bureaucracy and ineffective middle managers. After I left to pursue the startup life, I paid little thought to the matter. Little did I know that there were other places just as big and with layers of management that still managed to operate like smaller, nimble companies.
My time at Stack Overflow was informative as I got thrust into the world of developer productivity and culture. As we introduced the Stack Overflow Teams product into companies to help them with internal knowledge management, I started to see things beyond our product that played a large part in the successful adoption of an internal Stack Overflow.
Nearly everyone I spoke with was highly enthusiastic about bringing in Stack Overflow. This was mostly based on the brand and how familiar developers were with the world’s most popular Q&A site for developers. Yet some customers would fail to gain adoption. The tool was not the issue, it was all the things outside the tool that made using the tool challenging.
This was when I started formulating this concept that true developer productivity does not lie in the tools or measuring lines of code produced. It is all the things that enable code to happen that have the biggest impact on developer flow. This was when I coined the term developer enablement.
How does an engineering organization start to address developer enablement though? I started to unveil the different elements of enablement when I highlighted the activities that make up the bulk of “glue work” on engineering teams and how that differs from the work of DevOps and that of developer tooling vendors to support their products.
Based on working with many engineering organizations over the past several years, I observed that the key activities within the realm of enablement can be categorized into six domains:
Talent Development - how we onboard, develop, and nurture talent
Collaborative Teaming - how we communicate and work together
Knowledge Management - how we capture and leverage internal knowledge
Capacity Planning - how we estimate, assign, and measure work
Enablement Health - how we measure efficiency and productivity of teams
Culture Leading - how we align to common values and organizational vision
As an engineering leader, one could argue that some of these domains are already accounted for. HR typically owns talent development programs. Knowledge management and collaboration are usually relegated to tooling decisions managed by a platform or DevOps team. Capacity planning is mostly the realm of product management or agile teams. Analytics, metrics, and the softer elements of culture are what managers oversee.
This however would be missing the point. There is no single-threaded owner that explores each of these domains to understand how to implement changes that could improve developer flow and elevate team performance from an engineering perspective. As a result, engineering leaders are stuck with HR’s generic practices, solving collaboration & knowledge issues with more tools, and guessing what impacts delivery times and team productivity.
You cannot implement developer enablement if you are parsing out and outsourcing the work to others. Would you outsource the core IP of your software to outside firms? Of course not, and the same applies to the levers and functions that impact developer flow. When engineering leaders hand over the responsibility of enablement to other teams, they are handing over the only controls they have available to boost team productivity.
Developer enablement is a new team in the engineering organization. Some companies are already experimenting with a single role to focus on enablement. The future however is that high performance teams will have owners for each of the domains of developer enablement.
Over the coming months, I will dive into each of these topics. In full transparency, I am also in the process of learning and discovering the capabilities in this nascent field. This is also why I am in talks to participate in the first ever industry consortium to help define what developer enablement is and how organizations should implement aspects of enablement within their own engineering teams.
What are major organizational blockers to developer flow in your company? How are you addressing those blockers to help developers and team be more productive?
Mark Birch, Editor & Founder of DEVBIZOPS
Head up that next week I am in NYC for the AWS Summit (you can still sign up for free to attend). I head over to Pittsburgh on Wed, July 13 , then land in Chicago from July 14 to 15 for a tech bunch for underrepresented founders and then other Chicago tech week events. Let me know if you are in any of those places, would be great to meet!
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!