Managing Organisational Change When Migrating to a Cross-Platform App Development Strategy

It’s not uncommon for companies with mobile apps to have a platform-focused strategy when they organise their teams, having an Android team, an iOS team, and a web team. This approach seems sensible when first considering skillsets, technical boundaries, and team cohesion when you’re maintaining multiple applications.

This organisational approach has the following issues:

Related Read: 5 Reasons to Embrace a Cross-Platform Mobile Architecture This article explores the migration to a cross-platform app development strategy, laying out a high-level approach to making the organisational change, taking your teams on the journey, and keeping what can be a massive digital transformation under control.

Before undertaking any digital transformation, there’s a need to assess how ready you are to actually undertake the journey. It is not enough to just want to make the change —  you have to understand the challenges ahead, so you can be better prepared to meet them when they occur. This part of the process is predominantly information gathering and preparing for the following stages of your journey.

Unlike digital transformations which can aim to modernise an existing architecture, or way of working, within the same technical domain ( e.g. keeping the same software programming languages), moving from a purely native approach to to cross-platform one requires introducing a whole new programming language alongside the architectural change.

Native development is overwhelmingly done using Kotlin and Java for Android, and Swift and Objective-C on iOS. Cross-platform applications use a completely different language; Dart for Flutter; JavaScript for React Native or Ionic.

The first step will be to understand the things your team already knows how to do. The likelihood, given that the web team is included in this, is that JavaScript will already be known to some degree of expertise. This gives a good platform for moving forward to a framework such as React Native.

All digital transformation projects have challenges. Being prepared for the challenges ahead is what helps separate successful projects from those which are doomed to fail. Each transformation project has different challenges, but some of the things to be mindful of during this type of a transformation include:

Many native developers like and want to keep doing native development. The move to a cross-platform framework is likely to cause an increased rate of attrition.

It is easy for the senior stakeholders to understand the business benefits for moving to a cross-platform approach, but the technical teams are the people who need to live with this choice.

Making sure the decision makers and technical teams are aligned reduces any risk around digital transformation projects in general, especially in the case where there are such large-scale changes.

The typical approach to migration is to do it slowly, using what is called the ‘ Strangler pattern ’, replacing a part of the application at a time. For a while this introduces more complexity while working towards an improved situation.

Engineers might be taking longer to implement individual features than they would on a single platform, which might make them feel slower.

It’s important to remind them that they might be taking a little longer, but they are building to deploy to 2 or 3 platforms, so overall the team is moving significantly faster.

The technical teams are the ones who will need to make these changes, and are best placed to understand what challenges are ahead, and the best outcomes for a successful future of product development.

Making sure that you continue talking with the team might seem like an obvious point. However, a lot of people make plans without consulting the experts who are already around them with a mindset that it’s those experts who caused the problems to start with.

Engineering teams want to build the best solution and sometimes they lose sight of the best way forward when put under time pressures, as we all do.

This also gives you a chance to assess how accepting of this new strategy your technical teams are. If they aren’t ready for the change then there is work to do to get them ready. If they are ready, willing, and positive about the change then your journey will be a whole lot easier.

Remember: this could be a complete change to the way they’ve worked before, and definitely a shift in  how they are working now. NearForm has the experience and expertise to help you assess your needs, potential risks, and help your team to understand and feed into the future solution.

Once you’ve done some assessment it’s time to move on to making a plan. Understanding what you want to achieve, when you want to achieve it, and the route to get there are all important factors in ensuring success, making sure that everyone pulls in the same direction and knows what to expect along the way.

Understanding the goals is essential. While there are multiple options for goals, in the case of moving from native to a cross-platform model the most likely candidates are:

Your existing team has the best knowledge of the domain, the technical challenges of the existing system, and a trustful working relationship. Ensuring that they are trained in whatever technologies are being introduced is an essential part of the strategy and should be one of the primary goals.

The existing platform-based approach to organisation doesn’t make sense in this context. Having multidisciplinary teams to look after the entire stack for a feature set leads to increased autonomy and velocity, and a more cohesive experience for both developers and users of those features. This article explores the subject in more detail.

Your high-level objectives will need breaking down into specific goals to hit along the way. Moving towards a multidisciplinary team, for example, will have many steps. These steps include things like figuring out what shape those teams should take, how large the teams should be, the sequencing of changes, and, eventually, naming individuals to be in those teams.

Once you understand your objectives and goals it’s time to set some timelines. Parkinson’s Law tells us ***work expands to fill the time allotted for its completion***, so we should need to set targets for each piece of work. Without these timelines the work will continue into infinity, and never complete.

There are many methods for estimating the amount of time something will take to happen. The best guide I’ve found is to use the Cone of Uncertainty .

What’s the best case, worst case, and realistic case for each goal? Hope for the best case, expect the worst case, plan for the realistic case.

In reality, most things will come in around the realistic times, some will be late, some will be early, and over a long timescale things will even out.

One other thing to consider when planning timelines is to build in ‘escape hatches’. These are places at which, if the plan paused, it would not derail the plan.

While there is always a desire to get to the goal as quickly as possible, these escape hatches are important to ensure that any high-value pieces of work can be inserted along the way. This placates the business folks, and ensures that opportunity cost is able to be kept to a minimum. At NearForm, we have helped many companies plan their digital transformations, including team restructuring, setting realistic timelines, and communicating with stakeholders.

As with any team, preparedness is key to success. As one of my former colleagues used to say: You don’t send a football team on to the field without training, and you shouldn’t send a technical team into such an important situation without training either.

I’ve already touched on the fact that there are a lot of technical changes in play, and making sure that your team are both comfortable and competent for the migration ahead should be the first thing on your timeline.

During the migration your team will be changing from using native programming languages, such as Swift and Kotlin, to a more generic language, such as JavaScript. This will necessitate some training in the new programming language.

Building cross-platform applications is carried out by using frameworks, whether this be React Native, Flutter, Ionic, or any of the other frameworks out there. Making sure your engineers understand the basics, and the potential pitfalls, of the framework will help reduce their development time.

There will need to be process changes, even if it’s as little as moving from separate codebases to a single codebase, or composite codebase, because your teams will no longer be working in a silo.

Understanding how to interact with other teams on a single product going forward is a must. If you’re planning to move towards a more cross-disciplinary team as well, then there are even greater process changes ahead.

Ways to prepare the team will depend on the outcome of the initial assessment and the plan. This means you will need to tailor your preparation to each case. Our team of experts is able and ready to help upskill engineering teams on new technologies, platforms, and ways of working to enable modernisation of existing teams, enabling transformations to be both seamless and effective.

Now that you’ve got a plan, and have your team learning the things they need to know, it’s time to start moving towards the objective. Managing the process will have nuances and differences depending on the exact situation, however, there are several things to take into consideration — whatever the process is.

Whatever the migration you’re doing is, understanding where you’re up to and how close to the planned timelines you are is an essential part of keeping ahead of any problems that are coming.

Based on the goals you’ve chosen and the timelines you’ve set, you should be setting out what you’re going to measure to understand how well you’re doing. These are some of the common things to measure:

How well is your team progressing at learning and understanding what they’re doing, and what they will do? The team is the powerhouse in making the project not only a success, but ready for the future, and making sure they are properly trained and supported as you go is key to success

Knowing how your team is feeling throughout the process is essential. You want to make sure they are feeling positive with what they’re doing and, if buy-in starts to drop, be ready to adjust the plan to make sure the team, who are your experts, are happy with what’s being done

Keeping a track of how much has been migrated from the old platform to the new one is important. If the project is a slower, strangler style migration then it lets everyone know how much is on the new platform, and how much is on the old one. If it’s a full migration style project it lets everyone know how far away you are from completion

The plan is a starting point and something used to bring people together, and get them pulling in the right direction. It’s built on assumptions and understanding at a point in time, and things will be learnt along the way. Being agile with your plan, adjusting the goals and timelines as needed, keeps the plan alive in the face of previously unknown dangers.

As things do change, either because of technical challenges or organisational needs, ensuring that these things are communicated is crucial in keeping people onside.

If you’re changing things and expecting others to understand what’s going on without telling them then you will be introducing confusion and reducing buy-in along the way.

Digital migrations can be a long, slow process. This can lead to fatigue and lowered morale from team members, and worries about progress from stakeholders.

Making sure that you are appropriately celebrating successes is important to both continue supporting and invigorating the team, and to keep stakeholders excited and engaged about the project.

As you hit milestones, even if they are late, you should be celebrating the success, and ensuring your team members have enough time to recharge and prepare for the next stage of development. Depending on the size of the success this could be as little as shouting widely about the success, to a full blown awards ceremony. NearForm can support your teams with project managers, skilled engineers, and a strong history of successful transformations to ensure that your migration projects can meet your needs while keeping stakeholders and teams informed.

As the transformation progresses there will be a point of diminishing returns. The 80/20 rule tells us that 80% of the outcome will take 20% of the effort, and conversely 20% of the outcome will take 80% of the effort.

This will lead to diminishing returns and the desire to simply stop the project at a certain point. Why continue to sink effort into a project when there’s such a small amount of benefit to be had?

Not finishing the migration will lead to masses of problems down the line, such as:

Sticking with the plan to get things 100% done will stand you in good stead going forward.

Once you’re done with the migration plan it’s important to reflect on the process and the result, and start preparing for what comes next. Ask yourself the following questions:

This will prepare you for the next stages of development.

As well as reflecting on the process, it’s important to keep sight of these points:

Without the focus on constant improvement then your shiny new application will start to build and retain technical debt, slowly becoming a problem for you and your team to work on, causing the situation you just moved away from to return.

I’ve given you a high-level approach to the organisational approach of migrating to a cross-platform app development strategy. If you’d like expert help in making this a reality for your business, contact NearForm today and we’ll discuss how we can help you take your transformation journey.