Honesty in an industry which loves being lied to

Posted on by under Business

Humans are a complex and contradictory bunch. We wish the impossible to be true, the complex to be simple, and mistake slow progress for inaction or reversal.

We are much more easily seduced by a singular, all encompassing answer1 than the messy, tangled chaos of reality.2 We love thinking that affecting change is straight forward. That if you did ‘This One Neat Trick’ then everything would be fixed.

We conflate simplicity with clarity, and are confident in the person delivering that message. We assume competence correlates with conviction. After all, if they didn’t know what they were talking about, they wouldn’t be this forthright and direct.

We use their words as salves for our concerns, to solve the big, thorny, complex problem we’re facing. We hope that some might even rub off on us.

And if we’re lucky – the illusion breaks, and we see that the Emperor has no clothes before any damage is done.

Back in 2017, I found myself needing to have the hardest conversation of my professional life.

At the time I was working at OrangeBus, as Scrum Master on a large account to develop a social care platform.3 This would allow people with additional needs to use their Direct Payments to independently book appointments, etc, for the assistance they needed.

As with all development, design assumptions are made with the best intentions. As people start to use the service, we find out if those assumptions are correct.4

During a few months of tweaks and changes, it is noticed that the pilot users are booking appointments in excess of the funds they have available. This was due to a user’s funds being deducted after the appointment has occurred, rather than when it was booked.

It was agreed that a sensible change would be to trigger the deduction at booking. A story was written up, estimated, and brought in to a subsequent sprint.

Work begins, and is picked up by a relatively junior member of the team. After a couple of days, questions start being asked about why it’s taking so long to get ‘this simple ticket’ in to test. The Dev Lead decides to pair with them, and they’ll speak to me if anything unexpected turns up.

Lunchtime rolls round, and the Lead catches me as I’m heading out to grab a bite to eat. Something weird is going on. The code is not performing in the way we’re expecting.5 We agree the best course of action is to keep investigating, and to shuffle some tickets around to make space.

Come end of day, we still have no idea what’s going on. I decide it’s best not to drop that particular bomb right before logging off for the night. In stand up, we try to walk the line between transparency and not spooking the PO/Client, with some success.

But by the end of the sprint, things are looking pretty bad – for two reasons. The obvious technical one, but also the relationship with the client. We’d been through some rocky patches before6 and there wasn’t much trust.

It’s the sort of situation you dread. Having to explain to someone who thinks you’re shit is only working with you because of decisions higher up, that it isn’t you and your team that are the problem, but the product they’ve spent the last 18+ months building.

And not only that, but we have no idea how long it’ll take to fix.

What do you do in that situation?

Do you try to bullshit your way through? To project confidence and simplicity in the face of the unknown? Trying to buy time, sprint by sprint, and hope that you’ll grind out a solution just fast enough so they don’t pull the statement of work?7

Or, do you tear down the facade?

Those of you who worked with me at the time, or saw my AgileNE talk many moons ago, will know the answer to what I did.

During the latter’s Q&A, my favourite question was on how to deal emotionally with that sort of situation. At the time, my answer was; “I drink a lot”.

A better answer is that honesty, transparency, and the truth are more important than perceptions and facades. Trust is built through someone experiencing you choosing to ‘do the right thing’. To not try to blag your way through.

To differentiate between your confidence in your skills and being able to lead the way out, versus pretending you already know the route.

We would never have solved the problem by hiding it, by pretending that what ended up being six months of rework to the core part of the system would be finished in the next sprint.

  1. i.e. Populism – deport minorities, the poor are feckless, addiction is a personal moral failure, etc ↩︎
  2. Ronald Reagan is attributed as saying “If you’re explaining, you’re losing” – and look how that philosophy turned out… ↩︎
  3. This was an account OB inherited when bought by Capita, and I was put on the project about a month before the pilot launch ↩︎
  4. And this is why waterfall will always cost more, take longer, and produce worse outcomes ↩︎
  5. With ten years – and many lunches – of distance between then and now, I can’t remember the details of what the issue was. What sticks in my mind is realising that we had no idea how the system seemed to be allocating money correctly, when the code to do so demonstrably wasn’t. ↩︎
  6. Some of which I handled better than others ↩︎
  7. Something they’ve already done, twice. The first being at the end of the first day you met them ↩︎

Wearing a suit doesn’t make you immune to peer pressure

Posted on by under Business, Tech

It seems to me that there is a point in a person’s life, career, and/or seniority, where following the crowd stops being called ‘peer pressure’ and starts being called things like, ‘reacting to market sentiment’.

Admittedly, I am a bit too young1 to remember the dot-com bubble popping. At the time, I was running around my primary school playing field, blissfully unaware of anything outside my little corner of the world. I have a vague memory of a school friend’s Dad losing their job2, but as my Dad worked for the Ministry of Defence, it didn’t really affect me. Actually, I was much more interested in the occasional rolling roadblock flanked by MoD Plod3 than anything even remotely compooterz related.

I say this to admit that I don’t know what it felt like in the run-up to that crash. Neither, really, what it was like in 2008. By that point I’d started at Uni, now more interested in computers than roadblocks, I was still too busy running around.

What I do know is what the industry has felt like since 2010, when I got my first tech job.

Smartphones, and Web2.0 fully usurping “the old internet”. The rise and domination of Facebook, and their purchase of Instagram. Twitter and The Arab Spring. Uber4, Silkroad and the first Bitcoin spike ($21 high!), and how Smart Contracts would change the world. The Gamification of everything. Silicon Valley’s brief flirtation with an abundance mindset. The release of Google Cardboard, Oculus, and the HTC Vive5, and how VR was going to change the world revolutionise global entertainment. The second, third, forth crypto spikes. Various rug pulls and straight up theft. Bitcoin ETFs, the Winklevii. Later, NFTs being a thing, and then very much not. Chatbots going from natural language search of dense knowledge bases, to the solution for every website.

The elevation of Will MacAskill6 from interesting philosophical curiosity, to the billionaires’ favourite guru. The release of GPT-3, the pandemic7 and remote work hiring boom. GPT-4, Claude, DeepSeek, and the positioning of LLMs as proto-AGI, and the ensuing arms race.

This period was full of useful progress.

For all their many, many, faults – Facebook was better social media than what came before. Uber did genuinely improve the experience of ordering taxis.8 Bitcoin, and crypto more broadly, was excellent for bypassing incredibly expensive money transfer systems like TransferWise. This is incredibly useful for migrant workers wanting to safely and reliably send money back home to their families. And, obviously, really useful as a pseudo-anonymous means of payment for a variety of things.

But something changed, and while I can’t really put my finger on when exactly that was, I feel it was around the time that ‘web3’ starting to be thrown around.

To me, Web3 has always felt like a random assortment of technologies, unified as technology-first tools, all looking for problems to solve. For me this is namely Blockchain, cryptocurrencies, VR, and AI. There may be others you include, or don’t.

VR is objectively cool, but severally limited in practical application. Even Apple, with all their billions, haven’t been able to make it useful9. Blockchain is terribly energy inefficient for transactions when done via Proof of Work, while Proof of Stake has serious trust problems for a supposed zero-trust decentralised network. Transaction costs are insanely high for everyday small purchases, leading to the minimal uptake we see in legit merchant contexts. The continued necessity to cash out into a local currency10, often in large increments to minimise the fee ratio, further compounds the problem.

And then we have LLMs.

LLMs are incredible. While I’ve always enjoyed writing, it’s never been something I’ve found particularly easy. Having what is in effect my own personal sub-Editor running in-browser11 helps me better structure my thoughts, and keep my phrasing clear and simple12. It’s not perfect, far from it, but it is very helpful.

The current generation of LLMs are incredibly sophisticated predictive text, and that is great. Friends of mine with dyslexia, or various other neuro-diversities, or normies who just appreciate a hint every now and again, have found it to be a complete game changer.

I’ve also had particularly positive experiences using Claude to help me think around some problems we’ve faced at the foodbank, such as safe loading procedures. It being able to provide direct links to legislation and best practice documentation is awesome. Natural language search is a hard problem, and these tools make significant improvements on what has come before.

A single technology being sufficiently adept at addressing both of these problems is really cool.

But, it’s also very clear that there is a genuine panic in the industry right now.

Across the board, every sector within the industry is trying to shoehorn “AI” in to their products. I’ve been told stories where devs have been directed to replace existing traceable algorithmic decisions for things like financial eligibility, with a GPT call. That 30% of code must be “AI written” by the end of the year. That all customer service enquiries will be answered by an LLM driven chat bot, with no human approval13. And even that user-provided content should be modified, without their knowledge or approval, before being displayed to other users.

The message I take from this is simple – it’s FOMO.

Companies are looking, top down, at what everyone else is claiming, but knowing that they themselves are struggling to make this work. So surely they must be missing something.

What they’ve done so far isn’t something they particularly confident is right for their business, but because their peers are doing it, they must have found the secret sauce.

Every CEO of every FTSE and Fortune business is singling AI out as the gaming changing tech, so it has to be…

Right?

Back in 2000, if I’d’ve done something I didn’t agree with, just because my friends in the playground did, my teacher would have called that peer pressure. She would have reminded me that just because others are doing something, it doesn’t mean I have to.

That desire to fit in, to not miss out, that if others are doing it surely it makes sense to do it too, doesn’t automatically go away when you leave school.

While part of maturing and ageing is learning how to better handle your emotions, fears, and impulses, periods of high stress can resort to us taking shortcuts.

And having shareholders, pension funds, VC, and big equity firms on your neck is rather stressful indeed.

Building sustainable, deep value businesses requires addressing human-level problems. FOMO doesn’t lead to reasoned responses, it instead prioritises reactive, knee-jerk, responses.

So, remember to take a breath, and remind yourself; “What is the problem I want to solve?”.

I promise you the answer isn’t, “I haven’t spent enough GPT credits”.

—

  1. Although, the increasing grey in my hair and speed I’m approaching 40 may suggest otherwise ↩︎
  2. Also the first person I knew who had a PC at home – and introduced me to Tomb Raider ↩︎
  3. From AWE Aldermaston, carrying surprising little, all under a black tarp ↩︎
  4. I was once asked to provide a cost quote for “the uber of social care”; they didn’t appreciate being sent a link to Uber’s crunchbase page which, iirc, said they’d had over 50bn in funding already. ↩︎
  5. And punching my friend’s ceiling after getting very disorientated trying to stroke a whale ↩︎
  6. No relation ↩︎
  7. No relation… ↩︎
  8. Now if only they treated their employees correctly ↩︎
  9. I do feel there is a genuinely viable usage for Augmented Reality – as a HUD for directions, etc – but all concepts seem to be based around forcing yet more advertising in to your eyes, which, well, who actually wants that? – beyond the people funding the development and paying for the ads of course ↩︎
  10. Or other coins, putting it well above the typical tech literacy of ‘normal’ people ↩︎
  11. I use LanguageTool, and highly recommend it ↩︎
  12. Or, at least as best it can dealing with the chaos that is my brain ↩︎
  13. And this is years after this has already blown up in company’s faces see Air Canada ↩︎

The choices we make, and the results we get

Posted on by under Charity

A point I make to teams I work with is that what we do affects real people. It doesn’t matter whether that person is buying a Christmas present1, reporting workplace negligence2, or making sure they and their kids don’t go hungry3, making that experience easier or harder has an impact.

The reason for this reminder is that we4 often abstract ‘People who use our products’ in to the much easier and less clunky term ‘users’. And yes, while this is done for reasons of convenience rather than anything nefarious, it can still lead to us forgetting that there is a real person at the sharp end of the decisions we make.

In turn, this impact is regularly referred to in other terms, such as ‘pain point’ or ‘nudge’5. Again, while done with no negative intent, this can further separate ‘us’ and ‘them’. After a while, ‘them’ almost become ‘things’ we act as if we have dominion over.

At this stage, it becomes very easy to believe your assumptions are actually facts. Assumptions in and of themselves are not objectively good, or bad, but they do need validating. It’s a very helpful shortcut to jump over validation, especially if you already – sincerely – believe you know the result.6 It’s exactly here where our biases can wreak havoc, and do serious damage.

You may know that I’ve been involved with Gateshead Foodbank since 2018 in various roles, and/or that for the last 18 months or so I’ve been spending a lot more time there as part of a career break.7 A year ago, I was invited on to the Board of Trustees, with a focus on Data/IT, and to support efforts in reshaping the charity so that we can continue to support those who need us, for as long as we are needed.

Since being founded in 2012, we’ve fed over 100k people. While the vast majority are in receipt of Universal Credit, that doesn’t mean they are out of work. A good chunk of the people we feed live in households where one or more adults are working, but their wages still need to be topped up by UC.8

We provide a week’s worth of food, per person, plus toiletries, and our typical visit rate is ~1.5 times. That means that over 80% of people we feed only need to visit us once or twice. We work closely with Citizen’s Advice to identify and solve underlying financial issues people may be facing; the most common cause being that they are not receiving benefits which they are entitled to. I have enough fingers to count those who have needed us more than ten times.

About one third of the people we feed are children.

Of the families we feed, 60% of them have three or more children, and whatever assumptive rhetoric people may wish to throw at adults, these kids have no choice, no power, and no agency.

They are going hungry because of the decisions made by others.

Trussell9 have done extensive research to uncover the main causes of people using foodbanks, and say the following:

The design and delivery of the social security system remained the most significant driver of low income for people referred to food banks. The vast majority (87%) were in receipt of a means-tested social security payment, including three quarters of people (75%) in receipt of Universal Credit. In the general population fewer than one in 10 people (9%) were in receipt of Universal Credit.
—Trussell – Hunger in the UK, September 2025, p.76

In my professional life, this sort of research result would be clear-cut – this process causes problems, and we need to fix them. No amount of “the user’s an idiot and is doing it wrong!” can hand wave away 87%. When I talk about systemic issues, this is the sort of thing I mean.

The correlation between the two-child limit, and the demographic of people relying on us, is strong and clear. I hope that it goes without saying that a family of five requires more food, more soap, and more loo roll, than a family of three. It should be a profound embarrassment to the country that this continued for eight long years after George Osborne made the decision to enact the limit on the users of benefits.

In the budget last week, it was announced that the two-child limit will be removed in April 2026. During the announcement, I was at the foodbank giving food to people who needed it. When we found out, the relief in the air was palpable. A few people cried.

It is projected that 450,000 kids will be lifted out of poverty through this choice, and will stop going hungry through no fault of their own.

There are always choices which can be made. Some good, some bad. Some outcomes can be foreseen, others cannot. Sometimes there are compounding factors and emergent behaviours, or there aren’t, and it’s pretty straight forward. Maybe the impact is so tiny no one notices, or so large that it feels trite to describe.

If the result of your choice is not what you intended, you can choose to change it.

Fingers crossed, we see double-digit reductions in people visiting the foodbank, and the kids of Gateshead stop going hungry due to the decisions of others. It also reminds me that…

[E]conomic injustice will stop the moment we want it to stop, and no sooner
–George Orwell – The Road to Wigan Pier, 1937, p.139

—

While not the purpose of this post, if it has given you pause for thought, please set up a regular cash donation to your local foodbank. Cash is best because we can use it to pay for fuel, leccy, and buying in items we don’t get enough of.10 While need hopefully reduces with the removal of the two-child limit, we’re a long away from that celebratory day that we’re no longer needed and can close.

—

  1. Fruugo (2022-2024) ↩︎
  2. Safecall (2018-2021) ↩︎
  3. Gateshead Foodbank (2018-Present) ↩︎
  4. read: software people ↩︎
  5. The latter I particularly enjoy, as it just reminds me of that Monty Python sketch; know what I mean? ↩︎
  6. Or, if you really don’t want to be proven wrong ↩︎
  7. The TL;DR being that I wanted to do something more visibly and immediately rewarding – and stopping people from going hungry is very immediate indeed. ↩︎
  8. That is to say, their employer does not give them enough hours and/or pay to feed themselves ↩︎
  9. fka ‘The Trussell Trust’ ↩︎
  10. There is always enough pasta – and beans. There are never enough sanitary products, or pet food, or cereals. ↩︎

There is no Step Two, or “What Comes After MVP?”

Posted on by under Business

An incredible amount has been written about Agile and MVPs over the last 20 years, yet the majority focuses on the first step of a process, the output of which is stated to be a minimum viable product. This mismatch is likely a side effect of most literature being focused at organisations transitioning from out-dated practices and adopting something “new”[1]or desperately clinging on to the past in the case of SAFe – I’ll get to that article, eventually. There is much less writing dedicated on what to do when you’re up and running, with the general guidance being to reduce cycle times.

The conflation of process and product is confusing, often resulting with the view that if you simply “do agile” then the product will take care of itself. Often an MVP is the conclusion, with minimal discussion on what an MVP is outside of an expansion of the initialism. Let me give you an example.

About 5 years ago I was involved in a pitch to an academic publisher who wanted to completely rebuild their website. They made it clear in the tender that they did agile, and that they wanted to release the MVP alongside the celebration of the company’s birthday which kicked off on New Year’s Day.

My section in this pitch was to discuss this “MVP”, and I took the opportunity to lay some ground work.

  1. What does MVP mean to your business?
  2. What can you do without, or copy from the existing site (e.g. content)?
  3. Given your 1st January deadline, when do you actually expect to release the new site?
  4. What are you looking to achieve?

The answers were what you’d expect. MVP = Minimum Viable Product. Everything was to be new (code and content). To release a) when the fireworks went off at 00:00 on New Years Day, or b) over Christmas, as long as everything is finished. The aim of the project was to do the project, but any further “why” was elusive with no cohesive view shared, not even metrics.

Rather than doing agile, they had changed their terminology and kept everything else the same. MVP was the new word for a release, the solution was predefined (a complete lift-and-shift), and the scope was locked in. It’s waterfall, plain and simple.

In this instance there was no MVP, there was a project delivery. Even if delivery was managed through sprints, and some tweaks made based on stakeholder feedback, it still won’t have been an “MVP”.

Why? Because an MVP requires an hypothesis to test.

The purpose of an MVP is to find out if you’re right, as quickly and cheaply as possible. If there is no hypothesis, there is no product to access the minimum viability of.

I joined Safecall because they had a particular strategy they wanted to validate, and needed a Product Manager to shepherd it in[2]In the interest of full disclosure, this was started before I joined the business. I turned up towards the end of the initial delivery from an external supplier, but had been in post nearly 6 months … Continue reading. Would companies buy software from an expert provider with 20 years experience in whistleblowing services, but very little in building software?

Given the company’s lack of experience in the area, the last thing anyone would do is to write a cheque for several million quid to build a whistleblowing platform from scratch. As such, we used pre-existing products built to handle entities related to individuals within businesses to build our MVP. I also took the step early on to purposefully keep every page and interaction as simple as possible. Simple in this context means few screens, little conditional logic, and little fluff. For the first release, for the vast majority of Safecall clients, the platform operated as a secure means to receive and transfer confidential information, and little else.

We gathered feedback from existing clients who had been granted access to this new system, as well as through the sales process. The most common feedback was that “it’s a bit simple” – considering it isn’t “what are you doing, this is rubbish” I take this as a pretty big win. Over the last 2 years, the platform has become a core part of the service we provide and we have fleshed out some features, added some new ones based on new hypotheses, and reworked some areas where our previous assumptions were proven wrong, or we discovered unforeseen consequences. Ultimately, what we’ve proven is that, yes, companies will buy software from industry experts, and that it isn’t only “software companies” that can play this game.

An MVP is two things, it is a product, and a method of testing an hypothesis. In this sense MVPs are unlike any other part of the empirical, iterative nature of doing agile as it isn’t just a piece of research, it is also the thing you sell. In this sense, they are the most expensive way to ever prove whether you’re right or wrong.

The answer to “what comes after MVP?” is another hypothesis, one based off of the new data you have now been able to collect. This new hypothesis and new MVP can take many forms, from scamps to research aides to A/B tests, but your aim should always be to do just enough to clarify your assumptions, and test your hypothesis. Or, to put it another way:

Simplicity–the art of maximizing the amount of work not done–is essential.

https://agilemanifesto.org/principles.html


And then you do it again.

Notes

Notes
↑1 or desperately clinging on to the past in the case of SAFe – I’ll get to that article, eventually
↑2 In the interest of full disclosure, this was started before I joined the business. I turned up towards the end of the initial delivery from an external supplier, but had been in post nearly 6 months by the time we’d made our first release in March 2019

Kill your product

Posted on by under Business

Last time, I ended by summarising that to progress you need to quickly iterate, and threw in a link to the wiki page on Fail Fast. A couple of posts ago I was waxing lyrical about bass players, and ended saying “Print that 7″, and move on.“. The theme here is obvious:

  • Do something
  • Pay attention to what happens
  • Use your new knowledge to do the next thing

When speaking about doing agile, especially when migrating away from outdated methodologies, people often focus on the individual side of it, the most obvious being differences between Command-and-Control Project Management versus Servant-Leader facilitators.1

But from a Product perspective, hubris is often king. We all know Product people who think they are the second coming, are absolutely indispensable, and have some sort of perfectly unique take.2

When you consider that an agile approach to Product requires you to run experiments and accept that you’ll make mistakes in order to learn, this is in direct conflict with corporate cultures which reward (perceived) perfectionism by way of arrogance, bravado, and the safe space afforded by feature-and-revenue led project plans. This can lead to people who have been moved in to Product positions3 as part of a transformation piece deciding that while everything else is changing, they don’t need to.4

The other part is the wider side – what are others doing?

If you consider a market of similar software products, there will be multiple companies and competitors, each making changes and learning from successes and failures. While no one has perfect knowledge, other people making mistakes for you is extremely cost-effective. And much like how you will look to take advantage of your competitions’ weaknesses, they will do the same, as their aim is to take money out of your pocket and put it in theirs.

If you’re able to learn from the mistakes of others, as well as your own, and act on them quickly, then you’ll have a better chance at staying ahead.

To fully learn from these collective mistakes, Product needs to do something particularly painful, they need to go out with the intention of killing their product. They must view their creation through the lens of a competitor, and rather than make excuses, they must pick it apart, highlight its flaws, and ruthlessly remove them.

You need to get over your own bullshit, because if you don’t kill your product, someone will gladly do it for you.

  1. Scrum Masters, Agile Coaches, etc ↩︎
  2. Ed: You really want to open that door, huh? ↩︎
  3. Often from previous “decision making” roles, such as a member of SLT, Programme Managers, Project Sponsors, etc ↩︎
  4. I’ll cover this in greater depth in a future post, for now let’s put a pin in this and move on, but do keep it in mind. ↩︎

Time to live

Posted on by under Business

Businesses who conduct any form of software development are increasingly “doing agile“. Typically this means they’ve replaced traditional waterfall project management within their “IT department” to probably Scrum or SAFe[1]For the sake of brevity I’m skipping over why SAFe is a step backwards and only entrenches problems. That’ll need a post all to itself., within smaller and larger orgs respectively.

A few people will go on a course, and on return set up a Jira / VSTS board, book a morning meeting titled “Stand Up”, and the release schedule is changed from Quarterly to Fortnightly overnight. On the surface, this is a step in the right direction[2]It isn’t..

If agility is a concept restricted to just your technical teams, and not your business as a whole, then you’re not actually “doing agile”.

A conversation I routinely have with friends, (ex)colleagues, and the like, is about how tired they are because of the level of extra effort required to affect change within their organisations. This is across all shapes and sizes, big/small, paid/voluntary, public/private.

The conversation will eventually meander through two topics:

  • How long it takes to make a change – start to finish? From concept, to delivery, not just development.
  • How much resistance occurs along the way? Do they feel that it is their own personal determination that makes change happen, instead of something which is embraced?

Complaining about work and feeling helpless isn’t new, and given that it is the plot for three of the biggest films of 1999 I’m not pretending like this is some sort of revelation. However, the frequency of answers[3]My sample is self-selecting because this conversation doesn’t come up in relation to organisations where the answers are “no time at all”, and “very little” being “a long time, could easily be a year or more“, and, “oh, so so much, I’ve given up more times than I’ve failed, let alone succeeded” coupled with the clear frustration expressed is something which leads me to believe that while this isn’t by any means rare, or novel, it’s actually an accepted, expected and purposefully constructed scenario by the organisation itself.

This is often done under the presumption that enough approvals and controls will ensure certainty of two things:

  1. Nothing bad will happen
  2. Only good things will happen

A fundamental aspect of doing agile is embracing uncertainty. To embrace uncertainty you need to be able to make changes quickly, and learn from them.

To make changes quickly, individuals need to be empowered with authority and responsibility delegated. They must be able to make meaningful change without arbitrary approvals and sign off. Equally, they must be responsible for the impact of those changes. That responsibility must be against quantitative targets, not subjective opinions. If they fail, they fail – now learn from it, and try again.

If your organisation can only do things quickly when the house is on fire, and you use executive authority to bypass red tape, then you have systemic issues which need to be addressed. Because if they aren’t, then you better be absolutely right in every decision you make, otherwise you’ll lose to a competitor who can move faster than you and found out the mistake long ago.

It can’t be left up to the determination of individuals.

Notes

Notes
↑1 For the sake of brevity I’m skipping over why SAFe is a step backwards and only entrenches problems. That’ll need a post all to itself.
↑2 It isn’t.
↑3 My sample is self-selecting because this conversation doesn’t come up in relation to organisations where the answers are “no time at all”, and “very little”

Progress

Posted on by under Me

I read somewhere once that you should regularly take a moment to reflect.

To purposefully take time to see where you’ve been, where you are now, and where you’re going. To consider what went well, what didn’t, and how those experiences can be used to improve situations in the future.

To use your new experiences to make better decisions, and to allow yourself to take some pride in the accomplishments won.

The reasoning behind this is clear – if you’re always down in the weeds, you can get lost. Some people will fixate on the negatives, and miss the positives, others will do the opposite. Give yourself space to breathe, and to attempt to understand the full situation.

Within a project, or product, these decisions are quantifiable and should be measured. We can choose to invest in our deployment pipeline to reduce release costs and time. We can refine copy in a marketing campaign to improve conversion.

It gets much more complicated when you try to apply the same process to a more complex situation, like a person.

Within your own professional context – i.e. your career – the process becomes almost existential. Do you continue what you’re doing? Are you happy where you are? Will this get you to where you want to be? Do you even know what that is? Does it matter if you don’t?

Many years ago, an old boss (and mentor) once asked me to imagine a situation where we discovered a fence crossing a road. The job would require us to remove the fence. He asked me what I thought we should do before we removed it.

I focused on the practical aspects of how it would be removed – “We’d need tools to take it apart.” – rather than questioning why the fence was built in the first place. I later found out that this is called Chesterton’s Fence.

Don’t just look at the good and bad – try , too, to understand why we’re here, and why it happened.

Then you can make better decisions on what to do next.

JFDI

Posted on by under Me

Sid Vicious couldn’t play bass, and only recorded parts of a single bass track on Never Mind the Bollocks.

Sandy Miranda can play bass, and in 2006 released a studio album, nine 7″s, three cassettes, and a CD.

Omar Rodríguez-López got bored of playing bass at 12, started playing everything you can imagine, and has written, released, and/or produced more music than I can possibly imagine.

Actually, that award goes to Buckethead.

Even so, the Sex Pistols are generally considered as one of the most influential British bands. Causing the formation of The Damned and The Clash (Paul Simonon also couldn’t play bass, at first) with both bands playing their first gigs as openers for the Sex Pistols. Then, as the apocryphal story goes, a gig at Manchester’s Free Trade Hall on 4th June 1976 had attendees who would end up founding Joy Division, The Fall, and The Smiths.

How does a band with a bassist who can’t play bass have an influence like that?

Or, a better question – how do have the confidence to join, or even start, a band when you can’t play an instrument?

Sid’s snarled expression helps, you just fucking do it. Because who’s stopping you?

A more restrained statement may be that everyone must start somewhere. Edin Blyton didn’t wake up one day and decide that she was going to write 762 (slightly problematic) books. $FamousFootballer wasn’t born being good at SportsBall. The chef’s on in the Michelin Guide didn’t go from microwave mini-pizzas to whatever it is Heston is doing right now I mean come on.

You may have a vague notion or hope that, some day, you’ll fill a room with your creations, but thinking that success is only that – and nothing else will do – will destroy you.

It is a rather trite statement, but you must see how perfect is the enemy of good, and that it’s actually much more important that you do the thing, rather than obsess over it.

That’s how you learnt every skill you have, and that’s how you’ll continue to improve. Oh, and you’re probably not destined for greatness, and that’s ok! Literally no one is! Again, something doesn’t have to be perfect for it to be worthwhile, or the right thing for you to do.

Even Sid Vicious got better overtime, and by the time he died was…alright? I guess. I mean, he wasn’t John Entwistle – but who is?

Don’t let perfection stop you. Don’t spend more energy talking yourself out of doing something than it would take to just do it.

Print that 7″, and move on.

Release, repeat.

Foolish is he who builds his house on an outdated tech stack

Posted on by under Scrapbook

This was originally scribbled, in haste, in April 2015, where it has sat, to be published now without change.

Production works.

Production pays your wage.

Don’t fuck with Production.

In recent months I’ve been noticing that what I thought to be true is not necessarily the case. There is a certain belief within our industry that while ‘new is awesome’ new should also be feared, new is unknown, new is untested, whereas Live is – that – Live. We know what it does, we know its problems and its limitations, and more importantly it’s been proven and is currently responsible for everything that is going on.

Burning it all and starting again is simple when you have no vested interests, when you’re not making money, when you’re still looking for that breakthrough. But, once that has happened, you can’t be scared to re-write, to re-build, to retread old ground, and potentially kill the goose.

We work in an industry that proclaims desires to fail-fast, to pivot, to constantly improve, but is also terrified of bucking the tread due to our continual reliance, nay – obsession, with hockey sticks. We tweak, we change, we iterate, and we lurch based on hunches and hopes, on superstitions and gut-instincts towards what we believe will work, and if we’re fortunate enough to get the right thing at the right time we end up being one of the ten percent that ‘succeed’ we probably didn’t get there by a single plan, an single vision, and a single tech view that took us from launch to exit in 19 months.

Most of us have changed; most of us have had bad ideas; have wasted time, effort, and development resource; we’ve wasted money, hardware, Clouds, and careers on foolish notions and frankly terrible thoughts (I’d in fact put a serious amount of cash on the claim that virtually no one has ever got it right first time) and if, when, we do finally gain traction, we need to – eventually – undo all the errors we made.

A tech stack is exactly that, a stack.

Stacks are inherently disorganised, messy,

Fuck Your Good Idea

Posted on by under Scrapbook

This was originally scribbled, in haste, in May 2015, where it has sat, to be published now without change.

The road to hell is paved with good intentions, or so the saying goes, and never has this been truer than in software development. Everyone knows best, everyone fights their corner, and everyone stops anything actually being achieved. The irony of this post is not lost on me, my intent is something different, I’ll concede judgement to the reader, but I’m likely to fail.

Clarity in vision, with the supporting determination and stubbornness, is what is required to inform people that their idea is not just misinformed, it’s actually detrimental to the continuation of the company.

Everyone champions ‘fail fast’ and in the very next breath caveat its rules, instead of really trying and failing, we continually tinker and delay for months until we have a perfect test and so we have too much invested to allow ourselves to objectively fail. We lose our vision, we lose our sense, we don’t want to watch our baby suffer. We shield ourselves from our possible failure, only to fail even harder.

We are human, we think emotionally – and that is why we are ineffective.

If only we could burn it all and start again.

Baggage is a part of life, it’s a part of love, and it’s part of creation – you will be bias to your own opinions, dismissive of others, and, well, we’ve all heard of “it’s not a bug, it’s a feature”.