The Alignment Anti-pattern, Improving Developer Skills, and Cloud-Native Teams (Ep. 42)

Episode 29 · 47:48 · SRT · archive.org · all Tanzu Talk

So, uh, I talked about this on my other podcast already, software defined talk.com, but I just want to get it out there. Um, you know, I was in Chicago last week, lovely city, and I had, I don't want to call it the best hamburger in my life, but it was top three burgers. And it was this little place. One of our, uh, one of our, um, our, uh, our reps up there was, was taking care of me. And he took me to this place called three greens market. I'll, I'll put a link to it here in, in the, uh, the show notes, but it's just that I got a, I got a pastrami burger, very thick cut pastrami. You got some cheese on that. And then there's two patties, not giant patties. These are like fast food burger sized patties. You know, it's like you'd get an in and out or whatever you have regionally. And then, uh, and then some French fries. I was told the French fries were wonderful. They were just French fries. Nothing wonderful about them. Nothing terrible, but that's what I recommend. If you're up in Chicago or find yourself wanting to take a trip to Chicago, go get one of those burgers. I think they have two locations. Well, I wish we had lunch right now doing a podcast. Yes. We were just joking around that. I just ate a fistful of peanuts before this lunch, uh, without, without having the requisite water supply. So we'll see if I end up with dry mouth during the show, but, uh, you know, when you just start wheezing halfway through, I'm going to try to empathize with you. I'm going to, I'm going to start churning. You just, just, just, uh, just not feeling it. So we don't, we don't have a, a guest this week. So, uh, uh, we were thinking we would just kind of blow out the bafflers. Is that right? What are the things you blow out? Anyways, clear out the, uh, the little items that we have and talk about some of the, the longer pieces that, that we've talked about. Now, all that said, aside, aside from the, uh, the U S elections, there hasn't really been that much news going around and, you know, uh, I, I would refer you to, uh, that similar podcast. We're going to listen to the burgers last, last week on, on my software defined talk podcast. Uh, we talked about, uh, the effect of the elections on tech and there's actually some pretty, uh, extensive show notes more every now and then. I like take way too many notes on something,

uh, for podcast show notes. And, and, uh, there's a couple of analyst shops in addition to journalism who've kind of covered, um, possible implications and things like that. Uh, I think in particular, like ovum, uh, was really quick and they wrote up a lot of coverage, which I believe is all free. I think I tested that out and four or five, one has a little M and a thing, but you can go over there. Uh, if you want to, it's at software defined talk.com slash 78 and, uh, get, get your fill on that stuff. If that's your bag. Nice. Now, meanwhile, was this, was this last week or, uh, the week before? I think, I think, uh, Microsoft teams came out. I forget when it was. I think it got leaked the week before and then slack did the, uh, not, I guess not unprecedented, but bold move of taking the full page ad out in the paper, welcoming Microsoft to the game, which, you know, that doesn't usually play well. Cause six months later, you laugh when the shot thing, you know, the competitor shuts up shop, but you know, Slack's awesome. We, we rely on it heavily at pivotal, but you know, Microsoft teams is an interesting entrant with its more integration to the, as you'd expect the office suite and threaded conversations versus sometimes the, the mania of Slack today. So either way, it's an interesting entrant to it that, uh, I'm sure was lighting up last week with, with election talk. Yeah. And, and, and, and, you know, normally I would, uh, I, if the word is askew, normally I would skip over talking about Slack because it's just like, uh, as, as, as even medium term listeners would know, you'll probably know that I have a very jaundiced eye when it comes to like AI and bots and all that kind of nonsense, which is sort of like Slack is in that mix. But I think, I think in the context of, of, of what we tend to cover here, like, um, narrow, not narrowing down, but there's a significant part of Slack usage or whether it's hip chat or old school IRC or whatever, where people do, um, I think what, what, what's commonly referred to as chat ops, which, uh, people like Victor ops are trying to, in the same

way that we try to, uh, uh, take up a significant amount of the corner on the phrase cloud native. I think, I think they, and, and Atlassian, and maybe Slack to a certain extent. I think, I think Slack's always shooting more towards the, um, non-technical people, uh, you know, to, to make a bigger market. Uh, you think so? Yeah. Well, I don't, I mean, they don't, Slack doesn't spend a whole lot of time nowadays in nerd talk. They talk more about collaboration and things like that, but they, it's not as much, they, I mean, I haven't come across Slack talking about like, we integrate with your GitHub and allow you to do a build. I mean, not that they don't do that, but it's sort of like, I think, I think their goals are now are, are beyond the, uh, the, the nerds as it were. Probably because they won that group over. In my last job, we did all the chat op stuff and I could push our website to the, you know, our website to production by typing, you know, four line words into Slack and it would go do it or, you know, bots would spin up a bridge when there was a service interruption in the service and automatically kick up, you know, a WebEx and notify who was on call from pager duty. So yeah, those things are pretty awesome. And the fact that they're pretty easy to make is wild stuff. So I think, right. Versus just straight up, Hey, here's yet another tool for us to talk to each other. I think that actually trying to introduce automation, but in the same place with everybody. So it's not, Hey, where do we go do stuff? But here's where we chat. Here's where we can kick off certain things. Here's where we can get insight into commits and to get, I think that's a pretty wild use that I hadn't seen a ton before Slack came on the scene. Yeah, no, I mean, you, you hit up on the, uh, I mean, the core things there and it was making me think of, um, a couple of conversations I was having last week when I was in, uh, in my, my pre and post awesome burger, uh, like lifestyle choice, uh, which is there's a, there was a lot of discussion we were having, um, with a couple of large organizations about how you, uh, how you switch over process and deal in large organizations, how you do a more agile approach. And I guess there's, there's, there's a tremendous amount of, I don't know

if it's selection bias. I would call it what I know bias, but I found that the conversation kept going around. Um, well, when it comes to governance and collaboration and coordination and alignment is another good word that's worth thinking of in large organizations, a lot of that is due to the fact that you don't have very good tools for doing that. So you have to go into the meat space and like do it in person. And then as everyone can kind of theorize or hopefully intuitively knows once you're doing like meatware integrations, like people just talking with each other, it's incredibly inefficient. And so, and you know, this is where the notion of, uh, breaking down silos and chucking things over the wall comes into play. But the more, uh, transference you have of like this one group did this one thing, this other group needs to do something about it. Whenever you have that exchange of something, there's sort of like the group one, the first group has to educate and have the second group understand it. They also have to build up trust with the other group. And then you also need a verification that everything went okay. And you know, then also there's just the time to schedule meetings and all of that stuff. And so at the lower levels of something like pivotal cloud foundry, there's like lots of automation that makes it so you don't need to file a ticket to get a server, which is great. But I think, I think things like, you know, the way that I've seen people using stuff like Slack and I would assume Microsoft teams is having, uh, speeding up that communication cycle that I was kind of just going over, but also putting out assurances that in addition to all the automated builds and like get, get, uh, commits and logs, like all this stuff that allows you to automate a huge amount of governance, the conversations and things that you have, if you have some discipline around them, that's another type of automation that hopefully reduces the need to, uh, to do a lot of, a lot of the governance that was required because there was no other way to do it than to like fire up a word doc and go talk with people and, uh, you know, just fill it out. So, I mean, you know, I, I, because I have to use Slack every day, I'm extremely dismissive of it because, you know,

I'm, I'm a, I'm a regular, uh, prints on a stack of mattresses and I can feel the pee underneath it. Right. So really all Slack has to do is remove that annoying feature so that if someone types in here a channel, it like freaks me out. Like if they just remove that, I would probably think it was a perfect communication medium. Uh, but, but they, for, for whatever reason, I, I, I, uh, I don't know why they're not listening to every time I complain about it. All they need to do is add an option that says when someone types in at here at channel, Coté doesn't care. Like that's, that's all I want. That's all I want. But yeah, no, this will be a good, uh, I think a good link into what we talk about for the rest of the podcast. But I mean, I think exactly to your point, even things around DevOps come from improved, faster collaboration and more transparency. And these sorts of tools, I think are completely foster that versus let's have meetings. Let's try to figure out what happened and do it. No, instead it's all out in front of people. You solve problems instantly versus dragging everyone into a meeting. So it's cool to see this space continue to evolve. Yeah. Yeah. And, and just, just, uh, just to close out that idea by adding some more to it, so to speak, I, I've, uh, I've, I've been thinking I need to write my monthly column for the register. And I was thinking, um, I've heard that there's, there's some nerd fight going on about the safe framework, which is all uppercase S a F and then lowercase E. And, uh, so I've been reading up on that and I kind of hit upon this earlier. I think, I think, I think there's a lot of interestingness. Like whenever you see the word alignment, I think that's probably an interesting area to go explore when it comes to speeding up communication. And I haven't really read a lot of the pro safe, uh, uh, arguments yet. And just to summarize safe is basically a methodology. Um, I think maybe it's Jim Highsmith and some other people came up with to talk about, uh, how you do what you might call agile in the large. What do you do when you have 10,000 or 5,000 or even a thousand people and you want to do agile, you know, develop software development and there's, it's got a framework and all sorts of stuff around that. Um, but one of the things

you're hitting on is, is something, uh, you were putting very well. One of the things that kind of comes up in this safe talk and comes up a lot in the conversations that I have. And I think other people, pivotal people have, which is, well, if you have all the roles you need on a small team, a team of like, let's say four to 12 people who are working on any given software, a lot of what we're talking about becomes a moot point. And then, and then the discussion becomes, well, is that possible? Right? Like, like given all the various applications and services that we have, uh, you know, you're basically proposing the opposite of how most large, uh, companies run nowadays in their it shop. And so, you know, I, I haven't really seen a tremendous amount of multi-year convincing case studies that you can push everything down to a single team. I mean, it's, it's what I think for the past two years we've seen, uh, in the pivotal customer base. Uh, but I think, I think you need a good five or 10 years of running things that way before you can kind of like conclusively say it's, it's a works in 80% of the cases. But so far, all the evidence is that, uh, if you, if you do your enterprise portfolio management correctly, and you kind of have a one-to-one mapping of an important service or an application to this small team that has all the roles and is fully dedicated to it, that, uh, all the efficiency you get for all this alignment stuff we've been talking about, when that gets sucked out, it just speeds up the process so much that it's worth going, shifting over to that way of doing things. But we'll see what happens. Awesome. Alignment. It's not just for justification anymore. That's, that's a little, uh, that's a little word document pun there for you. There you go. Uh, so also, uh, one of the things we didn't, we didn't talk about last week, cause we wanted to spend the whole time talking about containers is there was a, uh, I forget the title of it, but the cloud foundry foundation came up with a, another report. I think it was essentially, uh, I don't remember the N equals

whatnot in a geographic distribution, but I did file it away that it didn't, didn't seem totally bonkers and it was spread pretty well geographically and across, uh, industry types. So that's great. Um, but it was essentially on the idea of do companies feel, feel that they have, I think it was developer focused, right? Do they, do they feel like they have the developer skills that they need and what's their perception of their own abilities or inabilities to do a developer skill? So you, uh, you wrote something up on that, which we'll link to what's kind of like the, uh, what are the highlights of that, that, that, that you liked? Yeah, I'm glad you pointed out. I think it was a good, I think it was a quality survey. If you look at the, yeah, I forget what you call it that one, not just the demographics, you just look under the covers at what they did. This was not like a, Hey, we did interviewed four people on a web survey and came up with these numbers, right? So these were, this was a legit survey that said, look, is there a skills gap? Are we manufacturing this or is there actually a problem finding and hiring good developers? And for the most part, companies were saying, yes, that we're seeing there is an emerging challenge to find the best people. And, you know, the survey admittedly, I think was trying to tie this to, Hey, companies that don't see a gap are ones that are super cloud native and they have built the culture and they have the sort of talent gravity. That means they don't really experience it. So if you're running a great IT group, whether you're an all state or whether you're a, you know, Uber, it doesn't matter if you're running a great software team, you don't really feel the gap because people want to work there. So that was, I think the hypothesis they were trying to prove. I don't think the numbers totally bore that out, but you know, I think that's an interesting hypothesis is the teams that struggle the most are the ones trying to run, you know, legacy stuff and having a hard time attracting people to work on that code base. But the more important thing I think in the survey was how are people handling this either real or perceived skills gap? And the answer was training. The answer was not outsourcing. The training, you know, it was not, let's find other people to help do this for us on a contract basis. It was, we need to get this skill in house because we feel like

software is a differentiator. I want people invested in our business. And so I did write up a blog post that kind of talked about how can companies tackle this skills gap? Because it's one thing to say you have it. That's not helpful. It's how do I actually get out of the skills gap or just jump over it? And so I focused on things around training and how do you build up the right team? And how do you demonstrate some of the things that developers are going to want to see to work there? And that at the same time, you want to invest in the people you have. Don't just longingly look at the market and say, Oh, I wish I had that team. You know what? You probably have that team internally. You've just handcuffed them for the last few years with lousy process and lame tech. So how do you unleash them a little bit? And then at the same time, you're going to be making it more attractive for new people. Yeah. I mean, you, you, you bring up a lot of, uh, uh, core pivotal issues, I would say in, in, in a, in a good way. I mean, there's, you're, you're even reminding me of another interesting thing from my, uh, my safe reading, so to speak, which is, uh, and, and, and, and again, I can't really argue for or against safe. I'm just kind of relating interesting ideas in, in the reading that I've had the research, but you know, there's, there's another interesting thing that when introducing a methodology, uh, uh, you have to be careful that you're, you're basically not just, uh, allowing people to keep doing the same thing. And, and one, one of the same things in that issue is like, well, if, if, if we feel like we're not up to the task of, of doing really great software development, right. And nevermind the whole argument of like, why you should do that. Let's just assume that you accept you should be good at doing custom software development. Um, and we don't feel we're up to that task, then we probably need to change things. Right. And what, one of the things that I, I like to point out a lot is, um, it's not only developers who need to change, but you know, also management needs to change how they think about doing things, how they manage and organize things and, and the, uh, incentives that they give people and what they

do. And that, that was one of the criticisms of, of the safe methodology is it's, it's, uh, it almost gives management too much to do in, in the sense of it sort of justifies their current way of working instead of switching them over to doing things. And, and I was thinking of this because, um, you had a good summary of, uh, um, uh, some of, some of the comments that, that city has had from, you know, around and about, but they did actually, I forget if it's two or three, but they did, they did a, uh, a small handful of talks at spring SpringOne platform. And one of the things that was interesting is their plan to, to have, uh, insourcing be the majority of the way that they do their staffing. Uh, instead of, I think, I think, you know, I'm always suspicious of a, uh, what is it? A Petro thing or an 80, 20 split, but whatever it's a, it's a, it's a easy way of doing stuff that now it's, it's basically 80% outsourced and 20% full-time. And they want to, they want to flip that ratio around, which I think is something that, um, is more or less the implication of this idea of being good at software is that the relationship that you have with outsourcers, uh, probably needs to change a lot. And, um, you know, this, this is why I bring up the management thing is to, to insource or outsource is basically a more or less a high level management choice. And so man, that's something that management has to do and walk through and think about how they, they execute on that kind of strategy, which, whichever one they put in place. So it's, it's kind of one example of how management has to change just as much as developers do. And then of course, the idea of training and paying for that stuff, right? Like that's, that's another thing that, that management needs to do. There's only, there's only so many self-directed brown bags that, uh, a development team can do before, you know, the brown bag explodes and doesn't, I'm thinking of metaphors of how much stuff you can put into a bag before it doesn't work out, but you know, probably peanuts. Uh, but how many honey roasted peanuts can you put in a bag before I eat them all? The answer infinite, but you hit on a

great point is again, I think we've, and you're, you know, and then we'll talk about a little bit in a moment, but a lot of your work and others focuses on, it's not just about changing the tools and tech at the, at the grassroots level. It is at this case, you know, Brad at city coming on stage saying, we're flipping this because we need to be a software company. And because this makes a difference to us and we're going to put our money where our mouth is like that is the only way you're going to get your culture to change is when you should people prove it, not just, Hey, let's send out a memo saying we're going to be agile. Like that's arguably the most worthless thing you can do because you have to prove it. Like, look, we're going to invest in training. Look, we're going to bring in coaches. Look, we're going to bring in pivotal labs and do pairing. Like you've got to prove it. And that only happens at the top, top, especially when you hit a tough decision point and somebody has to prove that they're going to stick with it. That that's when you prove that this matters to you. Yeah. Yeah. And I, and I mean, and that, that hits on, I mean, so it's the, uh, as you were alluding to, like, there's this, uh, uh, I don't know what to call it. Maybe you or some listeners have a good idea, but, uh, there's this cloud native journey addition to, uh, that I've been working on. And I actually, I'll put a link to it in the show notes, but, uh, uh, I've actually made it public if you know where the link is. So it'd be great if, if the, uh, if the listeners go in and check it out and tell me what they think of it. You can, you can leave comments, but not edit it, but you know, you can try to leave suggestions and comments. That'll be, uh, enjoyable, but I mean, there's a couple of things that I've been kind of wrestling with in there. One of them, just to connect to this is the, the, I mean, so basically what I'm doing in there is over the past year, I've had, let's say are about seven to 10 of the same conversations on the same topics as I go and talk with, with organizations. They have the same questions either of why am I doing this or how do I do this? How do I switch an organization over to being, um, uh, really good at doing its own software? So I've tried to collect together, uh, those questions and the answers to them. I'll, I'll see when I get finally down to editing, if I don't have answers to questions, if I just delete them and pretend like they didn't exist, but you know, cause that wouldn't be a very good section. Uh, how do I do such and such? I don't

know. See you in the next section, but, uh, it's a little shrug, shrug shape. If that fills in your document, we got problems. Exactly. Exactly. But this, this outsourcing topic is one of the sections I have in there. And, you know, uh, I always like to have some, uh, some numbers and analyst stuff to hide behind as it were. And the, um, the, uh, the horses for sources firm, I think is, is the one I'm sure there's many other firms, but it's a firm that I know an analyst firm that covers outsourcing pretty well. And I was looking at some of their surveys and you see similar things from their surveys that like a huge percentage of the, uh, of the executives at companies when asked what they think of their outsourcing, it's not so much that I would say, retroactively. Well, at least it doesn't really say retrospectively if, if they don't like it, but looking forward, they, they want their outsourcers to begin behaving in a different way. And, and I, I assume it's a lot more around help us create business value, not just optimize the process by which business value is provided, which I don't mean to be demeaning towards outsources, but I kind of think that's what a lot of outsourcing and especially BPO stuff is about. Um, and so you look at these surveys and people want to reorient how they're doing outsourcing. And so, you know, in that section, at least at the moment, it's essentially is, is sort of that, that part of the conversation I've been having over the past year is it's not so much. And I just had a conversation like this last week. It's not so much that outsourcing is inherently 100% bad. It's just that the way you're currently thinking about it as a tool and, and, you know, managers are thinking about it has to be reoriented. And I think as one example that I was talking with a large insurance company with, uh, last week, you know, if you look at the, the layers of pivotal cloud foundry, as an example, or, or any cloud stack, the, the huge degree of automation you have at the infrastructure layer, uh, it's basically the main reason you call out your outsourcers of the infrastructure layer is just to add capacity to the overall cloud. And, you know, the analogy I was using, or I don't know why it's, you know, no one's heard

it except the people in that room. But the analogy I was using is a stupid one, but if you have a house and let's say you build five houses, five rooms in your house until you filled up those five rooms, you don't need to call a contractor anymore. But once you want to call, you know, once you need a six room, either you have to build it yourself or you call a contractor. And so again, it's kind of a stupid analogy, but the notion is that like, you don't, you don't need to every single time you want to enter a room and use that room. You don't really need to like call up your contractor. And the issue becomes, uh, you know, the way that normally you deal with a lot of outsourcing people, the infrastructure layers, you have like a service desk and you've got to file tickets and do all this stuff. So you just imagine that if you remove that, it's sort of like, well, what do we do now with the outsourcers? And so again, the idea is once you put something like a pivotal cloud foundry in place, the staffing and the function that happens at each of the kind of layers from the dirt to the physical infrastructure, to the, the infrastructure as a service, to the, the, basically the platform as a service layer, to the application layer, things switch around because the software is different. And it's a good opportunity to go back and figure out the relationship you have with your outsourcers and what you expect them to do. So where are you seeing that? I mean, I put you on the hot seat a little bit. I mean, there's, there's different models, right? I mean, I think pivotal labs, we like to say we should be the last consultants you ever hire, which on one hand sounds, you know, really ominous, but I think the point is you shouldn't need consultants after that because we try to train you and ECS team and others who come in and do a great job of helping people modernize, help them replatform, learn good models. So in a cloud world where I don't want a service desk because I should be able to do self-service and provisioning, or I don't necessarily want to have teams that just take up requirements spec and six months later, you know, throw some code back at me. Where, where are you, when you talk to some of these folks who are considering, you know, what's my future look like? Where do you see some of that value for an outsourced model? Is it to do platform ops and to do things that don't necessarily slow down delivery, but still serve a valuable function? Or do you see it as this agile partner, which I have a hard time getting my head

around how that could work? Yeah. I mean, I, I can, I can think of, let's see, I'll do something out later. I can, I can think of, I can think of three things, uh, which, which I'm writing down now, so I don't forget them. And then what was, see, I almost forgot the third one. All right. I think, I think one, what you could do there's, there's a different word that seems slight, but it's, it's a big difference. And that is you might think of outsourcers as contractors. Now, I don't know how it is in the rest of the world outside of tech, but in the tech world, a contractor basically means, uh, you're someone who works here, your badge color is different and you don't get our health insurance, right? Like you might be paid hourly, uh, you know, whatever, but you basically report and are responsible to the same manager as the insource talent. And you're on the team. Like I'm thinking of a very specific contractor that I worked with once and more or less these contractors, and it gets a little squishy if it's an offshore person versus onshore and all this, but the contractors are just there. And for whatever reason, they're not like a FTE, like a full time employee. So I think that model is kind of like a, um, uh, it's a weaselly way out of your question, right? It's, it's just like, for whatever reason, they're not full time employees. And that part of that reason is probably like, I remember this one guy I'm thinking of, he didn't want to be a full time employee. He wanted the option of, of leaving and doing whatever benefits that he perceives, uh, of, of being a, a contractor. And on, on the employer side, it's also a, there's a certain amount of debt or not debt. Uh, there's a certain amount of overhead that you don't have to carry for a contractor. I mean, I would think that the, in this situation we're talking about, the risk overhead that you carry with them is, would cancel it out, but whatever there's, uh, sometimes what's that? You're describing staff augmentation. Yes, exactly. Right. Versus like I have 400 people who do X for me, which is the more traditional. Exactly. So that's why I was saying it's kind

of a way to weasel out of the answer. Now I think the second thing is, and this is hard to like express. Cause it's sort of like, there's a whole bunch of stuff that comes before that. But if you're running in kind of a cloud native way and you have, uh, I'm going to try to avoid using the word microservices, but you have a very services component driven system, right? Where each of the different services and component are independent and staffed independently. In theory, it would be fine to outsource some of those things in the same way that we encourage people to outsource their platform. Like you should use pivotal cloud foundry instead of building that on your own, or in the same way that you would outsource your database as a service or your mobile backend as a service. So you could imagine situations like I always like to use airlines where airlines have reservation booking systems and they probably have a way of dealing of paying the people who come and clean up the airplane. Like you can break down the business and all these components. And similarly, you might have just APIs that you would call to do things. Now, somehow you have to incent the people you're outsourcing it to, to care about the craftsmanship and the quality of all that. But technologically, there is the option that you could sort of outsource those things in the same way that you outsource it to a vendor to do it. So again, all the danger in all of this stuff is how you line up the incentives of, uh, I just get paid versus having a certain amount of like what I would call like pride in your craftsmanship and making, making any individual and team perform above their compensation, if you will, and do things that are above like just a straight up transactional relationship, which is, which is a weird area. But I could see that you could totally architect things out so that you could, uh, you could kind of safely outsource functions like that. And then again, this isn't like a, an architectural thing, but I was using the example earlier, like you, I mean, the same way that you could run your infrastructure on public cloud, that's a type of outsourcing. Like you could, you could also outsource out your, uh, your, uh, your infrastructure at the bottom. And as you're

alluding to, you know, when you add in various like brokerage services, you could outsource things out like that. So there's like kind of clean areas you could cut things. And I would, I would imagine that the lesson that we learn over and over again, uh, and whether or not we execute on it is that, um, you always, whenever you outsource something, you have to keep a very close eye on it, that it's as good as it would be if you insourced it. And I just wonder if, right. The metric goes from how much money did I save to, am I moving with the same velocity? Like, I think that's what matters more like, Hey, all of a sudden I'm paying $15 a head versus 85 for loaded costs. Like that. I don't know if that's the thing that we care. I hopefully most of these companies don't care about it. Did I outsource this, but now am I shipping less or my customer experience worse? And it's not that it would inherently be worse or slower, but if you haven't built in, as you say, the incentives or either the kind of the isolation. So this team can build and ship their things and everybody's not interconnected in weird ways, but you have to actually, I think, design for this, not just architecturally, but organizational. Yeah. Yeah. And, and, and it, yeah. I mean, if, if, if all you use is like money as the lever and incentive, then people optimize around that. I mean, like, like as, as what seems like a wacky example, I often think about, uh, like, do we, uh, is the incentive structure we give salespeople, not, not we pivotal, but just we as in humanity, like, is that good. Right. Cause it obviously it incents salespeople to close deals sooner rather than later. And to make the deal as big as possible. I mean, it's, it, you're, you're giving people short-term incentives to, to close deals. Um, and that's why the cloud screwed so many people up. All of a sudden you were selling a subscription service. So you actually had to make your customer happy every month. Exactly. They could ditch it tomorrow. And so, you know, you can, you can build in things that say like, uh, that sort of like meter out the same way that options are given to employees. You don't get all the options on day one. You've got to like, usually stick around for like three

years and, and, and then the way you grant them in blocks or portioned out by a month, like all those sorts of incentive things. And so I think similarly, you have to look at the mechanics of how you're incenting your outsourcer, because I would suspect that the core incentives of an insourced that is a full-time person are one, I'd like a job, right? Like I would like to stay employed until I choose to leave, right? Like it's incredibly disruptive if, if you're suddenly your cashflow, uh, you know, you get laid off or fired. So you want to maintain your job, which is a good long-term incentive, right? So you're incented for the long-term health of the company. And then two, you also would like to get paid, right? So like, so like good pay is good and good benefits and all of that. Um, and then, and then I think third, there's probably again, this going back to it, this pride in craftsmanship, you would like, given that you've achieved the Maslow's hierarchy of employment, which is I am employed, I am getting paid. The next one down is probably like, I would like to be happy in what I do. Right. So, so those are some good, but whereas incentives or outsourcers are basically just like pay, right? I mean, that seems to be the main incentive. I'm going down a deep rat hole here, but, uh, anyways, so getting back to getting back to the rat hole. Yeah. Yeah. So, so I mean, I think this, we'll, uh, we'll skip our third news item cause I want to jump into some of your stuff, but you were breaking down in the, as we were just talking some of the, you know, these teams and we think of balanced teams and we think about, you know, what, what does this modern team look like? You have a big section on product roles in your toolkit. You talk about the core roles and the roles that aren't core. So I don't know for, for the sake here, you want to let's, let's start with the ones you think are not as cool. Well, well, first of all, first of all, I all, but straight up cut and pasted that from some pivotal labs documentation. I of course went through and added my own view and my little commentary, but a lot of that, a lot of what you, one would read in that section. Um, not all of it, but, but the, the, the product team section is a lot of labs theory,

if you will, which, which having all but cut and paste it, I would say I agree with it's, it's a good representation of that. Um, but, and, and especially if you go talk with, um, uh, you go look up some of the talks that a lot of, a lot of pivotal labs, cognoscente and, and, uh, thought lords and ladies do, um, they have this idea of a balanced team, which is, um, it's, it's basically more detail on a two pizza team, right? I mean, a two pizza team being, you should have a small team that given a, uh, Pacific Northwest size pizza, which I think is the same size pizza you get in the rest of the world. Little Caesars sizes kind of screw up your math here, but let's assume a regular sized round pizza. And I'm assuming you can verify this in the Pacific Northwest, pretty much standard pizza sizes, right? There's not like crazy, small or crazy big pizza sizes up there. There are, yeah, I mean, it's not like crazy, super deep dish. I think we throw some fish on there here and there, but yeah, normal size pizza. All right. All right. So you should only have as many people as you can feed that I guess don't have a gluten intolerance and are eating carbs, uh, with, with two pizzas. Long story was something that I made into a very long joke short. It's basically like eight to 12 to 15 people, right? So you want that many people on your team. Now, why do you care about the people size so much? Well, we just talked about this alignment stuff way back. The more people you have, you X, I think it's exponential, but it's, it's some dangerous amount of communication paths you have. And sooner or later, you're going to be spending all your time just syncing up and aligning people, which is terrible. So you have a small team. So on that team, uh, then what's the scope of responsibility you give them? Well, you give them, some people would say one service, one microservice thing, or one application, but you kind of chunk up from an end user perspective, one thing that they might do. So I would imagine like a mortgage loan application would be one thing. Now underneath that, you might have other teams for like fraud

detection and credit checks, and those might be other services. And how you decompose all this stuff is like easy to parlor trick out, but like it's, it all, it's all dependent, but you have them focused on this one thing. Now the next important layer is so as, as you were getting to, uh, what roles do you have? Well, you're going to need some developers so we can start with that. And, and I think, I think developers maybe constitute, let's say 40 to 50% of the team. Like it, it, it varies to some degree, but the next most important role that you have, uh, is the, the, what, what we in pivotal world called the product owner or, or the PO, which has all sorts of puns you can make off of it, I guess in, in, in the software vendor world, they would call this the product manager. I think that, but, but we, uh, we like PO terms. So the product owner, and I was talking with one of these people at one of our customers last week. Um, I mean, I would liken them to a combination of three things. What's traditionally called a business analyst, which is understanding what the business is and what the customers are and how that kind of decomposes into technology stuff. And then also that product manager role. And the product manager role is basically like, what is it, what features are the developers going to work on? I mean, there's, there's other stuff that goes in there, but that's kind of the salient thing there and, and how you get to that decision process and how you prioritize that and everything is a lot of what a product manager does. But then I think another part, I'll have to go see if I wrote about this, but I think they are effectively like a general manager of that product. Like when you push, you push down so much authority to the team that the product owner is sort of like the de facto GM, right? Like like the mini CEO is how I used to describe it when I ran a team of product. Totally. Exactly. That's a, that's a phrase that one of my, my past bosses used and such a situation. But yeah. And so the product owner is basically the one who has, and phrases like this are like annoyingly authoritarian, but whatever, they have the final say on things. Now, conversely to the judgy and authoritarianness of

the final say, they also are responsible for holding back the onslaught of helpful helpfulness that the rest of the organization wants to give this small team. So, so like this, this, this, this, uh, this product owner I was talking with last week was saying, yeah, we're in a large organization and, uh, there's always lots of people who want to come help. And so my job is to schedule a meeting with them and make sure they never actually get down to my team, which you could take a cynical, but it's the, the, the, the other part of that is, and my job as a product owner is also to educate them and help them understand why we're keeping a small team, right? Like I need to walk them through that process and make them understand why, uh, why I'm holding them back instead of letting them cut flood in here and, uh, and help us out so much. Yeah. I mean, I used to tell the team, look, a product owner is the voice of the customer inbound and the voice of the engineers outbound. And to some extent, you know, I would measure the success of a product owner by how much time the dev spent coding. Cause if they spent all their time in meetings, you have a pretty lousy product owner who's not helping prioritize well or randomizing them. So I, what I want to ask you though, is, are you really seeing this pop up more and more in an, in an enterprise environment? Because I know I've read a lot of pieces around, Hey, enterprises really could use product managers implying that, Hey, they don't really have them. So are you starting to see more and more of that take shape? I mean, I, I, I'll be the first to admit that I have a sort of halo effect in that. I mostly just talk with people doing, you know, who are pivotal customers and doing things. But when I do go out and talk with other people and, and, uh, and, you know, read analyst reports and also just talk with non-pivotal customers. I mean, they are, I think the role of the product owner is the hardest one to get in place. Like I was even stumbling through like, you know, mini CEO and stuff like that. Cause you are basically saying, Hey, executive management, how about I steal some power from you? So like, that's, that's the most difficult thing to put in place. But I think, I think I do hear many,

many anecdotes and tales of, we went with a small team and that seemed to work out better. Right. And, uh, and, and it's almost like that's not to get too abstract, but that's a general pattern that I see over and over again is if you're in a large organization trying to figure out how to do custom written software better. The one word that you should repeat over and over again is small. Like it's, the answer is not always, yes, we should make it more small, but in every single situation, you should say, can we do this smaller? And of course that's not grammatically correct or whatever, but like, can, can we take a smaller approach than we're currently doing? And in general, whether it's a smaller scope, a smaller release, a smaller team, a smaller, whatever, usually in many cases, doing something smaller will result in bigger success at the end to be all Hallmark greeting card about it. Uh, but like, that's, that's kind of the pattern that I see over and over again, whether or not you're putting all of these different, uh, things into place. Um, so, so then the other role. Yeah, no, sorry. I mean, and that goes with your general small batches mantra. Exactly. Just small everywhere and do the least amount possible, but not too little. I mean, whatever the Einstein quote is, there's, there's a quote in there around, like, look, you don't want to have anarchy, but there's also do the least possible because that's going to help you move faster. And then, and then, and then also to self-congratulate myself with my cleverness more, right? Like you can, uh, if you're one of these management layer people, you can also take a small batch approach to how you change your organization, right? So you can say, uh, well, let's try this for a month. I have a theory that if we, if we, uh, my theory is that if we have a small team that's fully dedicated to doing their product and they don't do anything else, let's try that out and see what happens. And if it doesn't work, then we'll stop doing that. And if it does work, we'll do some more of it. Right. And, and we'll, we'll limit ourselves to doing it for a month or whatever. And that's, you know, there's another section on getting started, which I think I published also in medium or somewhere else as an excerpt, but like, that's another approach is you try just a

series of small projects and you ramp up as it works or doesn't work. So again, it's an example of like, always think about how you can do a, a, a sort of small batch approach. So getting back the other roles, like, so on a labs, people recommend, uh, having a designer, uh, you know, design, design skills on because a lot of the, um, it's not always the case, but I think most of the time you're going to have a UI and, and it's good to have a designer to, to study user interaction and how users are doing things. And the designer does more than just, you know, uh, graphic design and stuff. They're all, they're the ones who do the user studies and figure out like how things are being used. So if you were doing a purely backend API driven thing, uh, the designer role might be something more that you would expect a, uh, that you would expect to see from the spring framework people or from people like Joshua block way back when in the Java day, which is if you're designing an API, I mean, I've already used the word design, but when you're putting together an API, it's worth thinking about what the users are doing and how you make them more productive and more effective in the same way that you would do that with the UI base thing. And I think a lot of what you see in, in, um, going all the way back to, uh, to, to bobbleheaded Rod Johnson. Do you ever get that statue of the bobbleheaded Rod Johnson? I've got that in a box somewhere. I should find that. I did. I didn't. No, that sounds great. It was good times. Uh, but, uh, you know, there, there was a lot of care put into thinking about the user interaction of those APIs. And if you go read your effective Java, that whole book is basically about the usability of APIs. Um, so you've got the designer on there. Now there's a few other roles, uh, that are on there, you know, as, as you might expect, there are probably ops people on there and this, this is where things start to get squishy now at the start. And so far I've seen this pan out. You generally have like a, a, um, a traditional ops person, like someone who really does no ops and through peer pairing, which is another thing that goes on that I'm not really talking about here, but like all throughout this, you're doing pairing, which essentially when you have rotating pairing,

it spreads knowledge and it kind of levels out in a good way, all the knowledge. So over the course of probably a couple of years and, and when the first year you have your operations pair people pairing with people. And so they spread that knowledge out. And I don't know if everyone would agree with this, but I think the goal is basically like, it's not so much that there aren't ops people. It's that there are people who know development and ops. And so that, that knowledge gets spread out amongst everyone. Right. And you see a similar effect with, uh, testing. And this is where things get really controversial for all number of reasons. Um, generally like if you ask labs people about testing, they'll tell you that like the developers do most of the testing, the develop, I should say the product teams do most of the testing on their own. So that might imply that you have actual full-time QA people there, but I think more of what it implies, this is goes back to what we were talking about is like the technology works, uh, the technology works to automate so much stuff that you spend a lot less time on just like scripted testing and manual testing. And a lot of the function of testinality is just like very high value testing, like the old, I guess this is exploratory testing where you're just like, I'm going to put a book on the keyboard and leave for the day and see what happens when I come back. Like just that kind of stuff. So, you know, you might have QA roles and then there's a bunch of optional stuff. Like sometimes you need security people on their full-time and auditors and all that kind of stuff that could probably rotate in there, uh, more than anything else. And then I think supporting that, this is where a lot of the safe talk comes in. You might have enterprise architects and other people who are coordinating stuff. And that's, that's, uh, that's, uh, that's highly experimental stuff at this point as, as these teams fan out to larger stuff. But, you know, that's generally the, uh, the sort of team structure. And then just to be quick about it, so we can wrap up here. Uh, there are, there are different teams that actually run your platform that like run pivotal cloud foundry for you, but the goal, the reason that you have pivotal cloud foundry in place is so that your product teams don't really have to worry about that. Just like, just like they don't really have to worry about the roads that they use to drive in or the tracks that they use

to come in to work. That stuff is just all taken care of and they can just focus on writing software. Yep. Yeah. I mean, that was a, I liked you calling that out and even on testing again, it'd be easy to think of testing as just, Hey, these are people who point and click and run a 90 page test plan. But you know, QA nowadays is definitely more, as you mentioned, it's user testing, it's understand relationships, experience. Did you break things? But some of that skills in the team and to your latter point with the platforms, I think that gets pretty exciting when you actually have platform ops that run things and you kind of change this relationship from maybe not needing full stack devs who are actually, you know, configuring load balancer and firewall rules. Instead, they're, they're still app focused and any ops type people in that balanced team are focused on building continuous delivery pipelines and helping you set up maybe cross site things, but not actually going down to the metal. Yeah. I think that's a pretty exciting transition. Yeah. And I don't know if this is really a helpful way to think about it or if it's true, but one theory I might have is that, uh, any technical specialization you have needs to be protected and hidden behind an API somewhere, which, which is to say, if, if it can't be, something's probably something bad will happen, right? Like, like if, if, and it's for example, right? Like you're, you're, you're, uh, your network engineer and your database administrators, like just who are infamous sources of slowing down progress for, for all good reasons. Right. But it, and it's because there's not, there's usually not APIs around that. Like you have to go deal with people and educate them and do all this stuff. So it's fine to have that specialization, but somehow they need to make it accessible, uh, and, and make it so that people don't, don't bottleneck and worry about it. So, uh, I mean, those kinds of things are where the challenges really start occurring is, is balancing out when we do need specialization and checks and balances and, and auditors and all that. How, how we make sure that they're an enabling function. I think

as, as a last comment, I think, I think, I forget who said it. I think it was an HCSC person, a Blue Cross Blue Shield company who said, or Liberty Mutual, who said, we want to make sure that it's easiest to do the right thing, not hard to do the right thing. And I think that's the approach that they want to move, that you should move towards when it comes to these specializations and external auditing functions. But with that, we, we got, we got to wrap up here. Uh, this has been Pivotal Conversations as always. You can go, uh, to our not so secret backend at soundcloud.com slash Pivotal Conversations. You can subscribe there, peruse our past episodes. If you liked this episode, it would be great. If you, uh, one, you can just, uh, say you like it in Twitter and send a link. That's actually one of the more effective ways of doing stuff or just tell other people about it. You can tell us you like it, or you could go leave a rating or a view in iTunes. I don't think anyone's really done that, at least for the, uh, U S version. So you could be the first. That would be wonderful. And as always, uh, you know, thanks for listening. And you can go to, uh, pivotal.io slash Pivotal Conversations with the hyphen in there to find the full show notes and we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.