AgileX Solutions, a leading Software as a Service (SaaS) company, is celebrated for its adoption of agile methodologies. However, the company encounters a significant challenge when its non-technical Chief Executive Officer (CEO) mandates the use of quantitative metrics to gauge the engineering team’s performance.
This requirement starkly contrasts with the perspective of the Head of Engineering (HoE), who advocates for a more nuanced, holistic evaluation approach.
The CEO’s insistence on employing analytical tools such as Jellyfish to monitor various metrics—including velocity, burn-down charts, lines of code and commit frequency—sets the stage for a critical exploration of the drawbacks associated with over-reliance on superficial or “vanity” metrics.
This case study delves into the imperative of integrating quantitative data with qualitative insights to foster a balanced assessment framework.
Key thing to understand is that with this kind of request, the CEO isn’t actually wanting insight into each individual’s or team’s performance to optimize or clean house, rather it’s an indicator that he doesn’t fully trust YOU
Ken K.
Key Issues at a Glance
Vanity Metrics vs. Value Delivery: The challenge lies in quantifying what truly constitutes a meaningful contribution.
Leadership Misalignment: A noticeable rift between the CEO’s quantitative demands and the HoE’s qualitative vision raises concerns.
Team Morale: The implementation of quantitative tracking mechanisms potentially jeopardises the engineering team’s spirit.
Protecting Team Integrity: The HoE faces the daunting task of safeguarding the team against practices that could be detrimental to their cohesion and productivity.
Engagement Questions
Balancing Metrics: In the quest for a balanced assessment approach, how would you reconcile the need for quantitative metrics with the intrinsic value of qualitative insights?
Leadership Alignment: What strategies could facilitate the alignment of non-technical leadership with the tangible realities of engineering work?
Team Morale: Facing the introduction of potentially intrusive metrics, what measures can be taken to preserve team morale and culture?
Holistic Measurement: Propose a metric or practice that effectively encapsulates the genuine value delivered by the engineering team.
Further Engagement
An invitation to participate in a “Metrics vs. Morale” virtual roundtable, aimed at debating the relative merits of quantitative versus qualitative metrics within agile frameworks. This forum is intended as a venue for sharing experiences and strategies.
The insights garnered from this case study will be further discussed in our upcoming Peer to Peer session. This presents an excellent opportunity to continue our dialogue, delve deeper into the issues at hand, and collaboratively explore potential solutions.
Your Thoughts
As fellow CTOs and engineering leaders, share your experiences and tips in the comments. Let’s collaborate to create a roadmap for effective leadership in the dynamic environment of a start-up. Your expertise could be the guiding light for many others in similar situations.
Peer Advice (Actionable Solutions from our CTO Community)
Ken K.
My take on this situation (and I’ve definitely been in this position before):
One of the key things to understand is that with this kind of request, the CEO isn’t actually wanting insight into each individual’s or team’s performance to optimize or clean house, rather it’s an indicator that he doesn’t fully trust YOU and how you’re leading, what you’re accomplishing with the department.
Now this isn’t to say you’ve done or are doing anything wrong, either in-fact (what you’re accomplishing) or in trust from the CEO not being strong. But it is pointing out there’s some gap in their ability to trust you’re driving great value from what you’ve got.
Some CEOs need more data and detail than others, and perhaps that is the reason. Often as leaders, even technology ones, we maneuver our teams, deliveries, and departments partially via intuition and finesse, and not precise algorithms or outcomes. Some fantastic CEOs I’ve worked with are good with that, trusting me as the leader to keep them informed about how things are impacting the business.
Other CEOs it’s not that they love data and detail, they’re just subconsciously (or consciously) feeling the need to get involved, control, and take charge. So this speaks to helping build his trust in you, the leader.
Now what I do in these kind of situations is to definitely put in place a series of metrics to regularly talk through with the CEO. I’ll talk about what twist I put on it in a second, but just tracking and putting together metrics actually helps you as well, even if you don’t feel you need them. “If you want to improve a thing, track that thing” “The spotlight of awareness tends to make aligning to goals happen naturally on its own”
Okay, but to metrics. The fundamental twist or distinction I make here is to have the metrics as a whole be about MY OWN success or failure, as a leader, at accomplishing my strategy and targets (which encompasses the teams and individuals). Yes this can feel a bit vulnerable and make you anxious, but IMO it’s the best way forward.
you subtly change the CEOs frame from focusing on the teams’ output to your leadership effectiveness
you build more and more trust with the CEO about you as a leader, so they need or want the metrics less and less.
What does this mean?
It means having a solid clear technology strategy written down and understood by the SLT and CEO. (you do have one of those, right? )
it means, yes potentially, folding team metrics in such as cycle-time, even velocity and burn-downs, but lean heavily into couching that data about YOU, not the team. Why are you making the choices YOU are making, with the detail and insight YOU have about the teams and their delivery?
it means using tactics such as milestone-orientation — coaching teams towards MVP milestone goals with lots of room for scope negotiation as timelines loom, yet still achieve (and claim) success.
it means even for tech debt areas, having a business case up front about what ROI the time/$ would bring, and tracking afterwards if that actualized
just my rambling $0.02, but take Responsibility, take Ownership of the ask, the trust building, and opening up to show not just what decisions you’re making, but how and why you make them.
In the realm of technology, wielding influence is much more than a testament to one’s expertise or position; it’s a profound responsibility.
Influential leaders in the tech industry not only drive innovation and set trends but also shape the ethical landscape of technology itself.
Their actions, both in the limelight and behind the scenes, serve as a beacon for others, making the conscientious use of their influence paramount.
Such leaders foster environments where diversity and innovation flourish, advocating for sustainable practices and inclusivity. They understand that their words and deeds can either elevate the industry to new heights of ethical practice or, if not carefully considered, lead others down less commendable paths.
This duality of influence requires a leader to be perpetually mindful of the broader impact of their actions, ensuring they embody the values of integrity, responsibility, and forward-thinking they wish to see in the world. By actively mentoring, engaging in thoughtful dialogue, and leading by example, influential tech leaders can harness their reach to herald technological advancements and instill a culture of ethical reflection and accountability.
In doing so, they pave the way for a future where technology not only advances human capability but does so with a conscientious understanding of its impact on society and the planet.
TL;DR: At InnovateTech, a fintech startup aiming to disrupt the digital payments industry, a significant rift forms between CEO Alexandra James, who advocates for rapid market capture with new features, and CTO Marcus Lee, who prioritises sustainable, secure growth. This clash comes to a head during a board meeting where the CEO’s aggressive strategy is approved, leaving the CTO to reconcile this with the technical team’s capabilities. Resulting issues include growing technical debt, team burnout and turnover, and a severe security breach due to rushed development. This case study spotlights the need for harmonising business drive and technical stability, managing technical debt, fostering team resilience and responding effectively to crises. It invites readers to contribute ideas for better CEO-CTO alignment and ends as a parable warning of the dangers of strategic misalignment in tech companies.
Introduction
InnovateTech, a burgeoning fintech startup, is on the cusp of revolutionising the digital payments space. At its helm are CEO Alexandra James and CTO Marcus Lee, both visionaries in their own right but divided by fundamentally different perspectives on the company’s trajectory.
The Scenario
Alexandra, with her keen business acumen, is pushing for rapid expansion and the introduction of groundbreaking features to outpace competitors. Her mantra, “Speed is the new currency in tech,” reflects her urgency to capture market share.
Marcus, on the other hand, is cautious. His focus is on building a scalable and secure platform that can handle the anticipated transaction volumes without hitches. His approach is methodical, emphasising the importance of technical debt management and a robust architecture to support future growth sustainably.
The Conflict
Tensions arise during a pivotal board meeting where Alexandra unveils her aggressive growth strategy, including an ambitious product launch timeline. Marcus, concerned about the technical team’s current bandwidth and the accumulating technical debt, voices his apprehensions, suggesting a more phased approach to development and scaling.
The board, swayed by Alexandra’s compelling pitch, green-lights the expansion plan, leaving Marcus with the daunting task of aligning his team’s efforts with the accelerated timelines, without compromising on the technical integrity of the platform.
The Complications
As development progresses, the tech team encounters significant hurdles:
Technical Debt Accumulation: In their rush to deliver, the team shortcuts some of the best practices in coding and testing, leading to a pile-up of technical debt.
Burnout and Turnover: The pressure to meet deadlines leads to team burnout, with key members leaving, further exacerbating the delivery challenges.
Security Concerns: In an oversight during a sprint to introduce a new payment feature, a critical security vulnerability is introduced, putting user data at risk.
The Climax
A major security breach occurs, exploiting the overlooked vulnerability. The incident leads to a temporary shutdown of services, eroding customer trust and inviting scrutiny from regulators. The fallout forces Alexandra and Marcus to reckon with the consequences of their misaligned strategies.
Discussion Points
Strategies for Aligning Business and Technical Objectives
How can CEOs and CTOs better synchronise their visions to support both innovation and operational stability?
Managing Technical Debt
What frameworks or practices could InnovateTech adapt to balance the pace of development with the need to manage technical debt effectively?
Building Resilient Teams
How can start-ups like InnovateTech prevent burnout and retain talent, especially when navigating high-stress periods of growth and scaling?
Crisis Management
In the wake of a security breach, what steps should a tech leader take to mitigate the damage, restore trust, and prevent future incidents?
Conclusion
The tale of InnovateTech serves as a cautionary story about the pitfalls of misalignment between a company’s technological capabilities and its business ambitions. By sharing and discussing this case study, we hope to illuminate the path towards more cohesive and successful partnerships between CEOs and CTOs in the tech industry.
Invitation for Solutions
You are invited to offer your insights, experiences, and suggestions for tackling the challenges faced by InnovateTech.
One response to “CEO-CTO Chasm at InnovativeTech”
Mats Oberg
Strategic alignment should have happened outside the boardroom. Probably with a pre-mortem. The the CEO could have presented to the board what the business benefits were, and how and why things may go wrong with the proposed strategy.
Now it retrospect it seems like the chosen strategy was wrong headed, but was the security vulnerability really a result of moving fast? An oversight can happen during any sprint.
In the digital era, mentoring transcends traditional boundaries, emerging as a keystone for growth and innovation within the tech industry. It’s a symbiotic relationship where experience meets fresh perspectives, fostering an environment where mentor and mentee thrive.
Mentoring is an important element of the learning journey – as both mentor and mentee. As you’re emerging in your career, it’s a powerful resource to lean into. As you give back in your career, it’s a fullfilling gift to provide.
Andrew Weaver, CTO Academy
Mentoring in tech is not just about navigating the complexities of coding or system architecture. It’s about understanding the ecosystem, predicting technological trends and manoeuvring through the dynamics of tech teams and projects. It significantly reduces the learning curve for emerging tech talents, thus offering them a roadmap to navigate challenges and seize career opportunities.
This journey offers mentors a unique chance to refine leadership skills, stay connected with the evolving landscape and gain fresh insights from the newer generation of tech enthusiasts. It’s an opportunity to contribute to the industry’s future by shaping its upcoming leaders.
Here’s how tech leaders can foster a Mentoring culture:
Initiate Formal Programs: Establish structured Mentoring programs that match mentors and mentees based on skills, interests and career goals.
Encourage Reverse Mentoring: Embrace skills exchange between generations, allowing younger employees to mentor seniors in, for instance, emerging technologies and new trends.
Facilitate Knowledge Sharing: Organise regular meetups, workshops and talks that encourage sharing experiences, challenges and successes.
Mentoring is about building bridges. It’s about connecting wisdom with ambition and experience with innovation. In the tech industry, these connections are invaluable. They are accelerating personal and professional growth, ultimately driving the industry forward.
In the dynamic realm of a tech start-up known for its innovative products, Mia, an Engineering Manager, shines as a pillar of support. She’s led her team through several successful product launches, earning praise for their creativity and dedication. However, a challenge from senior management casts a shadow over these achievements.
The team’s hard work is starting to take its toll, not due to Mia’s leadership but from the VP of Engineering’s intense pressure for continuous success, which is silently wearing the team down.
The Breaking Point
Mia notices signs of burnout among her team members:
Lowered engagement
Declining quality
Rising absenteeism
Unfortunately, despite her efforts to advocate for her team, the VP’s high expectations remain unchanged.
Consequences of Disconnected Leadership
The continuous push for excellence has led to a decline in product quality, customer satisfaction and team morale, with Mia’s protective efforts overshadowed by the VP’s demands.
The Crucial Realisation
A turning point occurs when a key team member resigns due to unsustainable work conditions, prompting Mia to address the situation directly with the VP, highlighting the risk to the team’s well-being and the company’s reputation.
The Key Question
How can Mia effectively convey the seriousness of the situation to the VP and champion her team’s health without compromising the company’s ambitious targets?
Seeking Your Guidance
As leaders who have faced similar challenges, what advice would you offer Mia? What strategies can help maintain team morale while achieving the company’s goals?
Join the Dialogue
We value your insights and experiences in navigating the complex dynamics of leadership under executive pressure. Share your thoughts on building a supportive environment that balances team well-being with corporate objectives. Engage in the conversation below and help craft a blueprint for compassionate, effective leadership.
2 responses to “Balancing Team Support and Executive Pressure”
Mats Oberg
First Mia need to ask herself “what is my contribution to the problem?” “Am I giving the team the resources they need, am I helping them prioritize their work, do they need to do everything they are doing?” Asking the VP for help solving the issue. If a key member leaves due to unsustainable working conditions, the VP may realize that there is a problem. The ask for help cannot just be help. By having pondered the questions above, as well as other related questions, the manager may be asking for help in a really specific way. E.g. “my team has been providing training to our internal teams monthly. All these training sessions have been recorded, maybe we can take a break in providing live training and let them view the recordings. I know it is suboptimal as they can’t ask questions, but given the current workload, we need to stop doing something. I think it would be helpful if we could hire a short term contractor to handle weekly collection of …. What do you think?”
Nilesh Jagdale
Mia, facing pressure to meet ambitious targets while maintaining her team’s well-being, should gather data on productivity, quality, and absenteeism to illustrate the team’s state. She should frame these issues in business terms, highlighting impacts on customer satisfaction and the risk of losing key talent.
Proposing solutions like adjusted deadlines, optimized processes, and initiatives supporting team well-being is crucial. Building alliances with other leaders who share concerns can strengthen her case.
During discussions with the VP, Mia should use constructive communication, focusing on collaborative solutions and actively listening to the VP’s perspective. Piloting new approaches on a smaller scale can demonstrate their effectiveness, while continuous monitoring and adjustment based on team feedback will ensure sustainable improvements.
By balancing these efforts, Mia can effectively advocate for her team’s health without compromising the company’s ambitious goals in the dynamic tech startup environment.
In a fast-growing technology company, the engineering, product and platform teams exhibit significantly different senses of urgency regarding project delivery and innovation. This misalignment leads to:
Delays
Frustration
Communication breakdown
Inefficient workflows
Concerns over losing a competitive edge due to missed innovation opportunities
“On innovation – I find teams struggle to innovate if they don’t feel ownership”.
Keith P.
Previous Attempts to Solve the Situation
Cross-functional meetings to improve communication.
Unified project management tool for increased visibility.
Company-wide OKRs to align team goals.
New Objective
Explore strategies to align the sense of urgency among teams, enhancing collaboration, efficiency and innovation.
The goal is a cohesive approach that balances quality, speed and stability.
Discussion Points
Strategies for addressing root causes of misalignment among tech teams.
Effective communication practices for a shared sense of urgency.
Balancing diverse priorities without compromising on quality, speed, or stability.
Successful case examples or experiences.
Let’s Discuss!
Share your insights, strategies and experiences to help navigate this challenge and achieve team alignment for success in a competitive landscape.
I would question the current shape of the teams. With separate engineering, product and platform, there is (in my opinion) going to be an additional overhead in maintaining/aligning vision and purpose.
If possible, I’d look to transform the teams into cross-functional pods, consisting of product, engineering and platform, and ensure they have a true sense of ownership – a one-team approach.
If this is not possible, I’d look to have advocates – bring a product person into engineering ceremonies (refinement, stand-ups, retros etc.) and vice versa.
Also, as a team or team of teams, agree on what getting done requires and achieves.
On innovation – I find teams struggle to innovate if they don’t feel ownership.
The CTO of a start-up is facing a challenge with a Senior Engineer who, despite a promising start and strong technical skills, is delivering work far slower than expected. This situation has arisen after replacing a previous bad hire and deciding how to “delicately” proceed.
Team Composition
There are three team members: a Junior, a QA and the Senior Engineer. The start-up is at a seed stage, emphasising the critical role of each team member.
“The skills and experience that made him a senior might not include being able to rapidly navigate your codebase/architecture/domain combination”.
Glenn P.
Performance Concerns
Issues ranged from environment setup difficulties to absence on critical delivery days. A crucial ticket is now delayed, prompting a meeting to discuss performance and expectations.
The Key Questions
How would you address the performance issue without demoralising the team or the individual?
What are possible ways to avoid similar hiring challenges in the future, considering the reluctance of senior candidates to engage in extensive interview processes?
Your Thoughts
Your insights and experiences could greatly assist in navigating this complex situation. Share your thoughts and advice in the comments below!
This case study reflects the nuanced challenges of start-up leadership, especially in balancing team dynamics, individual performance and company culture.
Interesting question, having been the “slow guy”, a couple of thoughts…
Before jumping to conclusions or doing anything drastic, in my opinion, it’s critical to understand what’s going on on his end. Is this a bad fit or has there just been miscommunication on expectations?
In no particular order:
How exactly has he been spending his time? Is he trying to really learn how things work in a new system with new tools? Refactoring and writing tests? If so how much? Is there too much context-switching?
What is his philosophy on tech debt?
What does he think his fundamental role is: to standardize processes and model good practices to JR dev or to just GSD?
Are expectations around delivery timelines totally clear to him?
As the new guy, where it sounds like others are starting to look up to him, does he feel safe potentially breaking things? (or shipping suboptimal solutions?)
As the only senior with you very busy with other things, does he have the support he needs? Does he feel comfortable bouncing ideas off of you, etc. or does he feel like he needs to do as much as he possibly can on his own (impacting delivery time)?
Glenn P.
I’d suggest here that 6 weeks in is a good time to have the intervention and do a deep-dive into what is preventing good performance.
The skills and experience that made him a senior might not include being able to rapidly navigate your codebase/architecture/domain combination.
From what’s been said – there’s lots to like about this individual. However, by the end of February, you need to identify if they were just a great interviewee or just a steady-starter.
It’s right to consider the impact on the team, but in my experience, letting a bad hire go is better for the overall team mood from the day after letting them go.
Ravi B.
There was a discussion about personality types (DiSC or CultureIndex etc).
Some people are slow to start and need all the details before they get going. They want to do everything perfectly by evaluating all possible options.
On the other side, you have people that jump into fire with very limited info.
It appears to me that you have a personality mismatch for the size of your company.
Tuomo T.
I’ve had a somewhat similar situation with a senior hire. They were delivering much slower than expected. I talked with them and asked what exactly was taking so long.
Found out that, indeed, it was mostly figuring out the architecture and how things are done and related etc.
Now they’ve been doing a task where domain knowledge is not needed and they are delivering a lot faster.
Depends on the product, but I think 6 weeks may not be enough to learn the code base and get very productive. I think the key is to find out why they are slow and what exactly are they spending their time on. Then find out if they can do anything in a reasonable time. If not, then it’s probably best to let them go sooner rather than later.
Jayson W.
Great points, Ravi. I share the same sentiment. On the surface, it sounds like there were some personality disconnects and or miscommunication expectations.
Given this person’s background, it sounds to me like an architect which may make sense as to why he/she did well with the communicative things in the beginning but may have either not realized they were going to write code or gotten bogged down with the big picture thinking.
Reply from Ravi:
Yeah. As part of hiring we make everyone take the personality test from Culture Index. This gives us an insight into what to expect and helps us with the right expectations on their bias for action, how social/influential they are etc.
A recent survey of 260 global CTOs found that 91% identified tech debt as a ‘major concern’ whilst issues such as cybersecurity, employee turnover and budget restraints registered less.
In this article, we take a deep dive into tech debt with contributions from five senior technology leaders across the CTO Academy community. They will provide their perspective on the problem and potential mitigation strategies towards the solution.
Last week, we had to put some external code on our website.
The new website manager put it directly into the template so it would load on every page. However, we have other external code on our website which is inserted via Google Tag Manager. So I insisted the new manager move the code from the template to GTM (with a bit of grumbling!).
If he had not moved the code to GTM immediately, it would have become technical debt. In other words, something which was simple to fix on the spot would become more challenging in a week as one would have to refresh one’s memory as to the problem.
How many of these simple examples does it take? 10? 50? How many before we end up with substantial technical debt on our hands making the website difficult to manage?
Let me open this discussion by detailing various forms of technical debt.
Forms of Technical Debt
(click to expand/download)
Code Debt
When code is not properly written or structured, often due to rushing to meet deadlines, we have a code debt. It can lead to a codebase that is difficult to read, maintain or extend. Examples include duplications, large classes or methods and lack of modularisation.
Design Debt
It arises when a software design is flawed or becomes outdated. Design debt manifests in systems that are hard to scale or modify. Poor design choices, such as not following design patterns appropriately or over-engineering, contribute to this debt.
Testing Debt
Skipping or rushing testing phases can lead to insufficient test coverage or ignored failing tests. This debt increases the risk of bugs and failures in production.
Infrastructure Debt
When the development or production environments are not properly set up or maintained, we end up with infrastructure debt. This can include using outdated tools or platforms, inadequate server capacity or lack of automation.
Dependency Debt
Comes from relying on outdated or unsuitable third-party libraries and tools, leading to security vulnerabilities, compatibility issues and limitations in functionality or performance.
Technical Skills Debt
This form of debt arises when the team lacks the necessary skills or knowledge to work efficiently with the current technology stack or to implement best practices. This often leads to suboptimal solutions and increased maintenance work.
Architectural Debt
It is similar to design debt but at a higher level. Architectural debt involves issues with the overall structure and interaction of different parts of the system, leading to difficulties in scaling, integrating new features or adapting to new requirements.
Process Debt
Process debt is generally caused by inefficient or outdated development processes. Examples include lack of agile practices, poor communication between team members or inadequate project management.
Versioning Debt
When software components are not kept up to date, versioning debt leads to compatibility issues, security vulnerabilities and increased effort required for future updates.
Documentation Debt
Insufficient or outdated documentation makes it harder for new team members to understand the system and for existing members to remember why certain decisions were made. Unfortunately, most technical documents go out of date the moment they’re written.
I have always been conscious of technical debt and tried to keep it to a minimum during my career. Code must be well maintained, systems kept up to date (including operating systems) and redundant systems/code removed. Finally, I make sure there is a sprint every six months allowing teams to tidy up so that it never builds up to something unmanageable.
When discussing technical debt, especially with non-technical leaders, I always ensure that we have a shared understanding of what we mean by ‘debt’ — ie, we take some shortcut today that we have to repay at some point in the future.
The cost of not repaying that debt results in ‘interest payments’ which translates to either software or infrastructure that is harder to work with and, therefore, costs the business more to deliver every new feature.
Every project has some technical debt, but not all technical debt is equal.
For example, you may have a particularly unruly module in your codebase that is a real pain to work with. But if it hardly ever gets touched, then the effort to refactor it may far outstrip any potential benefit you expect to receive from paying down that debt.
Therefore, understanding the impact of the debt on your teams’ productivity (and happiness) is essential. I’ve always encouraged teams to maintain a list of their worst bugbears which should be prioritised based on two factors:
How much it is impacting the team’s ability to deliver features
How much effort will it take to remediate
Allowing some time either in each sprint or setting aside a whole sprint every few months to tackle these issues will help keep technical debt under control.
I mentioned happiness above, and while it might at first sound odd to talk about developer happiness when discussing technical debt, many developers need to know three things.
First, you take technical debt seriously.
Second, you care about quality.
And, ultimately, third, you listen to and trust them to make recommendations that affect the thing they do every day in service of your business.
Ignoring technical debt for too long can lead to a negative spiral where new features take longer and longer to deliver. Consequently, team members, feeling frustrated and ignored, start looking around for new roles. Often, the strongest team members leave first, causing a sort of ‘brain drain’ on the rest of the team. This inevitably results in further slow-downs, and so on.
Good people won’t stick around for long if they feel that tech debt is something we’ll tackle ‘one day when there is more time’. In other words, a quieter day is not coming, so start putting time aside now. It’s sound economics and it will also make your team happier.
Forecasting and managing specific debt is critical
“A definite rigour can be applied.”
Ken Kolchier, CTO of Trade Technologies, specialising in optimising engineering organisations
With Jason having identified categories of tech debt to look for, we are in a position to assess any one of them for priority, cost to remedy and cost to leave alone.
Tech debt will, by necessity, always exist and accumulate. In software, we make directional decisions about where to add complexity to account for likely change, and where to implement stability and opinionated design.
Regardless of the type of debt, business forecasting the cost of handling or not handling specific debt can be critical to prioritising the right things. Forecasting and managing this area can sometimes be more art than science, but there is definite rigour that can be applied.
Most of us are well aware that tech debt stems from not designing enough adaptability in a highly changing area. On the other hand, coding too much flexibility in a slow-changing area is, de facto, tech debt in its own right. That is, whenever we might need to change that code, the complexity of pre-designed adaptability adds friction and possible instability.
When assessing code or design debt, typical (and atypical) codebase analytics involve scanning with tools such as Sonarqube, JetBrains Qodana, NDepend and others. Additional insight might be gained from other data, such as crunching numbers from the git log to map hotspots in the code to levels of debt.
Typical metrics that help forecast ROI
Lines of code
Total complexity (cyclomatic complexity)
Number of files with large complexity
Duplicated blocks/lines of code
Code issues/smells
Test coverage
Hotspot files and number of changed lines
Jira metrics about task duration in the area
Team estimation of friction ratio
The hotspot metrics are not only a factor to include in calculations but can also help us quickly decide when ROI simply isn’t there, and to stop analysing.
The team – and we as technical leaders – might feel a certain area is riddled with tech debt and needs to be addressed. Yet, if the system is stable and working in that section and the code is rarely touched, it shouldn’t rise as a priority.
For most metrics, we can get fairly good ballpark numbers about the cost of change or how many team hours are required to add test coverage to one line of code; fix one duplicate block or simplify one largely complex file.
We can apply these numbers to the debt metrics we’ve gathered, quantifying how much it would cost to remedy it in the specific component we’re analysing. But do make sure to include all the various factors — complexity, code issues and test coverage. This helps to reach a balanced assessment as code that is low in complexity and also low in test coverage might not be prioritised, as the impact of any tech debt is easily navigated later.
Along with the cost to address the debt, we need the other side of the coin —
How much does it cost NOT to fix it?
Granted, gathering this information can take some finesse. However, we can start with a solid analysis of how long our tickets or tasks take to complete in the code area in question. Survey the team to guesstimate how much faster those tickets might be completed if the debt were removed.
We can now easily generate a cost/benefit analysis, calculating the current cost of the friction by the following formula:
How much time would be saved per ticket x The dollar cost of our team completing one ticket x The average number of tickets in a given cycle
And then compare that to the previously gathered cost to remedy.
Combine this with priority based on hotspots, and we have a well-rounded picture.
Other areas such as testing debt can be analysed similarly. We can track the difference between bugs that are ‘escapes’ (bugs in newly changed code) versus bugs in legacy areas of the code and prioritise them accordingly.
Applying this kind of rigour not only helps us and the business make good decisions, but our teams can respond to it as well. We’re simply helping them see quantified, engineer-type numbers around what is usually a very fuzzy answer to a fuzzy question.
The necessity for strategic handling
“It needs strategic handling”.
Sid Mustafa, Fractional CTO and founder of Phoenix Consulting
In my tenure across diverse software engineering roles, I’ve encountered technical debt in various forms. It’s a nuanced challenge that needs strategic handling and I believe it is neither good nor bad.
For instance, at one company I worked at, we faced tech debt as a consequence of a lack of organisation, planning and prioritisation. The business was operating as a feature factory.
To improve the state of affairs, we had to judiciously decide if and when to incur this debt for agility. Additionally, we had to decide when to allocate resources for its reduction.
At another company, rebuilding the codebase demanded a delicate balance between rapid development and long-term sustainability.
Here, technical debt was a strategic choice and an important consideration for maintaining a robust, scalable product.
Using tools to reduce the team’s cognitive load
In addition to these strategies, we also employed a tool called Stepsize in our IDE. This tool significantly streamlined our technical debt management process. Stepsize allowed us to log technical debt more naturally as we worked, embedding the process into our daily development activities without causing significant disruption or context switching.
By tagging technical debt items with impact and priority labels directly within our development environment, we reduced the cognitive load on the team. This approach enabled us to handle mundane tasks efficiently while maintaining a comprehensive and prioritised log of our technical debt.
The integration of Stepsize into our workflow was a game-changer, allowing for a more fluid and less intrusive method of tracking and managing technical debt, ultimately contributing to our team’s increased productivity and focus.
After implementing a robust prioritisation and planning process to manage technical debt, we observed a 20% increase in deployment frequency and a 15% reduction in the time taken to transition from code commit to production.
However, after integrating the Stepsize, we observed a 75% reduction in the time developers spent on identifying and logging technical debt.
It was also central to the decreased cognitive load on the team when working around TD and significantly improved DevEx.
Technical debt extends beyond code; it permeates the wider business, impacting architecture, product features and customer/team satisfaction. To effectively manage it, a structured approach is essential. This includes:
Defining
Logging
Monitoring
Quantifying
Risk assessing and
Prioritising technical debt
By doing so, we can use it strategically to accelerate development without falling into an unrecoverable debt spiral.
Moreover, the categorisation of technical debt is crucial for efficient management. Utilising frameworks like the technical debt quadrant or the 13 distinct types identified by the Software Engineering Institute — architecture, build, code, defect, design, documentation, infrastructure, people, process, requirement, service, test automation and test debt — provides a clear structure for prioritisation and handling.
Most Common Causes of Technical Debt
“Name it, visualise it, prioritise it”.
Pawel Slotorsz, DevOps Manager at Hard Rock Digital, Poland
In my view, the term tech debt refers to the lack of ability of an organisation or team to adapt and respond quickly to changes, challenges and opportunities in the rapidly evolving IT landscape.
I have encountered tech debt in all projects that I have participated in and observed it from a distance in other teams.
Jason has provided some very good examples, and my experience has been very similar. But let me add my take on the most common causes of tech debt which recur from company to company and project to project.
An organisation decides to buy or lease a third-party codebase or platform to speed up the delivery of the product or service. Although feature- and market-wise the organisation compares several options and picks the best solution, they accept the fact that, for example, the tech stack will not fit into current modern tech architecture; eg, cloud-native, Kubernetes, serverless, development frameworks or others.
The solution to the problem is designed from scratch
In the above case, most of the time, the tech debt is created literally from the moment the engineers write the first line of code and the code is pushed to the repository. This happens because it is impossible to predict all the consequences of using a particular solution. It is also connected to a lack of skills in the engineering team.
Alternatively, engineers will often manage the issue by repeating a previous fix to a similar problem. Why? “Because”, they say, “it’s always been done this way”.
The aim is to free up teams or individuals and speed up delivery. But the inevitable outcome is tech debt. If that debt is not properly managed, it will decrease productivity, increase maintenance costs, reduce software quality and, ultimately, bring about the failure of the project.
So how can we deal with it?
Start by acknowledging that tech debt is there. Name it, visualise it and prioritise it.
This can be done in several ways. I’ve done it via a risk register, backlog refinement, proof of concepts and R&D.
The first two can answer questions such as:
Is this tech debt? If so, is it a risk I can live with?
Does it create a block?
Does it need immediate attention?
R&D provides the opportunity to research solutions, innovate or learn from others.
Therefore:
1) Allocate a percentage of your time and money to:
Constantly monitor tech debt and
Learn how to prioritise different areas of debt.
In some cases, you’ll need a strike group — a team for whom dealing with the most urgent areas of debt will be a priority.
2) Measure the following:
How often bugs are introduced into the codebase/product
The number of incidents or outages
How much time is spent on dealing with code debt
3) Determine whether too much or not enough of your workforce is dedicated to dealing with tech debt problems and whether allocating those resources is blocking the business from operating efficiently. Remember, it’s always about proper balance. The time and effort needed to deal with technical debt won’t be constant.
4) Resist the use of fancy tech when there is no use case or business value for it. And always learn from other teams, organisations and people in your network about how they manage the problem.
What are your thoughts?
It’s a challenge most of you are dealing with so I hope we’ve helped provide some answers.
Thanks to everyone who contributed to this article.
What are your experiences with tech debt?
Do you agree/disagree with the problems and solutions raised here? Let us know.
An organisation has embarked on a new journey, setting cross-departmental objectives that necessitate seamless collaboration among the subteam leaders from different departments. A team lead, Anisha and her PM counterpart, Gabriella, are at the forefront of this challenge.
Historically, their collaborations have been fraught with difficulties, stemming from their divergent leadership styles, values and interpretations of the organisation’s needs. This issue isn’t isolated to Anisha and Gabriella alone; it mirrors similar conflicts and competitive tensions among other team leads from these departments.
Faced with the task of jointly charting a course towards a shared objective, Anisha and Gabriella find themselves at a crossroads, burdened by a legacy of unsuccessful collaborations.
As no change happens from one day to another, the manager(s) would need to participate a lot more in day-to-day operations and be on the lookout for friction to immediately address them or bring the specific people to the side and work it out.
Ricardo F.
Strategies Implemented
Anisha and Gabriella have previously attempted to bridge their differences and forge a path forward. These efforts, however, have been notably time-consuming and often fruitless, even with the involvement of other colleagues.
NOTE: Unfortunately, at this stage, we don’t have historical information on taken actions so it’s for everyone’s interpretation.
Challenges Encountered
Despite the extended deliberations, agreements remain elusive, leaving many initiatives incomplete.
The Key Question
How can Anisha and Gabriella overcome the longstanding friction between them and unite effectively to achieve their collective goal?
Your Thoughts
As fellow CTOs and engineering leaders,
How would you solve this conundrum?
Have you faced similar challenges in your leadership journey?
How did you navigate them?
Share your experiences and tips in the comments. Let’s collaborate to create a roadmap for effective leadership in the dynamic environment of a start-up. Your expertise could be the guiding light for many others in similar situations.
Peer Advice (Actionable Solutions from our CTO Community)
Ricardo F.
Hi everyone! Before I give my take on this case, here are some points I need to highlight:
Having so many issues among team leads that seem to be craved on their way of working sounds like either the company culture needs to be revisited or it wasn’t well understood by the team and needs a lot of care in this aspect.
The involvement of other colleagues doesn’t explain what was done exactly nor if they were the right people for the job since not everybody is cut to handle these delicate situations. I’ll have to assume that the methods used and the considerations made were indeed well thought out.
From the leadership perspective, it sounds like they somehow were aware and tolerated these conflicts to happen and even affect the initiatives themselves, digging into their own problem at hand. Things should have been handled immediately and not allowed to scale it to this point.
Setting cross-departmental objectives when the team is not in a solid state, could blow and end up as the many incomplete initiatives in the past.
Now, my take:
Let me start by stating the obvious – anyone picking up the current scenario will have a hard time making it right since it’s not an isolated episode or a strict group of people, even when you, as a manager, have experienced such problems in the past.
Starting from the beginning, the manager(s) would have a 1-on-1 call with each of them and try to understand each other’s perspective. They should connect the dots of why there are so many conflicts which would potentially lead to a group call to address many of those points and bring the team back to cohesion. At the same time, they should make it clear that everyone is there to deliver their best work respectfully.
As no change happens from one day to another, the manager(s) would need to participate a lot more in day-to-day operations and be on the lookout for friction to immediately address them or bring the specific people to the side and work it out. Always without forgetting the 1-on-1s to listen and make sure the other person knows they are listening to their problems/concerns even when they don’t agree with them and some contrary actions need to be taken. Sometimes, people just want to feel heard and feel their opinions are taken into consideration.
Revisit the company culture, and make it open, inclusive and respectful.
Try to buy in whoever you can to help you foment these points and flip the current situation to a good path.
Consider a gathering event, if it’s a remote type of company or some drinks in a video call on a Friday afternoon for the team to bond outside of work and try to find some common interests/perspectives.
If nothing works and the manager(s) see that no one is making the effort to even try, maybe consider an improvement plan and personalise it for each team member. In the end, either they get better or you’ll need to find someone to take the business on a good path. In other words, manager(s) shouldn’t drag the situation for a very long time.
I know I’m making some assumptions and the suggestions might be a bit generic, but as I said, it’s not an easy situation to handle when many members of the team are not working towards the same goal, delivering the objectives, even if they have different opinions/approaches.
I would love to hear more thoughts on this and maybe even contradict/question my take.
In this post, we explain the relatively new Field CTO role and how it differs from a more traditional Chief Technology Officer role. We will see how a Field CTO job description determines the type of person suitable for the job. We will take a look at the job prospects and, of course, the average salary.
First things first…
What is a Field CTO?
A Field CTO is a high-ranking executive role that is becoming ever more popular in tech companies (IT, software or telecommunications industries). Their primary responsibility is bridging the gap between technology and business strategy while also engaging directly with customers and partners. In other words, the focus is on developing an innovative approach to dealing with customers’ problems. This is not something a traditional CTO usually does, at least not to such an extent.
The FCTO must possess business acumen and a deep understanding of the market. The reason is simple: the primary focus is on customers’ problems and innovation. As an FCTO, you want to map all the challenges into the vendor’s product portfolio.
Forward-operating aspects of the role
Another element that largely differs from the traditional role is technical evangelism. You will be directly responsible for (actively) promoting your company’s technology solutions. To put it bluntly, you will evangelise them to customers, partners and the broader industry. This involves articulating the value and benefits of the company’s offerings. Not exactly an ideal job for someone who’s struggling with open communication, is it?
So, unlike our traditional CTO who is mostly inside-oriented, an FCTO frequently engages with customers to a) better understand their technology needs, and b) identify opportunities. It is the only way to perfectly align the company’s products or services with customer requirements. Naturally, this often involves building and maintaining strong relationships with key customers and partners.
Inside-oriented roles
With such a deep understanding of customers’ needs, FCTOs often collaborate with the sales and marketing teams to help them understand the technical aspects of the company’s products or services. They may even participate in sales meetings, provide technical expertise during customer presentations and assist in closing deals. That involvement, however, doesn’t extend to active selling.
FCTOs of technology companies, due to the nature of their involvement, hold an important role in merger and acquisition processes.
Since they act as a bridge between the engineering and business teams, FCTOs work closely with in-house CTOs and engineering teams on product development. They are there to provide valuable input into the development of new products or services. Additionally, they help prioritise development efforts. This, in turn, ensures that products align with market needs and technological trends.
What makes the FCTO such a valuable addition to the development process is the feedback loop they gather from customers in the field. That Information and data is relayed to the internal teams responsible for product development and improvements. This helps the company to stay responsive to market demands.
Many Field CTOs are seen as industry thought leaders. They may write articles, speak at conferences and represent their company in public forums to showcase their expertise and vision in the technology domain.
It’s clear that a Field Chief Technology Officer plays a pivotal role in aligning technology with business goals, fostering customer relationships and driving innovation. However, we must note that the specific responsibilities and influence of an FCTO can vary depending on the company’s size, industry and strategic objectives.
Get the IT Career Path Roadmap (Free PDF)
Want more than scattered ideas? Get our IT Career Path Roadmap PDF – an 8-step framework to map your next roles, sharpen your skills, and build a layoff-resilient tech leadership career. Fill in the form and we’ll send you the PDF version so you can download it, annotate it, and use it as a living plan for your next career moves.
What is the Difference Between a Field CTO and a Part-Time or In-House CTO?
The roles differ primarily in terms of responsibilities, level of engagement and the nature of their employment. Here are some key distinctions:
Field Chief Technology Officer (Field CTO)
Engagement Level: FCTOs often have a broader role that involves customer engagement, technology strategy, market evangelism and thought leadership.
Customer Interaction: They actively engage with customers, partners and the broader industry to understand market needs, build relationships and represent the company’s technology vision.
Responsibilities: FCTOs are less involved in the day-to-day technical operations of the company. They are, however, instrumental in aligning technology with business goals, shaping the technology strategy and ensuring that the company’s offerings really do meet market demands.
Full-time position: They may hold a full-time position in the company but may spend a significant amount of time externally, interacting with customers and industry stakeholders. In fact, some jobs can involve remote working.
Part-Time CTO
Engagement Level:Part-time CTOs have a reduced level of engagement compared to full-time CTOs. They are typically engaged on a part-time or consulting basis.
Responsibilities: These may include providing technical guidance, reviewing technical decisions and offering strategic input. However, they may not be deeply involved in day-to-day operations or product development.
Flexibility: Part-time CTOs are often hired for their expertise on specific projects or to address particular technical challenges. Their engagement can be flexible and tailored to the company’s needs.
In-House, Full-Time CTO
Engagement Level: In-house, full-time CTOs are deeply embedded within the company and are responsible for the overall technology direction and management.
Responsibilities: They have a wide range of responsibilities, including overseeing technical teams, product development, infrastructure management, budgeting and developing technical strategy.
Commitment: In-house CTOs are committed to the company on a full-time basis and are responsible for the day-to-day technical operations. They are often part of the senior executive team. However, in start-ups and smaller organisations, they have a more hands-on role.
In summary, the key differences revolve around the level of engagement, the scope of responsibilities, and the nature of the employment arrangement. Field CTOs are more externally focused, part-time CTOs offer flexibility for specific needs, and in-house, full-time CTOs are deeply involved in the company’s technical operations and strategy. The choice between these roles depends on the company’s size, goals and resource availability.
What are the responsibilities of a Field CTO?
(click to enlarge/download)
The responsibilities of an FCTO vary depending on the organisation and its specific needs. However, the role generally encompasses a combination of the following responsibilities (this is, effectively, a summary of everything we discussed so far and, quite often, from the job requirements on job boards):
1. Customer Engagement
Build and maintain strong relationships with key customers and partners.
Act as a trusted advisor to customers, understanding their technology needs and providing solutions.
2. Technology Strategy
Define and execute the company’s technology strategy in alignment with business goals.
Identify emerging technologies and assess their potential impact on the business.
3. Sales Support
Collaborate with the sales and marketing teams to provide technical expertise during customer presentations and assist in closing deals.
Help sales teams understand and communicate the technical aspects of the company’s products or services.
4. Product Development and Innovation
Provide input into the development of new products or services to ensure they align with market needs and technological trends.
Serve as a bridge between the engineering and business teams, helping prioritise development efforts.
5. Thought Leadership
Act as an industry thought leader by writing articles, giving presentations and representing the company in public forums.
Showcase expertise and vision in the technology domain to enhance the company’s reputation.
6. Technical Evangelism
Promote the company’s technology solutions to customers, partners and the broader industry.
Articulate the value and benefits of the company’s offerings.
7. Feedback Loop
Gather feedback from customers and the field, and relay this information to internal teams responsible for product development and improvement.
Ensure that the company stays responsive to market demands and customer feedback.
8. Competitive Analysis
Monitor the competitive landscape, assess the strengths and weaknesses of rival companies’ technology offerings and provide insights to inform the company’s strategy.
9. Industry Trends
Stay up-to-date with industry trends and technological advancements, and assess their potential impact on the business.
10. Collaboration with Internal Teams
Work closely with various internal departments, including engineering, product management and executive leadership, to align technology initiatives with overall company goals.
11. Strategic Planning
Contribute to the development of long-term technology and innovation strategies for the company.
Ensure that technology investments align with the company’s growth and profitability objectives.
12. Risk Management
Assess and mitigate technical risks associated with the company’s products or services.
Ensure compliance with industry regulations and best practices.
As you can see, some of the responsibilities are universal; that is, closely similar to those of a traditional CTO. The specific responsibilities, however, extend beyond technical matters to encompass business strategy and customer relationships. In fact, some Field CTOs aren’t even coding-savvy. But they do know how to best navigate code developers to get exactly what the market demands.
What skills and experience are required to be a Field CTO?
5-10 years of industry-related experience and 5+ years of experience in a role similar to CTO, CIO, VP/Dir of Engineering, Operations or Product Development.
10+ years of architecture experience building, consulting or implementing technology for the relevant industry.
Knowledgeable in the challenges impacting the relevant industry and the application of industry-specific use cases.
A broad range of experience with technical and design direction that may also include large-scale database and/or data warehouse technology, ETL, analytics and public cloud technologies.
Familiarity with data providers and data aggregators.
Understanding of industry-specific concepts and applications.
The ability to travel to customer sites, industry events and other related events as required (in some instances, over 30% of time FCTOs spend travelling or working outside of the company’s premises!)
Required Experience
Demonstrated ability to conduct conversations and quickly establish credibility with C-level individuals and other business executives where selling solutions are the focus (ie, outstanding presentation skills to both technical and executive audiences).
Work experience in a client environment, ideally in a leadership capacity.
Strong interpersonal and presentation skills including consulting skills.
Strong oral and written communication skills.
As always, it is important to note that the specific requirements for an FCTO can vary depending on the company, its industry and its strategic goals. In some cases, soft skills and industry-specific knowledge may be just as important as technical expertise. Successful Field CTOs are well-rounded individuals who can bridge the gap between technology and business, providing valuable leadership and insights to drive the company’s success.
What are the career prospects for Field CTOs?
We know that FCTOs play a crucial role in the technological needs of an organisation. Consequently, the number of Field CTO jobs has slowly increased over the last few quarters.
Just like a traditional role, the FCTO position provides substantial benefits. We are talking about:
Top salary possibilities
Equity or shareholder offerings
Leadership opportunities
Reputation development
Recognition and enterprise-level goal achievement.
In terms of career progression, FCTOs can look forward to roles in higher executive management or opportunities in consulting or entrepreneurship. They can also transition into specialised roles within the tech industry depending on their areas of expertise. It’s important to note that the specifics can vary based on individual career goals and market trends.
The successful candidate’s starting salary is usually determined by skills, experience and location. FCTOs are frequently offered competitive benefits packages, which commonly include:
Medical, dental, vision, life, and disability insurance along with a 401(k) retirement plan
Flexible spending and health savings account
Paid holidays and time off
Parental leave, etc.
What are some of the biggest challenges and opportunities facing Field CTOs today?
Challenges:
Technological Changes (ie, the rapid pace of technological evolution that requires high levels of adaptability).
A shortage of IT Professionals (creates a challenge in managing day-to-day operations).
Strategic Role (requires balancing the strategic role and daily operations).
Opportunities:
Operational Possibilities (technology is now much more embedded in day-to-day life, thus providing more business opportunities which, in turn, creates a wider array of operational possibilities for FCTOs).
Field CTOs, as a relatively new role in the world of technology leadership, have yet to discover what bumps may be awaiting them down the road.
That’s why here at CTO Academy, we are continuously working to identify both challenges and opportunities and to educate and inform our members. Our Global Community of Tech Leaders is actively involved in daily discussions and problem-solving, helping each other in their day-to-day operations. All members have a unique opportunity to shadow seasoned CTOs and learn from them during live sessions and Expert Q&As.
A long time ago, we became aware that the only way to successfully overcome the hurdles is a peer-powered trust of brains and cumulative experience. Existing and future Field CTOs can greatly benefit from such a community because it removes much of the unknown from the equation. Because if you don’t know that the obstacle exists, you will inevitably trip over.
)
One response to “CEO-CTO Chasm at InnovativeTech”
Strategic alignment should have happened outside the boardroom. Probably with a pre-mortem. The the CEO could have presented to the board what the business benefits were, and how and why things may go wrong with the proposed strategy.
Now it retrospect it seems like the chosen strategy was wrong headed, but was the security vulnerability really a result of moving fast? An oversight can happen during any sprint.