Beyond The Tech Stack for Successful Change Management

Aditi Kulkarni, Mike Dickinson, Praful Poddar, Izwan Ismail at UXDX APAC. Video: https://youtu.be/sex7gb379lE

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Izwan: Hi everyone. I'm really excited to be part of this panel and talking to amazing designers in the region. I think we have about 40 minutes, so we're going to start off. This panel is about successful change management, beyond the tech stack. I'm joined here by Aditi, Mike Dickinson and Praful. Guys, please introduce yourselves. Aditi, let's start with you.

[00:00:30] Aditi: Hi everyone. I'm Aditi, and I'm a UX manager at Shopify. Happy to be here, and excited to talk about this topic. I think it's very close to my heart.

[00:00:43] Izwan: Mike?

[00:00:43] Mike: Hey, I'm Mike, chief product officer for Brankas. I'm based in Singapore. We're solving for open banking in Southeast Asia. Hopefully I can elaborate on some of the COVID challenges that we went through, as well as challenges in previous roles at other companies. So happy to share.

[00:01:02] Izwan: Great. Praful?

[00:01:06] Praful: Hi guys. I'm director of product management, part of the OLX Group. Within the OLX Group, I'm working specifically for a business unit called OLX Autos. Essentially we're trying to create a car buying and selling experience in some of the emerging markets across the world. Really excited to be part of this panel and share some of my learnings, observations, dos and don'ts on change management, from startups as well as enterprises, that I've seen through my career. Thanks for having me.

[00:01:35] Izwan: Great. And as your final host, I'm Izwan Ismail. I'm design head for a regional bank based out of Malaysia, also the founder of UX Malaysia, and previously I ran my own company in the design space.

Change is about people, not just process

[00:01:52] Izwan: So let's talk about change management. I think it's an interesting topic. Each and every one of us has gone through some form of change. Aditi, your previous talk was about the storm and being in the change itself. What do you say about change management, to start at the very top of it?

[00:02:13] Aditi: I've worked in startups and large companies, and I think it's different based on the size of the company that you're working in, the size of your team and the market that you're in. But it's always hard, and it's about the people, not just about the processes. I think sometimes people focus on the process part of change management, when actually it's a lot about the human part. Overall, change can't be avoided, as I mentioned in my talk, and the best thing that we can do is figure out, as leaders, what our defaults are when we are in a really tough situation, and practice how we can get better with our default reactions to that change.

[00:03:08] Izwan: And speaking of change, Praful, you've been through quite a bit of change yourself, with OLX Group and changing ideas. Recently your talk was about the product that you were building to help people, using WhatsApp and video. That's a gigantic change there, if you want to touch a bit on that one.

[00:03:28] Praful: Sure. Taking a cue from what Aditi was saying, and specifically trying to link this to the tech transformations that are happening in large companies like OLX, I think the first and foremost thing is to really define why this change is taking place. Is it because the company wants to stay competitive? Is it because user needs are evolving or changing? Or is it because you're setting up for forward-looking success in the future, because maybe you're behind the curve there?

[00:03:59] At OLX, what was happening was we were largely pivoting from a classifieds model, which is largely marketing-run, where you throw in money and that playbook starts to operate on its own, to more of a transaction model, because consumer needs were changing and the competitive scope was also evolving, which required more focus on a product-centric approach. And similar to Aditi's thoughts, the aspect of how overwhelming this change can be, not just from a culture and people standpoint but also from a technology and adoption standpoint, can largely be underestimated. Even with an OLX Group backing, with all the kinds of resources you could have from a Naspers and a Prosus level, with all the experts and trainings that you can put through, getting it executed on the ground can be super, super hard.

[00:04:50] One thing that we realized, and I'll try and break it into two levels. One is really at the top level of management: you do need to take some hard calls. To give you an example, we were operating in a fairly decentralized team scope, where we had a lot of pockets of product, tech and design teams operating in all our geographies, more as teams supporting the business needs that were coming in, because with the sheer size of the team, that's all they could do. We took a hard call to say, "Hey, let's create one center of excellence, or maybe a couple of centers of excellence, where we can really drive product innovation and change across the board for our users," versus having to operate in that particular way.

[00:05:28] The second level is really about getting this adopted and getting people motivated for this new way of working. I think it's really about creating an example. Can you actually take a sample team or project, really create a case study out of it, almost do internal product marketing around it to communicate how it benefits the business and users end to end, and then try to replicate that across the board, piece by piece? Those are the two levels in which I could classify how some of these changes have worked for us, and what I've learned.

Growing teams and Dunbar's number

[00:06:02] Izwan: That sounds really interesting, because the two stages are very important regardless of the size of your company. And talking about scaling and the speed of scale, and even a case study: Mike, you are a case study yourself, at Brankas, scaling from a team of two to the size that you're at right now, 60 or something, if I'm not mistaken. And previously, having started with other companies, from a team of one to 20 or 30. That's a whole case study of change. Can you share a bit about the two or three learnings that you've gotten from that process?

[00:06:39] Mike: Great question. You have to remember that every single team and every single company is different. Ultimately, when it comes to growing teams, you're trying to address the needs not only of your customers, but also of the direct internal team that you have: how the company is structured, how the product is structured, what your business model is. It becomes exponentially more difficult, of course, when you're going through that hypergrowth phase as well, when you're having to hire fairly aggressively. I was talking to Aditi just yesterday about this, how growing in Singapore for Shopify has been a very fast and explosive journey for her.

[00:07:32] One thing to note is that, as you start bringing people into the team as part of this change, you have to remember that one person is one brain. Then you've got two people, and there's a communication line between the two. Then you add a third person, and you've got communication happening between the three. And when you get to the fourth one, that's when the communication lines start to grow exponentially. When you get to four, you think, well, that's not really that many still, because as a human being you can understand... There's this concept called Dunbar's number; if you don't know what it is, go look it up. It's the idea that your mind is not able to hold beyond a certain number of people in a three-dimensional space, a stereotypical space.

[00:08:15] It means that once you get past that number, people just become two-dimensional objects, and communication starts breaking down. No longer do you refer to that person as, "Oh, Fred the product manager, I've been working with him for a while." Now it's the product team and the sales team, and you never refer to individuals anymore, and the empathy starts to decrease. That's a battle that you have to fight as you get larger quickly.

Autonomy, empathy and the trust battery

[00:08:46] Izwan: I think that's great. Empathy is a very key factor. As designers, we are trained to do so, but sometimes it just kicks in with the fact that you're a human being. Scaling and change at work is one part of life. There's also scaling and changing in life, where you're growing your own family, with your own set of challenges that you're facing there, and this too is one person. In the case of empathy itself, I would love to hear from you guys how you use it to stabilize your team. Because change is something that's moving; change is an energy, and this energy can go in multiple directions. How do you use empathy to center it? I'll open it to the floor, to be honest. Let's make it fluid.

[00:09:40] Mike: Maybe I'll carry on a little bit from before, because it leads into that. How do you use empathy? There comes a point when you can't manage all the people underneath you. I've mentioned this talk a few times; it was from a few years ago, by Alex Schultz, the VP of growth at Facebook. It's a great lecture on growth, and he describes how it's just too difficult to go and micromanage each person. So there comes a point where you have to give autonomy. But when you give autonomy, it means that you need to have empathy as well, because there's an element of trust there. There's also an element of saying, what would I do in their shoes? How would you address pain as that person? So by this point you're teaching principles, rather than saying, "Hey, do this because this is important."

[00:10:33] So it's having that empathetic approach: understanding the problems of your team and how to address them from a more global, higher level, in order to drive direction without trying too hard to get into the nitty-gritty. I'm saying don't micromanage. There are situations, of course, with certain team members where that has to happen. Aditi is laughing because we were talking about this exact thing yesterday. But ultimately you can't necessarily micromanage every single team member, because guess what, they've all got their own hearts, souls and minds, and ultimately they're trying to solve a problem, and they're probably going to do it differently to you.

[00:11:21] Izwan: Aditi, do you want to catch that one? I feel there's a bit of energy that's going to come through.

[00:11:27] Aditi: I just want to add that I totally agree. I think trust... At Shopify we talk a lot about the trust battery, which has to be high in the team, especially when change is happening and lots of stuff is happening, and you can't always know what everyone is working on all the time, or you can't always know everyone's context, like you mentioned, their personal lives. You don't know what's going on with someone most of the time. So having that high trust and assuming positive intent is so important, to make sure everyone works well together.

[00:12:05] I do feel, though, that sometimes the word empathy is overused. I see a lot of people talking about empathy, but for me, what matters in the end is the actual action that you take to support your team or help your company change. It's easy to talk about it, but when restructuring is happening, or when things are really inconvenient, I feel like that's where your values really show as a leader. A lot of companies are really cool in the easy times, and then in the difficult times it's crunch time. The difficult times also have to be empathetic and caring, because that's how you get a productive team. It's good for everyone. So those were the three points I wanted to mention: the trust battery; empathy is too common a word; and action, what you actually do versus what you say, is important.

[00:13:08] Izwan: Cool. I like this terminology, trust battery. Can you explain a bit more?

[00:13:17] Aditi: There's this concept of charging your trust battery. When you're new to a team, maybe your trust battery is at 50, and then you work with people, hang out with them, get to know them, and charge it up. And it's the same with leadership, and vice versa as well. You should have that high trust, so that if something happens, you trust that, okay, I may not understand this totally right now, but there must be some thinking that went into it. Then you give people the benefit of the doubt, and go and investigate and figure it out. Of course, this assumes a lot of autonomy as well, as Mike mentioned. I'm assuming a culture of autonomy while I'm talking about the trust battery. It's the culture that I'm used to; I've rarely worked in teams where that isn't already there. So there's that assumption of autonomy when you talk about the trust battery.

Bringing people along on OLX's inspection change

[00:14:18] Izwan: I think three great points have come out of that: autonomy, the trust battery, as well as change. And Praful, all these three things are actually your case study. Talk a bit more about the change that you've done with the team, implementing a video-based assessment for cars [?] in that application, and it goes all the way to top management. I'm going to touch on this point, and I think all four of us should talk about it: governance. How did you do that?

[00:14:54] Praful: Just for context for everyone, what we're really attempting to do, and maybe not just us, I think a lot of SaaS-based organizations and other competitive organizations in the car buying and selling ecosystem are really trying to rethink: how does this inspection process take place? Does it need to continue to be such an operational, one-hour thing, where people need to drive down their cars and go through this? To make that come along as a solution that can be thought through very differently, almost consumer first, I think all three of these points, around trust within the team, autonomy for them to actually operate at a super high level, and empathy for each other, not just within the team but also for the consumers, are the key ingredients to make them succeed.

[00:15:40] For us, what's worked to date with this is, one, we've definitely let the team be. By having some goals which are very set for them, both quantitative and qualitative, let them operate and give them room to experiment. It's okay to fail on a small scale. We have millions of users; it's okay for a few hundred to have a bad experience. We can always come back and salvage that a little bit, but it's good from a pure learning perspective.

[00:16:07] The other thing, on the empathy side, which is more internal, which has really worked, and which Aditi was also hinting at, and which I feel adds to the trust battery as well: can you take people along, and not really look at them from just their expertise within a function? For example, I've had product and design folks who come in and bring the technology folks along only once the Jira ticket is actually ready: "Hey, this is what you need to code and deliver." There's so much lost before that, in terms of inputs, people getting onboarded, actually feeling for the consumer. Specifically for things where you're trying to make big changes, it's important to bring people along from the word go, and it could be small steps. I've noticed it's so much smoother sailing afterwards, versus trying to convince so many people at the same point in time later on.

[00:16:57] The rule of thumb that I've noticed in these meetings is when people start answering for each other. There's a question on design, but a product person answers. There's a question on product, but a tech person answers, and vice versa. That's when you really know that people feel for each other and they know what they're really building. So those are some of the things which have really helped us craft this team well.

[00:17:20] On the last bit, on internal empathy: while COVID has been a big, big challenge, and I know I'm using a virtual background myself right now, this sneak peek into each other's homes, with no virtual backgrounds, has helped build so much personal empathy, trust and understanding of what this person is really about. I encourage so many people: if you're not doing that, at least once in a while have the camera on, versus talking to a black box with a name, and do see what the other person is all about.

North star metrics and governance

[00:17:53] Izwan: Oh, definitely. I've run meetings with teams and stakeholders where all of a sudden my daughter just jumps in and starts mimicking my movements, the hands and the mouth and stuff, and here I am trying to keep a straight face. But it is what it is. We're living in a very different world. We're managing our own change, and it's crazy. There are a couple of factors. The point that I was trying to push to the panel is governance. You're talking about how you let people into the team, let them make the mistakes, and support that. I think that's amazing. In addition, we're talking about the trust battery again; we're seeing the same theme here. Mike, your recent talk was about the north star. How does the north star govern this, and what's your point of view in terms of governing teams?

[00:18:44] Mike: For sure. This really bakes in some of the comments that Aditi and Praful were making before as well. Really, it's that idea of driving towards a common metric of success. As a company you have a vision; well, I hope you do, and if you don't, then figure that out. It will help. But ultimately that north star metric, which is an amalgamation of a couple of metrics, helps drive the decision-making that happens within not just the product team, or the UX team, or whoever. It's to drive the organization forward, with what are famously called OKRs, or you can call them goals, or cascading steps, whatever you want to call it.

[00:19:39] The ultimate idea is that you get a situation where you've got this north star metric that people are driving towards. For example, at Brankas, each team, and they're now called cross-functional teams, has its own individual north star, because they're solving different problems compared to each other. But they also know that their north star has to tie to the company one. Then they have quarterly goals, three goals per team, and they have steps to execute those as well. What that means is that it's never, "Okay, I decide on the roadmap, and I'm going to tell you the priorities and what's coming up next." It's, "Please figure it out, because ultimately that's the metric that we need to hit, and if you don't, that's when there's going to be a problem. But I'm going to give you autonomy in order to get there." We align this with what our vision is and what we're trying to drive as a business, and that's the thing that you have to hit. But I don't care how you build the rocket ship; just figure out how to build the rocket ship.

[00:20:46] Izwan: That's pretty cool. Figure it out, move along and learn from the mistakes. But we're talking about Southeast Asia. We're talking about traditionally embedded business principles, not design. We're talking about conglomerates, and even Asia in general. This autonomy given to the team is fairly new and fairly interesting. Give me some points of view on this: what have you experienced? And is it important for us to have experts leading experts in moments of change management?

[00:21:30] Praful: Maybe I'll just add to what Mike was saying, and really drill down into what Mike was trying to elaborate with the north star, which is focus. With autonomy, a lot of the time what could happen is you spread yourself thin and try to do a lot, which again sets you up for almost a false negative, or a failure. Really articulate the north star, and take the time to articulate the north star first. And as I was saying in my talk, really define the problem well, because a lot of the time defining the problem is not something that we spend a lot of time on. It's, "Hey, let's just get started and start executing on solutioning."

[00:22:10] Just those two, I think, give razor-sharp focus to the team: this is the direction you need to go, and anything outside of it, you have autonomy to say no to. That is where leadership also needs to back that up, by making sure that you're almost creating a filter, or a backup, to say, "These are other things that the team is not going to get distracted by." I think that's a sort of governance. And then hold the team really accountable and responsible for driving towards the results. I think that creates a good governance environment in terms of making sure we're proceeding in the right direction. And then the classic: a lot of the time what happens is the ball gets dropped, and then you just pick it up after six months, or three months, or six weeks, and say, "Hey, where are we?" all of a sudden. Creating regular rhythms of taking stock of whether we're headed in the right direction really creates an environment of autonomy and responsibility that the team can benefit from.

Building trust remotely

[00:23:06] Izwan: I think we're hitting a really good note here. We have a question from Christiana, I believe. "There are many challenges in creating that trust with new people and teams that have developed from working remotely." I think this is the key phrase here, working remotely. "What kind of activities and/or communication have you done to raise that trust?" What do you guys think?

[00:23:27] Aditi: I could answer that. In terms of cultural stuff and remote, we do a lot of things to help connect people. I would say that our team in Southeast Asia, and Asia in general, is a bit better at remote, because we were doing it before COVID. Our team is spread across Japan, South Korea, Singapore, Indonesia and India, so it's a lot of time zones already, and that gives us a lot of good practice. One thing that we do, for example, fun stuff, is Friday hangouts. Another thing that we do is we have an olden-days, 90s-style chat room, where in the morning everyone logs in and says good morning, and then at the end of the day people say, "Okay, I'm signing off now." That gives the feeling of being in a room together. It's a virtual room, but it's still a room. People say, "Okay, I'm going to go cook lunch now." This is totally true, by the way. It's amazing, and it gives that warm feeling.

[00:24:43] The other thing that we've tried a couple of times is Secret Santa lunches. You don't know who delivered your lunch to you; it's randomized within the team. It can be hilarious, because somebody could do something terrible and send you food that you don't like, or it could be something amazing as well. So I think there are a lot of ways that you can create that real bond within the team remotely. And I hate to say this, but autonomy is really important as well. If somebody is micromanaging you remotely and there's no clear vision, as Praful was mentioning, and as Mike mentioned, that north star is really important, any communication problems become a hundred times worse in remote. So having that clarity is very important.

Agile and change management

[00:25:39] Izwan: That's very nicely put. We have a couple more minutes left. I'm going to give a couple of seconds to each one of you to tell me what you think about agile and change management. The word agile's been thrown around everywhere, with anything. Just a point of view: what do you guys think about change management and agile? We have silence. Nobody wants to go first, right?

[00:26:11] Praful: Let me take a stab. Just one line on that: I think agile is a means to an end. A lot of the time it's considered, "Hey, I'm agile, and I'm going to be successful now, as an organization, as a team." That's not going to work unless you really figure out the principles of agile. So I encourage people to actually read the Agile Manifesto every now and then, to go back to what it really means. The second is that the process should work for you, not the other way around. A lot of the time what we get caught up in is following the process. Just as an example, if I may share: we do these two-week sprints, and there's a production issue, and someone says, "It can only go out after two weeks, because I'm following an agile process." That's just plain stupid, in my view. If things are breaking, we need to break the process and make it a one-week sprint and get things out, or get it out immediately. So don't take agile as the silver bullet for solving everything, is going to be my view.

[00:27:13] Izwan: That's great. Mike?

[00:27:15] Mike: There's the agile concept in product development and software development, but to be completely honest, you can apply the iterative approach to teams in change management as well, which is actually exactly what we did at Brankas over the past year. We went into 2020 thinking, okay, we've got these products that we've planned, we need to grow the team. I had literally put the plan down after I had joined the company, and then COVID hit, and all of a sudden it was thrown out the window. So, okay, right: respond to the market, figure out what needs to be done. We need to change these roles. Who do we have here? Budgets have come down, so we need to figure out who's inside the company that can actually help. All that type of stuff. So you keep your ears on the ground, listen to the market, listen to the problems of your team and the rest of the company, and iterate, iterate, iterate. That's what we do, and it works; it's worked so far for us. And I'm sure we're going to go through another iteration in about three to four months from now.

[00:28:22] Izwan: Or a couple of weeks' time.

[00:28:24] Mike: Or a couple of weeks' time. So any of my team members on the call, just warning you in advance.

[00:28:29] Aditi: I think agile is great as a concept, but sometimes there are too many meetings. Especially for a team where everyone is high in the craft and just wants to do the work, let them do the work. I think it's very important to iterate on the process, remove meetings, and minimize the time needed for the rituals. I think you can try to go post-agile if possible. Don't get dragged down by too many stand-ups or whatever. Check with your team whether it makes sense anymore, and if everyone is cool, just delete stand-ups. I don't know if it's okay to say this, but let people just work, and get that half an hour or 15 minutes back in their day.

[00:29:19] Izwan: It's great. Wow. We're about to run out of time. I'll tie things together from the conversation and repeat back to the audience what we've talked about. Change management is less about process and more about people, and people require some empathy, for us to understand where they're at and their situation, especially in these unprecedented times that we're in. They're at home with their families, working and crunching spreadsheets and timelines and Gantt charts, trying to hit the time. But we often need to be a little bit more agile in terms of how we work together, how we help one another and build upon each other. I think that's a very important thing. With that, I really want to thank each and every one of you, Aditi, Praful and Mike, for joining me on this panel, and I hope you enjoyed me hosting it. Thank you so much.