Becoming Digital means more than to have your backend on an API

Are you tired of reading about how every company will be digital and those that don't are doomed to fail whenever new technology comes around? Endless stories about how technology will destroy companies that refuse to evolve. How customers will run away from your business and flock to a competitor with a new algorithm. And even some of those stories being true, we understand the technology itself can do little without a strategy to apply it correctly. This image states this point in a fantastic way:<figure class="kg-card kg-image-card"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/1c/60/1c60e9bf-9de2-46fa-93c5-15bdb7a85e2a/not_technology.jpg" class="kg-image" alt="alt text"></figure>It's not about what technology you use. It's about what business opportunities these technologies can unlock. It's about to offer better customer service. About really listening to your customer, talking, reduce costs and so much more. This varies from one business to another, finding a single answer to this complex question is tough, but there are a couple of things that will help almost every company: Think digitally about internal processes, understanding the new customer journey, and Venturing Beyond.<h1 id="thinking-digitally-connecting-the-parts-of-your-organization">Thinking Digitally: Connecting the parts of your organization</h1>One of the main hindrances that stop companies from fully taking advantage of technology is what Salim Ismail, author of Exponential Organizations, calls <a href="https://medium.com/@salimismail/overcome-internal-resistance-to-exponential-growth-30167ea12426">"the company immune system"</a>. Salim exemplifies how companies can, unknowingly, create rules or processes that hinder innovation. Let's say, for instance, that your company discovered a way to use Blockchain, to answer clients faster and never lose track of activities again. But it needs information from the shipping department for that. It's here that the problem starts. The folks from the shipping department have a rigorous rule about sharing data due to privacy issues. Instead of figuring out a workaround that could respect their privacy concerns and still share the data, it's easier to drop the idea and keep doing things the way they were. To innovate using technology, strategic pieces of our business need to be able to talk to each other, share information and insights, as well as create value together. The first step is to clear communication. The executives need to acknowledge that there are multi-department demands and encourage initiatives that help bridge the gap between departments. Without support from the higher ranks, any attempt at connecting different departments is doomed. After that, it's paramount that this cooperation in no way hinders the actual work of the department. In the previous example, if the Blockchain integration causes the shipping department to lose deadlines and underperform, it'll be shut-down in no time. A safe option here is to create a systematized way for departments to interact, demand and receive outputs from each other. Departments will always manage their activities differently, but if you create one communication channel for each department where others can input their demands, you can drastically reduce overhead as the department learns how to deal and include these requests in their daily routine. Even if the managing works through a monolithic CRM/ERP, a development shop can be hired to create or integrate a communication tool upon that. The important thing is not to let the existing barriers stopping the company from evolving.Once you start breaking barriers and supporting cross-department interaction, your business will be able to address and experiment way faster with any new technology or app that people feel might do good work for the whole.<h1 id="digital-journey-no-more-single-point-of-contact-with-the-customer">Digital Journey: No more single point of contact with the customer</h1>Until a couple of decades ago, depending on your product/service, you could pinpoint exactly when a possible customer would get in touch with your product. On the way to work, leaving her/his kid at school, at the supermarket, late night at home, and so it goes. But some ten years ago things changed, we started carrying multiple devices wherever we go. Add to it the fact that we're spending progressively more time connected to the internet and suddenly there are a plethora of different touch points someone can get in contact with your brand online. If used correctly, this means a way more personal approach and conversation. However if not successfully used, <a href="https://www.canny-creative.com/top-website-design-mistakes-fix/">several things could go wrong</a>. Let's use Spotify example. Their clients use them to listen to online/offline music. So maybe a customer might be using it while grabbing an Uber, while at work and even while he's talking with someone. Every single user has specific needs and contextual preferences. Currently, it's natural for a company dealing with these scenarios while more possibilities are created every day. Thankfully there are ways to circumvent that. But it requires a change of mentality. There is no way a company can map every single possible interaction with your system, especially if you are a big company with multiple applications. So you need something to make your solution way easier to plug things in and out and that works both ways (so people will also be able to plug-in with you and make your integration smoother). In our understanding, the easiest way to give this first step is to create an API for your business. An API, in a quick, non-technical, explanation, is a standardized way your software will ask and answer things from other software. The problem is: turning a system into an API is quite difficult and expensive. Usually the two better solutions are:<ul><li>To create an API version of your software from scratch (and let it deal with simple cases and connections until you understand better the multitude of possibilities);</li><li>Wrapping your system into an API, allowing it to answer and make requests to other applications.</li></ul>The key point here is to understand that this is not something made in a 48-hour hackathon, but something that specialists need to be doing. Otherwise, you risk not getting the connections done correctly, difficulting the access of information. But when it's well architected, you will be able to evolve your old system into a platform for all your departments and partners plug-in and innovate together.<h1 id="venturing-taking-the-chance-to-create-new-value-propositions">Venturing: taking the chance to create new value propositions</h1>In the first section, we’ve already discussed how you can create institutional ways to reduce friction between company departments and how that accelerates experimentation and, consequently, innovation. Also, in the second session we discussed how changes are required outside of your company and how it communicates and connects with vendors and partners. But both of these changes demands something more: Open your mind to experimentation.There are a lot of concerns regarding being more open to experimentation, but a couple of disclaimers need to be done:<ul><li>We realize culture is sometimes intangible and measure the effectiveness of change can take longer than a quarter, but steps towards this are necessary to fully take advantage of the changes we described in the previous sections;</li><li>Statements from the high administration that call for more experiments to be done will hardly change the situation when not backed by functional measures: from managers talking more positively whenever someone presents an idea to them, passing through giving time for people to experiment, all the way to congratulate people whose experiments gave light to new products/services. </li></ul>On that end, there are a couple of measures already being developed by big companies that can give some results:<ul><li>Amazon has implemented a process called <a href="https://hbr.org/2007/10/the-institutional-yes">Institutional yes</a>, it’s a way to encourage employee experimentation. The rule states that for any given meeting, to deny an idea or experiment would require the manager to send an email of at least two pages explaining why the idea was rejected. This was a great way to give more weight to the decision not to experiment and keep things as they are.</li><li>IDEO takes a way more risky approach, but that also brings excellent dividends. Every couple of years, they take a couple of board members and create a spin-off company whose mission is to “try to beat IDEO at its own game, using the more recent and up-to-date practices and products.” The experiment lasts for one to two years, and after this time the board is re-incorporated, and any new thing they learned is included in IDEO’s processes.</li><li>Another interesting approach is to hire a partner that can create a spin-off product or process and run the experiment with you. Some companies have even modeled themselves to take only this type of service. They are called Venture Builders. They can work either with a pre-existing team or hire someone outside of the company to lead the experiment. Venture Builders can be very specialized on it, and hence, more expensive, but many digital partners of product shops could do this service as well.</li></ul>The message behind this blogpost is that it’s understandable that a lot is being said about organizational catastrophes related to digitization. Many of those bring clear problems to light, while many others are more alarmist than necessary. But the essential is understanding that going digital is not something you can solve with a bigger tech team. It requires changes in the organization ranging from how people interact, to how your company thinks about its product. Although it takes time, the first step is always to agree what kind of process is more fit for your company and how much risk can your accept while experimenting.

Becoming Digital means more than to have your backend on an API

Join the Tech Forward newsletter

Related articles

Uploading files from the frontend to Amazon S3

Gearing up: the challenges of managing a growing team

Database concurrency in Django the right way