My approach to digitization

My approach to digitization

Similar to my approach for creating customer value the core idea is extremely simple.

Start with small things today

What I have seen a couple of times now, in very different types of organizations, is that people are kind-of afraid to get started. Mostly it seems to come from a feeling that the first project needs to be big and yield powerful results. In my view, that is actually the worst possible approach. Let me explain why and what other things I consider relevant.

Start small

Assuming that you have absolutely no experience in climbing mountains, would you start with the highest mountain on earth, the K2? Of course not. Instead, if you had that ambition, there would be many years of training and climbing smaller mountains first. Unless you are suicidal, of course. So why on earth are people still starting digitization with big projects?

I guess it is either ignorance or the inability (for many different reasons) to withstand internal pressure. So we need to help those poor souls with actionable advice. Instead of saying "no", folks need a better approach. One that has been proven to be universally successful: show small results quickly.

Practical examples could be really trivial. If people are used to printing out a lot of things, ask them to question themselves for the need. Example: Ten years ago I would have responded that I need to print texts (like a response to a request for proposal, aka RfP) for proof-reading. Today, with bigger and better monitors, I may still do that but only for the last two iterations. You can argue that this does not truly qualify as a digitization initiative in terms of outcome. But in terms of changing the mindset it surely does.

A slightly less trivial example are invoices via email. Assuming the legal side is clear, you could start asking your customers whether an electronic invoice would be ok for them, instead of the usual printed one sent via the post office. While this looks trivial on the surface, it makes a wonderful starting point for exploring what non-technical challenges might come up. Which brings us nicely to the next point.

Reduce complexity

The section heading says it all. The first order of business, if you sail into uncharted waters, is to make things as easy as possible. That means to understand what the various dimensions of a digitization program actually are. The second step is to look at what experience the organization already has with those areas. And if there is little to no existing knowledge, this means that extra care is required.

When you take into account the whole picture of digitization, as a minimum we are looking at a combination of business process re-engineering, change management, and IT roll-out. All those topics are hard on their own already, with change management being the toughest. (Remember Peter Drucker: "Culture eats strategy for breakfast.")

If we start with the scenario of sending out invoices via email in the future, we can focus on non-technical aspects. Or do you prefer to combine those with the migration of a mission-critical monolithic application with 2 million lines code to Microservices? Easier things look more realistic to people. Which helps us with the core challenge of getting people on board.

Make things tangible

People need to understand things, otherwise their instinctive reaction will be to dislike or even dismiss them. Therefore, giving presentations about the great outcomes of a large initiative is not going to help. For any given topic the majority of people will have a hard time mapping it onto their own life. And since this is a very individual thing, it does not help to say "this is what it means for people in department XYZ". Because everybody has a unique personality, and working in the same department very often does not mean doing the same thing.

When it comes to reacting to new things, we are basically talking about instincts that were made for survival thousands of years ago. On a sub-conscious level substantial change in the workplace is something that our brain treats with high importance and sees as a threat. That is not something that can be ignored and you need to convince people to get them on board. And the easiest as well as most effective approach is to let them experience some positive results first hand.

A direct, personal experience offers another huge benefit, relative to some presentation that leaves people with the task to map the content into their own world. Experience greatly reduces the risk of misunderstanding. In today's world we have international teams that collaborate from all over the globe. So everything is in English and, in many cases, people have to comprehend complex content that is conveyed in a foreign language. In addition, meetings are not face-to-face. So how convinced are you that the majority of people really gets what you want to say?

Have open discussions

Once people have made some personal experience, you can have a proper discussion with them. They have witnessed how the new way of doing things impacts their daily work. There is feeling in the game. And you will see quickly who is keen for the journey and where the reservations dominate. To better understand the different members of the second group is important. There will be people who in principle are on board but have just had a specific problem with the new way. Skeptics and naysayers are the two other standard groups. Plus all the gray areas between them.

Regarding the openness, you need to find a format that works for your personality and overall situation. The key message, which people must be given, is that their input is valued and makes a difference (the latter is a huge step-up from the former). If you start a meeting by presenting your view and asking for feedback or other opinions, you already lost. Instead ask people to prepare something before the meeting and present it there. Do not broadcast any thoughts before. Also try to refrain from engaging in the discussion other than encouraging people to speak candidly.

Delegate some decisions

You should very seriously think who is best qualified to make which decision when. In many organizations the HiPPO (highest payed person's opinion) principle rules, i.e. the person highest up in the hierarchy decides. If that person is you, think long and hard. Chances are that someone younger, closer to technology, and with less time in the organization has a more open mind. And since we are talking about innovation, those factors may be more relevant than political standing.

If you are brave and innovative enough to delegate some decisions (yes, you can delegate more than work), you will also change the organization for the better. Although at the beginning of the journey that is more of a by-product. The critical success factor is to deliver tangible results fast. Using the "start small" approach will make this less risky. So if some junior person has only seen the technical simplicity of a certain approach and neglected the backlash from a certain department, the damage is limited.

Run things as a series of experiments

If you have multiple experiments running in parallel, you gain a number of things. By calling activities "experiment" rather than "mini project", you already set expectations the way they should be. Because what you do are truly experiments. Learning certain things in addition to providing a solution is a key aspect. And not everything will work out the way it was expected. As long as you truly learn something relevant, this is success.

I thought long whether I should add this section. But I truly believe it is the most accurate description of how things should be handled and not an easy way out. It will also encourage people to be more open-minded. And isn't that what you desperately need for such a transformation?

In closing

There is a lot more to say. But for now think about the approach outlined above as the positive variant of "death by a thousand cuts". Your likelihood to transform the organization is much higher by starting small, trying out very different things, and letting people run their own mini-initiatives. Allow everybody to experience new things and learn, most importantly yourself. This is a journey. For the organization as well as every individual.



要查看或添加评论,请登录

Christoph Jahn的更多文章

  • Unique IDs in programming

    Unique IDs in programming

    Most people have probably come across what is usually called a UUID (universally unique ID) while using software. UUIDs…

    9 条评论
  • Staff communication. Successful!

    Staff communication. Successful!

    Do you have the challenge that your communication does not reach your staff? People telling you "I never heard about…

  • The limits of conventional wisdom

    The limits of conventional wisdom

    In discussions you often hear things that fall into the category of “conventional wisdom” or best practice. I have…

    1 条评论
  • Legacy software: Better than its reputation

    Legacy software: Better than its reputation

    All the time I hear people talk like "this is legacy software". And they do that as if it were a bad thing.

    12 条评论
  • The conflict of values and goals

    The conflict of values and goals

    Compared to ten or twenty years ago, many organizations put a lot of emphasis on values these days. Many of them also…

    3 条评论
  • Finding topics for great conversations with your customer

    Finding topics for great conversations with your customer

    Are you also always looking for topics to have a good conversation with your customer? Why don't you let the customer…

    3 条评论
  • Thoughts on (personal) branding

    Thoughts on (personal) branding

    In recent weeks and months I have come across a number of online articles and posts that covered various aspects of…

    7 条评论
  • How to give a presentation

    How to give a presentation

    “Everybody who loves attending presentations, raise your hand! No one? Hey, come on. …… Still nobody?” Ok, so why is it…

    14 条评论
  • You are not faster with an 80% solution

    You are not faster with an 80% solution

    When the schedule is tight for a software development project, one of the first things non-technical people…

    1 条评论
  • One secret of good demos

    One secret of good demos

    Nobody would argue that preparing a demo for a software product is not important. But one aspect for doing so is often…

    3 条评论

社区洞察

其他会员也浏览了