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.



There’s not much that tests your communication skills as quickly as building furniture. It’s something that can seem simpler than it actually ends up being. It needs more than one person to do effectively, and those people usually have different levels of experience to bring to the activity.

Firstly, you should read the instructions. Look at all the stages and each detail of those steps. This brings out any assumptions and smooths them over. This first activity starts to balance out those gaps in experience.

Next you arrange your tools and make sure you’ve got everything you need. This lets you agree some terms upfront, building your shared language and ensuring early understanding of term.

Then you talk early, before starting a particular action. You are sharing expectations early, rather than hoping that someone figures out what you want after you’re already straining under the load of a heavy lump of wood. Trying to share meaning in stressful situations is hard, and often just raises the stress.

So, to communicate well you should:

  1. Uncover assumptions early
  2. Agree terms and their meanings
  3. Set expectations before it gets stressful

This wont just help you put furniture together more easily, it’ll make you more effective in any situation where you need to communicate something important.

Coaching Leadership


The desire for perfection often stops us taking that first step. Once we accept that nothing is perfect, that’s it’s valuable to learn from an initial effort, and that “better than before” is so much better than nothing, then we are able to get moving and start making positive change.

The next phase is to return to that effort and to refine what you’ve done. In technology, it’s a key way that we identify we’ve moved away from a project focus and into the more powerful product mindset. Things are never done, we can always refine them to make them better.

This is true whether it’s a product feature, a technical solution, a series of meetings, or even something like a blog post!

When you think about your refinement approach, you can try to explicitly carve out some chunks of time for improvements. This can be a tough sell, especially if your improvements aren’t as immediately visible as the next bright and shiny thing. When I sit down to write, I certainly find it easier to work on a new article than go back to an old piece to freshen it up.

Instead, you can build your refinement in to your process. Whenever you are working in an area, if you spot something out of place then take a few minutes to leave it in a better place than it was before. Cleaning as you go gives you lots of quick improvements, without big investments in tracking, remembering what you were going to do, or continually fighting to carve out this time.

For example, I’ll write and edit in a couple of passes. I schedule posting a few weeks in advance. When a post goes live I’ll check it out with fresher eyes, and use that as a chance to clean up any rogue words or phrases that aren’t as clear as I’d thought they were. If I share links, or link back to an old article, then I’ll scan through and check for updates then. It’ a much easier process than sitting down for an hour to just do edits!

So, once you’ve gotten started, and put your initial efforts out into the world, look out for opportunities to slot in improvements whenever you are back in the area. Make it routine, it’ll be easy, and you’ll quickly see the compounding benefits of these small refinements


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

Action Triggers

When you want to start taking steps towards change, but you are finding it hard to get going, then set yourself an action trigger to help kickstart the effort.

This is a simple mental plan to execute an action when you encounter a particular situation. It’s a great technique to help you build up or change a habit, by preloading some decisions in our mind.

It’s a simple technique. First of all, pick what you want to change. For example, you might want to show more gratitude when someone does a great job.

Next up, get specific. Exactly when and how are you going to do this? If it’s too loose, it won’t be effective in changing your behaviour. When we’re praising people, it has greatest impact close to the good activity, so you might set an trigger of “When I see someone asking a great question in a meeting, I will actively thank them for that input”.

This is good because it’s a specific situation (great question), and a specific action (thanking them). As you’ve already made this decision, you take away the concern of what “a great job” looks like, and how you’ll “show more gratitude.

When you make it easy, you are more likely to take these actions and change your behaviour. The complex processing that exhausts your Type 2 brain is dealt with ahead of time, letting you shift these changes to the quick and lazy Type 1.

If you want to be even more likely to be successful, then either say your trigger out loud, or write it down. Make the commitment public and it give you even more impetus to succeed.

This technique is not a panacea. It will only work if you want to make a change, and it will only help move you towards good behaviours. It’s not going to change your direction 180 degrees, and it’s not going to shift you fundamentally.

To make some positive change and build energy in your flywheel, setup a couple of action triggers to preload some complex decisions and make it simple when the situation occurs.