Leadership Uncategorized


The more often people ask “When?”, the less likely you are to be working in an Agile organisation.

If we’re building a software product using an agile model, then every day we’ll have the latest version ready, with all the most important features complete and the team working on the next most important. The choice is always with the organisation, they can launch what they have, or wait for another iteration.

If the conversation is always “When will it be finished?”, then you are thinking about projects, about things that don’t evolve with feedback, and most of all, something that has a fixed view of what’s considered good.

It’s much better to get that initial launch out early, and start to update quickly based on the actual activity of real users. That validates the assumption you made early on, or disproves them really quickly. It means that you waste the smallest amount of effort as you correct quickly.

I usually find that Marketing are a major asker of “When?”, there’s often a longer lead time with some channels, and they want to plan in a fixed way to account for these timelines. They aren’t able to move away from these processes, so you have to find some ways to mitigate the questioning.

There’s two techniques that I’ve found to be helpful (and that also work with anyone asking When?).

First up, move away from specific features. Switch up the conversation, and show what problems are being solved for your users. This lets you focus more on the overall value of the package, and sell the solution rather than any particulars that might not yet be complete.

Second, if features are important, take the conversation back to what’s already been done. Show off everything that’s available today. If you are experimenting with features before they reach prime-time, then you can use some that are nearly ready to go. Give the Marketing team early access, particularly to winning experiments that you are working to turn into full features. With the range of access, they’ll be able to slot features into various materials depending on their own lead time needs.

Do these, and you’ll start to wind down the “When?”, and get back into the agile swing of things.


Not Fit for Purpose

When we work in a agile fashion for long enough, we always almost encounter the “Not Fit for Purpose” complaint. I’ve certainly seen it in a number of different contexts, and depending on your organisation, you might be stuck with it almost every single day.

When we work agile, we aim to launch new iterations early and often. We are very clear that our product will not have every single feature from day one, and that it may never have every single feature a user could desire. We recognise the cost of adding and maintaining each new feature, and balance it against the benefit it brings.

“Not Fit for Purpose” raises its head when you encounter someone stuck in a closed mindset, usually a person who is looking for the perfect solution, rather than something that is better than they have today. This can really drain excitement from a new product, so you need to counteract it quickly and decisively.

Your first move is to force the complainer to get specific. Generic grousing like this is easy to do and hard to address as you are aiming at a moving target. Any justification you bring will be countered like a reed moving in the wind. Instead of letting the negativity frame the conversation, take it on. “What do you mean by that?”, “What exactly is the issue?”, “What specifically are you missing?”.

By taking the vagueness out of the conversation, you are able to squash the nebulous negativity, and move towards positive problem solving. Even asking these questions can kill off a lot of general negative feeling. People who are just complaining for the sake of it will often just go away when put on the spot like this.

Now you get to start unpicking some more genuine concerns. For the perfectionist, they may be unhappy that some features aren’t available yet, or they aren’t complete. Combat this by showing progress, and setting expectations based on the previous progress you’ve made. This challenge quite often comes from people who think in terms of projects, chopping and changing from different streams of work. They aren’t thinking in iterations, and they think that v1 is also v last.

As you’re working in an agile fashion, you’ll have previous launches to show (even if they were initially just to internal users). You’ll also have your prioritised list of future work to show. This progress is a powerful tool. If your naysayer is also your decision maker, then you can give them control by agreeing what is “Good enough”, launching when you hit it, and continuing to iterate to make it great. This is also a good point to specify and experiment, so that “Good enough” decision is driven by data, not the feelings of the perfectionist.

Also, you can use the “Is it better than what you have now?” approach. This brings you away from abstract perfection, and down to the brass tacks of the real day-to-day. It’s hard to say no to something that’s better than you have right now, even if it’s not what you want in the long run. Again, I’ve seen lots of complaints just go away when the complainer sees what they are getting is an improvement on the current status-quo, even if the gap to what they hoped for is still large.

Finally, you might have a purpose mismatch. The complainer has a different vision, or a misalignment of what’s important. What they want is not what you are going to give them. For these people you need to hear that concern, and address it by reminding them what the goals of your product are, and what the problems are you are going to solve. With this mismatch, sometimes you just have to fire a customer. If they are never going to be a good fit, then it might not be worth the effort to serve them.

To recap, “It’s not fit for purpose” is a poisonous phrase, often deployed by those who aren’t able to embrace the agile journey. You need to counter this actively to stop them sucking the energy out of your powerful change:

  1. Force them to be specific, drive out any real concerns so they can be addressed, and silence the serial complainers immediately.
  2. If it’s just “not perfect”, then show your pace of progress, and what’s coming in your next iterations.
  3. Next, agree “Good enough”, and use an experiment to put data into the decision.
  4. If your purpose doesn’t align, don’t hesitate to fire the customer, putting half your effort into 1% of your users is not a winning strategy.

Agile methods are simple, but that doesn’t mean they are easy. Watch out for these types of challenges and combat them effectively to drive significant high-value change and launch truly impactful products.

Coaching Leadership

Technology is a Creative Endeavour

I work with a large number of technologists, I build a lead teams working at significant global scale, solving problems with technology.

If you are outside of this world, it’s easy to get lost. Why is it so hard? What’s going on? Why does it take so long?

The exciting thing about technologists, and about software, is that they are constantly involved in a creative endeavour. It’s a cross between science and art, with a whole load of emotional and personal considerations thrown into the mix.

Think about how hard it can be to build a house. A dozen trades, maybe more. They follow a plan, but flex from it when difficulties arise. It’s creating something from nothing, but you’re probably following a pretty standard path. You know houses, you can see them. They’ll be used by a well known number of people, in a standard way. It’s pretty predictable, but there are still difficulties, overruns and variations from the plan.

When we’re building software, we have some of that certainty, but not the majority. We may not be sure what the problem is we’re solving. Will it be used by ten people or ten million? Who’s going to try and break it, and what if we get half-way done and decide to do something else?

If you are leading a tech team for the first team, part of a digital transformation or an agile experiment, it can be bewildering. Engineers, computers and logic suggest predictability, certainty and rigid planning.

Instead, stop and reflect. If it’s worth creating a new technologic solution, then it’s novel, unique and new. You can’t plan to the day, but you must let the creative process occur. Set goals, go after outcomes. Figure out ways to launch early to learn, then course correct.

Don’t look for perfect. No art is perfect. It’s done, and it’s out in the world, changing people and bringing joy.

Set expectations like this, and you’ll be an exceptional technical leader. You’ll empower people, bring real change to the world and never waste time search for misplaced certainty.