The Qualified Answer
The Qualified Answer dissects the real decisions senior technology leaders make - what was chosen, what was traded away, and what they wish they'd known.
Because every honest expert answer comes with conditions. This podcast unpacks them.
The Qualified Answer
Going Fast as a Company without Gatekeepers
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Send a text message to the show!
What if the whole business went fast together?
You've spent two years getting product and engineering shipping multiple times a day. Releases are fast and of high quality. Then you notice the company isn't actually moving any faster.
Herry Wiputra spent seven and a half years at hipages tackling that exact problem. After accelerating product and engineering, he made a controversial call - break the silos open, restructure around cross-functional teams that own customer flows end-to-end, and put senior leadership members on the hook as direct sponsors of each team. Simon and Herry walk through the decision, the near-mutiny it triggered, the guardrails that kept it from collapsing into chaos, and the two environments where the whole approach is an anti-pattern.
A decision case on cross-functional teams, theory of constraints, and what it actually takes to move end-to-end velocity from a tech conversation to a board-level one.
Guest: Herry Wiputra, Chief Product Officer, hipages
Hosted by Simon Elisha — former AWS Chief Technologist, 35+ years in enterprise technology.
Subscribe to The Qualified Answer newsletter: https://pages.thequalifiedanswer.com/subscribe
Learn the strategies we discussed in this episode - head to https://pages.thequalifiedanswer.com/profile for our full training program.
Want cool merch? [NULL]Shirt: https://shop.nullshirt.com/
So, what do you do when your product cycle is fast, but your company is maybe not going at the same speed? Do you tighten your grip? Do you throttle it with all your might?
SPEAKER_00The qualified answer with Simon Elisha.
SPEAKER_01Do you take a different decision? Well, joining me today is Harry Riputra, who until recently was the chief product officer at High Pages, which we'll talk about shortly, but has had a huge experience in the IT space trying new things and doing different things in the way that we build and deliver products. So, Harry, firstly, welcome to the podcast.
SPEAKER_02Thank you, Simon. Glad to be here. Good to have you here.
SPEAKER_01Now, tell us uh very briefly about the context of what you're operating in, and then we'll get right into the decision that you had to make. But just to help us demystify what you were dealing with, you you know, HyPages, it's a two-sided marketplace. For those who are listening, what is it? What does it actually do?
SPEAKER_02I joined HyPages about seven and a half years ago. So when I joined, really the only product we had was the marketplace. It's basically a marketplace where we connect the homeowners with threads. Um high pages in the past used to be a directory business, but we flip it on a head. Now it's um driven by the homeowner. Um they're looking for threads, and then we'll connect up to three threads, or if they want more, we can, but up to three threes for the homeowners. And these are the threads that's available and engaged and has been fattered by us in terms of their licenses. So they're quality threes as well.
SPEAKER_01Now you spent a lot of time in your career, I think it would be fair to say, focusing on delivery, speed, velocity, and quality. Like that's sort of like your thing, isn't it? Like, how do you make this thing faster, make us deliver quicker?
SPEAKER_02Yeah, that's right. Uh, deep in my heart, I'm a student of Lin. I love Lean methodology a lot. I spent uh a bit of time as well going through Toyota factories, um, did a week-long study in Japan, going through the supply chain and understanding how lean manufacturing is working. And agile takes root in lean, you know. Like I am very impressed and obsessed about how can we optimize delivery pipeline using lean techniques. So that was my previous life.
SPEAKER_01And it's it's interesting, I think, not just uh doing it theoretically, but going to visit the source and to see to see what they're doing. Was that like, did that open your eyes to certain things when you when you went there and saw in the book it says this, but really it is, and it's it comes to down to culture and mindset, and it's really hard to replicate.
SPEAKER_02I remember listening to um a podcast about NUMI, I don't know if you heard about it, M U M I, which is the joint factory between uh GM and uh Toyota in Detroit, uh US. And I think um they tried to replicate what Toyota has done, um and they couldn't, because they couldn't get the mindset replicated, and it's the mindset. And it's amazing to see how the Japanese think about efficiency and everything that they do is it's impressive.
SPEAKER_01It's interesting how how much culture weaves in there. And I think to some degree you saw that in a microcosm, because uh I think that the challenge that arised for you was that you applied all these lean techniques and other things to the I guess the development team within Hype Pages. And you got to a certain velocity, didn't you? Like it was it's pretty good. Yeah. But you found yourself in an interesting situation. Maybe share with us what what you sort of came to at some point.
SPEAKER_02Yeah, I think it's probably actually before high pages. Like in my career, uh a lot of that has been doing a bunch of transformation. Prior to high page, um, you know, I I was able to optimize within product and engineering quite well. Here, for example, and this is prior to high pages. When I joined, um we were releasing like once a week. To the point that before I left, we can release multiple times a day. So we are we are very fast. We build an engine that can iterate very quickly and very fast and whatever. But again, the rest of the business is not ready. And the rest of the business prefer uh a more polished product rather than iteration of product. And then you hit this snag, and even though the product and engineering is ready to iterate faster, but the business is not ready, and as a result, you can be always as fast as the slowest part of your components of your system. That's the theory of constraint, right? So that that's that's where we are. So that's why when I joined Hype, the mission I had was how can we create a fast moving end-to-end system? Not just probably.
SPEAKER_01And I think it's it's worth diving in on that because I think in a lot of IT shops, we can be quite myopic and and say, well, we're gonna, you know, we're gonna optimize everything we do, and then there's the business somewhere out there that has its own challenges and limitations or what have you. But that's not our problem because we're everything's going great. But you've sat back there and and sort of tried to tackle this differently, haven't you? What what what were you thinking when you, you know, with was this just trying to take that sort of end-to-end system of constraints, lean thinking approach across the board and just forcing yourself to go to that next level? Is that what did it for you? Why, why did you pursue this? Because you could have just sat there and said, hey, I've got the fastest performing product engineering team out there. I'm I'm doing good.
SPEAKER_02Yeah, but you know, it it the the company not successful as a result. I think I think my obsession or what really I want to see is a really fast-moving uh organization that can deliver value to customer very quickly, rapidly, and learning very fast. And if we can learn very fast, we can beat our competitors very fast. And that that's to me is the premise. And that's what I'm trying to do.
SPEAKER_01And so so you're sitting there, you've got, you know, your your organization in a in a reasonably fast state as far as you're concerned, but you're you're seeing those gating points. How did you think about that problem and what did you do? How did you sort of come to a decision? Give us sort of the scenario of where you found yourself and what you were balancing at the time.
SPEAKER_02Yeah, I think when I see organizational problems like this, I think a lot of the problem happens because of the system that's being created within the organization. And when I look at many organizations, um, including the organizations I I work for in the past, is we're very functional silo. And the work that requires to deliver value to customers cut across multiple functions. It cannot be done by one function alone. And and functional silo really, if you want to trace it back, it goes back into the history of um the father of modern management, Frederick Winslotter. All right, his premise is management do the thinking and people do the work. So and then and then he's also advocating for division of labor. So people just do one thing and one thing only. And and that's how he advocates. And then back then, you know, when the the industrial revolution just happened, makes sense because a lot of people are not knowledge workers.
unknownYes.
SPEAKER_02So get them to think about the breadth of things is overwhelming. So get them to focus on one thing and just focus on one thing alone and just do that. But unfortunately, that thinking still permeates to today, right? Like management of the thinking, people do the work, and division of labor like crazy. And then that's what's happening a lot. If you look at the, you know, many of the banks, the telegraphs, and whatever you, like, how do they scale? They scale by growing functions bigger. So, you know, add more people to IT, add more people to finance, add more people to HR.
SPEAKER_01So it's the low-risk, acceptable MBI approach.
SPEAKER_02Yeah, and then they grow like a pyramid, right? Like, you know, everything's big. But really, in an organization, there are two or maybe three different structures that's actually working. The formal one is the people reporting line, which is what we just talked about, you know, the reporting structure like a pyramid. But that's not how the work is organized. That's not how the work is structured. The work is structured by getting the right people in a room with the same goal to deliver value to their customer. And it involves working with multiple different functions together to deliver value. And in reality, that's actually happening, but they do it informally by stealing people, begging people, borrowing time, and that's create chaos in the system as a result.
SPEAKER_01Rather than formalizing that.
SPEAKER_02Correct. And and that's happening anyway, right? Um, and what it ends up, it's actually creating a lot of frustration in the system, especially individuals that's highly in demand, that everybody comes to them and it's like, how do I prioritize? Like, every stakeholder wants me. Like, what do I do? And so that's the issue. And then we're playing all this game about people resource management rather than delivering value to customers.
SPEAKER_01And you start fighting over who works for whom, how much time do I give them, that's my resource, that sort of stuff.
SPEAKER_02Yeah. And when I joined Hype, if that was happening, I remember I asked, like, okay, this PM, which engineers working with him, and this PM which engineers working with her. And I was told literally every morning the PMs come together and they do horse trading, which is like who get which engineers that died. Oh my goodness. So that's what I find it baffle baffling, right? Like, because to me, there's actually a much better, like a much stronger structure that should be formalized, which is how the work is organized. And that to me is where the cross-functional team plays the part. Like, what if what if an organization is really a collection of cross-functional teams cut horizontally rather than vertically, and each one of them delivered fairly directly to a customer? Wouldn't that be amazing? Is it even possible? Um I still hold the belief it is possible. It is possible.
SPEAKER_01So then when you when you sort of saw this situation where there wasn't this sort of optimal alignment, what was the thing you did to, I guess, break out of the mold of just product and engineering into the broader company? What was what was the step you had to take to make the next step happen?
SPEAKER_02So once I got product and engineering to a reasonable level in Hyper Edges, the controversial thing that I did was to get a member of TSLP as a sponsor for each of the cross-functional teams. So the first of I did was to break all these functional silos within product and engineering into cross-functional teams. So each team will have, they could have a PM. What's another PM is mandatory. So we have a PM, a dedicated PM, a dedicated tech lead, UX if they have a customer-facing components of it, and then data. We have data people as well, because data was still complicated back then for us. So we need data, and then a bunch of engineers. And really, we slice the customer flows into sections, and then each team owns a section of that customer flow. So they own a particular flow in the system, including the underlying systems that power that flow. So they have a domain ownership, but also they own the customer flow. And that way they can deliver value to customer directly with no or minimal dependencies. It's dependencies that always kill productivity. As you know in Lean, you know, the seven types of ways, and one of them is handoffs. Anything we have to do with handoffs, you remove ownership.
SPEAKER_01And you lose, it's it's it's not just control, it's timing and prioritization and all those other things. It just becomes overhead in the system.
SPEAKER_02Exactly. When you create two organisms that depend on each other, that's complexity multiplied, and then add another one, there you go. Everyone just twiddling their thumbs doing nothing.
SPEAKER_01Exponentially more complicated.
SPEAKER_02Exactly.
SPEAKER_01When you approach these SLT members, you know, they're probably not used to having this ask made of them of, hey, you know, I need you to sponsor this team, this piece of work, this function. What was the reaction? How did you explain it to them that in such a way that they were amenable to it?
SPEAKER_02Surprisingly, I don't think there's any issue coming from the SLT sponsor. I actually they like it. They're like, this is great. I didn't get any pushback whatsoever. If anything, I get people keen to do to take on more.
SPEAKER_01So is is that you think a symptom of of the natural disconnect that we have in a siloed organization and people going, wow, this is so much better? Yeah.
SPEAKER_02Like I think this is interesting, right? Because how many times you listen, you know, to the frustration of these people, which is, hey, you know, like I need to do things, but the product team is super slow. And, you know, like the marketing people, the, you know, like the salespeople, they all depend on the product team to do something, and they're very, very slow. Uh, so they got frustrated. But now, what I just did is open the floodgate and like basically say, well, you have you have now a skin in the game. You can work with them directly in the area that's relevant to you. So that's the caveat. It's not everything. In the area that's relevant to you, right? So for example, uh, we have a team that focuses on acquisition. So that team is about growth, it's acquiring new customers and whatever. So there's a lot of product component in it, you know, conversion optimization, make it SEO-friendly, and whatever. So that team, to me, is best to work with marketing. So, you know, I asked the CMO to be the sponsor of that team instead of me. Because I'm not an expert in SEO.
unknownNo.
SPEAKER_02Right? I can learn, but I'm not the expert of it. He is the expert of it. So he should be working directly with the team to make it work. And I'm removing myself as the middleman, you know, as a getting function for the product or expose the PM to work directly with the CMO. And I, you know, it works, but it needs a lot of improvement on both sides to make it work because the PMs suddenly have to work with someone that may not have a good understanding about how product function works.
SPEAKER_01Yes.
unknownYeah.
SPEAKER_01Okay. And and it's it's interesting that I guess that the sort of new relationship. I guess the other part of that too is obviously your own position in the relationship and your role changes manifestly because, like you say, you're no longer the gatekeeper, etc. And I know you're not that way inclined, but for some people that that loss of control could be quite concerning because, well, what if things go off the rails? How do I know? All this, what were you putting in place to make it psychologically safe for you to do that?
SPEAKER_02Yeah, and and that is, to be honest, that is difficult for many people to let go of that control because things do get wrong. When things do get wrong in the product, it's the CEO will come to me. And what's going on there? Right? But I'm like, well, hey, uh, that that area, like I I'm not involved in that, right? Like, so that's that. But I think that's the bit that we have to put gut routes in place, which is like, hey, at least we have a lot of monitoring in place. So we know when things are not working well. Yeah, so we put monitoring in place, metrics, dashboard, whatever you. We also put uh architecture council in place. So everything that they want to do, they need to get architecture council approval. Okay. So this is where the horizontal garters is important. So the architecture council, so the architecture council is not so much like a gating function, but it's more like, hey, to make sure that what you're doing is in alignment where we want to go. So you don't end up taking us to a different direction altogether. And especially introducing new language that hasn't been sanctified and what have you. Because you could imagine if everyone has full autonomy without alignment, this is chaos.
SPEAKER_01Yes, yeah. You can't just do it, it's not like, you know, yeeha cowboys, let's go do whatever you want.
SPEAKER_02Yeah.
SPEAKER_01In a lot of other organizations, I've seen that architecture review board just be an absolute time sink and huge amount of work and lots of paper and that sort of stuff. Were you able to come to at it from a different dimension where it was more a more speedy validation slash check and balance rather than a ceremony?
SPEAKER_02So we have a standing meeting once a week, and then basically all the tech leads from every team get together. We are our principal architect, and then who has something to present, they present. So it's more like a bottom-up approach. Like, hey, I have something that I want to present, they present, and then they have a robust discussion, you know, on on that. But if you have something that you want to do urgently, you don't have to wait for that meeting. You can call a meeting immediately. So it's not that meeting is more like a standing meeting, really, rather than opportunity, but it's not the only opportunity. It's not the only opportunity. That's right. And it's also we're we're I think that the philosophy we live in is like, hey, there's always an exception to the rule. If you feel like you have to make a shortcut now because there's a business value, make your case. As long as you make sure that this is rectified afterwards, it's okay. It's okay. So there's always that trade-off that needs to happen.
SPEAKER_01Which I I guess ties back into this concept of if as a product team you have a better understanding of what the business priorities are because you've got your SLT sponsor who really, really knows, then you're in a better informed position to make some of those trade-offs than if you didn't have any visibility. Correct.
SPEAKER_02And that's not also the only guide rails we put in place. Uh we also put design review. Um, so same thing, right? Like you can introduce new designs and what are new, but it must be in alignment where we want to go as well. And that's also a standing meeting a couple times a week, that if someone has something to present. But eventually we systemize things as well. So we build design systems in place. So just use the design system, then you'll guarantee that everything is.
SPEAKER_01It's automatic. Yeah, it's it's the goal of path.
SPEAKER_02So that's what we do. We put things in place for that. And then on the high level, we build a vision, product vision to get, oh, hey, this is where we're going. This is, you know, three years' time. Everything that you do need to get us towards that.
SPEAKER_01And how did you know, once you'd made this change, and it sort of starts to sink in, how did you know it was working? What were some of I guess the hallmarks of behaviors or things that took place that you said, aha, this is the right call?
SPEAKER_02Yeah, um, a few things. So, for example, I had the CMO, basically, the CEO asked the CMO to do additional things with the team and try to put one more thing into that backlog in the next quarter. And then the CMO said, Well, the team already has three teams in the backlog, which one do you want to take out to make room for this? I would never in my life thought a CMO would ever say that. CMO's never say that. A CMO or CRO would say, Well, team bat line, you just need to add one more team. And you just need to make it happen.
SPEAKER_01Get it done.
SPEAKER_02Right? That's how it works, usually. But I almost fell off my chair when I heard that. I was like, well, this is working because the CMO has a skin in the game. The CMO has a skin in the game.
SPEAKER_01They understand what they're trading off. And this is this is, I think, this thing that pops up all the time is that this this presence or lack of direct feedback and feedback loops is is vital to any human function, but in business, like everything else. You know, if you don't know what something costs or how long it takes or what your constraints are or how much capacity you've got, you you can't make a good decision. So you're just going to make the expedient decision. Whereas this sounds like you've got folks who want to make good decisions, but they're operating with better quality data with which to make their decisions.
SPEAKER_02And traditional human behavior is survival. Right? That's human nature survival. Any opportunities that people can pass on to work to someone else so they don't get blamed when something doesn't work, people will do it. That's called politics. And I see that a lot. And it annoys the hell out of me. Because you gotta have honorship in what you do. So now they have direct control of what's happening, they have uh skin in the game, they will make the right decision without passing the buck to someone else.
SPEAKER_01Was there was there anything that went I think w went wrong is probably too strong a word, but were there what sort of bumps were there along the way? Because obviously you you mentioned obviously that some of the SLT people don't understand the the product process, which is understandable. And I I'd venture to say there were probably people on the product and engineering side who didn't understand the marketing process or this business. So what what were some of the bumps and and were there any things you did to help get over those?
SPEAKER_02Oh yeah, look, I almost had a mutiny, I think, uh, at the start of this. And the PMs didn't really want to work this way, and whatever. And I I lost some people as a result of that. And that's fine. Yeah. And that's um, it is the reality. There's a lot of coaching that needs to be done on both sides to make things happen. Need to get the product people to learn to speak a business language, you know, like, hey, we're getting this many clicks or we're getting this much engagement. But how does this move to business metrics? How much sales are we getting out of this? Well, how does it improve conversion? You know, how much retention benefit we're getting out of this? It's really getting them to think about it that way. And also, you know, when you're prioritizing features, you know, and then you you sell it to your stakeholder, it's not like this is what the customer wants based on our conversation. No, it cannot be just that. This is what the customer wants, and based on our survey and our data shows that, yes, this is desirable for our customer, but this is also how it's gonna make us move our business metrics.
SPEAKER_01Yes, yeah. It's gotta there's gotta be multiple purposes there.
SPEAKER_02It can't just be it can't be just that, right? Company exist to deliver fairly to stakeholders, shareholders.
SPEAKER_01That's that's the purpose of a company, unless you want it for one. Yeah, if you can if you can marry up doing the right thing by the customer for the as the right thing as your business, then you've got a great business to be in. But you have to have both. You know, otherwise, you know, you're not a charity. If you're a charity, it's a different scenario again.
SPEAKER_02And 100%. And I think in the product world that we have created, um, you know, like, you know, we we created a little bit more like uh uh a fairy land that, you know, like people think, look, as long as I solve the customer problem, the money will come. No. Yeah, it's a lot more if if only it was that simple. I I know. If only it was that simple. Well, isn't that the classic?
SPEAKER_01You know, if you if uh Henry Ford, if you ask people what they wanted before the car was invented, they'd say a faster horse, you know, not a car. Well exactly. You you you you've got to go deeper. You've got to go deeper than that. Do you do you think there are there are organizational types or domains where this sort of model is is an anti-pattern or something to be avoided, or there are conditions that you look at and go, uh, this is not going to be the type of decision to make that people should watch out for?
SPEAKER_02I think look, the whole premise of this is every cross-functional team should be able to deliver value to customer end-to-end with no or minimal dependency. That's really the place. Right? And what sort of things can make that not happen or hard to work? So there are a few cases which I think is the case. So for example, in a very highly regulated environment, you absolutely need like a getting, multiple getting functions to release anything. Yeah. It's hard. It's hard.
SPEAKER_01It's a whole different way of operating, like by by definition. It's not a free market type, you know, innovate, move quickly type stuff. It's a different. For some reason, hence the regulation, it's a controlled, defined, heavily gated, intentionally slowed down process which rewards other types of things like precision and discipline and provability and those types of things. It's a different way of operating.
SPEAKER_02Uh, you know, and then the other one is um when you have such a legacy, legacy, legacy system that's only one or two people that have the knowledge, like mainframes and whatever, that you are highly dependent on, you know, small amount of people that has the knowledge on how to do things, you can, it's hard to do this. Yeah.
SPEAKER_01There's always a handoff at the end. Well, I think it's it's it's been fascinating hearing about this. I think if we think about from a framework perspective, one of the things you mentioned at the start really, really jumped out at me, which is the purpose of doing all this is so that you can respond to your stakeholders, your customers, the market more quickly. And that's your classic oodle loop. Now you're you're you're running that oodle loop much more quickly because you're taking less dependencies, the skills are there for you, you can move quickly. But at the same time, you're also trying to avoid waste in its many nefarious forms. And so this is really not so much a technology story as a business efficiency, customer effectiveness, profitability story, isn't it? Really, that's that's the you know, when you're talking to the CEO, you're not having a conversation about software development.
SPEAKER_02No, no. And what makes me super proud now, you know, in my time at Hype Ages, cross-functional teams is the pillar of our strategy. So all our strategic initiatives are driven through cross-functional teams. So every year, when we have strategic meetings, it's all about okay, which cross-functional teams we want to set up, which cross-functional teams we want to continue, which cross-functional teams we want to stop. And each of these cross-functional functional teams, what's the metrics, what's the remit of what they're gonna move for us from OKR point of view? And then we get them to go off, do their planning, build business cases, and come back to present back to us. So it's like mini-part up within an organization.
unknownYeah.
SPEAKER_01With with high, high ownership, high agency, but still coordinated. It's still like it's not out of control. It's still you you're trying to find and and look, I'm gonna call it as I see it. I think I think it's a constant balance. It's not like you know, you you you go home every day relaxed and comfortable because things are just singing along. Like it takes effort and work and nudges and and that sort of stuff, but it's better than not doing it this way.
SPEAKER_02Yes. Well, I'm biased.
SPEAKER_01Well, you like it. That's okay. You get to you get to see you're the CPO, you get to decide. Harry, thanks so much for joining us and telling us your story. We'll definitely have you back in the future. We do want to talk about uh the future of this whole domain in this new AI world of ours. But for now, thanks so much for joining us.
SPEAKER_02No, thank you. Pleasure to be here.
SPEAKER_01And thanks everyone for listening. As always, we love to get your feedback. There's a link in the show notes you can click and you can leave a message from your phone or anywhere very conveniently, uh, or you can email the show as well on the website. And as always, it is yes with an if and no with a but. And there were lots of ifs and buts going on today, as you could see. That's the nature of making a qualified answer. And until next time, keep on building.