What to change

Understanding Change

After deciding to embrace change, what comes next? It's time to understand where the need for, and the skills, will come from. Before diving in, take some time to figure things out. While not changing anything maintains the status quo, changing without understanding the system is tampering, and is likely to make things worse, rather than better. It's important to understand the system, and it's foibles, before reacting to them. For that reason, it's worth putting aside any preconceptions and talking to the people who currently do the day-to-day work, whether it's QA, development, infrastructure, or accounting.

People's accounts of the work they do will provide evidence of which things are broken, and why. Are staff demoralised because they can't find the right libraries to do what they want? Do infrastructure and development teams point fingers at each other when something goes wrong? Are customers unhappy with timeframes for, or quality of, delivery? Do delivered features or products satisfy the letter, but not the spirit, of what was requested? These all indicate systemic challenges that people don't know how to solve; if they knew how, they'd be doing it.

Where to start

All sustainable change must include senior management. Management is responsible for the company being the way it is, chasing the things it chases, and valuing the things it values; management built the system that all staff work within. For the organisation to change, the thinking of senior management needs to change. Having seen this play out in many places, it's clear that while many changes can start at the front line, or middle management, they tend to revert over time, as the pressure of the system gradually erodes at the changes. Long-term change requires changing the way people think and, like it or not, the way people think is largely dictated by the system.

That's not to say that the front line cannot inspire management to change. Confronted by a set of symptoms from the front line (politics, poor decisions, unhappy customers, etc), or by a change process that's really effective, senior management may decide that change is required to improve the lives of customers, staff, or shareholders.

The first step in achieving sustainable change, then, is to get senior management involved. Understanding what the senior team is trying to achieve, its pressures, and its goals over the next 3-5 years, means that any desired change can be put into context of how it will assist with those goals. This is a dialogue where motivations, likelihoods, obstacles, people, processes, and technology all need to be explored, in order to ensure that things start from an agreed point. The goal is to get everything on the table, which can take hours, or days. During this dialogue, it's important to agree timelines, ensure everybody is going to be available, and designate a point person (and possibly and escalation contact) for the work. Some understanding comes about, during this meeting, of what counterproductive processes are already in place, and how they're created by management itself.

Next Steps

The next step is to meet with all staff, or as many as is feasible. The minimum required is a representative sample from everybody that works with IT, as well as everybody within IT. Most of this meeting is spent listening, drawing out motivations and goals, on the one hand, and the things getting in the way, on the other. They know, and they've either raised it and failed to achieve change, or have convinced themselves that it's pointless to raise the issues because their management will do nothing/ignore it/deny it/blow up/fire me. There doesn't need to be any evidence that any of these things will happen, only the belief that they will. Upon leaving this meeting, staff talk about feeling like they've come out of therapy, as if a weight has been lifted. Notes taken during these meetings are direct observations and quotes, which make it possible to refer back to source data whenever necessary. Direct observations will make proposed changes and inferences easier to back up with data.

From those conversations, a pattern emerges. Things stand out. Some issues occur more frequently, than others. Collate these, and do a root cause analysis - use a flowchart, or logic tools to connect the issues until it's clear which factors are causing the others. Sometimes it's processes, sometimes it's people, and sometimes it's technology. Frequently, it's a mix of all 3, as predicted by Conway's Law.

Once it's understood what's causing the problem, steps can be taken in addressing it. First, figure out what metrics, if any, can be used to determine whether a given change is effective. Most ideas about how to fix things will come from staff, though there's a chance that the changes that are needed are so radical that nobody has any experience with how to make them happen. This is where consultants are really useful. They can bring specific knowledge about how to achieve change, and how to model the behaviour you want to see.

Conclusion

Starting a change program requires a few things: understanding the system, senior management buy in, and a willingness to listen to front-line staff to see what's really happening. Without that inclusiveness, and the involvement of people at all levels, any change is temporary.

There are numerous different styles, strategies, and methods of implementing change. All we've done so far, is identify where to start it. We have yet to talk about how to achieve change, the importance of people as opposed to behaviours or actions. There's still a lot to talk about, but after coming this far, it's possible to figure out what's wrong, how change fits with the bigger picture, and where attention will be most valuable. Getting this far, despite how it feels, is the fast, relatively simple bit. Still to come? Implementation.

The Underrated Value of Listening

Unhappy Staff

You’ve implemented a change in how things work, and people aren’t happy. You spent time investigating the problem, and putting serious thought into what the issue was, and you’ve put a fix in place that you were sure people would be happy with. They aren’t. Why not?

At this point, you can do a couple of things. The first one is the one that seems to be the most common – chalk it up to ‘people dislike change’, and force things to go ahead, anyway. Eventually, people will get on board, if you’re right, and you keep pushing, and they don’t have a choice. But you’re going to have to work hard to get things embedded enough that they don’t backslide when you stop pushing. It’s a painful way to do things, and people make a lot of money being the bad guys who implement change. And when they leave, the change slowly erodes, performs badly, or gets discredited. In the long run, not much changes, and a lot of money gets spent.

The Road to Recovery

You can be more effective. Even at the point where you’ve implemented an unpopular change, things can still be recovered, though it can be intimidating to do what’s necessary. Step away from the problem, and your interpretation of why it’s happening. Put aside your judgement of the people involved. Take the time to sit down and ask them what’s wrong. People want to be heard. They want a voice. They want to know that their concerns have been understood. So take the time to go to the loudest, most upset people, and let them talk directly to you. Ask them what’s bothering them, and listen when they tell you. I don’t mean listen in the hopes of refuting their arguments, or waiting for your chance to speak. I’m talking about listening as a means of connecting to another person. Regardless of whether you think it’s justified, the people you’ve imposed change on feel aggrieved; successful change requires understanding why, and working through things with them. So, listen. Ask questions that show you’re listening (“What impact did this have on you?”, “How could things have been done better?”, etc). Don’t take anything personally. This isn’t about you, or the changes you’ve implemented, or anything you stand for or believe in. This is about them. Completely, wholly, unreservedly about them and the impact the change has had on them. Ask questions, and listen, until they no longer have anything to add. Then repeat back to them what your understanding of what they’ve said is, so you can be sure you’ve understood. This, on its own, feels cathartic to those with complaints.

Catharsis will improve things, temporarily. It will give people the feeling that someone has heard what they’ve said. The goal in going through this process is to understand where you went wrong, yes. But before that happens, you need to form a connection with the person you’re talking to. That connection is where communication really starts, and forming it comes from listening, and empathy. These, in and of themselves, are worthwhile goals. The next step is showing people they’ve been heard. This will close the loop, and make people more likely to talk to you directly, next time.

Moving Forward

Once you understand the problems that are being raised, you may or may not do anything (or be able to do anything) about it. It may be that your hand was forced, that the changes you implemented were correct, or that what’s being objected to is how things were done, rather than what was done. None of those things matter, in the moment. Stop trying to solve the problem, and just listen to what’s being said, and what isn’t. And once you’ve done it with the first unhappy person, go talk to the rest. After having those conversations, spend time thinking about what they’ve said, how to take it on board, and then communicate back to them how their advice has impacted things.

Empathy and listening are skills that are difficult for many people to master. Listening just to be listening, rather than to find a solution, is something that schools rarely teach, and work rarely rewards. It’s a skill that tends to languish, and get rusty over many years. Don’t feel bad if it doesn’t come naturally, right away. It will come, if you give it time. And the next time you want to make a change, even a fantastic change, for good reasons, talk to people first. They’ll be happy they’ve been consulted, they’ll be more likely to buy into the change that’s coming, you can learn from them, and they may even provide a solution to the problem that you hadn’t considered.

I first wrote this article for the OpenCredo blog

Making Money Through Science

Businesses exist to make money; their purpose isn’t just to generate revenue, but to create profits, now and in the future. Generating profits means delivering products or services that people want to buy. The creation of what people want is the entire purpose of delivery pipelines. (NB: The rest of this article will use ‘product’ to refer to both products and services.)

Generate an idea

Determining what people want is not easy, but it can be simple. The best way to determine whether people want to pay for something is to put it in front of them. Some companies do this by creating a completely finished product which has been fully designed, architected, and tested before a customer sees it. They want it to be perfect before showing it to customers and getting feedback. There’s only one problem with this approach: they can’t be sure what the customer wants until it’s in front of them. It’s entirely possible to waste an entire product or service delivery budget creating something nobody wants. It’s a huge risk, whose upside (if you’re exactly right) is often more than outweighed by its downside (what if it turns out the product doesn’t actually have a market?).

Hypothesise

The only time we find out if a product is valuable is when we get feedback from the customer. That means the faster we get feedback, the faster we can decide whether we want to continue, change, or cancel the product. The same is true when changing products – a change is only valuable once a customer is using it, and can provide feedback on it. (The corollary to this is that until a product is being used by a customer, it has absolutely no value.)

The logical extension of requiring customer feedback to find value is to work in ways that enable feedback as quickly and frequently as possible. Get your product in front of a customer, and see what the feedback is. Then adapt. This is also known as applying the scientific method to product development – generate an idea, form a hypothesis about the idea, create a means of testing the hypothesis, test it, draw conclusions, and adapt.

Image is CC-SA

In order to test whether your new approach works, make sure you measure what matters – how long does it take for an idea to come into the company from the customer, be developed, tested, released, and be back in front of the customers, happily being used. Don’t measure the time in each stage, as the customer can’t see them. The only thing the customer cares about is how long it takes to deliver a working, usable product, from end to end. And all you care about is whether that time is stable (with some degree of predictable variation), and whether your changes are improving it.

Test

Shortening feedback cycles means changing the way you organise product development. Rather than focus on who answers to who, and drawing it in an org chart, focus your teams on rapidly delivering products to customers. The focus should move from working on each phase of development to working on what customers need.

If you need analysis, development, and testing, then put them all together so they can figure out how to respond to customers quickly. If you write software, put in testing and deployment automation, so you can rapidly deploy small changes that customers see immediately. If you work on a large product, with lots of dependencies, start working on separating the components so development in one area doesn’t require testing and changes in a completely unrelated area.

Conclusion

You’ve changed your company. You’re now looking at how product development works, rather than on how people work on product development. And you have a measure you can use to determine success. It takes less time than it did before to deliver new features and products. They’re higher quality, and customer feedback is improving. Your measures indicate that you can get new features out the door in a predictable amount of time ( between X & Y days).

Your focus is no longer on production, but on flow. Keeping it there can be difficult, but it’ll significantly improve delivery, which will improve profits now, and in the future.

Adapt

Your first experiment worked. Now it’s time to see how you can continue to improve it. What factors contribute to product delivery timelines? After you’ve identified them, think about how changing them will change your delivery time scales, and whether a change in one area will impact another adversely. Focus on the areas that appear to be bottlenecks, and improve them until they stop being bottlenecks. Then repeat.

Feedback

Help me adapt. Leave a comment, or reach out to me on Twitter (@nrcantor) to let me know what you think and what you’d like to hear about next time.

I first wrote this article for the OpenCredo blog

Fear Kills Improvement

I originally authored this piece for The Register. This is the original, unmodified version.

Fear is the Great Motivator

Fear is a great motivator. Fear pushes adrenaline. It primes our fight-or-flight response. It primes us for a confrontation. Fear shuts down our higher cognitive functions, priming us for a visceral response, on top of which we layer rationalisation. Fear ensures continued survival of our species in times of dire straits. When we are afraid, we have only our intuition and built-in responses to draw on. When we are afraid, we cannot accept feedback, respond to things which run counter to our expectations, or learn. And so, a culture in which fear operates is one in which no learning takes place. Fear kills change.

In the last 200 years, work has changed significantly. Most of us do not face daily threats to our continued existence. But our fear response remains. We still respond with adrenaline when threatened, or embarrassed; we still shut down; we still lose our capacity for higher reasoning and openness. And it kills improvement at work. It kills creativity. And it's common.

Needless to say, fear is a response borne of perception, not reality. There doesn't need to be a tiger in the bushes in order for us to think there's one there, and react accordingly. There doesn't need to be a threat to our continued existence for us to believe there is one. In a world where we are taught to define ourselves by how successful we are at work, how much money we make, how influential we are, and how people see us, threats to our continued existence do not have to be life-or-death. Job loss, income loss, prestige loss, or promotion loss all generate a similar response. And the idea that trying something, but not succeeding at it, is frequently tied to more than one of those losses, making us risk averse, and afraid of experimentation.

"The ability to learn faster than your competitors may be the only sustainable competitive advantage." - Arie de Geus

Knowledge-heavy roles (such as IT or management) require learning in order to be effective, or help the company succeed. Learning through experience and mistakes is necessary in any role that brings about change, whether the goal is figuring out how to convert page views into sales, or transforming your business into a leaner, more effective organisation.

Knowledge economies are driven by learning - the converting of information into knowledge and understanding. Without learning, we cannot progress; without learning, our companies can't adapt; without learning, we are doomed to eventual replacement by companies with newer ideas that we couldn't test. And this is a problem, because it's culturally ingrained - we are taught not to speak out in class, if we don't know the answer; we are taught not to ask too many questions; we are taught to keep our heads down when we don't know the answer. We are taught to fear failure. And so failure gets swept under the carpet, never to be acknowledged, never to be embraced, never to be learned from.

Agile, Lean, Kanban, and DevOps all attempt to remove this fear by explicitly creating conditions where experimentation and learning are encouraged. All too often, however, the adoption of these processes fail, not due to failures in the processes, but due to their incompleteness. To see how important addressing fear is, all we have to do is look back to the theory that gave birth to every one of these movements - Deming's Theory of Profound Knowledge.

Deming, A (Very) Brief Introduction.

Edward Deming revolutionised Japanese manufacturing, starting at the end of WWII. He went into Japanese companies, spoke with Japanese executives, and told them that in order to succeed, they would have to start thinking of organisations as systems, where optimising the system and optimising parts of the system are not the same thing. Deming had 14 points for management; point 8 is

"Drive Out Fear: Encourage effective two way communication and other means to drive out fear throughout the organization so that everybody may work effectively and more productively for the company."

Deming recognised something that has been shown repeatedly through research - fear inhibits learning. Deming encouraged management to see mistakes as opportunities for learning, and failure as a stop on the path of progress.

The Value of Mistakes

Mistakes are inevitable. By punishing mistakes a company (explicitly with firing, or implicitly through reduced career or salary progression) doesn't eliminate them, it merely ensures that nobody will talk about them. And nobody will talk about the fact that nobody is talking about them. The entire organisation will collude in hiding mistakes in order to avoid feelings of embarrassment or threats (Argyris, Knowledge for Action). Any company in which failures are not openly discussed, in order to be learned from (without any sense of blame or shame), is not learning effectively.

Companies rarely explicitly punish failure. Instead, there are unspoken rules about the acceptability and impact of failure - fewer promotions, reduced raises, fewer hours, worse reviews. These unspoken rules leave no room for improvement, and must be changed for a company to start learning. Words won't change them. Changing unspoken rules requires action. Admitting failure requires vulnerability, so creating a culture that learns from failure also requires vulnerability, usually in the form of managers making their own failures, and learnings, more visible. Making it obvious that everybody makes mistakes, and only by admitting them can we learn from them. This, in turn, gives their employees the opportunity to experiment, fail, learn, and improve, more visibly.

The scope for improvement through vulnerability is downward facing, only, meaning that managers can start improving things by admitting vulnerability to their staff, but the only way to create organisational change is for senior managers to admit their failures, to themselves, to their peers, and to their subordinates.

Conclusion

Admitting failure isn't easy. It can make us feel vulnerable. The alternative is worse. The alternative is not admitting failure, not admitting mistakes, not learning from things we know are, or were, wrong. Companies which can't learn from mistakes stagnate, and eventually fail.

Fear and change are mutually exclusive. Any organisation that creates a place for one necessarily drives out the other. If we choose change, and adaptability, and learning, we choose an organisational life with difficulties, challenges, and hard work, in order to maintain a culture that embraces and reinforces learning, whatever the source. While it sounds difficult, it's the only life I'd choose.