4 reasons SaaS engineering teams stall – and ways to fix them in 2024

2024 is here. I’ve spoken to hundreds of engineering leaders over the last year, and SaaS many engineering leaders continue to face pressure to ramp up efficiency, streamline processes, and drive meaningful progress. 

But even the best teams encounter stumbling blocks. Left unchecked, they can – and unfortunately, sometimes do – derail the most promising of projects.

Reason 1: Alignment is hard

We all understand how important nailing alignment is, and we know that when teams get this right, they perform disproportionately better. 

But most of us don’t end up achieving it.

Why is alignment a tough nut to crack? At the core of it, it’s because we humans exist with natural cognitive limitations. In most modern software organisations, it’s impossible, even in principle, to be aware of everything happening. Even if we could do this, we’d be unable to process all the information and form meaningful connections and insights about them. And we’d even less be able to action everything that needs actioning. By the time we’ve even attempted these steps, we’re out of date.

And collaboration is tough, too. Humans battle decision fatigue, our inherent biases, varied interpretations and so on. We end up with scattered goals, misaligned strategies, and yes, plenty of frustrating conflicts. 

Alignment doesn't happen by accident, because humans just aren’t wired this way. 

For most teams, it demands a great deal of ongoing intentionality.

We often picture the exchange of information at companies something like this.

But in my experience, the real picture often resembles more of a creative disarray than anything else.

Somehow, against all odds, this seemingly tangled web of operations manages to function.

We rely on a range of processes and tools that help us mimic alignment as best we can. These include

• Synchronous methods, like daily stand-ups, cross-functional meetings, and so on
• Asynchronous methods, like status updates, emails and messaging people on Slack or Teams
• Systems of record, such as our PM software (think Jira and Linear), hosting tools (like GitHub) and more

…Trouble is, we’re still not really aligned. Alignment is usually an illusion, because – as we said – humans can’t, even in principle, always stay reliably up-to-date.

Alignment has no real ROI. But, at best, it’s costing engineering teams as much as 30% of their time.

All the while, we’re missing opportunities, wasting time, making suboptimal decisions, creating poor developer experience and so on…

Fixing it

• Master transparency and visibility. Think of visibility as the simple availability of information, and transparency as an open culture that fosters trust and communication. The key to effective information sharing lies in balancing these types of visibility while promoting a transparent organisational culture. I wrote about this distinction in detail here in relation to strategies to improve productivity.
• Get tooling right. Double down on a small number of powerful tools that provide real-time visibility into team progress, blockers and more.

And there’s a fast track to alignment I want to share. With my team, I’ve been working on a powerful AI tool that creates alignment in a way humans can’t do by themselves.

It’s called Stepsize AI. 

Stepsize AI observes your activity across your systems of record, such as Slack, Linear, Jira and GitHub. Then, it surfaces what matters in one powerful, easy-to-read team sync update.

The Stepsize AI Operational Intelligence Engine understands everything happening in your product engineering org, and surfaces what matters. 

Stepsize AI can create all kinds of reports, including

• Daily standups
• Daily team syncs
• Sprint and Kanban reports
• Executive summaries

I may be biased, but I’ve already seen the incredible impact of this AI on software organisations – it’s been a substantial driver in creating alignment, boosting productivity, cutting meetings and more.

Go ahead and check out Stepsize AI here.

Enough about us – let’s get into the next reason teams stall.

Reason 2: Technical debt

This is important: not all technical debt is bad.

Good tech debt can accelerate your timelines, get features shipped, and provide a short-term boost. That's the kind of debt you take on deliberately, with a roadmap for repayment. 

Bad tech debt is often reckless, unplanned or oblivious to things like code quality. It gives you a quick win today b,ut turns into an engineering nightmare down the line. 

It pleases the PM today, but in two months, you’ll be up to your neck in delayed schedules and irate customers.

Here’s a complete guide to technical debt, if you want to get into the nitty gritty.

Why Tech Debt Accumulates

Tech debt gets out of control when

• It’s taken on imprudently or accidentally
• There’s no plan to pay it back
• There’s a lack of code quality culture, tech debt heroes aren’t supported
• The time needed to pay debt back isn’t justified and approved
• Tech debt is invisible, poorly documented or lacks context

When tech debt is allowed to accumulate, the impact extends deeply – far beyond the codebase. This illustrates what I mean:

Ultimately, tech debt is an inevitable part of the software development process. What matters is that we accumulate it consciously and prudently, manage it correctly and pay it back in a timely manner.

Fixing it

As an engineering leader, it's on you to make issue tracking seamless. You’ve got your usual suspects: Jira, Linear, Asana. However, the question remains — do they truly solve the core problem? The consensus leans toward 'not really.'

Here’s what you need to crack the code on tech debt:

• Track issues properly. Require tech debt to be logged, and insist that codebase context is added to every ticket
• Assign resource. A good rule of thumb is to assign 20% of resources in every sprint, or a fortnight per quarter, to technical debt. Enforce this time.
• Prioritise properly. Have good conversations about the tech debt that is accumulating the most interest. Use backlog planning as opportunities to do this.

Here’s a detailed guide on reducing technical debt.

Reason 4: Outdated tools and failure to adop

Outdated tools are a rather obvious strategic mis-step, and one that most leaders will be acutely aware of. Sticking with ageing tools is itself a kind of technical debt. We’ll eventually find ourselves fundamentally misaligned with the demands of modern engineering.

There’s an opportunity cost element to this, too. A failure to adopt new tools that have the potential to unlock substantial, and sometimes exponential, returns leads to enormous avoidable opportunity costs.

The Exponential Cost of Poor Tooling 

There are various categories of costs for poor tooling.

Some cost you a few minutes here and there (think 15-minute deployment a couple of times a week that could potentially be cut down to 5 minutes).

Others are more insidious, contributing to a persistently sluggish and potentially unreliable workflow. They can do this in a number of ways, including imposing cognitive burdens, introducing friction, or amplifying the likelihood of errors and bugs.

The most insidious tools are those which are engrained not only in your operations, but in your projects. As an example, consider a legacy database system that’s deeply integrated into multiple applications. It’s slow, fraught with quirks, and everyone hates it. But the cost and risk associated with migration are prohibitive

These kinds of losses add up remarkably quickly. It’s not one developer losing a few minutes – or hours – it’s entire engineering forces aggregating problems until it becomes a substantial productivity tax. 

Crucially, they multiply quickly, too.

When you’re using tools ingrained in your processes, every new feature, patch, and bit of scaling you do is layered on top of this shaky foundation. Each new layer of the project is more fragile. The exponential effect can eventually threaten the viability of your project – and even whole organisations.

Poor tools are also something of a talent repellant. We all know the top engineers can afford to be picky – your stack will matter to candidates and can also push your existing engineers out the door. 

The staggering cost of AI aversion

I’ve spoken to hundreds of engineering leaders, and three camps dominate the engineering world's stance on AI.

• Camp 1: Too risky. Leaders here avoid AI, citing operational or security concerns. Their policy is clear: steer clear until it's safer.
• Camp 2: Dabbling. No formal AI policy, but engineers experiment with tools like GitHub Copilot and ChatGPT.
• Camp 3: Full throttle. These teams have dedicated personnel for AI adoption. They're not just interested; they're invested.

The performance gap between these groups is staggering.

According to this survey of 200+ companies, Camp 3 is shipping projects 2.5x faster. 

Translate that to a workday, and it's like freeing up 3 hours in an 8-hour shift. A year from now, they expect that number to be 5 hours.

Some teams (and leaders) treat AI like a fad. They aren’t the ones unlocking 2.5x productivity. If you're not actively using AI, you're losing ground at a much faster pace than many imagine.

Fixing it

• Getting the balance right. Invite quarterly discussion on how to prioritise available resource and encourage conversation backed with data to weigh up the cost vs benefit over time of replacing outdated tools.
• AI adoption strategy. Successful adopters have AI taskforces (or individuals at smaller companies) dedicated to working out how to get a competitive edge from AI. Use cases include collaboration and alignment, code implementation and review, documentation, tech debt and more.

For a full list of 7 AI productivity tools CTOs need to know about, head here.

Reason 4 – Snowball effect from poorly defined objectives

Agile development is lauded for its flexibility, but when goals are as fluid as water, it's easy to drown. Let's explore low poorly defined objectives can cripple projects, especially in an agile setting.

• Resource misallocation. Unclear objectives lead to misguided resource allocation. It's like blind shooting that backfires, wasting both time and effort.
• The priority shuffle. Agile's flexibility can backfire, causing perpetual re-prioritization that results in team inertia and demotivation. The dilemma escalates from "urgent vs. important" to chronic chaos
• Knowledge debt. Vague goals accumulate "knowledge debt," causing teams to build features without a long-term vision. This debt gets repaid in costly rework when objectives are later clarified.
• Interdependent confusion. In large projects, ambiguous objectives in one sprint disrupt future sprints. This turns sprints into emergency rooms, leaving long-term strategy by the wayside.

When these factors coexist, their impacts are multiplicative.

Teams lose more than just time. It’s entirely possible to lose confidence, and eventually credibility. Stakeholders grow sceptical and attrition rises. 

In the agile world, we have to have clarity on our objectives.

Fixing it

Let’s look at how to fix this in a way that complements – rather than complicates – your agile flow.

• Adopt Agile Objectivity: Adopt a framework that allows for agile flexibility while enforcing the discipline of clear, quantifiable objectives. Use OKRs within Sprints to align short-term flexibility with long-term vision. This approach ensures that agility doesn't become aimlessness.
• Automated Real-time Metrics: Use or build tools that provide real-time tracking of key objectives and outcomes directly in the development environment. This live dashboard keeps everyone accountable and minimises manual check-ins, allowing leaders to make data-backed decisions on the fly.
• Operationalise ‘Knowledge Debt’: Integrate the concept of 'knowledge debt' into your debt management strategy. Document the 'why' behind interim decisions, so future you (or future engineers) can make informed judgments even if the original context is lost.

These strategies should help resolve inefficiencies related to vague or changing objectives and enable your people to execute with precision and speed.

Rounding up

Alignment – or lack thereof – sits underneath many common reasons engineering teams stall. Without a fully aligned team, everything else suffers: productivity wanes, technical debt accumulates, and even the best of tools can't fully bridge the gap. 

True alignment is crucial for progress in engineering.

That's precisely why I built Stepsize AI with my team.

It observes your activity across various systems of record, including Slack, Linear, Jira, and GitHub, and then delivers what matters to each team, manager or stakeholder.

The end result? Teams that are not just aligned in theory but in practice, substantially driving up productivity, reducing unnecessary meetings, and creating a better engineering culture.

I’d love to hear your thoughts on how this could work for your use cases. Check out Stepsize AI here.