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.
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.
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 ๐
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):
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!
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 Farleyrecently. 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.
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.
I regularly encounter start-ups and organisations whoโve built things they didnโt need to, when there are many readily available platforms they could have used instead.
A key principle of doing less, better and being able to stay small, is to only build whatโs unique to your proposition.
Creating software can be like buying a pet โ it’s a big commitment. It’s not just about building it; you also have to care for it constantly. This includes making sure it stays safe, up-to-date, and working smoothly – much like tending to a garden to prevent it from becoming overgrown (and why, with 3 young kids, thereโs not much more than grass in mine ๐ ).
Hereโs some examples of common system components, where numerous platforms exist which you can use instead of building them yourself ๐
๐ Content Management ๐ Identity & Login ๐ eCommerce ๐ณ Payments ๐จ๏ธ Social features โ๏ธ Admin panels ๐ Search
While these platforms aren’t free, they’re often far more cost-effective than building and maintaining your own. They also have modular components and integrate via APIs and SDKs, allowing you to maintain control over the unique aspects of your service.
And unless you’re in the business of providing one of these platforms, they’ll also do it better than you.
Trade offs? There will be limits to what the platforms can do, you’ll be beholden to their roadmap and costs can rise significantly at scale. However, it’s typically quicker and cheaper to start with using common platforms and only consider building something yourself when you can really justify it.
Before adding any new feature to your product, first check if there’s an existing solution that eliminates the need to build it yourself ๐
Many jump in too quickly before nailing down the problem they’re solving.
You have an idea, have you defined your proposition? Who are your users? What problems are you going to solve for them? Whatโs your value proposition? Is anyone going to pay for it? How have you validated any of this so far?
Somewhat ironically as a technologist, I spend a lot of my time advising people not to build thingsโฆ yet.
It’s crucial to validate as much as possible around your assumptions and your users, first.
What’s the best way to do this? Speak ๐ฃ๏ธ to your potential customers! Do user research, surveys, and market studies ๐. Use tools like Marvel or Figma for quick and easy prototyping.
Remember, this is all quick and relatively cheap (unlike building software!)
Even then, you may /still/ not need to build something yet. Laura Pomfret (Financielle) ๐ธ and Holly Holland (Financielle), the co-founders of Financielle are a great example. They started with a WhatsApp group, selling PDF guides and spreadsheet templates to help women take back control of money. The Airbnb founders started by renting out air mattresses in their living room!
Before considering building something for real, ask yourself: Have I really validated enough? It could save you more than just time and money.
