BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Modeling Patterns for Digital Transformation

Modeling Patterns for Digital Transformation

Bookmarks
50:22

Summary

Asif Iqbal discusses understanding the consumer segment and needs, alignment with cross-functional teams, influencing and coaching changes, communicating often & celebrating success.

Bio

Asif Iqbal is a leader with 20 years of experience leading large digital transformation and technology strategies across businesses in wireless, retail, omni-channel, eCommerce, digital, entertainment, and data science domains.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.

Transcript

Iqbal: My name is Asif Iqbal. I currently work for a company called Couche-Tard, as a global director of digital and experience design. What that means in English, my teams are responsible for the website for North America, Canada, and Europe. My teams are also responsible for all the different native apps, we have quite a few, in Europe, North America, and in Canada. Part of this digital transformation journey is to bring all those mobile apps into one and obviously build omnichannel capabilities. In addition to mobile app and website, my teams are also responsible for experience design. It's our job and the team's responsibility to ensure that we have a consistent brand across all the digital channels, so website, mobile app, and what we call unassisted channel, so digital channel. That's what I do right now. I have about 19 years of experience successfully leading a large digital transformation in wireless, retail, mobile, and e-commerce domain. Of course, very excited to be here to share my digital transformation journey with you: good, bad, and ugly. Yes, there were some ugly digital transformations that I was part of. What that taught me was, what to do, what not to do, who to work for, who not to work for, and how to build teams.

A little bit about my experience. I had an opportunity to work with some great organization and learn from great team members, mentors, and bosses. Also, work for great organizations, the likes of Nordstrom, Walgreens, T-Mobile, Sony PlayStation, and obviously currently with Couche-Tard. In between, I had two years of opportunity and experience to work as a consultant in the consulting domain, which was awesome, actually great. I decided to go back to the corporate world to go back and work on a digital transformation. That's where the Couche-Tard comes in. I started working for them earlier this year.

Digital Transformation - What Is and What Isn't?

Once again, here to share my insight, my advice, and my experience, on how to bring digital transformation to your organization. I think it's important to understand, what is digital transformation to me, because it can be different for anybody, for you or for your organization. It's important to understand, what is digital transformation to me? What is it? Digital transformation is a mindset shift to enhance and create new opportunities for a business by changing how we operate and deliver values to customer and your shareholders. Why? Digital transformation, if done correctly, increases the development velocity, business agility, and delivers value to customers and your shareholders faster. It does. What is not digital transformation? This is not a digital transformation. I was part of a digital transformation where we literally ported everything from the legacy website or .NET, over to the cloud and said mission accomplished. Please don't do that. Lift and shift is not a good strategy. The approach often costs more in the short run and in the long run. At another company, we actually reviewed and evaluated the existing web features to ensure what we have, who's using it, how often that feature is being used. Then we built it using the cloud native tools to ensure efficiency and optimization. Remember not to do lift and shift, which is where we ported everything from .NET over to the cloud and said mission accomplished. In this case, we evaluated the features to make sure who's using it, how often it's being used. Then we built it using the cloud native tools with appropriate CI, CD, and CT, and obviously with robust telemetry. If you're wondering what CI, CD, and CT is, continuous integration, CD means continuous deployment, CT means continuous testing. Robust telemetry, the point of that is that whatever you build, make sure that you have a way to measure it. Having good KPIs, making sure your customers are using it, making sure where the bottlenecks are. If you have no way to measure it, you cannot improve it.

Overview

With that clarification of what digital transformation is to me, because it can be different for others, for your organization, for you, for whatever, which is ok. I will talk about modeling patterns for digital transformation that has worked for me. Four patterns that could be helpful for your digital transformation are, understanding your customer needs and habits, aligning with your cross-functional teams, listening, influencing, and coaching. Of course, measuring, communicating, and celebrating. At the end, I will share the case study from my team's current effort towards digital transformation.

Customer Segments and Needs

My professor at Ross will be so proud that I am finally using one of his models from the B School. If you're wondering which B school I went to, I went to the great University of Michigan, Go Blue. Let's look at this model. This model is so simple but important. What is it saying? Always think strategically. Means, what are the aspirations of your company? How do you compete in the market? What is required to be successful? Who are you competing against? In other words, what, where, and who? Before you do anything in life, especially in digital transformation, you have to know what you're doing. Where are you doing? Who are you doing it for? What, where, and who? Once you're aligned on what, where, and who, or once you're aligned on the strategic thinking, then you go and listen to your customer. Understand their needs. Create personas to understand, who they are. What they're looking for. How often she shops. Who does she shop with? What time does she shop?

As one of my favorite CEO from T-Mobile, always used to say this, John Legere, "Listen, and do whatever your customer tells you to do. They're always right." If you Google this saying from John Legere, you may notice that he may have dropped the F-bomb in there somewhere. Finally, experiment and gather feedback through research, indirect or direct customer feedback. Always start small with time box. Keep the egos at the door, find something quick, and fail forward. What does that mean with those two comments that I just made? The idea is that, get customer feedback directly or indirectly. You can do that through multiple means. You can do moderated testing. You can do unmoderated testing. You can put a simple survey page on your mobile app or on your website, or whatever feature you're building, and ask for feedback from your actual customers who are using it. Again, get direct or indirect customer feedback.

The comment about always starting small with a time box. What I mean there is this, if you have a great idea, or if you have any idea, or an idea, work with your leader to prototype that idea, try that idea. Do that with the time box in mind. Go and say, I need one sprint of work to do this prototyping to see how a customer takes this and how this idea works. Worst case, do it for two sprints, so 1 month. After that one month, or the timeframe that you've picked, if the idea doesn't work, it's ok, fail forward. It's not that your idea was bad. Again, that's where the ego comes in. It's not that your idea was bad, maybe it's not the right time for the idea. Shelf the idea. Go innovate something else, or come up with a new idea. Things like that. Again, fail forward. Try quickly. Prototype it. If it works, great. If it doesn't work, you're not going to get dinged by your organization. If you do, then maybe that's not the right culture or organization you want to work with. The idea is that, always have a fail-forward attitude. An important quote from Steve Jobs, "Get closer than ever to your customer, so close that you tell them what they need before they realize it themselves," that is, iPhone. Interesting story here. I'm sure there's still a company in Canada, who were in the mobile business. When iPhone came out, this company's comment was that customers will never adopt this new device, because they are so used to working using the keypad or keyboard on their device. Fast forward, we know where that company is right now, and where iPhone is, or where the smartphone is.

Aligning with Your Cross-Functional Team

No one person or team can do all by themselves or in a silo. It's important to invest the time on aligning the why with your team, the stakeholder, cross-functional team. Please, clearly articulate what's in it for them, not for you. Understand that your team may not embrace transformation because they're worried about their skills or lack of. Invest in relationship and show empathy. Support and train and empower your employees and your customers and your stakeholder. What does all that mean? Let's say you go to a company, and you're responsible for digitally transforming from point A to point B. Now you know that you have your team members who have been working in this point A system for the last 15 years. You come in and you say, we're going to go from point A to point B. You know what your team's first response will be? They're going to be, what happens to me? I don't know what point B is. What happens to me, does it mean that I'm going to lose my job? Empathy, put yourself in their shoes. Or your customer, when I say customer, I'm talking about your business partner, they may go and say, "I've been using this Excel macro for the last 15 years to create an order. Now this new guy is coming in, and he's telling me that they're going to digitally transform and all these ordering will be done by looking at the sales curve, order history, past history, how the demand is, that stuff." Her first reaction will be, "I've been doing this for the last 15 years, and we've been very successful. Why should I change now? What are you talking about?" If you go with a little bit of different mindset, you go and explain to them the why behind it. It could be as simple as, "Whatever you guys have done for the last 10, 15 years, it was great. It got our company to this point. In order for us to get to the x billion-dollar company, we can't keep doing the same thing and expect different results. We need to innovate. We need to do something different." Again, explain the why. That's number one.

Number two is, with your own team members, maybe have a conversation saying, "We'd like to go from point A to point B, and this is the reason why we want to do it. If you're worried about not knowing point B, we will help you train it. We will help you get there." From your business partner's perspective, obviously, here you have to have credibility chips. Once you have enough credibility chips, what you do is you work with them and say, "How about take a small department in your area and implement this new ordering process in that one system, one department, and wait for one quarter and see what the results are?" I guarantee you if you go with that mindset, and if you see the results, at the end, the people who were a little surprised with what you were asking them to do, they will become your biggest advocate. It has happened to me. I'm telling you, it always works. Again, understand the why, explain the why, and show empathy. Again, invest in relationships. Of course, having a good framework also helps. What does that mean? Make sure you have clear objectives. What are your North Stars? What platform are you going to use? Why are you going to use it? What key expenses you're going to deliver. When are you going to deliver it? How are you going to deliver it? Digital transformation is a journey. It takes time. It will not happen overnight. If any vendor or third party or some hotshot person comes from the FAANG and tells you that he can digitally transform your company, trust me, run away. It's not possible to do it overnight. It takes time. It can take over 9-plus months to digitally transform your organization.

Since we're talking about framework, here are some of the frameworks that I have used. For consistent branding and experience, I have used design system. To help with the prioritization, we have used WSJF methodology. Of course, always strive to create a flexible architecture with continuous delivery in mind. Finally, you don't have to do or know all. Leverage partnership to gain awareness. Don't reinvent the wheel, but stay ahead of the curve. What does that mean? Here's my philosophy about buy versus build. If you are trying to get a competitive advantage and want to build a killer feature in your app, or killer feature on the website that your competitors don't have, or you cannot buy it off the shelf, build it. Simple. Go build it. If you're trying to implement a system for ordering, means you want to order something. Order gets sent to the vendor. Vendor takes the order, fulfills the order. The order gets shipped to your fulfillment center or your distribution center. Then, at the fulfillment center or distribution center, they do pick and pack, and they send it to the different stores. The store receives it and sells it to the customer. All these processes, you go and buy product from off-the-shelf because those processes, you're not going to get any competitive advantage on it. You may get it by how fast they can do it, but system-wise, it's the same process. It doesn't matter who you are, which company you're using. They're going to use the same thing. Again, in that case, you go and buy it. Again, this is where you leverage your partnership to buy something. Maybe in this case, you leverage a partnership where you say that you're going to have exclusive partnership for this feature that you're buying, that your direct competitors cannot have for X number of years. Again, change is hard, but we got this.

Another great quote from one of my favorite books, "Start with Why," always start with why. Without a why, you have to resort to manipulation to get people to engage with your product or services, which only leads to short term results. Leaders who start with why get people to follow them willingly instead. Important. I've seen organizations where they have gone and hired a guy from FAANG, who only had 18 months of experience doing technical sales job, technical director of selling something. They hired him as an executive at this company. His big thing is he knows everybody by first name. Great. Doesn't understand technology at all. He has some ideas that he wants to enforce it on you without telling you the reason behind it. Guess what's happening with that company? Majority of the good folks who used to work there are no longer there. The people who are still there, they are there because, multiple reasons. One reason could be, they're looking for other jobs, to get out of there. Or, they're just there because they don't know what's better outside. The point I'm trying to make is, leaders who start with a why get people to follow them willingly. They're not there because other folks don't have anything else to do, so they're stuck with that in that organization. It's very important.

Listen, Influence, and Coach

Here comes my nerdy slide, what I call, listen, influence, and coach. I'm sure you have heard of the term DevOps. Coach your leaders and team that DevOps is not moving all your development and support teams under one leader and saying, "We are DevOps." That's not what DevOps is. One of my biggest advocates, a former CIO at T-Mobile, Gary King, used to say this about what DevOps is, "You build it, you own it." What that means is, as a team, there's no production support or development team, as a feature team, or as a team, you are accountable for end-to-end. It means, as a team, you're responsible for how the UX/UI looks like. You are responsible to develop it. You are responsible to support it. You are responsible for security. You are responsible for end-to-end. You're accountable. If you take shortcuts, this is what's going to happen, you will get called at 2 a.m. in the morning. Your MTTR will be completely out of control, because you need to own it. That's what DevOps is. That's what the good organizations do, complete DevOps accountability.

In my previous section, we talked about flexible architecture. This is what that means to me and why it's important. Break systems into manageable components, so use microservices, containers. Do things in smaller chunks, so you can test it easily. It's low risk. You can deploy it in the middle of the day. If it doesn't work, if you have a green-blue deployment, you flip it back, and you're back to normal. Do everything small, it's lower risk. This is a true example. At one of my companies, before the digital transformation journey began, we were doing monthly and quarterly releases, for all our digital products. Every month or every quarter, whenever we were pushing any new releases or new code in production, we were taking 12-plus hours of downtime, with maintenance pages on our site, and on our mobile app. Maintenance pages, 12 hours of downtime for the digital product, while we are doing the code changes. By following the above two methods, and with a shifting of mindset, with lots of hard work, we went to do multiple releases a day with zero downtime. Multiple releases a day, in the middle of the day, with zero downtime.

How did we do it? We invested in CI, CD, CT, in addition to obviously breaking the system into manageable components, mindset shift, lots of hard work. We also enabled CI, CD, CT mindset. What that means is, make code deployment boring and hands off. Why? It will help with your MTTR. What is MTTR? Mean time to recovery or mean time to restore. If you do things in smaller chunks, or smaller code, and you can do it quickly, test and deploy, and it is low risk. Maybe you implemented a feature in the middle of the day, and something went wrong, because we all test our code. Something goes wrong. You know you made the change. You can simply go and say, when did this problem start? Five minutes ago. What happened five minutes ago? This code got deployed. Use your green-blue deployment, flip it back. Your MTTR improved. At this company, our MTTR used to be a couple of hours for basic digital product problems. Just by doing this simple stuff, our MTTR went from hours to minutes.

Once again, you can't improve what you can't measure. Influence a culture where no feature goes live in production, without some telemetry. Then, obviously, use the data to make decisions. By design, I said some telemetry. You can't build a robust telemetry for every feature that you're building, but have a basic telemetry, basic KPIs. What is the performance of the feature that you're building? Has the performance improved or decreased? If you're building a mobile app, what is your DAU, daily active users? What feature you're implementing. How is that working? What is your bounce rate? Simple thing. You've got to implement some telemetry for the feature that you're enabling. As far as using data to make decisions, again, this is a fact. We use data to make decisions, and we got rid of what we call, eyes on glass team. These were the folks who used to sit in a room with four or five TVs, and they used to watch metrics on the TVs, eyes on glass. Depending on if certain metrics hit certain thresholds, they used to log in and run a script. For example, if a server is going bad, they will log in and remove the server from the rotation. Just by enabling a data-driven decision and by automating those with scripting, we were able to save $5 million to $6 million in OpEx in one quarter. Huge savings. If you go and tell your CIO, or CTO, or a CDO, that you saved $5 million to $6 million in OpEx in one quarter, he or she may give you a hug. He may just take a picture with you, with his or her arms around you that you can post on LinkedIn, or Twitter, or whatever the social media you use, and get some likes, whatever works. The point is, there's easy ways to do these things. You can't improve what you don't measure.

Communicate and Celebrate

Continuation from my telemetry discussion before, enable self-healing systems for critical flows. Practice agility. You don't have to know all, seek out partnership as a differentiator. What do I mean there? For example, if you want to enable CI/CD in your organization, and you don't have the expertise. Go find a vendor who has done this, who can come in and give you a framework on how to enable CI/CD. The reason I did not say CT, continuous testing, you cannot get a vendor to come and help you build a continuous testing framework. Those tests are specific to your product, your company, your areas of expertise, your system. You cannot take from someone else's continuous testing script and say, I'm going to use it here. That will not work. Use the partnership to build your CI/CD framework, as just one example. That's the idea.

Over-communicate, and communicate often. You can do this through townhalls, roadshow, a sprint demo. I've been with this new company, Couche-Tard, for about 11 months, and you have no idea how many times I've spent on traveling, and talking to, all the way from C-suite, to wonderful folks at the store. Just to tell them the why we're doing what we're doing, how that's going to help them, from a C-suite perspective, how that's going to help their EBITDA. From wonderful folks, store perspective, how that's going to make their life easier. Because as you and I know, that folks at the store have so much going on that if you can take one thing away from them, it just makes their life easier. Communicate. Over-communicate through multiple means. Obviously, you can also do moderated testing and unmoderated testing.

Lastly, I cannot emphasize this enough, celebrate every success, it doesn't matter how small. For example, after every sprint, take your team out for drinks, to whatever they drink. If you see that one of your team members is working very hard, or working off-hours, why he or she is working off-hours, that's up to you. Because if you have done your job correctly, there should be work-life balance. For some reason, if that happens, get him or her a gift card to a favorite restaurant that they can go with a significant other or with their family. If this person is in sports, like I am, give them tickets to a football game, basketball game, or tennis, or golf, whatever works. The point I'm trying to make is that, recognize your folks when they're working hard. Celebrate every success, it doesn't matter how big or how small. Yes, you do a demo after every sprint, even for backend without fancy UX/UI interfaces. Two things, this brings transparency to your stakeholder, number one. Number two is, you have no idea how many times your stakeholders want to know how soon the data will be available, or how soon the data gets updated. If you have just backend, you don't have UX/UI fancy interfaces, run a script, and then show them, I just ran a script and within a second the table got updated. They will appreciate a lot.

Finally, give your time to innovate. You can do this multiple means. This is what I have done. Take 10% of your story points in every sprint and allocate that time for either innovation, or for tech debt. That's one way of doing it. Other ways, maybe doing monthly or quarterly Kaizen events. This is where what you say is every quarter, every month, you give four days break to those teams, so they're not working on their core product. The idea behind those four days, is that three days, they go and work with either cross-functional team within their own team, and come up with any creative idea to make their life easier, to make their customer's life easier. The idea could be as simple as that, that right now, the change management process in order to push a code in, it takes five different steps. Partner with change management team and come up with one step, it could be anything. The idea is that, out of the four days, they use those three days, and the fourth day they come back and provide a presentation as to what that idea is, and how that idea is going to help their team, them, or the customer. That's one way of doing it. Other example could be using your mobile app to maybe scan a prescription on your prescription bottle, instead of people entering the prescription by hand, manually. Maybe use the camera on the back of your phone, and scan it, and scan gets sent, or prescription gets scanned and it gets sent automatically to your pharmacy for reference. It could be anything. When you're innovating, what usually doesn't work is building an innovation team to innovate. Great organizations don't depend on a small number of people, teams to come up with innovation. Instead, they create a culture in which every employee is encouraged and empowered to innovate.

If you go and look at my LinkedIn, you will see there's a company, my title was a director of digital development and innovation. We got some conflict there, because my other team who were doing development work, their comment was, why are these teams so important that they are in the innovation team? You know what we did? We started rotating people. There was no one team who's responsible in a way. The idea was that anybody, we all are innovators, we all should innovate.

Case Study - Global Mobile App Program

Here's the case study from my team's current effort toward digital transformation. Team did research, learned about our customers, and created personas. Explain the where, what, and why now. Align on the framework with very clear North Stars what our platform objectives are? What key expenses they're going to deliver, and when, and how we're going to prioritize it? Then we used the WSJF model to prioritize those features. If you're trying to take a screenshot of personas and the framework, obviously you will see personas are dummy personas, because we really can't share our personas with you, because we don't want to share it with our direct competitors. Obviously, we don't want to share what the North Stars are. We don't want to share what other key experiences we are building, and it's coming. That's the reason why you see some black boxes, and also see the personas as dummies.

We communicated often at every level of the arc. Remember I told you that I have meetings all the way from C-suite to one of the people at the store. Again, we communicate often at every level of the arc. We enable telemetry to observe and measure and use data to make priority decisions. Using the 80/20 rule, we deployed the early access version of our mobile app, I think, in the first week of August. If you really look at the app that we enabled on August 1st to now, it has gone through multiple iterations. That was the idea. We didn't want to wait for perfection to put the app out. We wanted to get the app out in front of our customer and get their feedback, and implement those feedback. That's where the 80/20 rule comes in. We have added so many features that customers were asking for. For example, they wanted to see the fuel prices on the homepage, we added it. We could have spent six more months making our app perfect. That's too late. Always use 80/20 rule, and then listen to your customer to iterate on your product. Where we are now, we are on track to build a Circle K in a Pocket with these features. Finally, our goal is to have a team win the Webby Awards in 2024. As you can see, we have feature 2, 3, 4. What we're building is very cool.

Key Takeaways to Digital Transformation

The key takeaways are people, process, partnerships, and technologies. Digital transformation is not about new, fancy, cool technologies, or tools. It's a mindset shift, and requires awareness and understanding of your customer needs. This is what we say in my team, "This is not the end, it's only the beginning." Partnerships are very important. You don't have to know everything. You don't have to be know-all. There are some stuff that you can partner with your other vendors who can help you with it because they have done it. Don't start from scratch. Those four things are very important.

Questions and Answers

Reisz: Focus on your core competencies. If you can outsource something that isn't a core competency, a core differentiator, why not?

One of the challenges I've faced with some clients with transformation, is that mindset shift that you talked about at the very beginning. I get this, how long is it going to take question all the time. Despite even saying, this is a mindset shift, it's not about checking four boxes to get someplace a month later, or a quarter later, or six months later, a year later, when is this going to be done? How do you deal with that? How do you deal with and really drive home, particularly at senior leadership levels, that what you're embarking on is transformation and it's a mindset shift, not a checklist of things to lift and shift something to cloud, for example?

Iqbal: I think that's where I gave an example about lift and shift, because there was an organization that I worked with, and our executives, the big thing was, we want to get into a cloud, because that's a new thing. Just take everything from here, point A to point B, and say we are done. That's not how it works. What you do is, you have to show empathy. You have to understand the why behind it, from the executives, like, why do they want to do certain things so fast? Then understand their point of view. Then show them, there's a better way of doing it. Yes, I can do lift and shift for you right now, but long term, it's going to cost you more, because we want to do it the right way. Executives, whenever the cost comes in, or EBITDA comes in, that gets the point across.

That's number one. Number two is, it's possible sometimes that you maybe do something hybrid, where you do some lift and shift, but still have a plan to do it the correct way. Again, open dialogue, talking to them, understanding their reasoning. Then understanding the outcomes they are looking for, and coaching them, mentoring them to say, this is how we can do it. At the end, finally, they write you a check, they are the decision makers. Sometimes you have to do it just to get what they want us to do, because there's a business reason for it. They understand that.

Reisz: How do you get people on board? You talked about starting with why. You talked about being empathetic. Any strategies on really getting people on board and overcoming that resistance to like, we've always done it this way. How do we really get them on board to do a digital transformation?

Iqbal: Relationship building. You have no idea how much time I've spent on what we call coffee breaks or coffee talk. Take people out. Before you want their help, like your business partner, take them out to a coffee. In that coffee, you're not talking about what you're trying to do, get to know them personally. Know who their kids are, what they're interested in, what sports they like, things like that. When you get to the point where you need their help to transform, or to change the mindset, they know that there's nothing in for me or you, it's what's in it for them. Relationship building, spending the time with them before you need their help, things like that. Those are the core principles of build relationships, when you need help, they're there to help you.

Reisz: When you were talking about the HIP, innovation and planning and getting tech debt, and you talked about doing hackathons. I think that's another great way of building relationships between teams, just like you get into your silo working in your team. These hackathons let you break down some of these things and work across teams. Work together on maybe a data team that isn't maybe your core area, for example, and really see how you can bring some of those in. I think those are other great ways to tie in what you're saying.

Iqbal: We just don't do Kaizen events within my team. Like you said, that kills the purpose. We will bring legal team, we will bring data team, we will bring change management team, and we will bring product team to say, this is what we want to do. What can we do? How can we partner together to do something like that? Kaizen works but you will not get as much benefit if you just do it within your own siloed team.

 

See more presentations with transcripts

 

Recorded at:

Apr 07, 2023

BT