The Key to High-Performing Platforms: Product Thinking & Developer Centricity with GM Financial's Henri van den Bulk

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand. Let me kind of push the envelope. Let me fully enable you to make decisions yourself. People will just first, they will step up because they're like, wow, this is amazing, because you've given them the freedom and you remove all the other challenges around them. On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of. Hey folks, welcome back to the Convergence.fm podcast. If you've ever worked on a platform team or in enterprise technology where you're building a shared service that multiple application teams will consume, your work is definitely extremely important. It helps bring speed and efficiency to all of those product teams, and it enables them to focus on their customers and building value there,

[00:01:02] rather than having to build a lot of the basic non-differentiating features that can sometimes take a lot of time and effort. That being said, it's also really hard to build a platform that developers love and find both useful and usable. And you've probably faced some version of these challenges, like how do you balance standardization across your organization with flexibility to enable speed and innovation?

[00:01:31] How do you build a highly usable platform that enables the innovation rather than stifles it? How do you structure teams so they can work efficiently without getting bogged down by dependencies on each other or duplicating their work? Too often, platform teams roll out new tools and capabilities only to find that adoption is low or that their customers, the developers and the product teams are frustrated.

[00:01:58] On the flip side, if you don't set the right guardrails and abstractions in your architecture and delivery, you risk diluting your strategic efforts, duplicating the work across the teams, and even ending up with an unmanageable architecture that's slow and expensive to maintain and modify. Today we're talking with Andriy Vandenbok. He is the vice president of global software systems at General Motors Financial.

[00:02:22] And on the talk, we'll unpack these challenges as well as share practical solutions from Andriy's experience. Andriy spent his career helping organizations design platforms, align their teams and scale their technology effectively. Coincidentally, like myself, he started his career in electrical engineering and then transitioned it into software and eventually into artificial intelligence driven platforms.

[00:02:51] And he's worked across financial services, energy, big tech, and even worked at NASA. Andriy and I worked together at Pivotal at the same time where he helped enterprises with adopting outcome driven approaches to technology. And now at GM Financial, he's focused on platform architecture and organizational strategy at General Motors global scale.

[00:03:15] In the conversation, we cover a number of topics like how to define the term platform and how a true platform is more than just infrastructure. We talk about the term value line, what it is, and how it helps you make really smart platform decisions. We talk about how platform teams can build trust and avoid making their own customers alienated or even obsolete.

[00:03:42] We talk about managing dependencies and technical debt, especially in large enterprises. And how product management is just as critical for platform teams as it is for product teams. And finally, we talk about team topologies and organizational design and how they directly impact the outcomes that your platform can build and the success of your platform.

[00:04:06] If you're responsible for building, maintaining or even working with platforms, this episode will give you a few frameworks for making better decisions, driving adoption amongst your customers, as well as enabling innovation amongst those product team customers and inside your organization. That all being said, let's get into it. Here is our chat with Henri Vandenbalck. Subscribe to the podcast to get future episodes as soon as they're published.

[00:04:35] If you find this helpful, give the podcast a five star rating on your podcast app or hit that like button on YouTube. Thanks a lot for joining us. Thanks a lot for joining us. And I've been really excited to catch up with you. You are definitely very versed in outcome based delivery, outcome based work.

[00:04:55] And something that kind of pushes on this, I think, is the intersection of team topologies and platform architecture, something that you've gotten to work in and something that in my past can be very crucial in terms of determining how painful or how seamless your future can be. And doing the right decisions and applying the right discipline today can make a huge difference.

[00:05:19] So before we start to get into the details of it, let's maybe do some level setting, maybe define in your terms what is a platform and what is a system as a platform or systems as a platform for you? At the end of the day, it's just a set of capabilities that really helps solve several customer problems in an opinionated way.

[00:05:39] Right. And at the same time, it also allows you to extract those capabilities so that customers can also build on top of these so that they can focus on the proverbial being above the value value line. And at the end of the day, that's how I look at the short case that because people get too much confused about many different systems, applications, what's the difference on it.

[00:06:07] But if you just focus on what customer problems you're trying to solve for and allowing them to extend on that, that's the key definition for me. And so you mentioned above the value line. Maybe tell us, I have a guess as to what that means, but tell me a little bit more about that. If you're building a solution, what is valuable in what you're building?

[00:06:29] Right. And to give you an example, if you're building a financial services platform, for example, or a product, fill in the blanks, you're trying to solve a set of problems. What you're probably not interested in is solving some of the technical infrastructure type of pieces because a customer is not willing to pay you for solving those things. What they're willing to pay is, are you solving their problems?

[00:06:55] And so the value line is an important distinction to say, like, where are you delivering value for your customers that they're willing to pay you for? All the other stuff, they're not willing to pay for. And when you're in the world of platform architecture, that's probably an ongoing debate as to, is this something that we want our customers or our consuming developers to create value at that level?

[00:07:24] Or is this something that they might expect for us? And it's undifferentiated. How do you sort of, what's your north star or guiding light that helps you with that? And how do you teach your teams on having that discipline around what goes into the platform and what is something that you expect your users to build? Yeah, I like that phrase, undifferentiating aspects of it.

[00:07:49] Because at the end of the day, you always have to ask yourself the question is that what value are you creating for the customer? And that's a key way of making decisions here of what you add to the platform or what they should be creating. And part of it is also looking at like, how many problems are the customer having? Are they having toil in the things that they do? And again, this depends on what your platform is, right? Again, all times I fall back to financial services because it's an easy reference, right?

[00:08:17] If you think about platforms like Stripe, for example, or other payment platforms, they remove lots of toil. And they're always constantly looking at like, well, is this a feature that the customer should be building or that we should be building? But the way to look at that is you got to look at your customers and building empathy with them around what problems do they have? And what can I put into the platform that removes it from their side of the equation, right? Without dipping into their value stream, right?

[00:08:46] You don't want to compete with your customers too much. But at the end of the day, it falls back to like, what problems are you solving for them? And there's never a perfect answer to that. You constantly have to evaluate what things are they running into? What challenges are they having? And so for things like observation of the customer, the inquiries, quantitatively and qualitatively, you have to take that in and use some product management discipline.

[00:09:12] Because at the end of the day, this is disciplines that product management has really figured out. Like how do you build the best product? Well, it's by going after the product, the problems that the customers are having. And then ask yourself the question, well, what value is it creating for a customer? Right? So I think I simply look at that as sure because like, well, you know, you have to bring value to your customers. And if you keep focusing on that, your teams then also stay focused on solving those problems. And not as much on solving technical problems. You want to solve the customer problems.

[00:09:42] So help me understand that a little bit more because I get the theory of it. But what might make it a little bit more tangible is if you have an example from your past, maybe that you had to make that hard decision or your team did. So if you think about like Stripe, I'll use that as an example because it's a good example. Is in financial services, if you have to have payment gateways as a customer, right? You have to interface with many different banks. You have to interface with credit cards and all kinds of different areas.

[00:10:12] And if you then take that internationally, there's many different systems you have to think about. So as a customer, or if I'm building a financial services application, my toil there is having to do all these interfaces and maintain it. That's below the value line per se, right? And so Stripe has really figured out like, how can I extract those things so it doesn't cause that many issues, right? So that's one of the motions that they've really looked at.

[00:10:41] In my past, I've seen that as well when you're building platforms, for example, in the financial services where we observed customers having a lot of challenges on trying to figure out certain valuations for companies, for example. That they had to do over and over again. They had to calculate these things. And as you start seeing that, it's just a common thing that you can commoditize or standardize in your platform.

[00:11:09] And we make the decision like, well, why don't we incorporate that into the platform instead of having them having to do this all the time. But then you also have to rigorously question like, well, at the end of the day, it's a thesis that you have. Like you have observed that there's a problem, but then when you build it, you also have to test it out that are they really willing to pay you for it? Or are they really saying like, yeah, this is a benefit for us? So we have to do that, but you constantly have to do this motion to figure it out.

[00:11:38] You know, I love that we have you from thinking from the platform standpoint. And I think on behalf of the app developers, especially the founders and folks who are working on startups here. There is this fear of the platform making your application or startup obsolete, right? I think we saw Apple do it with iOS way back in the day.

[00:12:04] Maybe some of us forgot because a lot more of the noise now is startups that are based off of the OpenAI API. A ton of them just kind of go to the wayside when OpenAI provides that feature natively as part of their next release. And Sam Altman came out and said like, yeah, if you're going to try and compete with the platform, then you're likely going to get absolved. But if you are excited about the next release and what we can do next, then you're likely going to be here for the long term. Yeah.

[00:12:34] And it still feels a little bit abstract to me. So I'm curious, you know, if you were building an AI app, what are some of the things you're just going to be excited for OpenAI or one of the other models to be able to do soon? Where you feel protected in your business and your startup versus what are some of the things that feel risky like, hey, they're probably just going to come in and install that feature themselves or develop that themselves soon. And, you know, this business is going to go out of business. So what's your instincts on that?

[00:13:05] Yeah, it's time will tell you, right? You give some great example, Apple. I always can give the example of Apple, the flashlight feature. OpenAI has done the same thing, right? There was an app for that, for the flashlight feature, right? Yeah. For recognizing that incorporates it into the platform, right? OpenAI, no difference. Amazon, no difference. They all do this because they recognize that it creates people like a feature or a capability and they just incorporate it in the platform. It creates stickiness for the platform.

[00:13:35] Now, I'm not justifying that that's right. I think as a platform, you also have to make sure you create trust for those that use your platform, that you try to avoid those things. Like your platform is to enable others. It's not to just get pure gain for you as a platform, right? And there's not that many that do this, but I fundamentally believe in that aspect of it. But on the other part of your question is like, how can you avoid that?

[00:14:03] I think what it only comes down to, if you have an idea that is not just a generic idea of using a platform, you don't have a moat, right? As a startup, you have to think about, do you truly have a moat in your idea? And can you truly continuously innovate? Because as long as you can keep innovating in your space and you can establish a moat, you will always outcompete the platforms, right?

[00:14:32] Because in one sense, platforms are trying to standardize and look at the whole thing and then bring these things in. But there's a delay for them to actually build those things, right? And so the startups that are really good, they don't just look at another chat, GPT type of feature. That's like anybody can build that with the platform. But are you really solving some critical business problems that are really unique in your space?

[00:15:01] Then you can start establishing a moat with your customers, right? That they need your capabilities. And most platforms can't compete with that part. Because again, they're trying to focus on the common denominator and getting stickiness in that area, right? And the fact of the matter is, it's not just one platform, right? OpenAI is competing with their own competitors on the platform level.

[00:15:23] And so making things more convenient for their other developers and more attractive so that you choose the OpenAI, API versus the others is part of the business they're in. Now, in your case, when you're building platforms internal to large enterprises, that's something that maybe is not so much the case, right? Where there isn't as much internal competition or there's a little bit more negotiation that can happen.

[00:15:50] And I think one of the things you mentioned product management earlier that comes into play here is communicating the roadmap. Now, I understand that when you're competing, communicating your roadmap maybe exposes yourself to your competitors understanding your vision more than you want them to. Whereas when you're working internally to an enterprise, what does that look like as far as a platform lead communicating your roadmap? And what are some things that you're doing there to give your consuming developers the best experience?

[00:16:20] One of those things is that an enterprise a lot of times assumes like I can conform people into compliance of using a platform. Right. That used to be the case. You could do those things and there's standards. You can do those things. But I think actually you should do the alternatives. Like it should be so much easier to use your platform. And it also lies down to a couple of things. Like one is understanding the customer.

[00:16:46] Like for example, if you have internal developer platforms that you have created or internal data platforms, are you really making it easier for them that it's almost like an easier choice to use the internal platform? Right. But then the other part of that is you have to communicate the roadmap to articulate what problems are you really trying to solve for them? Because communicating the roadmap is also a feedback loop in my opinion.

[00:17:12] And this is where strong product management really comes into play as well, internally as well. That's another lesson learned that I've had is that standing up platforms, using platforms without product management, it's like you're just giving somebody a platform. Right. Product management comes into understanding your customers, understanding the challenges that they have, building out a roadmap, seeking feedback, observing the customer, interviewing that whole motion around that is critical, critical to do.

[00:17:43] But part of the communication is also to articulate the outcomes in the roadmap that you're trying to achieve and what is the value that's being created for your customers. Again, it's another lesson learned because a lot of times when people say even internal, oh, is it just a project plan? No, it's not. Right. You got to be clear on what outcomes you're going after in your roadmap.

[00:18:08] And people miss that step a lot of times because your customers are clear and like, okay, are you helping reduce the mean time to value for me? Or are you, you know, driving business impact and how do you measure that? That is fact of it. Right. And I want to make sure that we highlight a few things that you mentioned there where I love that you're communicating the roadmap. And we talked about it earlier, how it might be easier to do internally.

[00:18:35] But some nuances that I really love there is number one, you're communicating the problems. Yeah. As well as the outcomes and the value, oftentimes the communication of a roadmap looks a lot more like a project plan saying, hey, this is what I'm doing. And these are the features it's going to have. And a lot of the underlying context there is lost. And also when I think if it looks like it's something that's set in stone, you lose the other piece that I love you talk about, which is a feedback loop. Right.

[00:19:04] When if something looks kind of rough or something looks like, hey, you're trying to solve the underlying root or something versus it's already been solved. And now it's just a matter of execution. And I think you limit the amount of feedback that can come in the hand raisers whenever you're doing this communication of your roadmap that says, hey, my team actually needs this a different way or my team views this problem slightly differently. Yeah.

[00:19:24] And I think especially in the enterprise, for whatever reason, unfortunately, folks are afraid of looking like they're less capable or less credible because they ask, quote, stupid questions. Those are as someone in your role or someone when I've been a product person, some of the favorite questions you get because it helps you poke holes in things that you may have overlooked that help validate the roadmap well before it's gone into production where it's way more expensive to change. And I think it's important to highlight some of those things.

[00:19:53] One thing I want to get into that I also liked is the ease of use. Right. Whether I've mentioned this to the audience before, when we worked in mobile at Extreme Labs, we would have to work with some executives who had this false sense of confidence around being able to design or prioritize a mobile app because they were so excited about using mobile apps as the iPhone kind of became way more proliferated.

[00:20:20] And it's the same thing that happened as with the rise of platforms. Right. Yeah. And I was guilty of it myself. Hey, I consume APIs all the time. Let me just start writing APIs without really thinking about it versus thinking about, OK, what is the customer value? Who is the customer we're targeting? What is their worldview and mindset? And what's usable for them? And that requires a lot of discipline.

[00:20:43] It requires a lot of discipline on platform teams that maybe didn't historically face the pain of friction user experience or developer experiences. So what are some ways on your teams that you like to drive that discipline amongst your software engineers or your endpoint designers to drive usability and ease of use? Yeah, it's interesting because a lot of enterprises forget that part.

[00:21:12] They don't understand what the challenges of the consumer. But also they forget that the developer a lot of times for your platform is a consumer as well. And, you know, product companies do a really good job with this that, you know, cater towards developers. They understand this part, right?

[00:21:31] And they also understand that making it easier on a developer to develop the first application using your APIs, for example, super creates stickiness and, you know, it explodes from a developer community perspective. So to answer your question, what I try to push the teams for is like when we have APIs, for example, I said, OK, great, great. Now build a solution using the API you just designed.

[00:22:00] Right. And how long does it take you to do to do that? Because that puts your own developers in the shoes of the consumer. Right. And so the proverbial walking in your customer's shoes is so important to continuously hone in on as well. Or asking probing questions in that sense. It's all like a great we designed this API. So how do you know this is going to make it easier for your consumers? How can they get to value faster for doing that?

[00:22:29] And so you got to challenge your teams as well in that regard. But also there's also a little bit of a developer advocacy. And you talked about team topology for a minute. There's enabling teams as well. So you kind of have to have some advocacy working inside your consumers as well to say, hey, let me show you how to do this. And then getting the feedback loop on it as well. Is it working? Is it not working as well? And then feed that back into your backlogs to incorporate as well. I love that.

[00:22:58] Another point of friction I think that comes up between the platform teams and the product teams or application teams is dependency management. The application team has a customer or business need that requires some functionality that's on your platform roadmap. But for real reasons and constraints, you can't necessarily prioritize that going to production on your platform in the time that the application team needs it.

[00:23:25] And so those conversations can go any which ways. Unfortunately, oftentimes in a stalemate where it doesn't speed up what the business wants or the customer wants or the platform wants. And I'm curious, how do you navigate that dependency management challenge when you're working on internal platforms? Yeah, it's also a real challenge. And I think it's an illusion when people have like the I can remove all the dependencies because you also have time constraints.

[00:23:55] You have finance constrained, resource constrained, fill in the blanks. So sometimes internally, it actually might be a little bit easier than with an external party. Internally, you can still shift priorities around if necessary. It becomes a little bit more of a negotiation sometimes. Like you can negotiate piece in the roadmap by trading things off. But what I like to always do is like base it on data as well.

[00:24:22] Like if, for example, you have an internal user or customer base that says, well, I need this. I need this done now. Then we need to say, OK, well, can you quantify it in some way of what the impact is for delay? Right. Right. There's always a cost of delay on certain things. OK, quantify that for us to help us understand. Because that gives a justification for either do we need internal funding, resourcing or those kind of things.

[00:24:48] If those kind of things fail, then you also have to figure out, OK, are there other workarounds that you can incur some technical debt temporarily? Right. Again, I use this term in general purposes because also it has a very negative connotation. But at the end of the day, sometimes it's OK to incur some technical debt, but you have to rework later on. But you can have made an agreement with the parties to say, OK, go this particular route.

[00:25:15] We'll address it and we'll take it on into consideration as part of the roadmap and we'll come back and fix it. Right. But you have to be deliberate about it because a lot of times people forget these things as well. But it's just a negotiation that happens at that particular point in time. Sometimes there's also cases that we'll never make it into the roadmap. But you just have to be clear, like the reason why it doesn't make sense to do these things.

[00:25:42] And quantifying here oftentimes can be more of an art than a science, especially when you're in the early days of some application that you don't have a ton of data points in. I think the problem is compounded when you're in a big organization that's been around for decades building a maybe non-software product and transitioning into software or adding software to their product.

[00:26:04] Where there is, I think, some level of imprecision that software folks are way more comfortable with as long as we're being accurate. Whereas if we're building super scaled hardware that we're making millions of units a year, that precision and accuracy both have to be there. And so what are some tips on quantifying where you're not boiling the ocean, but it gives you enough information to make the right decision?

[00:26:34] Most enterprises that I've come across have a hard time dealing with risk and probabilities. And the reason I say that because they only think about it's either zero or one for most cases. That's why you have project plans. That's why you have risk mitigation and impact analysis, right? So we're going to try to get so much precise because we're trying to factor out risk out of things.

[00:27:02] So first tip is you've got to first make people very comfortable that you're dealing with probabilities in these things, right? Like the probability that you have a particular outcome. You need to be able to specify this as well and get people familiar with what that really means, right? And that also the probability changes over time as well. I guess you had more fidelity in a particular problem or particular space. Your confidence level becomes better.

[00:27:30] Again, confidence level is just a probability if you can kind of think about it that way, right? But it's feeling comfortable with the fact that there is risk in the system. There's likelihood that you have to deal with. So my first tip is establishing that part. Because if you don't feel good people comfortable in the enterprises around this notion, everybody's going to fall back to like, no, no, I need definites. I need guarantees. And again, I fall back to people talking about project lines because they say, no, it has to be done by this timeline.

[00:27:59] If you don't meet it, but they never ask the question, what's the likelihood of hitting that target? Or what's, you know, and getting people comfortable with that, that you can also change is okay. But getting people comfortable with that concept first is the most important thing, I think. And I think the similar question is around technical debt. And if you think about, you know, remove the word technical from there, there's great reasons to take on debt and there's bad reasons to take on debt financially, right?

[00:28:28] Like many of us have mortgages. And, you know, come the holiday time, I know from folks who are even okay with taking some temporary credit card debt on that they have a plan to pay back compared to maybe having it kind of unintentional or not in a deliberate way.

[00:28:44] And so if I am someone who is familiar with that mindset and I find myself in an organization that is very uncomfortable with taking on any form of debt and requires super high levels of efficiency, you have any stories or any sort of anecdotes that help folks kind of be open-minded to an intentional way of taking on debt? Yeah. Yeah.

[00:29:09] You got to go beyond just talking about the preferable or technical debt or just talking about how we're taking on debt because it's too conceptual, right? You got to fall back to it. You got to quantify it and also make sure you have a plan to remediate it, right? Sometimes you don't really have to talk about it in the terms of debt because people feel uncomfortable about this. And so in the past, what I had to do is one can quantify it, right? Okay.

[00:29:38] Well, you can quantify it in the sense of a delay that you're taking, right? And that delay is just costing you X amount of money that I need to invest next time. So what you do in that case, you just say, well, okay, great. So I'm just going to allocate funds or resources in a particular quarter to address a particular problem that you have. So you get first people get comfortable with that notion. But what it shows you that, one, you have a plan to address it in the future, kind of like what you mentioned as well.

[00:30:07] Like I've got a plan to pay my credit card bill December 16th or something like that, right? You're making a deliberate action and you're calling it out that you're actually going to do it. But you also want to probably say, well, I'm going to pay so much towards my debt. So you're actually making it also deliberate on quantifying how much you're going to remove and what it is, right? And again, there's different ways to measure technical debt or debt in general.

[00:30:34] But putting it in financial terms or delay cost makes a lot of sense, especially when you talk to business folks. And again, the key thing is that get away from this calling a technical debt without having any quantification. That's just, you know, it doesn't make any sense for people. And actually most people get in enterprises very frustrated when people just call technical debt. And they're like, okay, can you quantify it? Like what's the impact? What's the delay of that associated with it?

[00:31:00] And for the most part, quantifying it back into either time or money are the kind of most universal languages at all businesses. And it's a lot easier, especially if you give yourself that leeway around, hey, there's going to be a margin or ever around this. I say three months, but it could be, you know, plus or minus 20% on that. And then that is something that can feel uncomfortable.

[00:31:25] But someone who's more savvy or someone who's willing to kind of join the real discussion with you will realize, hey, three months plus or minus the 20% is still well within the threshold of which I have a problem with it. So it doesn't matter that you have a plus or minus a delta on that. What matters is that we stay close to whatever those tolerances are. And then, you know, you get out of that unlock of saying, well, I could spend three more months estimating this correctly. And that could have been the three months that you spent developing it, right?

[00:31:55] Well, that's a good point. And I like how you phrased that is that if you can kind of give a range, that's the other part of getting people comfortable with talking about ranges or pluses and minus, right? It kind of gives a signal to people like, hey, you've got a level of confidence here, right? Versus saying now it's going to be a million dollars or X amount of time. Like your confidence must be 100% at that point. But you've got to get people comfortable with that aspect of it. So I really like using those kind of concepts that you mentioned.

[00:32:28] Fostering an engaged product organization and aligning them with the principles around lean, human-centered design, and agile will more than likely lead to successful business outcomes for your organization. But getting started or getting unblocked can be hard. This podcast is brought to you by the player coaches over at Integral.

[00:32:48] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile. Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:33:08] During this session, the Integral team will facilitate a problem-solving exercise that gives you clarity and confidence to solve a product design or engineering problem. That's integral.io slash convergence. Now, back to the show. The thing that I know that you're pretty passionate about alongside platform architecture is team topologies.

[00:33:37] And Conway's Law, even Reverse Conway's Law, we know that there's ways to kind of give ourselves the best chance of having the most autonomy, the most speed, while also de-risking the outcome in the best way.

[00:33:50] And so when you have either a team to reorganize or a platform to architect, what tends to be the way that you go about figuring out how to organize the talent and organizing the systems in your architecture to get the best possible chance of the outcome you're looking for? Yeah, I love that part because I'm always very passionate about this part. And I'm always very interested in the human condition as part of this.

[00:34:19] But the general process that I follow around this is, first and foremost, what outcomes are we hoping to drive first and foremost? What are we trying to do? But then going from that as well, what are the capabilities that I need? And then what informs my architecture to look like? What is the target state that I'm trying to work towards from a capabilities perspective that I have a thesis around that can get me to the outcomes that I want?

[00:34:50] And then you start working through a process of figuring out, how do I establish flow to get to those outcomes in an organization? So you have to then understand the value stream mapping to a certain extent. Team topology talks about this. Many different lean practices talk about this. How do you establish flow in that aspect of it? And what helps you in the capabilities part, I think you just mentioned as well earlier, wordly maps, for example, your capabilities looking at like, what do I need to build?

[00:35:18] What is commercialized that I can just take off the shelf, right? That gives you a sense of enabling capabilities in that aspect of it. So when you have those PR parts, then you really understand like, what's the stream alignments? How can organization work efficiently establishing the flow? Like if you have capabilities that are depending on each other or you're trying to remove the dependencies as part of this, they come up with a map that shows, okay, so what are the capabilities?

[00:35:48] What are the team structures roughly, product team structures roughly look like? And then you start figuring out, okay, what talent do I need to this organization design? And making sure there's enough structure there that you always in those team composition figure out like who's driving on what problems are we trying to solve for? How do we design that? And how do we engineer that?

[00:36:09] So we used to use this model of product design and engineering and now data as part of that as well as one nucleus of those teams and the capabilities. And then you then figure out like, okay, what's the talent that I move on to the bus per se in those different areas that allows me to figure it out. And then there's another factor I use as well is that you look at some kind of called social engineering metrics as well.

[00:36:36] Like how many people, like Dunbar's number comes into play, like how many people can really form a nucleus that they can work efficiently together. And then establishing a set of charters for those teams as well to clear to them what's their vision, mission that they need to focus on. How do they know that they're successful as well? So it's a couple of different steps.

[00:36:57] It sounds like long-winded, but it's a methodology I've used to quite a number of times to really come up with an organizational design that then supports the outcomes and the targets they've won. But the other thing I also kind of keep in mind is that that is never set in stone. I always call it proverbially set in jello in that sense, because you got to build in the flexibility as well.

[00:37:20] Like, because if you need to adjust to the outcomes that you want or you're observing that you're not achieving outcomes, like how can you change the composition around? And again, the analogy I give people is like, I can compare it to, I grew up with soccer and so football, we could use code football, of course. There's no chance of total football in the Netherlands that came up.

[00:37:45] And it's all about everybody can play a role in the field, but you figure out like, what are you trying to see? You're trying to win a championship. So the team can then work through this mechanism and you don't get stuck into like, I'm only a forward or on defensing purposes. Now you all focus on the same goal, which you're trying to achieve and you can move people around on the field. I love that. And I know for a fact that this is a lot easier said than done.

[00:38:13] And I also know that you've done this as a consultant, you've done it in-house at big companies. What's the hard part, you think, about why most companies who know this theory that you just said struggle to get to that place where they're getting benefit of the process or getting benefit of the new organization? Yeah, I think fundamentally comes down to any transformation feels uncomfortable.

[00:38:40] And when you do these things, people feel like they have a personal association with something. So change management becomes a challenge in this area. What I've found is because we're, oftentimes we're not clear on why we're doing this, right? You have to be so clear in the organization of like, why are you transforming or why are you trying to do these things? How is this better than what I'm doing now? Right.

[00:39:08] Because again, people have identity to what they're doing right now. And it's a sense of comfort that gets created. When you're trying to disrupt this, it becomes very uncomfortable. And then kind of the white blood cells come down for people trying to attack it. And they might not have no reason to attack it, but it's not clear to them like why they're doing it and why they're being impacted by doing this. Even though that you're always trying to focus on making it better.

[00:39:37] The challenge here is that you've got to be clear in the why part. Another thing I have observed, and there's a Larkin principle, if you've heard of this, it's kind of the frozen middle. Especially in enterprises, this is the case. And every single time I run into this, it's like the middle management inside of organizations. They try to hold on to this, right? Like there's the individual level of making a change. And then the management level is trying to hold on to the status quo.

[00:40:05] So you introduce, you saw this during agile as well. Organizations like, oh, we're going to do agile. And what they were doing is giving a lip service to agile because they were trying to hold on to their positions. So nothing changed. One, it wasn't clear to them, but also they wanted to hold on to their position as well. That's law of self-preservation that kicks in as well. And so my deepest experience on this was at a big auto.

[00:40:31] And what we did, and this was when we were at Pivotal together. And what we did there was create a lab that was literally a 35-minute drive away. I think there was different reasons where that made sense. It wasn't close enough to those white blood cells where there was a little bit of autonomy and distance there.

[00:40:53] Someone had to drive 35 minutes to come in and protect the old way and act as the antibody versus allowing it to be and seeing what happens. And then there's some other reasons too where I think we created it in a city that was a little bit more of a startup ecosystem and had access to university and stuff. And six, seven years later, I've seen that that company has now spun out businesses and created new business models, new revenue streams.

[00:41:22] And I know the folks that we seated in that lab, and those folks have kind of permeated across the organization and our leaders and are able to drive change and kind of thaw out that frozen metal, if you will. That's one approach that I've seen, and I'm kind of biased because it's the one that I know and having done at scale. What are some of the other ways if you're a large organization and you need to sort of get to the other side in terms of approaches you can take?

[00:41:53] Yeah, I definitely do like that model as well. It's kind of the revolutionary model, I kind of call it, because what you're doing is really you know what the problem is when you take everybody out of the comfort zone and you create the new situation, right? That really helps in the short, short run and some of the individuals that inspire, like what you said, will spin out and start this out again. It helps in the short run. But you want to be able to make sustainable change in enterprise.

[00:42:22] And what you really have to think about from a change management perspective, again, I go back to being very clear and intentional, like why you're doing it. And also give everybody a North Star on what to focus on, right? Is, for example, an organization might design like, well, we need to focus more on customers. Great. So how are you going to ensure everybody understands what the challenges are that the customer has? What value are you driving?

[00:42:49] Because most enterprises, you'll ask anybody in the company, like, okay, how do you make money? How do you solve problems for a customer? A lot of people don't know that answer. It is actually very shocking. So to do this, you first have to create that motion of what is the new North Star, right? And then you also work with, internally, with a lot of coaching individuals as well, but also putting them in a little bit of a different position that you have to kind of unfreeze the frozen metal in that sense.

[00:43:15] By moving some folks around to say, well, hey, let me put you in a position where you're a little bit stretched and you focus on something different than what we're trying to do. Because that way, they get the experience in doing that. But you also have to make sure that, and again, I go back to the apprenticeship model and the pairing model, per se. You also need people that they work with that they get to see the art of the possible with it. You mentioned creating a lab somewhere else.

[00:43:44] Because part of what you did there as well is you brought people there and they were pairing with other people to see what the art of the possible. Because most individuals have never had an appreciation of what the new world really looks like. And guess what? They will fall back to their own situation. So you have to, again, be intentional in organization that you pair people with individuals that have done this before. They can see how it actually works. Because without it, it's just very hard in an enterprise to do that.

[00:44:11] Because people fall back to their old routines, their old mechanism, right? Because it's comfortable. It's what they know. And so you have to be delivered about this learning aspect. Yeah, you're totally right. And the other thing that maybe I brushed over is that the seed team from the auto company that we chose to be the original folks or the initial folks to come help us almost found this lab were chosen very intentionally. These were hand raisers.

[00:44:39] These were folks that already showed sort of promise of this new mindset. They were folks that were, frankly, the troublemakers amongst the cubicles because they were trying to do the right thing in the wrong place. And it ended up kind of butting up and causing friction and managed to get them all into the same place where they were willing to go the extra mile and take some more chances because they felt like the fight was worth fighting because it was already one that they were already trying to fight by themselves.

[00:45:06] And they felt like they had a collective, a community, and a little bit more momentum to go about in order to, to your point, prove some of those internal case studies. So that art of the possible kind of comes to being. I think one of the local companies here often talks about you have to believe it to see it for some of those early adopters so that the other people who are more skeptics can see it to believe it. And you kind of need both sides of that.

[00:45:36] So being intentional is absolutely one of the things. I think so. And maybe to kind of tie this to what we talked about earlier, is that, you know, talk about space race, for example. Right. And there's always individuals that are explorers. Right. That then go out and explore these things. Because most of the majority of individuals might actually be, I want to stay where I'm at. Why would I explore it outside my purview?

[00:46:03] But it isn't until they see the results of that exploration. Like think about like what SpaceX, for example, has done. And where everybody's like, wait, this is possible now. And everybody gets more excited about this aspect of it. That's the part of being very deliberate. And also finding those individuals that have that inspiration, are willing to go along because they are the game changers in that particular part. And these are little stories, right?

[00:46:31] They're not big, big case studies that take a long time. You got to look for the little wins. And I think one element of creating that high-functioning team is having this space that's safe and is maybe emotionally mature. And it seems very counterintuitive in larger companies to show that kind of vulnerability when there's usually some kind of corporate climbing the ladder, stepping on each other's heads to get there sort of mindset.

[00:47:01] And I'm curious to know, you know, as you start to foster a new culture in order to ultimately drive better principles and practices that drive better product, if there's any instances you can think of where folks kind of showed up differently and that led to great outcomes from your change management standpoint? Yeah, because you can't do this throughout our organization. Fundamentally, enterprises, there's areas that you want some stability.

[00:47:30] You're not going to be able to make these massive changes, right? So I'm also kind of looking for, is there an area, project, or lighthouse initiative that you can leverage to help create the new motion, right? The reason for that is because in large enterprises, that gives you one funding, it allows you some flexibility to try things new, right?

[00:47:56] So these are your projects where you're going to try to build a new system or you build some particular piece in the enterprise where you can actually tether the new practices to. But you also want to make sure you see that with team members that are also willing, again, back to the Explorer example, right? That are willing to go along with that. But then as a leader, you also need to make sure that those teams are then kind of isolated in their own right inside of the enterprise.

[00:48:25] They don't have to be fully in a different building to a certain level. Isolate in the sense that they can collaborate together. They can work together. You remove some of the other enterprise things from that team, per se, that you start off with. So they have the freedom to kind of innovate, to challenge each other. And as leaders, you want to not be in there the whole time. You want to be on the outside to say, let me remove the challenges in the enterprise. Let me kind of push the envelope.

[00:48:54] Let me fully enable you to make decisions yourself, right? And it's amazing every single time I've seen this. I've seen this everywhere I've done this is that people will just flourish. They will step up because they're like, wow, this is amazing. This is the best project I've been on or the greatest initiative, right? Because you've given them the freedom and you remove all the other challenges around them, right? But again, you can't do that across an enterprise. It's just too hard. There's too many challenges to do.

[00:49:22] But you have to find something that you can gravitate on. It's like, this is going to be the lighthouse. So this is going to start the initiatives to get good. So you mentioned Explorer a few times. And I think I've come to realize I might kind of fall into that. It's not a compliment, per se. Because if you put me on the wrong team where they don't need any explorers, I tend to struggle to get out of bed.

[00:49:47] And I tend to be kind of irritating to the people around me because I'm trying to mess with too many things when all we need to do is keep a steady hand of the ship. Versus if you need someone to go with a machete swashbuckle their way through a jungle where there aren't any paths carved out yet, you can tag me in. And I find that I get the right amount of engagement. So I'm curious. Do you have different archetypes like that, similar to Explorer?

[00:50:16] Or how do you organize talent into a way that they feel the most engaged? Yeah, it's an art and science, per se, in that sense. You want to get the note of individuals first to kind of get a sense of like, what do they gravitate towards? Are they truly explorers? Are they more focused on the harvesting side or the stability side of the house? But you don't know until you try.

[00:50:45] But I do think fundamentally, you don't have to have everybody to be an explorer. That doesn't make sense either. Then you get a lot of friction in that sense. But what I do like to do is give people a little bit of a trial. Try this. See if this works for you, right? But you have to create a productive environment that they don't become disingenuine or resentment created. Because also you need to be able to say, well, hey, if it doesn't work out for this individual,

[00:51:13] have the conversation and say, well, hey, I understand that this doesn't work. Let's try something else instead. You need to be okay with that. Because you might be observing things that a person is one way, but you don't know until they get truly into a situation or in a team how they really will act. Right. Because what we say, what we observe, may be one thing. But if you put somebody in a more stressful situation like what you just described, you will really see how people are like.

[00:51:43] And in that case, you need to be able to say, well, okay, great. That's fine. Seems like that's not working. Let's see if we can find something else that works better for that person. Yeah. And I think we talk about one way of optimizing in the lean agile world as being minimizing the cost of change. And I think there is a reputational or emotional cost that as a leader, you can de-risk by making it a non-issue if someone is switching teams.

[00:52:12] Or I think in your case, you've probably done a number of lateral roles that don't necessarily seem like promotions, but it's in the spirit of learning, whether it's about yourself or about new subject matter material out there. And it's a little bit more on the leaders and the folks who are the stores of the culture to make that easy. It's something I really loved at Pivotal where one day you could be working on one engagement and then what the team needs and what you need, you can get rotated onto something else.

[00:52:40] And it's a non-issue for yourself, for the organization. And I think a lot of the standardization in the way that we did work also kind of made that easier when it came to having discipline and interoperability between the teams. So one question I have for you around going back to platforms is standardization and platforms are somewhat synonymous, right?

[00:53:09] At the same time, there's a risk of being very constrictive or hard to use or limiting the innovation of the teams that you serve.

[00:53:23] And I'm curious if there's any advice that you follow for yourself or anything that you give to your teams to help preserve that innovation and exploration for your consuming teams while maintaining all the benefits of efficiency that come with standardization. Yeah, it's interesting the example that you gave, right?

[00:53:47] Is it you have all the individuals that were very innovative in one sense, solving a lot of problems, but you got there by standardization, which is kind of ironic to hear that. It sure is. But there's a truth to that as well. Like you can actually, because innovation people all think like radical new changes, right? Like again, the example I gave when the iPhone came out, that was a radical innovation in one sense, right?

[00:54:12] But most innovation is our solving small problems in a unique way. And you always want to create that ability that people can do that. But part of that is also to provide standardization as part of that to say, well, you don't have to innovate and solve all the other problems. Let me kind of standardize those aspects of it. And cloud is a good example of that. A lot of things got standardized if you think about it, right?

[00:54:41] Like access to VMs and fill in the blanks, it got standardized. Massive amount of innovation has happened by using cloud services because we standardized a lot of things, right? And so the art and the science with the platform is to figure out like where do you need to standardize that allows you to scale and provide innovation, right? And that's the fun part, I think, as part of platforms is figuring that part out.

[00:55:08] Because in enterprises, it's very easy to say like we need to standardize everything. But why? Like what are we trying to solve for? Is it trying to get scale? And trying to get scale also means that I can do more innovative things because I've removed a lot of challenges. Again, I've standardized a lot of things, right? So it's a balance, Ashok, that I think is just so exciting to me in platforms to figuring that out. Like where do you need to standardize? Where do you don't standardize?

[00:55:38] But at the end of the day, standardization helps you actually with innovation in many different ways. I completely agree with you there. And I think in working in the financial services space, especially in the auto world, in my history, creating those platforms for experimentation is what we called it.

[00:55:55] And when we started to have those debates and needed to go back to guiding light or a North Star, the question we would ask ourselves is, would it make it easier for the product teams that are sitting on top of our platform to experiment and help get closer to the uncertainty that it is to build consumer apps? Or is it going to slow them down in terms of trying new things?

[00:56:18] And I'm surprised that it's not easier to do things like shared usage of automobiles or paper mile, usage-based insurance and things like that. And if I had to place a $20 chip on the roulette table as to the causation, in my opinion, it's because a lot of that stuff is built on mainframes. And building an abstraction layer that's also reliable and robust, like the mainframe's hard.

[00:56:46] And it's like a heart transplant that you're doing for such a big organization. And in most cases, the intent and the priority has been in terms of enabling new models from the end consumers. And that will oftentimes be more work for the platform team, whether it's thinking work or having to do more on our roadmaps to really enable that.

[00:57:13] But ultimately, I think it leads to that better delight. It is what makes it fun versus saying you did your job compared to saying that you helped enable someone and we all won together. Yeah. Yeah, absolutely. The interesting part, I had some examples where I actually built a platform that was underneath the covers was just a mainframe.

[00:57:36] But what you did is you standardized and innovation really happened by understanding how developers and users needed to use what was in the financial mainframe, essentially. Right. Versus having to get a green screen or file and all the other stuff that mainframes had. You just build an abstraction layer that just turned into the platform. And most of them didn't even know and cared after a while. Like, wait, there's a mainframe underneath the covers? You go, yeah, you didn't have to know. Right.

[00:58:04] That's a measure of success in my opinion. And it allowed for a lot more innovation to happen. Hey, thank you so much for making time. This has been super educational for me. One question that I love to ask all my guests is having you talk about a product or a service that you recently used, and this could be at home or at work, that completely delighted you was really surprisingly great. And I'm wondering if anything comes to mind for you.

[00:58:35] Yeah, it's meant to be very critical in that area. Because as you build products, you become very critical. I'll see. Products that don't have like a massive amount of feature, but that solves like the one problem that I have. Now, I will tell you, I'm always going to come back to my Mac from a user perspective. Like, hey, this feels natural. But what I've been experimenting with lately, and I haven't found a great product yet, but I'm seeing some consumers of load. As I wear glasses, I'm always kind of interested.

[00:59:04] Like, okay, how can I make that experience easier? That solves the problem of like fitting it on. And there's a couple of solutions that are out there. One I've been playing around with Zuni a little bit. And it's going to get the full experience that doesn't solve my problem. I'm quickly being able to pick things out with a prescription and those things. And they've done a very nice job in that area of quickly, like, here's a prescription. Hey, these are the frames that will fit and we can ship it to you. And I'm like, wow, this is pretty amazing.

[00:59:33] I could solve my problem that I don't have to go to 50 different last optometrists and stores to kind of figure out which one fits and all that part. So I really enjoyed kind of playing around with it. I haven't found a perfect one yet still because I'm very critical. And that's O-Z-E-N-N-I. Yeah. I'm also impressed with how affordable they've made glasses, right?

[00:59:59] They might, yeah, I wouldn't be surprised if the insurance companies get in realizing that you don't have to spend as much on glasses as we all thought. It showed how much we overpaid for many years for glasses. Exactly. What is the best way for folks to get a hold of you? Yeah. So I think LinkedIn is probably the best and I'll share it out as well. That's where I hang out professionally. I think that's always the best place to get a hold of me. Cool.

[01:00:27] We'll make sure to have links to your LinkedIn as well as any in the show notes there. Henri, thank you so much for making the time. This was super fun, super educational, super engaging. Hope you have a good rest of the day. Yeah, I appreciate it, sir. And thanks for the opportunity. Looking forward to getting feedback. I hope you enjoyed that chat with Henri.

[01:00:52] During the episode, we talked about how product management is just as important on platform teams as it is on product teams. Now, why did we both jump on that? I think it's because we tend to see platform teams oftentimes forgetting about some really helpful methods. Things like human centered design, being intentional about prioritizing your roadmap, as well as testing and experimenting super early in the process, as well as often.

[01:01:21] Much like the best product teams do. At Integral, our team's been very lucky that we've gotten to work on a number of customer engagements in helping them build software platforms, APIs, SDKs, and other products that were consumed by customer developers or internal developers.

[01:01:41] In those cases, it sometimes took us a little bit more effort in convincing those platform leaders or our clients with bringing more of that product thinking both into the discovery as well as the delivery workflows. Thankfully, in all of those cases, those leaders were willing to try. And then they saw the value of that incremental effort when they started to see the changes in the outcomes and the progress and the success that we made from it. This included doing customer research, spending more time with the target customers to understand them better.

[01:02:08] It involved being intentional about prioritization and ultimately having really uncomfortable and difficult discussions on things like who do we serve first? What problems do we target first in the features in our platform? Or it was also creating an ongoing feedback loop with those customer developers, like we shared our API design or data workflows really early, well before the product was ready to get feedback.

[01:02:33] Or we sat with the first sets of customers and paired with them to implement integrations into the platform together. And then incorporated the feedback and what we learned from sitting with those early customers into the product and the onboarding and made it way easier for the next sets of customers to onboard to the platform a lot faster, a lot cheaper and with a lot more delight.

[01:02:55] All right. This is such an important topic that we talked about it and we decided to host an episode specifically around the stories from the field, around pragmatic ways to improve how you can create much more customer delight from your platform. In the meantime, check out our episodes from last season, season one with Kenneth Auchenberg. We get to talk at depth with Kenneth, who's an expert in the space around how companies like Stripe and Microsoft, where he worked at, develop surprisingly delightful platforms.

[01:03:25] Until then, I hope you all have a great week. We will see you next Wednesday. Thank you for joining me on the Convergence podcast today. Subscribe to the Convergence podcast on Apple Podcasts, Spotify, YouTube, or wherever you get your content. If you're listening and found this helpful, please give us a five-star review.

[01:03:52] And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today.