Failing fast

Leave a comment

Buzzword bingo

Failing fast.

A phrase you’ve probably heard countless times in agile literature, in books about start-up and lean culture, and in umpteen articles on the Internet. And yes, here I am: yet another monkey on the proverbial typewriter. Fail early, fail often, fail smart. In the software development world it’s safe to say that we’ve all been bonked on the head with the proverbial fail-stick enough times for it to have been driven home.

However, I would like to make an argument that the phrase has become so much of a buzzword that it has lost much of its impact. The phrase is applicable much more widely than within the bounds of your team’s scrum ceremonies. It’s applicable to all work that you do.

As a manager, the bounds of your work are wider than just the code that you and your team are producing. Your job is about doing the most with what you have as efficiently as you can. You are involved in discussions, hiring, processes, and decisions that can all benefit from the mindset and methodology that encapsulates failing fast. Before we look at specific scenarios to explain this further, let’s explore a factory metaphor that neatly demonstrates the core concepts.

A factory

Imagine, if you will, that you are running a factory.

Let’s pretend that the production line produces cars. We’ll envisage an unrealistic scenario where the factory builds the cars completely from end-to-end, starting with the raw materials such as sand, metals and plastics turning up in trucks at the loading bay. At the end of the production line the cars are ready to be sent to showrooms nationwide.

There are some observations that we could make about the production line. The raw materials are very cheap (e.g. sand) when compared to the end result (a car). Therefore at each stage of the production process value is being added. A moulded, painted bonnet is worth more than the raw alloy that it is made of because a process has been applied which added more value. The same can be said about the cost of sand compared to a sheet of glass, compared to working electric heated window.

Therefore the closer that you are to the start of the production process, the more options that exist for what you can do with a given component. For example, even after sand has been made into glass, you could still make a window, windscreen, or mirror. For comparison, it’s a lot of effort to turn a finished car into a motorbike, even if the raw materials and components have many similarities. It’s hard to disassemble and go backwards.

This highlights the issue of waste. The more value that has been added to a component, the less reusable it is, and the more there is to lose when failure occurs. It is more expensive to fail further down the production line. It would be much better to check for defects in the sheet glass immediately after it has been made rather than discovering the defect in an installed windscreen at the end of the line.

If you were running this imaginary factory, I suspect you would be embracing the principle of failing fast in order to prevent issues upstream where they are more expensive to deal with. I find that when imagining the creation of physical products, from cars to computers to furniture, the principle is fairly obvious. But as a manager in mainly knowledge-based work, have you had ideas, projects, and decisions take a long time via lot of effort only to be thrown away?

Will we ever learn?

The ideas factory

The production line that produces software is complex and also much less tangible than the physical products that we alluded to in our example. Additionally, as a manager in a knowledge-based job, there is more to your role than just producing software. There are processes, discussions, prototypes, ideas, happy and unhappy staff, hiring… you name it. There’s a lot on the periphery. Can we apply the fail fast principle there too? I think that we can.

Let’s loop through some examples of areas you will operate in as a manager, and see where the fail fast principle can be used.

  • Software development. This is the area in which it’s likely you’ve heard the phrase used most often. If your production line is creating software, then failing fast is a very good idea. Do the riskiest and least known pieces of work first in order to learn more and fail if you need to. Do technical explorations as early as possible to fail smartly or understand what’s next more clearly. You don’t want to find yourself months down the line with code that you can’t work with. As lines of code increase in your project through ever more thought, time, and toil, the more value that codebase represents, and the bigger the potential waste if it isn’t fit for purpose. Get it right up front. Or even better, get it wrong quickly multiple times.
  • Product ideas. We can now move upstream to the Empyrean realm of product ideas and think about how we could fail faster there, so we don’t even need to consider writing any code! Before an idea goes anywhere near a developer’s keystrokes, it is worth considering that the more time that is spent on it, the more value that it has, even if it is still just an idea. How can an idea fail as quickly as possible? Let’s see. Can it be put in front of a user verbally or through some simple sketches to confirm that it’s worth doing at all? Before building something to test user adoption, can you fake a sign-up page to gauge interest? Can you build a quick financial model in a spreadsheet to see if six months of work pay off? Ideas can be generated and discarded so quickly and easily: capitalize on this.
  • Technical explorations. How can technical ideas fail fast? How fast can you prototype an approach to see whether it is going to suit your application’s needs at a required scale? Can you try something out quickly in the cloud to fail on somebody else’s hardware before you even think of buying your own? Instead of needing to collect petabytes of real data from production data stores in order to perform benchmarks, can you instead just generate petabytes of random data to meet your needs instead? The salaries of your technical staff are not insignificant, so you should be treating their time as an investment of company money. The same is true about serious production deployments in the cloud or in the data center: getting it wrong could prevent you from hiring a whole new team. Make sure that time and money is spent wisely.
  • Hiring. You’ll want to fail quickly with hiring. Is your interview process set up so that candidates that are not going to make the cut are screened out as early as possible? Do you perform a quick pre-screen on the phone? Interviews, like technical explorations, are an investment of time from your technical staff. Make sure that your interview process is like a funnel, with the best candidates getting the most of your time. Also, treat hiring decisions very seriously: you can consider the hiring process as adding value to a candidate, and when they are hired it becomes much harder to “fail” once you’ve gotten past a probation period. Nobody likes dealing with performance problems. It’s easier to say no after the second interview, or come to an agreement that it’s not working out after the probation period.
  • Decisions. The longer that a decision goes unmade, the more value that it gains, for better or for worse. Unmade decisions attract ever more opinions and become more diluted and complicated and harder to execute. This is especially true for decisions that are not being made because they may cause conflict, such as a strong veto that will inevitably cause some friction. Act confidently on decisions and do not be afraid to say no. If the team shouldn’t go in a particular direction, be firm and say so. Cognitive power can then be spent elsewhere with loose ends neatly tied.

Your currency

If you need motivation to fail fast then it can always help to think about time and money. One could argue that in the workplace time is money, because everybody there is getting paid; all activity can be considered an investment from the company.

If you don’t fail fast, you’re effectively wasting money. The bigger your team(s), the more investment that you risk by not doing so. A few engineering teams could easily represent a yearly investment of £500K-£1M. Thinking of it in raw currency, would you really let that project run for six months, or would you try to prove whether it is worth doing in the first two weeks? Would your team really interview those candidates with applications that you were on the fence about, just on the off chance that they were better in person? It’s critical to think about how you spend your currency, as your company expects a good return on their investment in your function.

In summary

You have a responsibility to ensure that you fail fast in all aspects of your job. After all, Plan C might have been the best plan all along. Bring the fail fast mentality to software development, product ideas, technical explorations, the hiring process and decision making and make sure that the company’s investment in your team yields the best possible results.

Are you unsure about anything you’re doing right now?

Force multipliers

Leave a comment

Now what?

It’s Thursday.

You stroll back to your desk from the coffee machine and before taking your seat, you have a stretch and you look around at your colleagues. Life is pretty good, isn’t it? You’re managing a team. People seem to think that you’re doing a great job. Your staff are a talented, happy bunch and you’ve got an interesting project with autonomy to build it in the language and framework of your choice. What could be better?


Something doesn’t feel quite right. You’ve wanted a stable team in a good company ever since you quit the role that will not be named a year ago, and now you’ve got it.

Still a strange feeling. So what gives?

Well, you’re ambitious and you’re not quite sure where to go from here. Is this it for you as a manager in this company? Will you be standing here on a Thursday four years in the future looking at exactly the same people in the same seats?

A sinking feeling develops.

The department’s headcount for the coming year is meant to stay constant, so you’re not going to be able to dramatically expand your team. What about the promotion angle? Unlikely. It’s pretty crowded at the top of the pyramid. Your boss is the CTO and she isn’t going anywhere any time soon. How can you continue to expand your output, influence and value if you’re stuck where you are? What can you aim for?

The equation

It’s a common dilemma. We are no longer patient when it comes to career development. Some considered that the architect Zaha Hadid, who passed away in 2016 at age 66, was “mid career”. Architecting buildings requires a lifetime to be considered a senior expert. Architecting software? Maybe not so much. Technology moves fast and so do promotions. Developers are sometimes grasping for Senior titles not many years after they’ve been legal to drink in the US.

How can we continue to apply ourselves in a way that increases our responsibility, interest and satisfaction in our jobs when we can’t rely on organizational change to hand us that sought-after promotion?

Let’s revisit the equation that Andy Grove coined in High Output Management:

A manager’s output = the output of their organization + the output of the neighboring organizations under their influence.

Reflecting on that expression, how can you increase your output if your team isn’t going to change size and you’re not going to be promoted in the near future?

Well, there are a bunch of ways, but you’ll need to think more laterally, both in terms of exactly what your own output is, and in turn, what you consider your organization to be. If you only consider your organization to be your team, then you’ll be limited. You’ll be tied to the current position that you inhabit in the org chart, and there’s only so much predictable impact that you can have on the future size and structure of the company that you work for.

How can you remain where you are, doing the same role, yet begin to measurably increase your impact? You can consider force multipliers.

Force multipliers

What do I mean by force multipliers? There are three broad categories:

  • Technical: You can make your technical skills go further. You can mentor others and teach them what you know, or you could be a technical advisor on other projects, offering your advice on design and code review.
  • Cultural: You can focus on improving the culture of the department by making it a more engaging and fulfilling place to work.
  • Procedural: You can focus on making department-wide processes better, such as the amount of time it takes to ship code to the production environment, or working on improving communication between teams.

For all of these force multipliers, you can decide as to whether you would like to work on them as an individual by setting an example of the change that you wish to see, or you can form working groups with your peers, meeting regularly and broadcasting your progress.


If you’re a manager in the Engineering department, then it’s likely that you have a technical background. Within your team you can spend more time on technical mentoring of junior members of staff. You can do this by sitting down and pair programming with them, always offering to be a sounding board for what they are thinking of building, being keen on sketching out approaches together on paper or whiteboards, and making a concerted effort to do thorough and helpful code review. It may require you to do less coding yourself; instead your output is through others.

You can extend this support outside of the team as well, depending on the time that you have available. If you have sufficient experience of the wider architecture of your application(s) then you can offer your help in the design of new parts of infrastructure, and act as a “networker” who can introduce engineers to each other; hooking an engineer who needs help up with a particular problem with the person you know to be the expert in that domain.

Even better, once you have a skilled team of autonomous engineers you can encourage for them to pick up the same technical mentorship culture with others in the company, effectively multiplying your output by having your mentees do their own mentoring.

Technical force multipliers make your department more skilled.


Are there ways in which you can improve the culture of your department? As we’ve written about previously, culture is sometimes difficult to define. However, what would your department be doing if you were to imagine it with an amazing culture? Would it have regular technical talks from external guests? What about a closer link with the commercial side of the business, creating a heightened sense of hustle? Or perhaps it would have a regular video games night, lunchtime meditation sessions or hack days?

Rather than waiting for your wishes to be executed from from higher up in your organization, why not try and organize them yourself? Lobby around for interest, consult those that should have some say in the matter, and just do it. It’s very unlikely to cause harm.

Could you, perhaps, start working groups for broader cultural themes? As an example, at Brandwatch we have a social working group who arrange fun activities such as movie nights, outings and pub quizzes, and a wellness committee who have budget to fill the office with plants, put on regular company lunches and set up classes such as yoga at lunchtime. You could even start a blog in order to broadcast your culture to the world.

Cultural force multipliers make your company an even better place to work.


What processes are bugging you and your team at the moment? Does it take too long to get code into production? Do code reviews take too long? Is it a pain to find documentation or is your hiring process convoluted? You could lobby support to effect positive change. These kinds of decisions should come from the bottom up rather than being mandated from the top down.

In a previous article I wrote about a management bugs initiative which was a method for raising, assigning accountability and fixing these procedural issues. That is a wholesale method for trying to tackle all manner of issues, but you could start off much smaller. What do your team find frustrating? Do any of the other teams or your peers share the same sentiment? If so, could enough of you get together to start making a difference? A concerted effort can snowball into a movement of people who join together to make things better for everyone.

Procedural force multipliers make work smoother and more efficient.

In summary

There’s always more that you can do.

Considering how to multiply your output by forming connections with others outside of your team (and even outside your department) makes you more impactful and valuable to your company. You can improve technical skills, culture and efficiency of process. Doing so introduces you to more people, raises your profile, and pushes you outside of your comfort zone so you can grow.

Go on, have a go.

Step outside of your comfort zone

Leave a comment

When did you grow?

Looking back on your career so far, which parts would you consider to be the highlights? Do you most proudly remember being promoted, or shipping a new product? Are you drawn towards a time when you had to learn something totally new and, with time, became an expert on it? Was it the first time that you took to the stage during a conference and spoke in front of hundreds of people?

Typically when you rewind through these memories to find the highlights, there is one thing in common: they were moments in time that you were pushed outside of your comfort zone. The most satisfying projects were the ones that were hard-won. The best teams you worked with made you initially feel out of your depth, yet with time you leveled up to be just as good as them. The key promotions pushed you just that little bit further than you were comfortable with, forcing you to step up and operate at a higher level than you were on before.

Control is an illusion

Humans are creatures of habit. Many of us crave a predictable, steady routine that allows us to feel that we have control over our lives.

“My new routine is going to be brilliant. Tomorrow I’ll be waking at 5:30AM to do 15 minutes of meditation, followed by a 30 minute run round the park. Then I’d be back to shower and get the 7:15AM train to work, where I’ll have the porridge and smoothie that I prepared the night before. I’ll be in work before everyone else, which means I can get at least 45 minutes of coding uninterrupted before our stand-up.”

And then the next morning the alarm doesn’t go off.

Control is sometimes an illusion. The same can be true about your job. There is a yearning for a time where the workday will flow so effortlessly, where it will be so predictable, with no interruptions or challenges beyond what we know we can manage. Yet, the irony of this idealized situation is that despite it being controllable and comfortable, it can also be the sign of lack of challenge, boredom and stagnation.

Purposefully facing change, challenge and unpredictability pushes us outside of our comfort zone and builds resilience. Do you remember learning to ride a bicycle as a child, and how overwhelmingly impossible it seemed to be able to continue pedaling when the supporting grip was released from the saddle? Sure, you fell a few times, but with continued perseverance you were able to conquer that fear, adjust to the new normality of being unassisted, and now you’re probably able to cycle across Europe if you really wanted to.

The same is true about your job. As soon as you feel that it’s getting too comfortable, your initial reaction shouldn’t be one of kicking back, getting a coffee and taking it slow. Instead it should be a recognition that perhaps you’ve increased your skill to the point that it’s easy again, and you should think about ways in which you can continue to grow.

Why don’t we push ourselves?

As per the example of riding a bicycle, when we are children we are generally more uninhibited than we are as adults. We think less about the world around us, how we are perceived, or judged, and just get on with the task at hand. Scraped knees, bruised elbows and new scars reflect the times that we tried to jump from the slide to the monkey bars, from when we thought it was a great idea to try and climb that precarious-looking tree, or when hurtling off that mound of mud seemed like a fantastic proposition. The curiosity for new experience and pushing boundaries seemed part of our DNA. Yet, as adults, we are more wary of being outside of our comfort zone. Why?

  • Fear of failure: It sucks to fail at something, which can prevent us from wanting to expose ourselves to situations where there is a higher probability of it happening. Doing badly at something can be upsetting and can chip away at the self worth that we have nurtured over the years.
  • Fear of judgement from others: Not only does it feel bad to fail, it can be even worse to imagine that other people around you are also judging you for failing! Imagine the embarrassment of becoming lead engineer on a project only for it to be a complete mess: what would that say about your capabilities?
  • Fear of the unknown: As mentioned previously, we can crave predictability. Given the choice to continue in a role that offers no surprises, why would we put ourselves in one where we have no idea what will happen? Is that not madness?

Taking these three aspects into account, it seems fairly understandable as to why we wouldn’t want to push ourselves too hard. One could even say it’s against our instinct. Yet, overriding this instinct with the logic that doing so will improve us is what makes us more capable in future.

A programming anecdote

You could say that going outside of your comfort zone is akin to introducing controlled chaos into your life. When ruminating on this thought, I was reminded of the Chaos Monkey tool which was developed by Netflix in order to test their production infrastructure. When deployed, the tool randomly kills instances in their live environment. The idea is that developers are forced to create their software knowing that instances thereof could be killed at any time; a scary proposition! However, this means that more conscious is was put into the creation of applications because they could go catastrophically wrong at any time. How could they cope with diminished service? How could they restart gracefully?

The same is true about pushing yourself into new and challenging situations. If you have a comfortable environment where there is little chance of anything going wrong, then you’re not going to develop into a truly resilient person. Exist in turbulence, especially that which has been created by yourself, and you will be a fuller, rounder, human being with a better SLA.

When I learned the most

The times when I learned the most in my professional career were when I forced myself into really uncomfortable situations. Three particular situations stand out; each of which being the first time that I took on a given responsibility:

  • Lead engineer, attempt zero: My first time as lead engineer was on a particularly challenging piece of infrastructure that was written as a distributed system. When I volunteered for this opportunity, had I created anything like it before? Nope. Did I know whether I was going to succeed? Not really. Did anyone else in the company have a lot of experience at doing this? Nope. That lack of safety net made me put in some of my best work. It’s still running in production today (although it could definitely be improved vastly…)
  • Managing my first team: As our company grew after a VC raise, our Engineering department began to require some more line managers, and the opportunity arose for me to take that role. Had I done it before? Nope. Did I always have a plan of becoming a manager? At the time, no. Was it potentially interesting? Definitely; especially so early on in my career. I’m glad I did – I think I’m a better manager than I am programmer, in retrospect.
  • My first conference talk: I’d watched videos of this particular conference on YouTube for years, and I always really respected the quality of their speakers. After taking a punt and submitting an abstract, it turned out that I was going to be one of those speakers myself. I was petrified, but the experience demonstrated to me that standing up in front of a couple of hundred people wasn’t all that different from speaking to a group of ten. At least none of the audience knew me, and I could barely see past the first row for the bright lights! Nothing catastrophic happened, and I’ve since talked at many other events.

In summary

So, in short: we must create difficulty and unknowns for ourselves in order to grow more in our professional careers. How can you do that?

As managers, you also need to think about how to create these environments for your staff. Which of them crave challenge the most? How can you give them new experiences that will really expand their remit as people? How can they push you outside of your comfort zone?