Tag Archives: ego

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 ↩︎

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. ↩︎