CTO Fraction

Menu
An image with the text "the issue is not the issue" representing the need for a fractional CTO to do root-cause analysis.

Digging Beneath the Surface as a Fractional CTO

As a Fractional CTO, I recently engaged in a conversation with one of my clients to assist a software engineering manager in resolving a process-related problem. Understanding root cause analysis is important for effective technical leadership. 

 

Fractional CTO: Digging Below the Surface

Before sharing the details of our discussion, it is important to understand the context surrounding the issue.

  • Team Composition: A four-person team consisting of one manager and three software engineers (two front-end and one back-end).
  • Work In Progress: Typically, the team manages 3-4 features simultaneously.
  • Problem: A feature initiated months ago has been paused to prioritize other, more critical features. From the perspective of the Product team and stakeholders, this feature appears to be progressing very slowly due to its prolonged status. However, the engineering team has not been actively working on it. The engineering manager sought my assistance in managing the feature timeline in Jira Product Discovery to accurately reflect the team’s activities.

Client and Fractional CTO Conversation

Our conversation went along something like this:

Manager:
How should we handle this type of feature, which we have placed on hold for the time being and will finish later, so that it is obvious we are not currently working on it? Should we split it into two smaller features?

Me:
Splitting it into two parts is one approach. This way, the completed portion will be visible, and the unfinished part can be moved further along the timeline. However, you currently have four features in progress with only three engineers. Have you considered reducing the number of active features? What if your team focused on only one feature at a time?

Manager:
We can’t do that because our work is very unbalanced.

Me:
How is it unbalanced? What do you mean?

Manager:
About 25% of the work is front-end, and the remaining is back-end. With two front-end engineers and one back-end engineer, the front-end tasks are completed quickly, allowing FE engineers to start on additional features while the BE engineer continues with the initial feature. This leads to the FE engineers working on a third feature, and so on.

Me:
Is it often that your features consist of roughly 25% front-end work and the rest back-end?

Manager:
Yes, that’s the typical distribution.

Me:
So the issue is not that you have imbalanced work, the issue is that you have an imbalanced team, no?

Manager:
Yes.

Me:
What if the front-end engineers learned some Python and back-end development skills, allowing the entire team to collaborate on one feature at a time?

The manager agreed that this was a good solution. I further elaborated on the advantages of having front-end engineers acquire back-end skills, highlighting the benefits of collaborative focus. This topic deserves its own discussion, which I will probably address separately in a future article. But for now, let us look at some quick points.

Need a Fractional CTO to do root cause analysis in your org?

Are the processes broken in your tech org? Are they non-existent? Are you wondering why your teams are not delivering much value?

Hire a Fractional CTO to help you understand the inefficiencies in your R&D teams.

Schedule a Call

Benefits of a Balanced Team

Implementing strategies from a Fractional CTO can lead to a balanced engineering team, enhancing team collaboration and reducing context switching. Some benefits include:

  • Balanced Team: Equal distribution of skills prevents bottlenecks.
  • Collaborative Effort: The team works together on the same feature, instead of running in different directions.
  • Reduced Context Switching: Focusing on fewer tasks minimizes distractions.
  • Simplified Communication: Stakeholders have a better understanding of feature timelines.
  • Engaged Engineers: Opportunities for skill development increase job satisfaction.
  • Faster Delivery: Shorter cycle times lead to quicker feature releases.

Additionally, I suggested that front-end engineers could contribute to documentation, testing, and other tasks to ensure the team progresses collectively from one feature to the next.

 

Fractional CTO: Lessons Learned

I could have easily stopped at giving recommendations to this manager on how to handle the situation at the Jira Product Discovery board level. However, that would have treated the symptom and not the real issue.

Fractional CTOs, and any leaders for that matter, have a responsibility to see through the surface and sniff out the real issue. Those of us who have an engineering background naturally want to jump to solutions whenever a problem is presented to us. However, it is important to take the time and investigate. Dig a little deeper. Understand whether the situation is the root cause or a symptom of something else beneath the surface.

A fractional CTO must be good not only with providing solutions, but also with investigating. It is the whole idea of diagnosing before prescribing. Healthcare professionals do this all the time. Have you ever called a doctor’s office and tried to get them to give you even a rough diagnosis over the phone? They are very reluctant to do that. They want to see you in person and take an examination, take x-rays, or run other exams before sharing what they think the problem is.

CTOs and technical leaders need to take a similar approach. We must be able to observe, make connections, dive deep, and also zoom out to see the big picture. We need to quickly detect when we are being taken into a rabbit hole, which may look like the problem but is actually not. We need to be curious and ask lots of questions, having the ability to put a puzzle together and building a picture of what is actually going on. 

Many times we can be fooled, because the person we are trying to help is painting the picture for us. But we need to detect when that picture corresponds to reality and when it does not. We also need to detect when it represents only partial reality.

Taking this critical thinking approach will make us better advisors, and better leaders, as we will be focused on solving the real issues, instead of the ones masking them.

 

The 5 Whys Technique

The 5 Whys is one framework that could help Fractional CTOs and leaders to diagnose better, before prescribing. It is a problem-solving technique designed to identify the root cause of an issue by repeatedly asking the question “why?”—typically five times. This iterative process helps delve beyond surface-level symptoms to uncover the underlying cause of a problem.

Origin and Purpose:
Developed by Sakichi Toyoda and integrated into the Toyota Production System, the 5 Whys aims to enhance efficiency and quality by systematically addressing the fundamental causes of problems.

How It Works:

  1. State the Problem: Clearly define the issue.
  2. Ask “Why?”: Determine why the problem occurred.
  3. Analyze the Answer: Use the response to form the next “why” question.
  4. Repeat: Continue this process, typically five times, to identify the root cause.
  5. Develop a Solution: Address the root cause to prevent recurrence.

Example:

  • Problem: A machine stopped working.
    • Why? It overheated.
    • Why? The cooling system failed.
    • Why? It wasn’t maintained properly.
    • Why? There was no maintenance schedule.
    • Why? Maintenance procedures were not standardized.

By identifying the lack of standardized maintenance procedures as the root cause, appropriate measures can be implemented to prevent future machine failures.

Benefits:

  • Simplicity: Easy to implement and understand.
  • Effectiveness: Uncovers true causes, leading to better solutions.
  • Prevention: Addressing root causes reduces the likelihood of issues recurring.

Limitations:

  • Depth: The technique may not be sufficient for complex problems requiring more detailed analysis.
  • Subjectivity: The quality of the outcome depends on the knowledge and perspective of those involved.

 

Conclusion:
The 5 Whys framework is a valuable tool for Fractional CTOs and leaders for root cause analysis, promoting a deeper understanding of problems and facilitating the development of long-term solutions. By utilizing such techniques, we ensure that we address the real issues, and create more effective and sustainable outcomes for our teams and organizations.