Addressing performance issues is something many shy away from, often putting it off or hoping it will go away.

The sooner you do so, the more likely there’ll be a positive outcome for very everyone.

The longer you wait, the more difficult it becomes.

If it’s clear things aren’t working out then you need to act decisively. Don’t let it drag on.

It’s not only about the individual; it’s letting the whole team down and sets the standard for the level of performance considered acceptable.

“𝘞𝘦 𝘯𝘦𝘦𝘥 𝘰𝘶𝘳 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘦𝘳𝘴 𝘵𝘰 𝘣𝘦 𝘣𝘶𝘴𝘺 𝘤𝘰𝘥𝘪𝘯𝘨”

I still regularly come across this mindset. Not with any ill-intention. Developers aren’t cheap, so naturally you want them to be productive.

Whenever I do, I’m reminded of this meme (image created by Sebastian Hermida).

So this is a reminder that with software development…

𝗧𝘆𝗽𝗶𝗻𝗴 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗯𝗼𝘁𝘁𝗹𝗲𝗻𝗲𝗰𝗸 🐵⌨

Development is about a lot more than just being heads down hammering out code – it’s about problem-solving, understanding user needs, designing scalable solutions, and ensuring that what’s built is truly valuable. Rushing to code without seeing the bigger picture leads to missed requirements & re-work, technical debt and buggy software.

It actually slows things down more than it speeds them up 🐌 🚧

Developers should be involved in the full end-to-end delivery process, not just the coding bit:

🔍 Understanding what we need to deliver, and why

🧪 Quality Assurance (you mean you didn’t test it before you threw it over the wall to QA?)

🚀 Shipping! Getting things out to customers before picking up new work

🤝 Collaborating with each other and other disciplines

Collaboration is a key one. When developers pair with each other or folks from other disciplines, it speeds up the process by reducing feedback loops and capturing issues early, and fosters shared understanding and ultimately, better solutions.

Having developers engaged more widely might seem counterintuitive if you’re focused on keeping them “busy” with coding, but it’s the best way to get the most out of their time.

Why are so many software projects late? Estimation (and how we use it) is often at the heart of it.

Humans are naturally optimistic. We overestimate how well things will go and underestimate the time required. It’s a well documented phenomenon:

🤞 Optimism Bias: Our tendency to believe things will go better than they likely will.

🗓️ Planning Fallacy: Underestimating time required, even when past experience tells us otherwise.

Secondly, even with careful planning, we can only account for what we know. As well as software development being inherently complex, as time progresses, unexpected factors always emerge: shifting priorities, new challenges, team changes – the “known unknowns” as Donald Rumsfeld infamously put it.

𝗖𝗮𝗻 𝘆𝗼𝘂 𝗴𝗲𝘁 𝗯𝗲𝘁𝘁𝗲𝗿 𝗮𝘁 𝗲𝘀𝘁𝗶𝗺𝗮𝘁𝗶𝗻𝗴?
Yes, we can avoid common pitfalls and improve our estimation practices. But they are still likely to be optimistic because of the reasons above.

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

– Hofstadter’s Law


𝗗𝗼𝗲𝘀 𝗔𝗴𝗶𝗹𝗲 𝘀𝗼𝗹𝘃𝗲 𝘁𝗵𝗶𝘀?
Agile embraces uncertainty, such as breaking down work into the smallest possible pieces and delivering value early and often. But it doesn’t eliminate the challenge of longer-term planning.


𝗗𝗼𝗻’𝘁 𝗯𝗼𝘁𝗵𝗲𝗿 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝘁𝗵𝗲𝗻?
Not at all. Organisations need to plan. Without long-term planning, you can’t set realistic budgets, allocate resources & people, or prioritise efforts. The trick is learning how to plan effectively, even in the face of uncertainty.

In my next post, I’ll share how I’ve approached longer-term planning successfully.

If you’re looking to drive change in your organisation, 𝗲𝗹𝗲𝘃𝗮𝘁𝗲 𝘆𝗼𝘂𝗿 𝗰𝗵𝗮𝗻𝗴𝗲 𝗮𝗴𝗲𝗻𝘁𝘀:

🔎 Identify them – look for the people who are most on board with the changes you’re trying to make, the most proactive and unafraid to challenge the status quo.

💪 Empower them – give them a seat at the table, involve them in initiatives, elevate their voices. Don’t be afraid to break hierarchy in doing so.

🛡 Support them – protect their time, don’t overload them.

The new leaders in your organisation may already be there

The UK’s Research and development (R&D) tax relief scheme has long been a vital resource for tech companies, offering substantial tax relief. Created to encourage investment in R&D, the scheme allows small companies to claim back a percentage of their expenditure on qualifying activities. However, the recent crackdown on fraudulent claims, tightening of the claims procedure and additional scrutiny on all claims is raising questions about the effectiveness of the scheme, leading to growing frustration in the tech sector and many to question if it’s becoming more trouble than it’s worth.

Fraud and abuse: a growing concern & increased scrutiny

The scheme has been plagued by issues of fraud and abuse. According to a recent BBC article Errors and Fraud have cost the taxpayer £4.1bn, and another recent article from Dan Neidle at Tax Policy Associates, states R&D Tax Specialist Green Jellyfish are guilty of £100m fraudulent claims alone.

The has led HMRC to ramp up its efforts to detect and prevent false claims. They tightened their claims procedure in 2023 and have hired an additional 300 inspectors since 2022.

Within my network at least, it’s clear this is having an impact, with many reporting a significant increase in their claims being questioned, delayed and rejected. It’s caught a lot of organisations on the back foot.

While the crackdown is undoubtedly necessary, it’s also exposed the complexity of the scheme and the subjective nature of the scheme’s requirements, and the increased scrutiny has made it more difficult for companies to navigate the claims process.

The issues with the scheme: complexity and subjectivity

One of the significant issues with the R&D tax relief scheme is the subjective nature of its requirements.

According to the UK Government’s R&D tax relief guidelines, to make a successful claim, a company must demonstrate that their project:

• Looked for an advance in the field.
• Had to overcome scientific or technological uncertainty.
• Tried to overcome this uncertainty.
• Could not be easily worked out by a professional in the field.

What constitutes an “advance in the field”? How significant must the “scientific or technological uncertainty” be? Who qualifies as a “professional in the field”? How hard does something need to be to say it couldn’t be “easily worked out”?

Ah but helpfully, HMRC do have more detailed guidance. Behold CIRD81910, and CIRD81960 for further guidance for software. A quick glance at these documents reveals that they are highly technical and not particularly user-friendly (it appears none of Government Digital Service‘s skilled content designers had a hand in drafting this guidance).

Even with these guidelines, the answer to whether a project qualifies is frequently (as is oft’ the case when you ask a software developer a question), “it depends.” The CIRD81960 guidance for software itself acknowledges these difficulties, and I could write a whole article on the cases for and against the eligibility of software development to be considered R&D, ranging from most of it to very little.

This complexity and subjectivity poses a key risk: differing interpretations between HMRC inspectors, potentially resulting in legitimate claims being unfairly rejected.

Increased burden on companies

Previously, companies could rely heavily on R&D claims specialists to handle much of the work involved in submitting claims. However, with the heightened scrutiny now applied to nearly all submissions, companies are needing to provide far more detailed descriptions of their R&D activities.

While R&D claims specialists can assist with navigating the claims process, they typically lack technical experience and certainly lack the knowledge needed needed to accurately identify which aspects of your software development involve genuine technical uncertainty.

This burden is increasingly falling on the tech teams within organisations, who must now invest significantly more effort into their claims, often resulting in weeks of back-and-forth between technical staff and supporting R&D claims specialists.

Nervously awaiting legal precedents

As many organisations that previously relied on R&D tax relief are finding their claims rejected, it’s pushed some into financial difficulties. Consequently, more are being challenged in court, and these cases are likely to set precedents that will shape future interpretations of what qualifies as R&D.

In the meantime, many other organisations are anxiously awaiting the results of their first claims submitted since rules changed in 2023 and all the new inspectors came on board.

The outcome of these court cases and recent claims could have significant implications, not just for the companies involved but for the entire UK tech sector.

(By the way, previous successful claims are not home and free, HMRC can go back and review claims up to 4 years old and there are recent examples of where organisations have received tax relief and then been asked to give it back).

The need for a rethink

While improving and simplifying the guidance might offer some benefit, the real solution may lie in a complete overhaul of the scheme. Tax incentives that support the creation and growth of innovative new businesses are undoubtedly valuable, but it’s becoming increasingly apparent that this particular scheme may no longer be fit for purpose.

There are certainly at least, questions to ask about the the feasibility of the scheme, given the growing cost and effort required for HMRC to manage it effectively and prevent fraud, the increased burden on organisations to submit detailed claims, and the rising uncertainty over whether those claims will be accepted.

An incentive you can’t rely on?

Despite HMRC’s claim of “making R&D easier for small companies,” recent developments have made the scheme far more difficult to navigate.

With increased scrutiny, a much greater burden for making claims and greater uncertainty as to whether claims will be accepted, many tech companies are finding it increasingly difficult to benefit from the scheme.

If tech companies can no longer rely on the R&D relief scheme, it ceases to be an incentive.

A common misconception is adding more people will speed things up. Often this can lead to only marginal gains and 𝘮𝘢𝘺 𝘦𝘷𝘦𝘯 𝘴𝘭𝘰𝘸 𝘵𝘩𝘪𝘯𝘨𝘴 𝘥𝘰𝘸𝘯 by exacerbating existing inefficiencies.

Here are some of the common reasons why 👇

🚧 Key person dependencies – bottlenecks on particular individuals.

🤖 Lack of automated testing – resulting in lengthy (and error prone) manual testing required for each release.

🧩 Complex code – significant effort often required even for small changes.

🎯 Lack of clear prioritisation and focus – trying to do too much at the same time and regularly shifting priorities meaning everything goes more slowly 🐌.

❓ Unclear requirements – resulting in a high change failure rate and lots of re-work.

🤝 Lack of collaboration – working as a group of individuals rather than a team – exacerbating bottlenecks on key individuals and roles.

🎓 Low talent density – skill gaps and lack of familiarity with modern best practices, unable to 𝘥𝘰 𝘵𝘩𝘦 𝘩𝘢𝘳𝘥 𝘸𝘰𝘳𝘬 𝘵𝘰 𝘮𝘢𝘬𝘦 𝘵𝘩𝘪𝘯𝘨𝘴 𝘴𝘪𝘮𝘱𝘭𝘦 (edit: added)

If you’re experiencing some of the challenges above, I generally recommend focusing on improving how your existing team operates 𝘣𝘦𝘧𝘰𝘳𝘦 adding more people (which might mean temporarily bringing in specialist support to address specific skills gaps).

The double benefit is in the short term, you get a greater impact from your existing team, and when you do decide to grow, it will increase the impact of any new roles you bring in.

As I’ll regularly say, 𝘥𝘰 𝘭𝘦𝘴𝘴, 𝘣𝘦𝘵𝘵𝘦𝘳 and 𝘴𝘭𝘰𝘸 𝘥𝘰𝘸𝘯 𝘵𝘰 𝘴𝘱𝘦𝘦𝘥 𝘶𝘱.

I recently wrote that we may be reaching a plateau with GenAI development, and the implications for use in business-critical systems, due to their current limitations. But just how precise do they need to be?

🛣 Road Transportation in the UK shows a 99.99996% safety rate [source], with only 0.4 casualties per million miles travelled in 2022. 🛩 Aviation globally is similar, with one accident for every 1.26 million flights in 2023 [source].

🏥 Healthcare, not so great. According to the WHO, 1 in 10 patients are harmed in healthcare worldwide globally, with 1 in 20 preventable [source]. For the sake of the argument, let’s say accuracy here would need to exceed 95% (it’s a lot more complicated than this of course).

Most industries have stringent regulatory safety standards they need to comply with, and the consequences of errors can come with huge financial implications and often criminal punishment.

How accurate are GenAI systems currently?

Studies I found show GPT model accuracy varies widely, from ~50% to ~90% (the higher end generally for more simple tasks) [source].

For healthcare, while LLMs like ChatGPT4 are good at interpreting medical notes, their accuracy drops in complex diagnosis – 93% in identifying common diseases but only 53.3% in identifying the most likely diagnosis, far behind physicians at 98.3% [source]. And 18% less accurate in diagnosis than radiologists in musculoskeletal radiology [source].

As anyone who’s worked on system reliability will tell you, it’s the last mile that’s the hardest. Improvements often face diminishing returns, especially as you approach higher levels of reliability.

This is why, unless there’s another exponential leap, we could still be a long way off from these models being reliable enough to be used in business critical systems (of course this doesn’t mean there isn’t the potential for lots of other valuable uses for GenAI).

I’m regularly asked for my advice on 𝗼𝘂𝘁𝘀𝗼𝘂𝗿𝗰𝗶𝗻𝗴 𝗮𝗻𝗱 𝗼𝗳𝗳𝘀𝗵𝗼𝗿𝗶𝗻𝗴 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴, for both start-ups and established orgs, so here you go👇

Early stage start-ups

For 𝗲𝗮𝗿𝗹𝘆-𝘀𝘁𝗮𝗴𝗲 𝘀𝘁𝗮𝗿𝘁-𝘂𝗽𝘀 unless you’re well funded, I typically recommend outsourcing, as hiring permanent engineers at this stage is a significant cost and commitment. However, big caveats here: I rarely come across founders who’ve had a good experience. If you’re not an experienced technical founder, I’d advise getting a fractional CTO or similar to support you. While an additional expense, it’ll save you money in the long run (a lot of my talk “Navigating the Tech Galaxy for Early Stage Start-ups” covers how to avoid common pitfalls).

Established organisations

The following advice is for everyone else, from later stage start-ups/scale-ups to large enterprise organisations

Account for management overhead

For 𝗲𝘀𝘁𝗮𝗯𝗹𝗶𝘀𝗵𝗲𝗱 𝗼𝗿𝗴𝗮𝗻𝗶𝘀𝗮𝘁𝗶𝗼𝗻𝘀 considering outsourcing – either for perceived cost savings or due to a lack of internal capability – the management overhead is often underestimated. To work effectively, it requires more oversight than an internal team, especially if they’re working in a different timezone. Organisations often pendulum swing from “expensive” internal capability to outsourced/offshore, only to find things take longer, objectives aren’t met, cost savings aren’t realised, and then swing back the other way.

Outsourcing projects

If you’re thinking about 𝗼𝘂𝘁𝘀𝗼𝘂𝗿𝗰𝗶𝗻𝗴 𝗮 𝗽𝗿𝗼𝗷𝗲𝗰𝘁, make sure to factor in for a ramp up period for new engineers to get familiar with the code and architecture (typically around a month) and, for what even might be considered “stand alone” projects, not insignificant impact on the existing team required to support (and notwithstanding whether your architecture effectively supports another team working in the codebase). For these reasons I advise a minimum 3 month engagement and the most beneficial impact over a medium to long term period and an ongoing relationship.

Insourcing

My best experience has been with “𝗶𝗻𝘀𝗼𝘂𝗿𝗰𝗶𝗻𝗴” or 𝘁𝗲𝗮𝗺 𝗮𝘂𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 –  bolstering internal teams with people from external partners, meaning lower management overhead, allowing you to flex capacity based on demand and retain knowledge internally, avoiding dependency on a partner. It won’t work if the supplier is working in a significantly different timezone.

True partner relationship

In all cases, it works best when it’s a 𝘁𝗿𝘂𝗲 𝗽𝗮𝗿𝘁𝗻𝗲𝗿 𝗿𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝘀𝗵𝗶𝗽, not a customer/supplier one. It should feel like you’re all part of the same team. Your contracts and commercial relationships can incentivise this – ensure quality and operational requirements are shared responsibilities, and define mutual obligations to enable effective collaboration.

In-house teams

Overall, my best experience – both in terms of cost and outcomes – has been with 𝗳𝘂𝗹𝗹𝘆 𝗶𝗻-𝗵𝗼𝘂𝘀𝗲 𝘁𝗲𝗮𝗺𝘀, using independent contractors sparingly to flex where needed or fill short-term capability gaps. This approach works best with a broadly even and predictable pattern of demand.

Important footnote: UK R&D Tax Relief Changes

If you’re using or thinking of using nearshore/offshore engineering partners and intending to claim tax credits under the UK R&D Tax Relief scheme, note that since April 2024 overseas expenditure is no longer eligible under the scheme, except for very limited circumstances.

Commitment Language is a concept that focuses on creating explicit agreements and expectations between individuals and teams. I was introduced to it by Richard Halliwell (CEng), but it originally comes from the book Elastic Leadership by Roy Osherove.

Not commitment language ❌
“I *hope* to have this done by tomorrow”
“I’ll *see* if I can do it this week”
“I’ll *try* and get around to it *sometime soon*”

Commitment language ✅
“I *will* have this done by tomorrow”
“I *will* complete it by the end of the week”
“I *will* have it done by next Wednesday”

Yoda says it best, “Do or do not, there is no try”

Initially, I thought “yikes”, this sounds a heavy handed and a way to beat people with a stick when things go wrong. However, experiencing it in practice led to an “aha” moment.

It’s about removing ambiguity and creating clarity. Clear commitments build trust within and between teams and individuals. Everyone knows what to expect, reducing friction, preventing time-wasting, and improving collaboration.

🤔 What if you’re uncomfortable committing to something? Just say so! It’s a great way to flush out what’s actually priority.

🤔 What if you can’t meet a commitment? Just communicate this as soon as possible. It’s perfectly acceptable not to meet a commitment if circumstances change, *provided* you keep everyone informed.

🤔 What if you’re like me and struggle with on the spot commitments? Try a commitment to a commitment. For example, “I’ll get back to you by tomorrow to confirm when I can complete this task.”

Commitment Language doesn’t just change how we talk; it transforms how we collaborate, fostering a culture of reliability and mutual respect.

Where do you start? Have a conversation about it with your team, and review your role responsibilities so there’s clarity around accountability and responsibilities. A good first step (and something I’m a stickler for) is having owners and dates on actions from meetings.

Give it a try!

People experiencing work related burn out often don’t realise it. It can be very subtle – much akin to the “boiled frog” metaphor, where the water is very gradually heated up over a long time and the frog doesn’t notice until it’s too late.

It could be you right now, or it could be someone you’re responsible for. Either way the sooner you spot it and do something about it the better.

What does it look like?

• A feeling of numbness or detachment, with work and even your family.
• Feeling overwhelmed and lacking energy.
• Feeling a sense of failure.
• A general feeling of greyness (hence the overcast image I’ve used for this article).
• Inability to disconnect – finding it hard not to think about work all the time.
• Overcompensating – working even harder, trying to gain a sense of self control with the situation.
• Not looking after yourself – dropping your exercise routines or activities you typically enjoy doing in your spare time.
• Working ineffectively – dropping the practices you typically employ to keep your work and time well organised and instead feeling a sense of urgency to rush work.

As you can see, with many of these symptoms, it’s a vicious cycle – the things you think you’re doing to improve the situation are most likely making it worse.

If you’re relating to this, what should you do?

Speak to someone.

• Ideally, speak to a professional. Many employers have an employee assistance programme (EAP). Call them (or encourage your colleague to call them).
• Speak to your doctor.
• Speak to a friend or family member.

Either way, talk – the hardest part is the first step, accepting you’re burnt out.  Talking to someone is a great way to gain that self-acceptance.

Then, typically in my experience, you need a break. You need to get yourself out of the situation and the vicious cycle it’s creating, and your brain needs some time to recover. Depending on how long you’ve been burnt out this could be a week or even months (so again, the sooner you tackle it, the better).

You also need to get back into your healthy routines (both mind and body), or create new ones, which again, people typically struggle to do if they’re in the situation causing the burn out in the first place.

When you’re ready to return to work, speak to your manager and set boundaries.

Unfortunately burnout is often caused by unhealthy and toxic work environments, so it may also be time to look for a new role.

*Disclaimer: Whilst I’ve supported and witnessed many people experiencing work related burnout, I’m not a medical professional. You should always seek professional advice if you’re experiencing any issues with your mental or physical health.