Sympathy for the Platform Team with Adam Furtado of Kessel Run

Episode 182 · 30:24 · SRT · archive.org · all Tanzu Talk

Welcome back. It's been a bit of a hiatus on the Dormain hosted episodes of Tanzu Talk. But I'm excited to have with me today Adam Furtado from Kessel Run, who I've heard speak many times, have caught up in hallways at conferences. And he's taken on a new role at Kessel Run. And that's prompted a couple of questions that I have for him. So Adam, maybe you could introduce yourself and describe like, what is this transition you've just gone through? Sure. Yeah. Thanks for inviting me to chat. I'm excited about it. So my name is Adam Furtado. I'm a member of Kessel Run. We're a U.S. Air Force organization doing software development within the government. We're about three and a half years into our journey started at about five people doing a kind of quick side project and slowly, maybe fast, quickly grew into a 1300 person organization trying to figure out how to continuously deliver software to airmen around the world on multiple networks and classification systems and all that. So the kind of recent change is that in the last three years, I've been in various product leadership roles, leading application development across Kessel Run in various capacities, and I've recently moved over to lead our platform, which is a very interesting change and new change for me and one that's been really a lot of fun, to be quite honest. Yeah. And now just to like unpack some of the language that you're using, you talk about being on a product team. Uh, I think what a lot of folks might actually connect with is like, you mean an application or like a piece of software, right? That, that gets used. Uh, but is that

fair to say? And, and why, why do you refer to them as product teams? Sure. Yeah. So I was on the first product team, uh, at Kessel Run and then, uh, kind of grew in my, uh, responsibility from there when we had four, I was the first product leader and then up to, uh, a couple of dozen of them. Um, we refer to them as product teams. We want everything to be thought of as a, as a product. You want everything to be, you know, thought of as the outcome we're delivering to end users at the end of a value stream. Um, so using kind of product terminology allows us to, uh, ensure that we're always thinking about that. And that actually comes into play quite a bit in, in my new role, even in, on the platform side, thinking about, you know, services and kind of backend tooling, uh, in the same way, which has been a bit of a change. Yeah. Okay. So, um, that, that transition before we get into that, thinking about as a, as a product team lead, um, and what you've been doing for the last three years, what has your relationship to that platform team been and what are some of the kinds of things that you would have looked to them for, or, um, have wanted from that team in the past? Yeah, I think it's, uh, evolved, uh, over time in good ways and in bad ways. I think when we first started Kessel Run, we were so small that all of us did everything right. It was very small, close knit team. And we knew that we needed to kind of have all of these different things we had to do to get software from, um, you know, being developed into users hands. So we were working hand in hand with the folks leading the platform organizations and teams. Then as Kessel Run has grown, uh, to this level of over a thousand people, you just kind of like, after a couple of reorganizations, all of a sudden you realize that there's a bit of a bifurcation growing between, uh, application development and the

platform organization that is charged with, uh, supporting. And, uh, I think as that kind of divide grows, the lack of empathy increases or the empathy decreases, um, and the, uh, it becomes a bit of a challenge. So I would say that the thing that we're looking for on the application side is, uh, ensuring we have an understanding of the infrastructure and platform services and basically everything we need to get the product that we're thinking about all day long into our user's hands so we can learn from it, um, and make changes from there. Um, and then the, the complexity of that, you know, has changed over time to be, to be certain. Um, so now we're trying to kind of get back to the basics and simplify a bit to, uh, make it a little bit easier than it's kind of, uh, grown to be. Yeah. And that makes sense. And like putting in the context of how rapidly that organization has grown and how there's just that, yeah, this sort of natural distance that occurs. You can't, uh, you can't stay in tune and in sync with that number of people, but this is a challenge that a lot of organizations, you know, if they're not dealing with already, we'll have to, um, can you think of things that like when you were on the product side, you had gotten to the point as maybe you were getting a little bit more disconnected that you, you kind of thought, gosh, why hasn't the platform team solved this yet? Or why are we still having to do this? Has anything come to mind where you're just like, all of it? I think, I think it's, it's everything. I think, um, you know, every conversation was that, which I think was not, uh, which is a problem on, on both sides to, to like the place we got to is that every time a particular capability or service wasn't available to us yet, you know, our minds went to this place of, there are these evil people over there that only are there to like, keep us from being successful. And like, what are we going to do to overcome this, you know, enemy at the gates? Um, and, uh,

it was, it was not good. And I, I played a part in that too. And I, you know, in, in retrospect, did a very poor job of bridge building as a leader in the organization. Um, to just understand that, you know, people are inherently good. Everybody's trying to do a good job. Um, and, uh, you know, uh, taking things from that perspective and, and, and really having empathy on both sides, not just saying that, um, what was really important. One of the, the, the, the more kind of interesting things that I've learned in the last few months in taking on this role is that I've, um, you know, brought over to this, you know, important idea of customer centricity, right? So I'm a product person by trade. I care about delivering things that our customers and our users, uh, love and really want to use. Um, so when I came in, I had this kind of thinking that like, okay, I'm walking into an organization that's not customer centric. They don't care about users and customers because I just was one. So I know this to be a fact. Um, but I walked into a very different, uh, experience and I was completely wrong. And it was, it wasn't that the team didn't care about customers. It's that they were trying to like solve customer problems so much that it was leading to them being a little bit more ineffective and inefficient than, um, we would like them to be. So as an example, uh, they were working kind of a scrum way of working. So they have sprint planning and they're working on kind of delivering against these kinds of things in their two week sprint. So then I, or some other customer would come screaming from the rooftops about this like incredible priority that we have to get solved right away. And all of the work that they were planning on already in the sprint gets dropped to the floor. They're responding to this fire that we've just like created for them. And all of a sudden, uh, that gets dropped the next day for the next fire, the work in progress increases, nothing gets delivered. And we just keep complaining that nothing's getting done. But in reality, it was like, they were trying to be customer centric by responding to our needs the whole time. Yeah. And to be customer centric, you have to learn how to say no. Um, and, and saying no to customers can be the most customer centric thing you can do. Um,

and I think, uh, so I had about a bunch of bad assumptions coming into this new role that I learned really quickly were wrong. That's, that's a pretty powerful takeaway of like, you know, sometimes to be customer centric, you have to learn how to say no to your customers. Um, and that kind of tees up what my, my next couple of questions were both, you know, what did you, what did you learn when you kind of walked into the platform team? So you shared some of that. And then also, what did you bring with you from your, uh, product team leadership experience? But let's, let's drill in a little bit more. So you, you came into this team, um, and you were sort of, uh, the myth was debunked, right? The myth that they were this evil organization that didn't care about their customers. Um, I like how it goes immediately from like, you know, cares about customers to evil, right? There's not like a spectrum, uh, of just like apathetic or something. It's like, no, they're evil makes total sense. Um, okay. So you come in and you learn like, oh, actually they're really, really trying to, uh, what else surprised you about the way they were working and what they were doing and some of the challenges that they faced? The, the thing that became really clear, very, so I, in, in the application development side of our organization, we've used like very strict XP and Kanban principles of actually starting from working with Pivotal Labs early on. And, uh, the thing that I underestimated was how great that way of working is for me, for managing your work in progress. Like it, you know, as we, um, you know, worked in our development teams, we're pulling the next story off a backlog. We're working it through completion and acceptance and all of that. And that just seemed very routine and very normal to me. Um, and then as I moved over to, uh, the platform organization, working in more of a scrum way of working, uh, so two weeks sprints, but all of a sudden, um, the amount of work in progress

was, uh, astonishing, uh, to be honest, and more the idea of how we did capacity planning. So I, uh, in order to kind of like understand the organization, I did kind of like my own version of a Gemba walk, uh, through the platform organization and these virtual kind of like meetings with each team to understand how they worked, their processes, how they took in work, how they prioritize them. Um, so at the beginning of these meetings, I would ask kind of an innocuous question, like how much unplanned work do you guys have? Like how much interruption work do you guys feel or do you track it? Whatever. Yeah. That would be like something like 40% or 50% or something crazy. It goes back to that early conversation we were having around customer centricity, constantly like reacting to fires and things like that. So then later in the conversation, I would ask like, okay, so think about your sprint planning. Let's say, you know, what level of capacity are you planning to? Let's say you have a hundred hours in a work week. Like, what are you like? Oh, 90%, 95%. So we were, we had 150% capacity on every one of our teams, basically like, oh, of course we're not delivering things when we think we're going to deliver them. We have no way to do that. So, um, I think, uh, coming around to the realization that we just had like product management problems on the platform was fascinating to me because I never really thought about product management on a platform before this at all. Um, so, and, and so it really got me back to thinking around like, okay, I just realized why I like our XP principles on the app side were really good. Um, but it also got me, you know, researching more and looking into more. And I realized, you know, uh, on the ThoughtWorks tech radar this year, the number one thing listed on there was product management on platforms. So it's like not the, you know, not the only person coming to this conclusion. So that I think was the really interesting thing to me that we didn't have a technical problem at all. It wasn't a technical expertise problem. It was literally a product management problem on how to manage our work more efficiently to increase developer productivity and flow and just get out of people's way. And I think, uh, and it's a whole different job than I had before. So it's been really exciting to be honest, to try to like flex these new muscles. So I want to pause and back up, um, a little bit

because, you know, you, you talked about like realizing that using kind of a Kanban method or Kanban just the vowels, they're hard, vowels are hard. It was, has been really useful. Uh, but the team was practicing scrum, like just for, for the uninitiated, like what's really the fundamental difference about these two approaches? Cause they, they sometimes get kind of sloshed around in the same conversations. So it just, it occurs to me that like, you know, if someone thinks, well, we're doing scrum, like why might they, there's still be something left on the table for them to learn? Yeah. So I think, uh, I would give my kind of perspective on this. I'm sure they're like more, uh, Oh, I'm sure there's pages on the interwebs of this, but yeah, from a Kanban perspective on the, on the XP side, um, we would have backlogs for each team and that were managed by the product manager. They would be the one writing the stories and working with their teams in a balanced team model. Um, those backlogs really went out more than two or three weeks. So it was constantly like re-evaluated for priority. Um, and then as we went forward, the, we're constantly prioritizing things and we're grabbing stories at the top of the backlog. So you're always working on the most valuable thing at all times. The system requires it, uh, in a lot of ways. Um, the downsides to it that we ran into is that when we grew from like one product team to two dozen, the portfolio management across a bunch of teams working this way is challenging. I think there are ways to solve that. I'm sure, um, we could have done a better job on a lot of it, but the idea that you are kind of empowering product managers to work their own priority is harder to plan for it. Like the strategic layer, if you will, at least in my experience, we're on the scrum side of things on our platform team. It's easier to plan because you have this sprint planning, spending an entire day every two weeks or whatever it is to understand the sprint plan. Um, so you can like communicate

to your stakeholders more easily and like wrap your own head around the work that's coming because you're like playing a role in it and you can like see it kind of all coming together. Um, the reality of it is though, it rarely actually happens because once you get into this kind of two week planning cycle, we had all this unplanned work and interruptions we talked about earlier. A lot of our teams are doing like operations work. So doing a two week sprint for operations work doesn't really make so much sense anyway. So, um, the plan that you had going into this two week work becomes an initially, um, uh, affected by the changes that happen rapidly in, in the world that you're in, in the context that you're in. Um, and it becomes a little bit in, in, in personal to me too, where, you know, if you have a customer request or a question and you can say things like, I will put it in our next sprint. Um, it's like the, the equivalent of like, you know, I'll get back to you later to me. Um, so I, I really hate that term. Um, so I think there, there are pluses and minuses. It kind of depends on the nature of like the kind of problem you're, you're here to solve, I guess. Um, but, uh, I like the idea of being able to, you know, sense and respond to change as rapidly as possible. So I kind of, uh, kind of, uh, like that idea from the kind of Kanban way of working. Okay. Thank you. That's very helpful. Um, okay. So, you know, you also talked about kind of bringing the, the product management principles to bear on this platform team, uh, and, you know, getting out of people's way. I wrote that down as well. Cause I thought that was kind of an interesting way to think about how, how, you know, you're being successful on a, on a platform team, right? That's customer centric, not evil. Tell me a little bit more about what products, what kinds of things would, would end up getting, um, prioritized in and what kinds of things were hard to say no to when you're really applying those product management principles at the platform level. Yeah. I think the biggest

difference, um, is without having like a product mindset of understanding, like why you're building things and how they're going to be consumed. Um, I think it's easy to get attracted to really fun technical challenges with a group of engineers who want to solve complicated problems. Um, where, you know, sometimes those things are, may not be the best solution for the problem set that you're like setting out to achieve. So I think in, in, uh, changing the kind of mentality around the team, you know, as best I can, and this isn't just me, it's a kind of group of people. Um, we're trying to make sure people understand like, okay, why, why is it important for you to have this level of observability? How is it going to be used? And like, what value is it going to bring to the organization at the end of the value stream where before it would be like, I have a ticket to deliver Prometheus. So I'm going to do it. And then I'm going to check it off when it's done. There were just like engineering tasks being completed without an idea of like the larger picture we're here for. Right. So in our case, our platform exists in order to enable our application teams to deliver value and create value at the end of that stream, uh, down to like our airmen who are deployed around the world. The abstraction between that and like the actual service teams was so great before that, like you couldn't even connect the dots really. Um, so I'm trying to work on, um, ensuring that there is a, um, uh, a connection between the work they're doing and the actual like outcome being achieved. Um, the second thing is on, uh, success criteria. I think in, in, in the way that we were like building our kind of ticket system and that we really lacked like what success looked like for completing a thing. It was like such like the idea here isn't just building a thing. It's what happens afterwards.

Right. So in the same respect of like, if you're on a product team, you know, you build your story, have an acceptance criteria that you should also probably measure the outcome and ensure that like your hypothesis was right in the beginning, same thing on a platform or a service team, making the thing available and nobody uses it. You should probably, you know, want to know why that is, uh, and react to it. So I think it's more around shifting towards solving user problems towards, you know, pulling a ticket off a backlog and just delivering the engineering tasks and going to the next thing. Okay. I think we've kind of covered like a lot of my sort of burning questions on, on the sympathy for the platform team, uh, which is in my head, what I've already named this episode. Yeah. I guess like if we were to dig in a little bit more on that success criteria, what are, what are some, some wins that you've seen the team be able to have kind of pretty quickly and that, that tell you that this mindset shift is taking hold? I think it happened pretty quickly. I just started seeing the language change, um, pretty rapidly. And I think, you know, some of that is like new leader comes in, that's like, you know, uh, get off on the right foot. But I also think like, if I'm watching some of the, these conversations from afar, I'm starting to see more questions and more conversations with our customer community on, you know, what good looks like and what success looks like. Um, and, uh, so I think we're still kind of working towards that. I think that the place that we're in right now is really like stripping down the complexity and trying to simplify and communicate as, as effectively as possible. So I think one place that we historically struggled on our platform team is that, um, you know, this isn't the case everywhere, but on within Kessel Run, our product managers aren't all like inherently super technical. A lot of them come from the business and that kind of thing. So I, I, you could see conversations happening between like product management on the business side or the application side and like some super complex answer to an engineering thing on the

platform side. And everybody's in the room going, yeah, I understand. But like in reality, nobody understands what the other one's saying. They just want to get out of this meeting. Um, and I think it was like, uh, that's one of the things that we're trying to change by figuring out how can we like describe the, the inherently complex technical work we're doing in a way that anybody, uh, can understand. So I started calling this the Luna rule. So we have a, this product manager at Kessel Run named Crystal Luna, and she's amazing. And, uh, I cleared this with her before actually talking about it, but, um, she comes from, she was an active duty air force airman. She's a senior airman who came and worked with us, uh, temporarily got out of the air force and now as a product manager for us. And she is fantastic, but she's not technical by trade. So one of the things that we talk about internally is that, okay, you have this solution. You're going to go talk to do a customer engagement here and describe it. Like take the Luna rule into account. How can you describe this where Crystal would understand what you're saying? And I think those types of conversations are starting to happen more and more where people are like, okay, I understand this, but how can I make this communication a little bit more effective? Um, so, uh, our customers understand it. So that type of thing, we're starting to see, um, a lot more, which has been, uh, great. Um, the other place that we're really diving into is, is similar, but in like kind of roadmapping type of work and making our roadmaps and planning available to our customers. Um, the other thing that I realized in this transition was that like, it's okay if something's not going to be available, like customers are okay with that. They just need to know so they can make their own decisions internally, right? Maybe you go a different direction, you do something kind of janky temporarily or whatever, but we, uh, traditionally had a really hard time understanding and articulating our roadmaps. So our customers could even respond to it. Um, so we're trying to do a better job of like, yeah, even if we're not going to have something available for you, we at least tell you that. Um, so you can kind of, so it's a lot of online, like basic communication, which maybe ties into that product discussion a little bit, but more on just like, um, yeah, effective communication across the organization.

Yeah, that, that actually brings up another good question where, you know, you described earlier, how, as the organization has grown, the, the sort of the touch points have decreased, right? Between different product teams and the platform team. And so the sort of mental rift builds up. What else have you seen? Yes. You mentioned changing the way that, uh, the, the solutions that the platform teams are building get described to customers. You mentioned making that roadmap available and transparent about things that are, and aren't on the roadmap. What else have you done or are thinking about doing in order to build back up in a scalable way, right? Because it's, it's, when you're at that, Hey, we've got 1300 people now, like we can't rely on some of the things that maybe worked really well in the beginning when we were all just working really closely together. We know that that's not going to work anymore. So how are we going to approach this problem differently of building back that, that empathy, that sympathy for the platform team? That's not just Adam, because you came to work on that team and lead it. Like, how do you now, instead of having everybody rotate through the team, um, scalably get, get everyone kind of connected back to that group and vice versa, that the platform team has those connection points back out. Yeah. So I, I mean, me having past relationships is certainly helping. We also brought a couple other really great product managers over with me, uh, which has been great. So it's not just like me saying things. There's actually like product management in the organization who are kind of like, here's a good way to do things. Here's the way we solve this roadmapping problem that other folks can see. So that's been really great. Um, a couple other things that we've, we've done that could have been successful. We're doing monthly customer AMAs, uh, where we are kind of like, uh, every fourth Friday, we have an hour where any of our customers can come and pepper me and our technical leadership

with, with questions and can ask about a ticket or ask about a roadmap, whatever you're not getting. Um, so we do a little bit of that. Um, we also like back in my, uh, application development days, uh, we started this Friday wins meeting that, uh, actually we started it basically right when we went remote in, in mid-March where, uh, our entire teams, a couple hundred people would get together at four o'clock on a Friday, go over like, you know, wins from the week. It could be like a feature you delivered. It could be some like, uh, business process improvement or whatever. There's also like a fun end to it where, uh, one person a week would do a pecha acucha on like their life in quarantine. It's kind of a fun team building thing. So that's been going well on the air outside. And just the last couple of weeks, they brought, uh, they invited the platform team in. So now like last week we had a Friday afternoon before the weekend where the platform team was able to be like, here are our wins for the week. We're able to deliver this. And the thing that was cool about it is that all of a sudden you started hearing things like we were able to deliver this feature on the application side because so-and-so on the platform team really stepped up and helped us there. And it just like, you know, it was great. So like all of a sudden you're seeing, oh, this is what collaboration in a healthy way it looks like. And so we're starting to already see that by just kind of like introducing opportunities for that. Um, I guess. Um, so that, that stuff's going well from a scalability perspective. I think, uh, we just kind of have to keep it up. I'm really nervous about being in like a honeymoon phase, uh, for this kind of change. So I'm trying to make sure that we are finding like sustainable ways to kind of maintain this. So like once everybody's done feeling good about it and we're back to like real life, uh, we have the same type of collaboration happening, but we'll see how that goes. Yeah. That's awesome. I do have to add what pet pet should. Yeah. So it's, uh, I'm probably gonna get this wrong. I have no idea if I spelled it right in my notes, by the way. Uh, yeah. P E C H A K U C H A. Uh, it's Japanese. I think it's basically you have, it's 20 slides. Uh, it has to be like a single image on each slide. It's 20 seconds

per slide. Um, so, uh, it's kind of a fun way to ask people to do like these presentations. So like people will go through and talk about what they've been doing and these kind of like, uh, hobbies that they've built, uh, since they've been at home, um, to try to kind of, uh, you know, and the, and the week on a fun note before we kind of sign off for the weekend. Okay. Um, so this begs the question, like, I mean, we don't have slides, but like what, what fun hobbies have you picked up like at home? The funniest thing has been, um, the people who have been doing that, it's crazy. The hobbies other people have got, I feel really boring. Like we have people who have like, they're like doing crochet and I don't know, building stuff. Um, I don't know. I've been just kind of just trying to survive. I got a puppy, uh, quarantine puppy, which I thought was a good idea because we'd be home a lot to train it and it was a horrible idea. Um, and now I have like a separation anxiety puppy because we're never left the house. So that's a whole thing being outdoors as much as possible, I guess. Yeah. Um, no, I, I hear you. I think, I think surviving is a good hobby, like, uh, getting a puppy. That's definitely, that's a bold hobby to take on. Crocheting is probably somewhere in between, you know, just back to like, why do we need extremes survival, raising a puppy, like another living being, um, crocheting. I hear sourdough is really popular. A ton of sourdough and a ton of fancy coffee drinkers. That's basically all it is. It's a lot of people describing their coffee situation. Yeah. Well, so I like have basically, I haven't been having any coffee because I'm a espresso sort of person and we don't have an espresso machine. And this combines with my other hobby, which was early on, we started watching the Marie Kondo show and we were going to like, we just Marie Kondo the house. And part of that is I'm working my way through the tea collection,

but I have also managed to break three teapots, um, in quarantine. So, uh, coming back to survival, like I'm, I'm now trying to make sure that I can have a teapot that survives, uh, you know, quarantine or shelter in place. I don't know what you call it anymore. Um, with me, because apparently, like, I just drop things in the sink and they shatter. It's all learning. You're it's build, measure, learn. Yeah. Everything's fractal. So yeah. Eventually it's like, I'm going to stop buying that teapot because it's obviously the teapot's fault. Yeah. But yeah. Well, it was a pleasure chatting with you. These are some great takeaways. And I love hearing about the bridge building between application and product teams and the platform teams. And I always love hearing perspectives on how platforms teams can take that product mentality. It seems to just, uh, again and again, come up as making a huge difference in how they approach their work in a way that's satisfying both to them and to their internal customers, the product teams and app developers that they work with. So appreciate your insights. Cool. Appreciate it. We can try it again after the honeymoon phase is over. We can see how it actually went. When it gets real. Yeah. That sounds like a good plan. Thank you.

Tanzu Talk · 🍕 Get more pizza.