When Russia attacked my native Ukraine on February 24 2022, I was with my Ukrainian team on an annual retreat in Egypt. After the initial shock wore off, I realized I was responsible for 21 other people: they couldn’t go back to Ukraine and we couldn’t stay at the resort for more than 5 more days. I had to acquire a new set of crisis management skills very fast.

Here are some of the things I learned.

Plan only the next step

Chaos doesn’t allow you the luxury of long-term planning, because the environment is constantly changing. News is coming in fast, the plans you made an hour ago are now obsolete. All you can afford is to plan for the next step or two.

My first step was to make sure everyone’s family back home was safe and determine whether anyone’s family members needed to be evacuated. I didn’t know where we could evacuate them or where we would end up, ourselves, but that would be something to figure out later.

Prioritize urgent over important

When you’re planning only the next step, you have to prioritize urgent problems over important ones. You will never get to the important thing unless you unblock yourself from something that’s right in your face. Although the big question for everyone was where could we go from Africa, I had to get a few things out of the way first. A few men on the team wanted to go back to Ukraine to their wives and kids who stayed back, so with the leadership team we quickly had to compile a route for them from North Africa to central Ukraine, which involved air travel to Poland, followed by busses and taxis over the Ukrainian border, while trying to avoid Russian missiles on the way.

Of course, the urgent issues will never stop coming if you let them, so you have to use your judgment when to put away small issues and focus on the big picture.

Provide strong and available leadership

Leaders are a stabilizing factor. When the world is crashing around them, people need to have a solid, comforting center to look up to. They need someone who will reassure them that there’s a plan to move forward. Equally important is that there’s a single voice communicating with the team to avoid the loss of confidence due to even small discrepancies in messages.

With a small leadership group we opened the center of operations in my hotel room, where we made calls to our friends and partners in Europe, discussed options for moving forward, and where everyone on the team could come in, talk about their circumstances and get help. It was amazing to see how people who previously didn’t display leadership qualities stepped up to look for airline tickets, bus routes, vaccine and mask requirements for various destinations.

It is hard to overestimate how stable leadership and frequent communication kept many of our team members from collapsing from the pressure.

An imperfect option is better than inaction

Sometimes there are no great options to choose from and in a normal situation you might not make an immediate decision. But in a crisis, you have to choose. Take a breath and pick one that will extend your option space in the future. Although you can’t calculate the outcome of each decision due to the changing environment, you can get an idea which of the imperfect options will open up new possibilities for you in the future.

In our case, I knew that extending our stay in Egypt would limit our future options. It was clear that we had to go to Europe, but where? Through a friend, I found four days of lodging for the team at a Calvary Chapel base outside of Budapest. We bought tickets there without knowing what would come next, but at least I knew we would have more options once there. In a crisis, rough imperfect solutions are ok if they give you a platform from which to make better decisions.

It turned out to be a good move. In Hungary, my leaders and I kept reaching out to people we knew as well as available BnBs we found around Europe. Finally, an IT community in Mönchengladbach, Germany, offered our team several apartments to stay at as well as an office to work from. It was perfect. I couldn’t believe how fortunate we were.

Your culture will pay dividends

In a crisis, the culture you have already built pays off in a major way. As a leader, I had to walk a fine line between a shocked, disoriented, grieving team and clients, who, although very supportive, might start to get concerned about their projects and look to diversify their risk if the progress was going to stall for too long.

I had to make sure we kept the business. When we got to Hungary, I got everyone together and told them, “The worst thing we can do right now is stop working.” We agreed to start ramping up on work, while taking care of our families and immediate needs in the new location. I could make such a difficult ask of the team only because of the culture we had built at New Normal over 10 years: my team members know that they can trust that I will take care of them and they didn’t feel the need to make “every man for himself” decisions, which in turn gave them peace of mind to take care of our clients. As a result, our unscheduled downtime was only two days.

At the same time, our clients banded around my team and displayed incredible solidarity. Not only did they not diversify away, but rather they gave us the time we needed to settle in. They knew our work ethic and dedication to their success, proven over the years, so that while most of the Ukrainian IT industry shrank because of client risk aversion in 2023, my business grew.

It pays to build a culture of trust and transparency with your team as well as clients in peaceful times, but it can downright save your business in a major crisis.

Embrace reality as it is

In his legendary book, “Man’s Search for Meaning,” concentration camp survivor Victor Frankl recalls that deaths and suicides in his camp would rise between Christmas and New Year’s. A lot of prisoners held out hope that they would be rescued by Christmas and lost their will to live after that didn’t happen.

Most of us on the team initially thought that we would be able to go back to our Ukrainian office in 3 weeks, then in 1 month, and then in 3 months.

Such thinking kept us from fully taking advantage of the situation we were in, from adapting to our new surroundings and making the most of it both for our lives and productivity at work.

In a crisis, it is essential to embrace reality as it is, to act on facts rather than aspirations. As leaders we might lie to ourselves that things are not as bad as they seem or hope that if we give it time, the crisis will blow over. But it’s a mistake. As dire as the situation might be, acting on the reality will allow you to make better decisions as a leader and lead your business through dark times.

I realized that I needed to stop giving the war in Ukraine imaginary deadlines, and focus on improving the quality of life and work for myself and the team. With the leaders we decided to commit to a long-term office lease in Germany, purchase much-needed equipment, we were able to get better rent deals on apartments, and take comfort in the peace of mind that comes from committing to a plan.

Remember that this is temporary

For New Normal, the crisis is not yet over. A good part of my team can’t go home. But we know it’s not forever.

By responding to each situation as it arises with consistent action and by maintaining open communication with the team, I’ve learned not only to lean into the situation we find ourselves in, but to use it to stabilize our operations and support Ukraine by providing war-immune jobs.

Unless it’s your core business, it is never a good idea to build your own digital product.

Commercial fishing company looking for an ERP? Buy one and get someone to integrate it for you. Healthcare insurer needing a new client dashboard? Get an Epic consultant to configure it.

Don’t do it

What seems like a money-saving move turns out to be much more costly to support, customize and update. At this stage, companies usually start to cut corners to economize. The product becomes a burden to use for the staff until someone has enough courage to mercy kill it.

You will inevitably end up in a situation where it’s impossible to do anything without a good amount of tribal knowledge: if you need to change a line on an invoice, you have to create another copy of a product with a different price and name it something like “!!!DO NOT USE” so another unwitting manager doesn’t sell it to a customer. I’ve heard stories of staff quitting because it was so frustrating to use their home-grown system. A pretty grim picture, isn’t it?

It’s a mistake to think that it’s enough to build the functionality you need and set the system loose. Software requires upkeep (security updates, minor modifications, update requests after external APIs changed) and thus a team to service it.

In case you need more convincing, run a quick financial analysis by comparing the costs of development, support, changes, security updates and liabilities from downtime or security breaches on your legacy software against licensing and professional services fees from a manufacturer. It will always come out one way, and that’s because manufacturers have a massive advantage you don’t — economies of scale.

That’s why it’s a good idea to purchase software from a company that has the infrastructure for it.

The exception

There’s one exception to this rule. The investment is worth it if you can make the product work as a separate business: a business with its own goals, financial flows and team. It’s a radical statement, but it’s the only way—a software like that has to live its own life.

As in any business, a product requires financial analysis: is the initial investment and ongoing cost worth the cost savings from improved operational efficiency? Is there an opportunity to commercialize?

Then, there’s the team. As products grow, even minor changes will become more costly because interdependency of its parts make it more complicated. The most persistent mistake I see is when developers add minor features on the fly, which reduces usability, architectural integrity and security of the entire system. The correct way to add new functionality is to go through the architect, who will evaluate the changes on all of these factors and then naturally incorporate it. That’s why the engineering team has to have at least one dev as an architect, a QA engineer, and a project manager. If you’ve ever wondered why Facebook needs thousands of engineers for a social posting app — that’s why.

Same thinking applies if you are already stuck managing a legacy product: turn it into a business. If it’s not viable as one, it makes sense to buy something off the shelf.

Never build your own software to save money, it just doesn’t work as a tactic. But if you have a vision to spin such a system off into a separate business and maybe even commercialize it: that’s something I definitely want to hear about.

Whenever there's a project to be done, regardless how difficult, I always start with  "Just do it, what's keeping you?". Deceptively simple, but it allows to invoke resrouces and problem solving at the right time and in the right quantity.

Before this realization I would try to build a strategy or implementation plan by analogy: what's something similar I've done before that could inform current project? But this line of thinking doesn't utilize critical thinking, merely copying methods from another project.

It's healthy and necessary to ask fundamental questions with each new initiative. Thus "Just do it. What's keeping you?", challenging the normal with each new project. In his classic work "The Mythical Man Month" Fred Brooks describes the danger of the "second system", which comes from repeating the same patterns in a successful first project or trying to compensate for the limits of the first system. The former blinds you to the mistaskes you made since the project was sucessful, and the latter – to the priorities of the second endeavor.

The "Just do it" approach lines up your priorities correctly, starting with the final product in mind and working back from it to the resources and processes you need to invoke.

Are you tasked with building a telehealth app? Just do it! In the simplest form all you need to build is a streaming service. There's enough options in that field that will help you integrate or relatively quickly spin up a streaming server. From there we need to think about setting appointments, also a very solvable problem. Then privacy, then doctor and patient management, then integration with EHRs, accounting systems, etc, etc. The scope of work quickly grows, but if you start with a very basic understanding of what's required, you can grow other systems around it. And the advantage is: you are using resources optimally, which enhances your chances for success.

It's a common perception out there that regulation stifles innovation by putting outside constraints on an industry. Regulations make it more difficult to create something new, let alone try to gain a competitive advantage.

Such perspective is simply wrong. Innovation's objective is to solve a problem, you need a problem to innovate on. You cannot innovate in a vacuum, if possibilities are endless, there's no opportunity to create. For an innovation to be such, it has to disrupt the status quo.

External constraints, then, provide a framework where you can start to think creatively, your very ability to do so comes from the existence of these constraints. Limitations are the stuff great ideas are made of: how to achieve goals within a set of parameters.

Fred Brooks makes a strong point about it in his classic work "Mythical Man Month":

There are many examples from other arts and crafts that lead one to believe that discipline is good for art. Indeed, an artist's aphorism asserts, "Form is liberating." The worst buildings are those whose budget was too great for the purposes to be served. Bach's creative output hardly seems to have been squelched by the necessity of producing a limited-form cantata each week. I am sure that the Stretch computer would have had a better architecture had it been more tightly constrained; the constraints imposed by the System/360 Model 30's budget were in my opinion entirely beneficial for the Model 75's architecture.

Similarly, I observe that the external provision of an architecture enhances, not cramps, the creative style of an implementing group. They focus at once on the part of the problem no one has addressed, and inventions begin to flow. In an unconstrained implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.

If everyone in healthcare has to work under the same set of regulations, it's up to your creative mind to innovate your way into a competitive advantage. The bar is set pretty low as is, so coming up with ideas shouldn't be hard. Here's a free one: give patients and members access their data. Here's another: allow them to make basic operations without calling customer support.

You will notice that these things, while obvious, are not easily achieved. This brings us to the second point about innovation in our industry: it's not about tech. It's about cooperation with multiple stakeholders, corporate buy-in, research, listening to your members and patients, convincing your team and overcoming all kinds of business obstacles. Therein lies the difficult part.

Innovation in a heavily regulated industry is not impossible to achieve. Banking is doing it beautifully. So is e-commerce. So are airlines. What's stopping healthcare?  Let's get to work!

Throughout my childhood my dad used to say "If you start with a wrong button, the entire shirt is going to look crooked."

If you start a project with an unfitting stack, you will not be able to finish it. The worst thing? You will find out that it's doomed 60% into it, after spending most of your budget.

There are multiple scenarios why you might end up with a wrong stack:

• You might have been sold something that looked good in a demo
• You might not have had all the business requirements before start
• The discovery phase was limited in time or access to various stakeholders
• You might have inherited technology decisions made before your time

What do you do in this situation? I would suggest several steps:

1. Step back and re-evaluate. When a project is failing it's natural for strong leaders to thow themselves into the mix and start doing something. That would be a mistake. As leaders we have to think 5 moves and several years ahead. You need to ask youself: will fixing short term problems dig you even deeper long trem? Do we need to make a rollback to come up with a better solution that would solve a particular cluster or problems we are currently experiencing? Do we need to go back to square 1? What would be the impact on the business side? How would proceeding or rolling back impact organizational tactical goals?
2. Negotiate a multi-phase mitigation plan. It's very rare that you have to tear everything down and start anew. Can you salvage anything and release the project with a smaller scope? For a lot of technical leaders it's a matter of professional pride to build products properly the first time, I'm one of them. But we all have to contend with other constraints, like business goals, committments to clients, etc. As a tech leader, you can negotiate release of a slimmer project to meet outside requirements with a multi-phase plan to catch up on the functionality and technical debt. In that case you can still deliver value and buy yourslef some time for refactoring.
3. Hold an extended discovery phase and start to building a solid foundation. Once you've been able to take the temperature down by releasing a temporary solution, it's time to do a proper discovery phase where you can hear and evaluate needs of all stakeholders. This will inform your choice of underlying technology. This also would be a good time to get some people off the bus and pick up strategical fits for your team.
4. Follow-up with stakeholders regularly. What has worked yesterday will not necessarily be satisfactory today. Keep regular contact with all internal and external groups who depend on your system for everyday operations. Their feedback will give you a plan for future adjustments, ideas for new applications and ensure good adhesion between business and tech.

Innovation is not a destination, it's a journey. Good luck!

One of the gravest mistakes IT managers  can make is to ask their internal support team to develop new products.

Support and innovation do not mix, you either are in one mode or another. You either have a support IT team or innovation IT team. They are water and oil.

It seems counterintuitive, doesn't it? It's all the same skills: development, QA, DevOps, etc. The difference is the incentives and the mindset.

Support teams are measured by the uptime of all informational systems, stability of operations, security of the network and availability of all outwardly facing applications. Support team's mindset is to keep the status quo.

Innovation team's incentive is the opposite: they want to experiment, break things, combine services, integrate into new interfaces. Security is not their first concern. Building something new means disrupting the status quo.

One of the biggest issues that will come up over and over is misalignment between business sponsors of the initiative and risk-averse nature of support work. Business wants to get a proof of concept as fast as possible to get it into the hands of potential users (internal or external), whereas the team is incentivised not to release anything that hasn't been stabilized, properly secured and thoroughly tested. These projects inadvertently fail.

What's the solution? First, it's important to leave the support team to work on what they are good at. Secondly, hire a product manager that will have the innovation mindset, urgency and bias towards action. From there, the manager will have to assess current state of technology and either hire an result-focused team internally or work with an expert firm.

“If I had asked people what they wanted, they would have said faster horses.” – whether Henry Ford actually said that or not, this adage accurately describes both innovative thinking and a flaw that many of us have when thinking about innovation.

The flaw is to always think in incremental changes as opposed to conceptual changes. People in the 50s imagined that robots would do our chores as we would do them, by hand. It turns out that washing dishes is more efficiently done in a compact machine, sweeping through a vacuum on wheels and ironing by a chemical in out detergent.

When thinking about innovation in healthcare, we must avoid the same trap – healthcare is going to look very different in 5 years, we need to design for the extended timeline, not merely improving the process today.

Case in point, have you seen the Patient Room 2020, from NXT Health? It was designed in 2013 with an eye on 2020. This solution is an example of a "faster horse" because the designers made an errouneus assumption that in-patient care would be the same in 2020 as it was in 2013. It's not. In fact we are seeing a trend of providers moving more and more services to out-patient basis, making this design largely irrelevant.

How do we avoid this trap? We need to start thinking "where the puck is going" and be there with the solution, we need to solve for the future, not present. Neither Steve Jobs nor Elon Musk have used market research or surveys to determine roadmaps for their products, they could see where their industries where going and created that future.

In short? Hire a millenial and let them tell you what they do.

While most of the industries have moved beyond dreamy descriptions of how a mobile phone will change "the way we do X" to a more realistic approach where we explore only the next few steps, healthcare content authors are still at that stage.

For most of us in tech, post-2016 privacy controveries have had a sobering effect on how much we let our devices collect and know about us. Now we are moving past that stage into an even more concerning future, where data companies not only know our likes, habits and history better than ourselves, but now can dial in and out our visibility, contents of our posts and our ability to share content with peers.

I don't care that much about Facebook evaluating most I have to say, after all I make these posts voluntarily, knowing the risks and rules. Approaching healthcare innovation in the same way we've been thinking about social media would be the first step to a technocratic dystopia.

This other side of tech automation is why I would be very careful in implementing connected devices as part of innovation strategies. Collection of health data is not voluntary, this fact changes the dynamic of how CIOs should think about acquiring, storing and governing such information. If it's possible to do irreparable damage to a person's reputation by hacking their social accounts and email, think about how much damage can be done obtaining someone's health record.

On top of that, big tech is moving into the industry with their own data solutions. Knowing what we know in 2020, would you trust them with your patient/member data?

So, the question is: as the providers are moving towards decreasing the number of beds and shifting more and more procedures to outpatient services, how do we collect, store and govern patient's medical data in a way that increases the value of our services and doesn't turn into a huge liability?