Analyzing a Problem for Real Causes and Coming to a Pragmatic Solution
7 January, 2022
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
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.
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.
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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..
VP - Engineering at ITILITE Technologies
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.
Senior Software Engineering Manager at Anaplan