Transcript: Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I’m sitting down with Luv Kapur. Luv, welcome. Thanks very much for taking the time to talk to us today. Luv Kapur: Thank you for having me on the show, Shane, good to be here. Shane Hastie: My normal starting point with these conversations is who’s Luv? Introductions [00: 58] Luv Kapur: Awesome. So Luv right now is a staff engineering lead working for a startup called Bit where we build a composable platform. I lead both their open source and enterprise solutions, where we build the open source solution to help build composable toolkits and the enterprise solutions for enterprises and organization to adopt composability. Before joining Bit as a staff engineering lead, I was a platform portfolio manager for all the platform teams for a large pension fund, where I overseed and managed a set of teams that were building internal tooling to support product teams that delivered custom software for portfolio managers, investment managers, analysts. And, where we build software that we manage up to a $100 billion dollars in transactions every year. The Path to Staff Engineering [01: 40] Shane Hastie: So, staff engineering lead. Why the path to staff engineer? Luv Kapur: It’s because I love software. I love writing code. My first love has always been code, that’s how I got into it. I remember I was nine when I got introduced to Logo. It’s a very old programming tool where you had a little triangle mouse and you would write little commands to get it moved from one place to the other, and absolutely fell in love with the idea that this is something where I can be creative. Programming I feel is one of those fields which is even though it’s technical, it’s your opportunity to be creative. So, that’s how I got into it. I’m a programmer first, but I loved building software at scale. In my previous job I was a portfolio startup manager where my role was technical, but not hands-on coding. I enjoyed it. I upscaled teams. I started off with a small team of four to five people that was building a platform that supported hundreds of developers. Before I left, that team grew to almost 40 developers with three internal teams as well. As much just I enjoyed it, not a lot of writing code itself, and being a little bit away from it I wanted to get back to it. And this is where I decided, you know what? I have this, it’s almost like a fork in my career path. I can get into this non-technical engineering manager role, help build teams, or go back to what got me into this field itself, the love for programming. And that’s why I moved to becoming a staff engineering lead where I’m more hands-on. I absolutely enjoy it. Mentoring vs Managing in Staff Roles [03: 14] Shane Hastie: So in nurturing talent and people, in that staff engineering stance, my perception is that that’s done much more through mentoring than managing. One, am I correct, and what does that look like? Luv Kapur: Absolutely. It’s more about mentoring in the staff engineering role, where you are just aiding people who are extremely good already in their technical talent. Just to understand how to pave this career itself, a lot of times my role is honestly just listening. I feel like one of those skills I developed is to be a great listener. You just need to listen to people a lot and listen to them clearly to understand where they’re coming from, where their needs are in their career, especially from the technical side of things. It gets a lot more easier to guide them if you are at the similar technical level as them, where you can sit down with them and understand where they’re coming from specifically. And at the end, I don’t know, when you are mentoring someone, you’re understanding what success looks for them, what at the end their goals are, what success is. And, whatever I can do is to reduce the amount of blockers for them to reach that success that they aim individually in their personal careers. Building High-Performing Teams Through Trust [04: 26] Shane Hastie: And how do we take these highly skilled individuals, and form them into effective teams? Luv Kapur: The number one thing that is trust. You need to make them feel that there is a level of trust. You trust them. One of the things I always tell enterprises every time I join and I’m leading a team is, the reason we hire people with great talent is because we trust. We don’t need to tell them specifically or hand-hold them at the end to do stuff. What we need to do is create an environment where they feel like their capabilities, they can use it without any hesitance itself. The environment itself allows them to deal with it. So for highly technical folks and building a high performing team, it’s the level of trust within the organization you start, the freedom you give them to do stuff and express themselves at the end, even through technically itself. What I do is before when I lead our team meetings and stand-ups, a lot of times for a lot of these folks, most of them are senior devs and architects and their team let them take charge. Take a step back completely and listen to them, make sure that the environment, the team, the structure is there for them to grow itself without having to do any sort of hand-holding for them at all. Rebuilding Trust After Organizational Disruption [05: 39] Shane Hastie: That trust equation has been damaged in our industry lately. If we look at the massive layoffs and all the disruptions that’s going on and has been happening, how do you rebuild trust perhaps after a reorg or when it’s going on around you? How do you create that environment of trust? Luv Kapur: I feel a lot of times trust gets eroded within an organization is because of lack of clarity. As soon as there is lack of clarity on what’s happening around me, which direction the organization is going, what direction the team is going towards. What are we building? Why are we building? Why did we pivot? Why did we reorg? If decisions come a lot of top down without a sense of clarity, it will erode the trust within because it becomes unpredictable. When the environment gets unpredictable, the people within that environment will start questioning a lot of things. In any organizations, it’s a nature of working in enterprises that hard decisions have to be made. You need to adapt yourself according to how external environment changes, industry changes and moves. What’s very, very important throughout this process is to ensure there’s complete clarity and transparency. Teams understand, an individual understand why certain decisions were made. They understand why certain decisions were made because of what influences are around them, and they also understand going forward what it changes in the path for the organization, for the department itself and for the team itself, and how it affects their individual and personal growth within that. So when we have clarity, a lot of times it gets a lot easier to communicate these hard decisions and make sure there’s less uncertainty around. And the less uncertainty you have, people feel more comfortable in their environment. Understanding Composability in Team Design [07: 26] Shane Hastie: One of the things I know that you are interested in and have been talking about is composability, but not in software, in teams. What do you mean by that? Luv Kapur: Composability is such a strong concept because if you ask any developer how they build software, even without saying the word composability, even when they envision stuff, how software gets built, it’s pure and composable principles itself. You always build on top. Imagine a scenario where you have to build software and every time you write something from scratch there’s hard-coded dependencies within everything, and it feels like everything is so tangled. I was in the scenario before because when I was leading these platform teams, one of the biggest differences between leading a platform team versus a product team is your org and your customers are other developers, which is a completely different equation versus your customers being non-technical users. This is where my loves for composability started because I have to lead a team that built internal tools that other teams were using to build on top of it, and this is when I realized it’s such a powerful concept when applied at an organization level because in the world where talent is very, very scarce and things are changing very fast, especially when you look at the introduction of large language models, AI, there’s a huge shift happening. We are living through very interesting times, which I would say was equivalent to when the internet dropped in the early 2000s, similar to that. Moving from Rigid to Fluid Team Structures [09: 16] Luv Kapur: What sets an organization apart is not just talent anymore, it’s the ability to shift within their changing needs. That means, can organization move their headcount fluidly between the teams itself. This is one of the biggest bottlenecks I have seen organizations have. When outside demand changes, they have to internally make sure the teams get restructured. And they realize their headcount is very rigid and then they ask themselves, “Why is my headcount so rigid? Why can’t I move X amount of people to team B and C and change how I work?” The reason is because the organization is so tightly coupled. It’s not built on composable principles itself. Teams have no clarity, no visibility on what’s getting built, how to use it, how to build on top of it, and this is where I take some of my learnings working in the finance industry, investment industry where the liquidity management for a portfolio was a very, very strong tool I noticed when I built these tools for portfolio managers. Where in fact, they were able to just leverage and move money across portfolio and liquidity. It gave them a lot of freedom and the same principles applied at an organizational level for technical leaders and for technical executives. If they have the ability to move headcount as freely as capital gets moved between portfolios, it gives them an immense amount of freedom and that ties back to how composable the organization is, how clear the contracts are between the teams, how teams understand each other’s capabilities, and then how they build on top of it. Balancing Stability with Dynamic Reteaming [10: 50] Shane Hastie: This goes almost counter to the concept of the long-lived stable team, and also aligns with work by Heidi Helfand on Dynamic Reteaming. How do you help the individual engineer become comfortable to shift and to move around in this fluid team environment? Luv Kapur: It starts with asking yourself, why does an engineer feel comfortable in a long-lived team itself? At the base of a long-lived team, the core principle makes an engineer feel comfortable. It’s the idea of that I understand what I’m serving, what I’m building, what my toolset looks like, what my technical capabilities are within the team itself. The reason a lot of times engineers don’t feel comfortable, especially with moving from one team to the other, is again the lack of uncertainty, a lack of visibility, understanding we have a specific way of building and doing things. We have clarity on how we do it and what we do it. When I move to Team B, is it going to be completely foreign to me? But envision a world, an organization, where engineers have complete visibility on how other teams operate. There are clear set of principles that are being used, that are set up front. When teams are built or structured, the first thing is to define an API for the team is what I say. Build API-first teams. An API for not what the team is, is what capabilities does it offer. Think about your organization in terms of capabilities, think about your teams as serving those capabilities itself. Be transparent on what the API of the capability is and so it’s completely discoverable within the organization of what it can do, how it can do it, and how to interact with it. Once you have these fundamental principles defined and clear at the organization level, someone extremely technical working on team A, if he has all of these visibilities, they feel a lot more comfortable moving to team B. For them, it feels like the entire organization is a long-lived team itself. It’s just where they’re contributing to the capability itself changes based on the needs of the organization. Creating API-First Teams [12: 57] Shane Hastie: So, what is this capability API for a team actually look like? How does that come into being in practice? Luv Kapur: The capability first for a team, it starts with the team understanding who they service and how they service, who are the customers and what they build to service the customers. And whatever they’re building to service the customers, as to how do you interact with it at the end. Is it a service? Is it a toolkit? Is it a product at the end? Is it an application you’re deploying? Are you providing automations for other teams to build on top of it? The capabilities could be anything, but the idea is to have clarity on what it is, how it links to the business initiative, how to operate with it, and how to contribute back to it. One of the health checks I asked teams to do when they’re trying to adopt this composable first architecture is if you pick a team and let’s say you will have a dependency on them, how easy for you it is to introduce a change. This starts with understanding that you need to stop looking at teams as a hierarchical model and more as a dependency graph. In a composable world, everything is a dependency graph. You either have some dependencies, or you’re dependent on someone. If once you have clear visibility into your dependency graph at an organization level and for capability, an API first team that looks like what they service, what they built, how they build it, how to interact with it clearly, and how to contribute back to the service itself, you have clarity now completely. And now, the team itself starts looking as a node in that long dependency graph of the organization. Individual Contribution in Composable Teams [14: 33] Shane Hastie: And, what about the individual? How do I communicate how I fit in, how I want to fit in? Or, how do I make visible what I bring to the team? Luv Kapur: From an individual perspective how I bring to the team starts back by understanding what part they play in the team itself, and we can take an example where let’s say you have a design system team and design system team composes of different individuals. You have a front-end architect. You have a senior designer. You’ll have a visual designer, and you’ll have all of them working together to build a cohesive design system that sets the design language for the entire organization. At an individual level, you know what capability you provide to build a design language for your enterprise or for your team. The designer knows their goal is to make sure they’re building aesthetic designs that are reflecting the brand principles of the organization itself. The architect knows that the implementation of the design principles are being done and built in a way that they’re easily consumable and extendable. That’s how the individual perspective ties into the team capability itself. The team has clear capability on what it provides and what service it provides, what its customers are and how they consume it. The individual knows what role they play within that team to make sure that capability is serviced individually. Home and Away Team Model [15: 47] Luv Kapur: A lot of times what helps, and we introduced in one of my previous roles when I built these highly dynamic teams, what helped was a concept of home and away teams similar to how in sports there’s home and away teams itself, where we individually split our team into a home team and away team and we rotate it within themselves where the home devs or home team members can be aware of team members and vice versa. And the idea was for a sprint specifically in a month I would say in any cadence you can decide based on how you operate. The away team will actually join one of your teams that are dependent on you. They will join it. They’ll attend their standups. They’ll listen to their product needs. They’ll work with them on what they’re building, and specifically what will work with them is what they’re building that actually consumes what you built at the end. And then, this away team joins the team. Not only they’re aiding the other team to deliver faster because if they just join and listen, you’re risking head count. You’re not contributing back at the end. So they were actually helping deliver faster for the team they joined itself, but they were learning. They were gaining knowledge of how the internal team operates, how they build onto it, what their design development practices look like, how they customer needs service up, and hey take it and come back to the home team. They share during home team sprints about this is how people who are dependent on us operate, this is how their customers operate. And, similar for product managers of the home and away team as well. And we can foresee in the future what they’re trying to build, and we front and build for them stuff so when they reach to a point we can service it. This is where the collaboration becomes very seamless. It’s completely visible on both the teams on what they build, or what they operate, how they contribute to each other, how they learn from what their contribution is and come back and rebuild this foundational whether these are services or components that will service back to these teams again. This proved to be a very powerful concept to scale a lot of these platform teams that were interminable service teams. Career Growth in Fluid Environments [17: 43] Shane Hastie: So the home and away metaphor there, that makes sense. How do we help people grow their careers in this very fluid environment? Luv Kapur: This fluid environment actually gives them a lot more opportunity to grow, because a lot of times when people feel that they’re not growing is because either they’re holding to a specific role and doing the same thing over and again. A lot of times a lot of devs or a lot of team members that reach out to me when I mentor, they feel that they’re not growing. A lot of times the complaints are very similar, where I’m flexing the same muscle again and again. I feel like I’ve done it so many times that it’s not helping me grow the other skills I have. And a lot of times, it’s not because they’re deliberately put in a position like that. It’s because the team structure is so rigid that it ends up putting them in this position. The fact they’re so accustomed to doing the same thing again, they’re extremely good at it, which helps the team to deliver fast, which also makes it very difficult to replace them because you’ll take a cost once you replace them. But then, what you do in this process is you forget about from an individual perspective how negatively it’s affecting their career growth. But imagine when they have more flexibility to grow, the more areas they can contribute. Instead of contributing within the teams, they feel empowered that not only I help within my team, I have the capability to let’s say, be part of an away team, join another team, contribute to their customers or their tech stack, improve those skills, or work on a more product-facing or a different tool set you were working on before. The expansion of possibilities of the contribution for an individual is the biggest motivator that helps them to grow at the end, which makes them feel that they have different areas they can flex. They can grow their muscles in, and they can get better at their technical jobs. Leadership Coordination Through Capability Lens [19: 32] Shane Hastie: So when the organization is a dependency graph, how do we as leaders coordinate? Luv Kapur: When the organization is a dependency graph, from the leader’s perspective, they’re no longer managing individuals. They’re no longer managing at the end. What their vision changes, and this is the biggest perceptive change that can happen is to look through a capability lens. What they have is a portfolio of capabilities they’re looking at and their portfolio of capabilities is tied to the business initiatives’ back. They look at leverage within the capability itself to see how I can manage where the head constant needs to shift, how I can manage where I need to put more focus on in terms of capabilities, how the market, external market shifts are making me make these decisions. Again, they stop viewing organizations as these rigid structures, or team structures, or surfacing with the clients. Those just become implementation details. This is what I call an implementation detail of the organization itself, and their focus completely shifts on the capability. They start instead of looking at managing tasks and managing epics, the perspective changes a little bit at that point. You know what? They start looking at it as in the long-term vision we have for the organization to reach the goal, what is the current capabilities we have and what’s the gap? This also bridges a lot of times organizations I’ve seen lack at is, a lot of times big organizations have to make this build versus buy decision in software, and specifically it comes at an org level where executives or team leads, especially for large purchases. A lot of times the inclination is to buy software for a larger organization,, and the reason a lot of times they buy software is because they have this lack of ability to understand what their current capability is and what the gap is and what gaps needs to be filled to purchase software to bridge it and provide the capability. And, this is why it ties back to the whole dependency graph. You view your organization as a dependency graph of capabilities. You understand how the capability assigned with your long-term vision itself. You understand where you stand within that and you understand where the gaps are looking at what your one-year, three-year, or five-year strategic goals are, and then you align and restructure and headcount yourself to make sure you are on the right path to achieve. Practical Adoption of Composable Organization [21: 48] Shane Hastie: What’s the important question I haven’t asked you about this way of working, or why not? Luv Kapur: The most important question is, can you move from your current team structure to a composable team structure in a month or two, how quickly that cadence looks like, how strong the shakeup looks like for an organization, because it’s very easy for me to sit here and talk about how good the composable organization is. In reality, in practical terms, you have 1000s of people that is working, you have 100s of teams working, and for an executive who wants to adopt it, how does this adoption look like. They can just go and do a whole shakeup and ask multiple teams to reorg themselves. That is the hard question is how do I adopt composability at an organization level when I have never, ever talked about it before? You always have to start small, and this is the best part of composability is you can start with one team and start with the team that the other teams are highly dependent on. You pick your leaf node within your organization’s dependency in growth, and you build your way on from it. You don’t need to do a big bang change. You’re not looking at a restructuring of an org with 10s and 10s of teams at once to achieve this composable organization structure. You will slowly build on top of it. You go to your leaf node on your dependency graph. You understand what the dependents are. You restructure the way they work with their dependence itself, and then you traverse your way up this graph. And then you start with their dependence, and then you ask them, and then you explore and you start going, slowly changing these teams. And the fact that you have already rebuilt the structure from the leaf to up, it gets easier as you grow and as you adopt at an organization level. Shane Hastie: Luv, A lot of really interesting ideas and some great advice, and I’m sure some challenging thoughts in there. If people want to continue the conversation, where would they find you? Luv Kapur: The best way to reach out to me is on LinkedIn so you can reach out to me as Luv Kapur on LinkedIn. I’m available. Shane Hastie: Thank you so much for taking the time to talk to us today. Luv Kapur: Thank you so much for having me. Mentioned:.
https://www.infoq.com/podcasts/building-composable-teams/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global