Analyzing a Problem for Real Causes and Coming to a Pragmatic Solution

Slower Velocity and Low Productivity

I’ve been in my current role for a little over two years. In this role, I realized that the managers that reported to me were constantly worried about the overall velocity of our teams. They were anxious that our speed was lower than expected, so we brainstormed many ideas. We were trying to increase our capacity or potentially deprioritize multiple items. Instead of jumping into solutions, my team tried to delve deeper into the problem & learn what was causing this problem, in the first place.

Analyzing the Problem and Creating a Solution

Delving Deeper:

My team began by sending out a simple survey to the developers on our teams. We were looking to figure out how much of their time was going into completing business projects, infrastructure work, meetings, and other activities. As expected, the surveys said that no more than 30% of their time was spent on business projects. By gathering the data and analyzing our problem fully, my team learned the root causes of our pain. Without understanding the core of our problems, we may not have focussed on the right problem to solve, leading to undesired results.

Context Switching:

We learned that context switching was one of our main problems. Individuals could never work on a single project or task for more than two hours without going into a meeting or getting pulled into another task. The environment was not prioritization-driven, and our teams found it challenging to decide the highest priority item to focus on.

Duplication:

We learned that many of my teams were working on similar shared modules without knowing how many others were working on the same type of problem, leading to huge duplication. Multiple teams were duplicating a shared solution because our group lacked alignment, documentation, and communication. This problem is so rampant in larger organizations when many teams are working on similar types of projects.

Improving the Developer Experience:

My managers and I tried to ensure that developers had the proper resources & least possible hurdles to work with efficiently. Instead of demanding our teams be more productive, we worked to improve the environment & clear as many repeat hurdles and red tape away from the developers, so they could work in the zone. After increasing the developer experience for around a year, we began to see some initial results.

Initially, we tried to improve the developer experience on many fronts from designs, test automation to NFRs. We were being very ambitious in our developer experience project when only one of these tracks was only getting the needed traction. In hindsight, It would have been better to only push one or two more impactful tracks than multiple tracks.

Learnings from Solving the developer productivity Problem

• It is vital not to react to the symptoms of a problem but always to try and understand the root cause of the symptoms. If you want to make your bus run faster on a highway, there are many ways to do it. You can increase the engine speed or reduce the friction by paving better roads or getting better tires.
• When solving a problem, it is essential to take the emotion out of ideas to make an impartial decision. Try and measure the problem objectively before starting to solutionize.