There’s a great scene, towards the end of the film American Sniper, where Bradley Cooper’s character has to take a shot from over a mile away from his target.

But the point is, there’s a long time between the point he takes his shot, and when he finds out if he has hit or not. It’s not like shooting a pistol from 20 yards – you have to wait to see the results of your efforts.

One of the authors who has been influential at the place I work is Jim Collins – in his book Great by Choice, written with Morten Hansen, he describes how you should “Shoot bullets before cannonballs”. What he means by this, is that in a world of uncertainty, full of assumptions, you need to test your ideas [with the market] with small bullets first (i.e. small investments of resource). Wait to see what hits, then go in with your cannonballs when you know what will work (rather than wasting cannonballs early on).

This is a great idea of course – why start a team of 100 people on a project when you don’t know if it’s a good idea or not?

And this is great, when you’re running a startup using a SaaS model and the Lean Startup principles – promote an offering on your site on Monday, check the feedback metrics Tuesday to Wednesday and pivot to a new proposition by Friday, if it’s not working out.

But the issue is that, in my experience in the world of B2B, that feedback mechanism takes more than a week to work. Hopefully you have a great Agile team, producing a minimum viable product as soon as possible, getting early ideas out to customers quickly. And you’re doing everything you can to get qualitative and quantitative insight from those customers. But is this enough information to make a pivot? Do you really know if your bullet has hit home or not just yet? There are a few issues that make this process slower than we’d all like:

1. As mentioned, the speed to get a first version out. The principles of Lean Startup are that you shouldn’t wait to have a fully working version before trying with customers. But I just don’t think you can get accurate, actionable feedback for an idea based on sketches on the back of a napkin. Particularly if you take in to account the points below.
2. Numbers – we’re not making changes to Facebook here. Each new idea isn’t getting seen by 5 billion users. If you have billions or even millions of users, then it only takes a tiny percentage to react to your new offering to get statistically significant data on what you should do next. But what if you only have thousands of customers? Or hundreds? Most of these people have day jobs and won’t have time to tell you whether your new idea for an “Automated Dog Grooming Service” (I heard this a few weeks back) is a good one or not.
3. Money – the true test. Someone looking at your sketch and saying “Yeah, looks pretty good” does not a sound, profitable business make If you want to test if people really like your idea (i.e. they’re willing to give you dollars for it), then you need to start selling it. And that involves sales cycles, proof-of-concepts, purchasing processes and so on. Particularly of course if you’re selling for more than $10 per month. If you want to test whether your $100,000 proposition is a winner or not, you’re not going to find that out in a week.

So these things mean you have to wait for more than a few days to see if your bullets are hitting their targets, before you load up the big guns.

But this is a problem – the issue is: when do I know if my bullets have missed? I started the project months ago (fired the first volley – not sure how long this analogy will last…), and I still don’t know if I’m shooting in the right direction or not? What do I do? Change target now? Wait and see? What if it takes 6 months, a year even before I know if the idea is good? Do I just carry on regardless?

This is a real problem – kill a project too early, and you could be clutching defeat from the jaws of victory. Keep it going unnecessarily and you’re just burning money (and teams, that could be used elsewhere for more profitable gains). But how do you decide, when the evidence isn’t in yet?

I think there’s a few things you can do in fact:

1. Good ol’ fashioned product management. Is there a market for this product? People paying money for similar services? Who’s the competition? I love this tweet: https://twitter.com/justinkan/status/614904706624720896 – there’s basic work to be done showing that there’s a market for your service, people are willing to pay for that service, that the incumbent isn’t unmoveable and so on. If you have confidence you’re addressing an existing market, with a better product, in a environment where you have reach and brand recognition, you should have confidence of success that can take you through the low points.
2. Being honest about the feedback you are getting. With a new idea I, personally, think that unless people are chewing your arm off to get something (“This is magic!”, “How did I survive without this!?”, “Please can I give you some money for this?”) then you need to be pretty cautious and honest with the feedback you are getting. Often we know a set of close customers really well, and this is great, but those close relationships can make it hard for said customers to tell you the truth about your new idea. You present something to them, you can’t help but convey your sparkly-eyed enthusiasm for this new miracle of software that you’ve created, and few people have the heart to tell you what a piece of crap it is. So despite the issues outlined before, you do need to be taking your idea to as many people as possible as early as possible. But more than that, you need to listen to them, encourage “constructive” criticism, and when 19 out of 20 people respond with “Meh”, hear that, and think about drowning your puppy.
3. Hedge, intelligently. Have a fallback, be thinking about alternatives, alternate uses for the technology and so on. If you do get to, say, 6 months in to your project, and are beginning to have serious doubts, this shouldn’t be the first time you’ve thought about a bad outcome. Really you should have been considering the bad outcomes from day 1. I like to think of this as “Schrödinger’s Cat Thinking” – you don’t know, on day 1, whether the cat is alive or not, but you should be thinking about what you do in either circumstance. Perhaps there’s a way of developing the product so that it can be easily switched to another market? Or sold off to someone if it doesn’t fit with your business? If you’re a sniper, waiting for your shot to hit home, you should have a plan of what do do next, regardless of the outcome [by the way, I know literally nothing about such military affairs, so I have no idea if this is the case or not – but it seems reasonable]. In essence, if you decide to pull the plug, you should be ready to go with “What next?”, not sitting there shrugging.

But the reality is that, even if you take these things in to account, you’re likely to have a long period in limbo, not sure whether you’re on to a winner or not, not sure whether to kill the project or not.

And this is where leadership comes in. What effect would it have to go to a team and say “Well, things are looking okay – I’m not sure, but there’s a chance we might kill your project at some undefined point in the future. Still, off you go – make progress!”? All you’re doing here is undermining that team, leaving them in a state of uncertainty, likely to seriously damage productivity.

Instead that team needs your support and backing. And they need to hear it from you. Yes, you may be only be 60-70% sure that what you’re doing is going to pan out, but internalising that uncertainty is part of your role – it doesn’t help to transmit your worries to everyone around you. So if you have a 6 month period where the project is in the balance, better to assume that project will succeed – and push it hard – than to dither and create a self-fulfilling prophecy of failure..

A place I used to work, perhaps 10-12 years ago, had (what I think, now) was a strange custom. Every Monday morning the whole company would get together to go through everything. There were around 70 of us, at the peak, and we would all stand around from about one-and-a-half hours going through sales, marketing, development, ops, specific projects and so on. This was tiresome, to say the least. I had this slight sense of dread each Monday morning as 10am loomed, and we all started shuffling to the space “around the boss’s desk” (difficult with 70 of you..).

Anyway, thinking back, the main points I remember from these meetings were:

1. There were pastries every time – and you had to position yourself well, to get the “good ones”. Other than the specific point I make later, this is almost the only thing I remember from, probably, 100-150 hours of my life.
2. The reviews from sales consisted of trying to sell (to us), why the latest lead was inevitably going to lead to untold riches. When this didn’t happen (months later), rather than updating us on “I’m afraid that dead cert didn’t cross the line”, instead these deals were conveniently forgotten. After a year, you begin to get cynical..
3. Development – every week the same: “We’ve done an extra week of work on product X. Nothing really to show”.
4. Ops – incredibly, almost every week, the update from ops wasn’t about servers, our technical infrastructure etc, but almost always seemed to be about desks and chairs – that we were getting new ones, that we were re-arranging the current ones to suit new starters, that we’d “had a rethink about the larger desks” and so on. An extraordinary waste of time.

So we’d endure these sessions every Monday morning – it filled the time until lunch – at the end of each session would be the CEO’s rousing finale, where he’d fire up the troops ready for the week ahead. This generally wasn’t great and, to be fair, how do you come up with something new week in week out? Particularly in quite a slow moving business where not a whole lot happened each week? “Go dev team, continuing to fix that next tranche of indecipherable bugs!!”.

But, there was one speech which I do remember, and still remember to this day. We’d been going through a tough period with our investors, questioning our progress, our organisation, our management (how dare they, with their millions of dollars sunk in to us ), and a lot of people in the company, who’d been trying to make progress on product, marketing and sales, had had to spend a lot of time dealing with requests for information from these people. We knew we had to do it, but still. We’d also had some issues with journalists, and analysts too, not quite seeing our way on things – whether they were right or wrong, again, it’s an exhausting process, trying to keep these groups happy when you have a day job to get right.

And it was at one of these Monday morning meetings that the boss stood up and gave a 20 minute oration on the topic of “Better to be in the arena fighting, than in the stands criticising and judging”. This is a relatively well known topic, and subject of such speeches, but it was such an impassioned 20 minutes, painting a picture of us in the company, fighting lions and gladiators (he had a background in the classics) whilst the petty and ill-informed outside world looked on, passing judgement without understanding the problems we faced (fighting lions!), that for once, it did genuinely rouse the company, and left us all leaving that meeting with just a bit more energy for the week ahead.

There were, in fact, two things that I took away from this event:

1. The value of a good speech, particularly in terms of timing. Our boss knew exactly what the feeling was in the company at the time (that we were all trying really hard to do something, and were being ground down by external sceptics), captured that feeling and spoke about that topic, rather than something else. And, as I say, I think a background in Classics helps!
2. The subject itself – I strongly agree with the principle that, it’s better to be having a go at something, however well or badly, making mistakes, learning from those mistakes, trying new things, than to be on the sidelines, passing comment.

It’s why I’ve never been a fan of journalists or critics – far better to be a musician, putting out an average album, than a journalist critiquing that album. What positive contribution do you make!?

So, a great speech, given at the right time, with a point-of-view that I strongly support. I just wish I could remember something else from the 100s of hours spent standing around, chewing on Pret-a-Manager almond croissants (definitely one of the “good” pastries)…

What is the essential difference between “Management” and “Leadership”? Are these, basically the same thing – “The stuff you do when you get “Manager” in your job title somewhere? These are both such vague, all-encompassing terms (perhaps the worst job title for this is “General Manager” – it sounds like you “just do stuff” not even specific to a particular domain!) that it can be hard pin down any sort of definition of each. Also note, very few people have “Leader” in their job title, a lot of people have “Manager”. Why the difference?

Completely ignoring job titles, which just confuse the issue, I’ll argue that these are very different modes of operation. In essence, Management is about “Things”, and Leadership is about “People”. This is a mild overstatement, but the difference is important.

What does this mean? To understand this difference, it’s useful to think about some examples of the way the word “management” is used, outside the office – terms like “Pain management”, “Waste management”, “Estate management” and so on. All of these describe jobs that involve looking after processes, performance indicators, co-ordination of activities and so on. I.e. “Things”.

Leadership on the other hand is a very different job. Again, various descriptions such as “Taking people on a path they wouldn’t otherwise take” and so on, but these can be a little vague. The definition I like, from a course I did last year is “Vision, Team and Communication”. It’s about providing a clear vision of where you’re going, getting the right team together and communicating that vision well. I.e. it’s about inspiring and leading “People”.

And I think, therefore, that the skills needed are very different. Leadership isn’t about carefully managed processes and KPIs – measurement, recording, project management. That is all in the arena of “Management”. It’s about inspiring people to believe in what you’re doing, communicating clearly what the path is, and so on. You can be fantastic at managing projects, keeping on top of KPIs and so on, but wanting when it comes to inspiring the people around you. Similarly, you might be amazing at bringing your team along with you, and inspiring people – but absolutely hopeless at managing a project, and keeping on top of things.

I think this is why “Manager” in a job title can be unhelpful. It’s often used to denote someone who is being asked to do both activities – “Manage” everything that’s going on in a given domain in the strict sense, but also “Lead” a group of people. And these tasks are very different – with different skill sets. I’d even suggest these are quite different personality types – management is more attuned to the Introvert type, lovers of process, people who find satisfaction in making sure everything is “In hand” and under control. Leadership is perhaps more appropriate for an Extrovert type – someone who enjoys telling a story, working with people (rather than spreadsheets), talking.

But there’s an advantage here – and why I think so few have the word “Leader” in their job title. Management is, I think, quite a specific role – you need to assign people to these roles to make sure things get done. “Project Manager” is the classic version of this – a specific job needed to make sure projects are run properly (i.e. “Managed”!). But Leadership is something that can be done by anyone. You can have a new graduate come in, inspire the team with some incredible ideas for the future (“Vision”), help get the team coalesced and flying (“Team”) and is constantly re-telling the story of what’s happening internally and externally (“Communication”).

Unfortunately, many job titles are confusing. “Product Manager” is a classic example – though some of this job is about “Managing the product”, really a lot of it is about leadership – inspiring a team to work on your ideas and communicating internally and externally about what’s being done.

So it’s something worth thinking about – regardless of your job title, are you really doing a job of “Management” or “Leadership”? The former is relevant to many people (and the chances are, they do have “Manager” in their title somewhere). But I’d suggest the latter is appropriate for everyone.

Another slightly abstract post today, though based on very real and pragmatic problems. When working on a project, where there are 100s of different options for things you can do and you’re drifting in to option paralysis, often a manager will use a deadline (for example, an event, or a customer demo) as a way of forcing the team to make decisions and progress – aka “helping the team to focus” :-). But I’ll argue that you can go one step further, and just use completely arbitrary deadlines to help bring focus. Why wait for an event in the real world?

I’ve previously mentioned Good Strategy/Bad Strategy by Richard Rumelt – a great book on how to create meaningful and useful strategies. One of the core stories in the book is around the moon landings in the 60s: scientists were worried about how they could design a landing vehicle to land on a unknown surface that would survive. This was leading to paralysis where the teams couldn’t progress because there were just too many unknowns in the problem. So, what did the director do, to aid progress? She set what was, essentially, a completely arbitrary constraint, that the moon surface would look pretty much like a desert in the US. What the director was doing here was setting a completely arbitrary constraint – how could she know if the eventual lunar surface was anything like the surface of the desert? Couldn’t she just have been so wrong that all of the work was a waste of time? My view is that it doesn’t matter – what she gave the team was a way of moving forward, getting something done. Maybe it was a waste of time, but better to do something – and likely learn some things along the way – than just do nothing, paralysed by uncertainty.

There’s another more subtle theme that goes through this book as well – constraints over time. The concept of “proximate objectives” (i.e. setting a short-term objective) relies on a constraint in time – “We are going to achieve this thing in 6 months” (or a year, or whatever). Why 6 months? Why not 9 or 10? Why should your timescales be based on half of the time it takes for the Earth to orbit the sun? Again, completely arbitrary.

One of the great things we’ve implemented at Redgate is the concept of release trains – see http://blog.red-gate.com/success-weekly-releases-occasionally-dont-release-release-wednesday/ for some more info. This is a method for running an Agile project and representing a backlog, by splitting the work for a project up in to separate carriages on a train. Each carriage represents a block of work which will be released. But here’s where it gets interesting – each block of work (or “carriage”) is a pre-decided length. For one project, this is 6 weeks – so every block of work carried out as part of the project needs to be done in 6 weeks. How can the team work with such artificial constraints? What if the work that needs to be done is 8 weeks? Or 4 weeks?

Here’s why this works so well – if you’re adding a new feature to a product (let’s say it’s “Allow user to register on the site”) a large part of what the product manager and team have to decide is “How big is this piece of work? How long are we going to take on it?”. And this is a problem – how do you make this decision? How do you assess the importance of the work and stop at the appropriate point, before moving on to the next feature? This is a real problem – before you do the work, you don’t really know how important it is, so when will you know when to stop?

Now, if we set, what is admittedly, a completely artificial length, to the piece of work we do – say 6 weeks – what does this give us? At least:

1. A roadmap – we can draw the train (with carriages) on a piece of paper and say, “Here’s what’s happening in the next 6 months – we’re going to do four blocks of work on features A, B, C and D” (four blocks of 6 weeks is approximately a half-year, with time off for good behaviour). So everyone knows what’s coming, internally and if you like, externally. NB: We’re still Agile – nothing is set in stone, we can adjust based on feedback and so on. But you are giving visibility to those that want it.
2. It forces good decisions in a team – if you want the feature to do everything, then it won’t look beautiful. Or vice-versa – but not both. For example, for our feature “Allow users to register on the site”, well it could integrate with all sorts of authentication mechanisms – Active Directory, 3rd party mechanisms, your own, but it’s not going to do all of those in 6 weeks AND have wonderful usability. The team has to start making grown-up trade-offs – is one sort of authentication okay? Is usability more important that types of registration? Suddenly the discussion is about the real value of each piece of work to customers – and this is good.

I.e. it gives product managers visibility and a great tool for planning, and it gives teams a mechanism for making good decisions. But primarily it stops option paralysis – conversations like “Well, if we did make it look nicer, wouldn’t that be great?” or “Why don’t we add these other three authentication systems as well?”. It allows you to get on with something, do it, finish it, measure its success and move on.

Of course there’s a risk – what if, by just adding that one extra feature, you did the thing that every customer wanted and that made the product a success? Well, may be, but two things:

1. How would you ever know that, upfront? You can’t.
2. Opportunity cost – what if the next carriage on the train was the thing that unlocked customers? You’ll never get on to it if you don’t get the current carriage completed.

So I’m a fan of completely arbitrary deadlines – IMHO, don’t even bother looking for a real deadline (or other constraint), just set one at an artificial point in time. The benefits out-weigh the cognitive dissonance caused by working to something that seems somewhat random.