Leadership

The Last Responsible Moment

We’re often tempted to plan as much as possible in advance and make decisions way before they are actually due. It gives us a sense of security and risk mitigation and preparedness. I urge you to stop doing that.

To understand why, follow this chain of reasoning:

  1. When making decisions, more uncertainty leads to higher risk.
  2. The more knowledge we have, the less uncertainty remains.
  3. (No matter how much you know today, it’s safe to say that) Tomorrow you will know more than today.
  4. Hence every decision you will make tomorrow (next week, next month), will be more informed than the ones you make today.
  5. That’s why making decisions as late as possible lowers risk.

The knowledge you’re accumulating can be pretty much everything, e.g. about:

  • Yourself
  • Your team
  • Your project
  • Your product
  • Your business
  • Your competition
  • The market you’re in
  • The legislative environment you’re dealing with
  • And so on…

Agile software development and Scrum have this way of making late decisions built into the process. What matters most is at the top of the backlog or is worked on during a sprint. Everything else isn’t important for now and most decisions related to everything else don’t need to be made yet.

Keep this in mind. Keep questioning yourself whether decisions need to be made already. And if not, don’t make them now. And maybe don’t even bother to think about them yet.

Fighting Scope Creep with the Techcrunch Test

No doubt scope creep is one of the biggest dangers to any software project. The possibilities to build everything are just too tempting and too often we think perfectionism is a virtue. Before we realize it, we’ve lost focus, got off track, and blown up the project far enough to be in trouble.

The Techcrunch Test (as I call it) originated for me during my work for a social local mobile app. Part of the job was to prioritize features properly and – at least equally important – find the right sizing of each feature. Thanks to iterative and incremental approaches it’s not necessary to be complete and perfect on a feature the first time around. However, cutting down features enough on this first time is often easier said than done. More often than not there were heated discussions about what needs to be done and what can safely be cut out and de-prioritized.

Techcrunch, one of the world’s most popular technology blogs, was one of the publications we were waiting to appear on. We knew we would have achieved something if Techcrunch would have started to write about us. (If you’re working in a different space, you should replace Techcrunch with a publication or authority that matters for you.)

The Techcrunch Test helps getting brought back down to earth whenever you’re tempted to build too much or set wrong priorities. For a feature X – or a part of a feature – ask youself and your team the following question:

If 3 months from now we will have failed and Techcrunch was to write about our failure, would Techcrunch say the following:

“If only they had introduced feature X they would have become successful!”

?

I promise you, in most cases the answer to this question will be No. And especially if you’re doubting the importance of a feature anyways already, the answer will almost always be No.

It’s that simple. Once you’re at the point of using the Test, pretty much nothing you’re putting into this question will appear important enough to be built afterwards. And there you go: don’t build it. Instead, focus on what really matters, focus on what sets you apart, focus on what is at the core of what you’re trying to achieve, focus on what brings you forward.

Focus on what Techcrunch would praise you for, some day.

The Best Damn Ship In The Navy?

Recently I’m trying to soak up lots of material about Leadership. After stumbling upon It’s Your Ship: Management Techniques from the Best Damn Ship in the Navyagain and again and now have it gotten recommended by a colleague as well, I finally decided to read it. I actually picked up the Audible audio book since there wasn’t a Kindle version available and I needed it immediately and take it on a trip.

Bad news first:

  • The US Navy as a context for a book using real-world examples seems refreshing at first, but it’s getting more and more difficult to digest. At least for me as Non-American, turned out to be a big turn-off eventually.
  • The author keeps emphasizing his own work and contribution and achievements as opposed to talking about him and his team. Given that leadership actually means working with your team, this is very surprising and ended up being another annoyance for me.

On the upside, the book contains a lot of good examples and useful advice to become a better leader. It’s not exactly innovative and doesn’t bring up points nobody else did before, but it’s a good and easy to read (or: to listen) summary of much an aspiring leader can start doing immediately. AFAICT at least, I’m aspiring myself.

“If all you give are orders, then all you will get are order takers.”. Agreed.