Author Archives: Rob

Can UK Tech still rely on the R&D Tax Relief Scheme?

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.

Scaling tech teams: it’s not just about adding more people

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 𝘴𝘭𝘰𝘸 𝘥𝘰𝘸𝘯 𝘵𝘰 𝘴𝘱𝘦𝘦𝘥 𝘶𝘱.

How accurate do GenAI models need to be to be used in business critical systems?

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).

Practical advice on outsourcing & offshoring engineering

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

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!

AI is neither artificial or intelligent

Not in its current form – generative AI – machine learning (ML) based chat GPTs & image generation models, and natural language processors (NLP).

It’s not ‘artificial’ because it relies on human-generated data for training, and humans for tuning and calibration. Take image recognition: teaching a neural network to identify cats requires feeding it images, with humans indicating the correct ones and adjusting and tuning the model. Rinse and repeat until the model is reliably able to identify cats.

It’s not ‘intelligent’ in the way we understand human intelligence. It doesn’t learn, it’s trained (machine training would be more accurate than machine learning). It lacks self-awareness, reasoning, and emotional understanding. It operates within the confines of its programming and the data provided to it, making decisions based on patterns rather than comprehension or conscious thought.

That doesn’t mean it isn’t incredible and impressive technology, and it doesn’t mean computers couldn’t become genuinely intelligent at some point in the future, but no nobody has any idea how or when this might happen, and it will not be generative AI that gets us there.

To best understand how it can be applied, it’s important demystify and cut through the hype.

Are you already burnt out?

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.

Quality is a Team Sport

I think it was Jamie Arnold who first introduced me to this phrase.

In engineering teams it’s – sadly – still all too common that Quality Assurance (QA) is the last step in the delivery process. Developers code, then throw it over the wall to QAs to test. Teams working this way typically have a high rate of failure and large release bottlenecks – features and releases pile up, waiting on the QAs. Developers pick up more new work whilst they’re waiting. Bugs come back and developers are now juggling bug fixes and new work.

It’s slow, inefficient and costly!

What I dislike the most is the cultural aspect – the implication that quality is the responsibility of QAs, not the developers who wrote the code.

Quality is a team sport. The most valuable role for QAs* is to ensure quality is baked into the entire end-to-end delivery process. This has become known as “shift-left” – QAs moving away from spending all their time at the end of the delivery lifecycle and focusing more on how we can “build quality in” throughout.

What does this look like in practice?

– QAs involved in requirements gathering and definition, making sure requirements are clear, well understood and we’ve considered how we’re going to test it (inc. automated tests).

– QAs ensure we’re following our agreed Software Delivery Lifecycle (SDLC) and the steps and control we have in place to ensure quality is front of mind.

– QAs collaborate with developers to write automated tests, developers collaborate with QAs on mutation testing, compatability testing, performance testing.

– If there’s any manual testing required, /everyone gets involved/. QAs make sure everyone in the team is capable of doing it.

It’s a much richer role for QAs, and far better for everyone!



*Some teams don’t have QAs. That’s fine, I’m agnostic, as long as everyone cares about quality 🙂

Is it time for an XP revival?

With all the stories I still continue to hear of failed agile implementations (often now called “digital transformations”), it feels like it’s time for an XP revival.

Extreme Programming (or XP) is one of the original agile software development methodologies, and it’s a shame I see it talked about less these days. It was pivotal in shaping agile practices, and crucially, focuses on engineering practices as well as ways of working, which none of the most popular agile methodologies do.

Why didn’t XP take off like Scrum, Kanban or any of the scaled agile frameworks? Two main reasons (my opinion):

  1. Unlike the most popular methodologies it was never commercialised or marketed. There are no (highly profitable) training and certification programmes for XP. It’s the garage punk band of Agile!
  2. It’s harder. Because of XP’s focus on engineering practices, unlike e.g. Scrum or SAFe, you can’t as easily get away with superficially plonking XP on top of your existing processes and not really change anything.

The second point is why, as often as not, there’s often little meaningful impact with Scrum, or especially the scaled agile frameworks (well, apart from adding a lot of bureaucracy to your processes).

I’m continually hearing of failed scaled agile implementations (often involving lots of very expensive consultants). These stories don’t often go public because, well, you’re hardly going to shout about it, but WalMart is one of them, as I found out from Dave Farley recently. How did they fix it? By focusing on the engineering practices over the process! You can watch Bryan Finster‘s excellent InfoQ presentation on it here.

For me personally, Scrum is OK (I’m not a hater). I prefer Kanban, or even ScrumBan – mixing the two. But XP as well. Following XP does not mean you can’t use or be inspired by other methodologies, but without the XP practises you’ll unlikely get any meaningful improvement.

However I’d argue you don’t need much more than XP in the first place, and it’s as good a place to start as any.

It’s time for an XP revival

I’ve watched as first, Scrum proliferated the industry, and then the scaled agile frameworks come along. They’ve had plenty of time in the sun and there’s enough evidence now indicating that these methods are regularly not delivering on the intended outcome, certainly not on their own, without focusing on the engineering practices as well.

It’s time for the latest generation of development teams to learn about XP. It may be over 25 years old now, but that’s also as long as I’ve been working in tech, and whilst the languages, tooling and platforms have changed markedly in that time, the fundamentals have not.

Appendix: What is XP?

For those not familiar, I’ll try to summarise XP’s Values, Principles and Practices, but I’d recommend getting a copy of Kent Beck’s masterpiece Extreme Programming Explained if you’re keen to learn learn more.

XP Values

  • Communication: Clear and frequent interactions within the customer, stakeholders and  team
  • Simplicity: Focusing on what is necessary at the moment and avoiding over complication.
  • Feedback: Actively seeking feedback to continuously adjust and improve the product and processes.
  • Courage: Being bold about making changes, trying new things, and facing challenges directly.
  • Respect: Valuing team members’ contributions and creating a supportive environment for all.

XP Principles

  • Humanity: Acknowledging the human aspect in software development, emphasising respect, understanding, and communication among team members.
  • Economics: The need to consider the economic impact of decisions made during the development process, optimising people, resources and return on investment.
  • Mutual Benefit: Encouraging practices and decisions that are beneficial for all stakeholders involved, fostering a win-win environment.
  • Self-Similarity: The principles and practices of XP should be applied at all scales of the project, from the smallest code block to the entire development process.
  • Improvement: Advocate for continuous improvement of the process, code, and team dynamics, always seeking ways to do better.
  • Diversity: the value of having a diverse team with varied perspectives and skills to tackle complex problems creatively.
  • Reflection: The importance of regular reflection on practices, progress, and problems to learn and adapt.
  • Flow: Aim for a steady and continuous flow of work, minimising disruptions and maximising efficiency.
  • Opportunity: Encourage viewing challenges and changes as opportunities for growth and improvement rather than obstacles.
  • Redundancy: The value of having some redundancy in skills and knowledge within the team to enhance resilience and flexibility.
  • Failure: Acknowledging failure as a natural part of the learning process, encouraging a positive attitude towards learning from mistakes.
  • Quality: Placing a strong emphasis on the non-negotiable importance of quality in all aspects of software development.
  • Baby Steps: Advocate for making small, incremental changes to manage risk and facilitate easier integration and testing.
  • Accepted Responsibility: Responsibilities should be accepted voluntarily by team members, fostering ownership and commitment.

Core XP Practices

  • Sit Together: Promote team collaboration and communication by working in the same space.
  • Whole Team: Everyone who’s needed for the success of the project is a part of the team.
  • Informative Workspace: Create a work environment that visually communicates the team’s progress and status.
  • Energised Work: Encourage working only as many hours as you can be productive and no more.
  • Pair Programming: Two programmers work together at one computer, enhancing code quality and knowledge sharing (add mob or ensemble programming these days).
  • Stories: Use of customer-defined user stories to guide development and ensure the product meets needs.
  • Weekly Cycle: Planning, development, and delivery cycles on a weekly basis to adapt to changes quickly.
  • Quarterly Cycle: Long-term planning sessions that set the direction for the next three months.
  • Slack: Incorporating extra time into schedules to account for the unexpected and foster creativity.
  • Ten-Minute Build: Keeping the build process short to encourage frequent integration and testing.
  • Continuous Integration: Regularly merging all developers’ working copies to the shared mainline several times a day (add Continuous Delivery these days).
  • Test-First Programming: Writing tests before code to clarify the requirements and ensure correct behaviour.
  • Incremental Design: Evolving the design over time as the system grows and changes, instead of doing all design upfront.

Spotify do not use the Spotify Model

Your regular reminder that Spotify don’t use the Spotify model, they never really did.

Don’t attempt to blindly copy practices from other organisations. Especially not big tech like Google, Netflix, Spotify, Facebook etc.

You’ll most likely just end up cargo culting if you do – going through the motions without real benefits.

Especially don’t simply try and graft “Tribes”, “Squads”, “Guilds” and “Chapters” onto your existing organisational structure. The original content on the model was about a lot more than team structures. But this is normally the only thing that orgs adopt.

Frameworks and models are appealing as they feel like a shortcut, but they usually miss the nuances of your specific challenges.

Be inspired, but don’t copy.