Cloud Native HR - talking with Pivotal’s Joe Militello

Episode 7 · 2016-03-11 · 43:30 · SRT · archive.org · all Tanzu Talk

We were talking at our worldwide kickoff meeting. We were having just a little after-conference relaxing up in what I like to call the Death Star of the Marriott Hotel there. It's got that gigantic, I guess it's called The View because it has a nice view. And, you know, realizing that you have quite a lot to say about HR. And then also thinking that one of the things I encounter when I go out and talk with our prospects and customers a lot is they have a lot of questions about how they do HR, basically. To be successful with the Pivotal way. And it seemed like you would be a great person to talk about those issues or just talk about how we deal with them and hopefully in a way that kind of helps out our customers. And to that end, why don't you introduce yourself? Hey, I'm Joe Militello and I'm responsible for the HR function here at Pivotal. One of the things we'd started talking about, and I think this reflects what we see our customers. Well, I should say how we encourage our customers to start thinking about organizing themselves is there's an interesting amount of complexity in how they have to start thinking about their staffing and organizing and the people that they work with. Because on the one hand, we're asking them often to have like these integrated teams of software developers and sysadmins and product managers and stakeholders and line of business people like all of the I always think of it as like a smoothie of all the people that you need to result in like a good product and a good sort of software based product. And usually in traditional companies, those things are, I don't know, very neatly partitioned out into their own roles, but instead we're trying to get them to, you know, make that smoothie of complexity. And I feel like we have a lot of dealing slash benefiting with that in our own organization. And I was thinking, you folks in HR must have to deal with a lot of that, right?

Like how you have these separate types of careers and roles and separate types of jobs people are doing and yet we're asking them to be, to perform day-to-day in a homogenous way. And yet traditionally the way you think about an employee is usually anything but homogenous. I don't know. I mean, I don't even know what challenge it is, but I imagine that you come across all sorts of interesting ones organizing the way that we do. Yeah. And I mean, every company has their level of complexity. And, you know, probably, you know, really over the last 12 months or so, actually myself and my team have actually been engaging more directly with customers, especially as, you know, they're undergoing their own, you know, what we've been commonly referring to as their own transformation journey. And when we talk to our customers around, you know, how to build software in a different way or in a more modern way or in a more agile way, you know, it also requires a, you know, a people and a cultural transformation. And so we've spent a lot of time talking to their HR teams, their recruiting teams, and just talking, you know, explaining to them and showing them how that would actually work and what things to look out for. You know, for the complexity that we deal with, I think anyone that's been at Pivotal in more than a couple months certainly know that we're not your typical company. And, you know, one of the conversations we had, you know, at The View was, you know, over the last three years, really the journey that, you know, we've been on and one of the things I've been focused on is how do we deconstruct a lot of that complexity? Like, there's not a lot of companies that on day one are 1,100 people in 33 different countries. And when you scratch the surface, it was about eight acquisitions over those previous three years, right? And you think about the different engineering practices that we had three years ago, the different go-to-market motions that we had three years ago, the different titling that we had three years ago, you know, the different leaders from those acquired companies that we had.

Obviously, a lot of them are still here, you know, the different cultures. And so it's really been this journey of, you know, how do we deconstruct the complexity so that we can, you know, so that we can continue to operate, you know, I hate to use the word agile, but really in an agile way. Yeah, I mean, at the risk of, like, maybe making us sound a little fuddy-duddy, it's sort of like, if there's a large company transforming problem that you can have, we've probably been through it, right? Based on, you know, the amount of time that, as various entities, the parts that form Pivotal are around, and Pivotal's been around for a while, too, and then also the size that we're at, the type of customers that we have, like, and I think in all aspects, we've been pretty successful at navigating through it. It certainly hasn't been short of pain, right? That's right. You know, we've certainly made our mistakes along the way, but that is also part of kind of the culture where it's been developing as a culture, right? And so, you know, we'd certainly never share with customers that we're perfect because we're not, but we try to have those tight feedback loops and learn along the way. So what would you say some of the more common things are? Like you said, over the last year or so, you've been talking with some of our customers more about how they can think about the HR function. Like, what are the first conversations that you usually have, like the questions and the answers? And then the best ones are things that people never thought to ask about that you sort of bring up. Yeah, I mean, the, you know, first of all, you know, the conversation generally with the customer C-suite and the heads of HR are a little bit more higher level, as you'd expect, in terms of, you know, philosophically how we approach things. And we talk about our values and how we do things and why we do things. And there's always a principle behind things, right? So, you know, we use words like, you know, pairing or RPI or test-driven development.

And sometimes you'll get the eye rolls or just the glass overs because they don't know what those mean. Right. So, it's really, we really try to talk in terms of, you know, the principles behind all those things. And then you start to start seeing the head nodding at the highest level of those organizations. But then when you get into dealing with the practitioners, right, the, you know, the directors of HRs or the directors of finance or the local recruiters, you know, helping them actually execute on it is a completely different, you know, set of issues. You know, so, for example, you know, where, you know, it's very common for us where we want to extend an offer, the SLA that we have, the recruiters have with the business is that we should be able to get out a written offer within 24 hours. Some companies are not set up that way. Right. And so, you think about, well, how does that, how do you actually do that? Well, you need to have buy-in with your leadership team, you need to have, you know, buy-in with your managers and your finance teams and your recruiters. And it's not easy, it's easier said than done. You know, when we formed Pivotal, a lot of our recruiting practices were from EMC. And I'm not saying EMC is a wonderful company, but their SLA wasn't getting out offers within 24 hours, and they certainly had reasons for doing that. And so, for us to do that had to require some fundamental changes within the organization to be able to do that. I mean, that's just one example. Yeah, no, I think that's a great example because it highlights something that I see in other, I don't know, in other discussions when we talk with people about transforming is it's easy to kind of be dismissive of like, oh, our process doesn't allow us to do that. And it's sort of like, therefore, we're terrible. It's easy to go all Eeyore on it, but generally what I found is like, as you were kind of alluding to, there are reasons the process was set up like that at some point.

Like, the way the business wanted to execute or a risk they were trying to manage, like, usually results in a process that you have here and now. And so, that's why I think it's always good to start, as you were saying, with like the principles and the goals that you have, because there's a reason you want to be able to put an offer out for, you know, in 24 hours, right? Like, that speed is necessary. It may not always be necessary, but if you don't have that kind of sort of like, I hesitate to use the word strategy, but if you don't have that kind of principle or reasoned approach for it, it can be a little confounding why you need to go through all this change and change things around. And so, I always find that, like, explaining why we're doing these things, but also understanding that there was a very good reason why we did things in a different way is a very helpful way of going about change. Exactly. And part of why we do it here is, you know, one, it could be a competitive market, so you don't want to lose candidates. You know, we want, as a support organization, you know, we want to be able to execute as quickly as the business needs to. And it also fits within, you know, this philosophy that we have within HR and, candidly, the broader G&A team is this focus on experience. You know, while, you know, our labs teams are focused on building apps and, you know, it's just one part of the organization. And they're obviously focused on the user experience, right? Our field teams are focused on the customer experience. Everyone that we touch externally, we're focused on that experience, right, the UX. But within HR and recruiting, we're very much focused on who our customers are and the experience that our candidates, our hiring managers have. And so, you know, I wanted to go back to when you were talking, you're talking sort of like the head of HR. One thing I always try to balance when I'm talking with people, and I'm curious, like, in kind of like the C level of HR, what you find effective.

Like, when you're going over these principles and, like, goals that you have, do you find that, like, you have to systematically prove them or that people more intuitively understand them? Or how do you, when you have someone who's a little confrontational, like, like, like, like, what methods do you use to kind of show them that going through this change is worthwhile and that it has results? Well, there's nothing like a good story, you know, to help contextualize it for folks. So usually we'll tell a story of a previous customer or we'll have other customers talk on our behalf. You know, our approach also, at least when I'm dealing with customers, is really to just take a very kind of humble approach and seek to understand. Well, we certainly have opinions on how things work, and we've certainly experienced the good and bad of different approaches. And so we just try to tell a story and explain it. You know, one of the other things that you always come up when talking with customers around how we do things, especially on the recruiting and HR front, is our pairing interview. You know, they find that very, just, it's very new to them. And, you know, really the pairing interview or the RPI for the software developers, all it is is a practical interview, right? It's just spending an hour with, you know, a potential candidate and doing the job as they would do it here at Pivotal. And they find that, that's one of the things that I find very difficult to get through because certain HR organizations and certain legal organizations are super conservative. And they wonder, well, you know, are you documenting that information? And if you document that information, are you setting yourself up for future lawsuits? Oh, right. You're very concerned about, you know, having too much data. And we're on the other end where we try to be as open and transparent as possible with the approach.

But also, you know, the practical interview is very controlled, which is, in a good way, it's one of the best indicators we have of whether our software developers are going to be successful. Right. That's why we have such a high success rate. And actually, one of our goals for the recruiting board this year is to take this concept of a practical interview, essentially working with someone before they officially join us. And it's a great way for them to evaluate us as us to evaluate them. We're going to take that to all the job functions, whether it's sales reps. They experimented with this last year called their stand-up, stand-and-deliver. We're going to take it to field engineers. We've already taken it to HR. So we think it's one of those things that can really differentiate us in the marketplace because my personal opinion is that recruiting is broken out in the marketplace. Most companies do not know how to recruit, whether it's how to source, whether it's screen, or properly onboard folks and have just a great experience. Yeah, so that's interesting. I mean, two angles. One that's interesting to me as a former software developer is that someone would be even slightly aghast at, I guess, testing the programmer out. We used to, at one company I worked at, we had a hands-on thing, and we jokingly called it the, you know how to use a keyboard test, right? Because I guess we had hired someone who actually wasn't that great at programming, and so after that, we ended up actually giving someone a very trivial, you know, that you can do in 20 minutes, a very trivial programming task. But I'm curious to hear, not only across, like, programmers and sales and marketing, the other roles, like, how, like, what does that hands-on thing end up looking like? Like, is that, does that mean you have, like, a two-day interview process, or do you reduce it down? Or how do you come up with a way of giving on, pre-on-the-job interviewing, so to speak?

Yeah, I can tell you the way it looks for engineers and for the design folks today. And it's essentially, it's a one-hour pairing interview where you have the candidate and you have, you know, someone who's RPI certified in order to conduct the interview. And basically, they work together and they solve problems together. And the RPI-ers, in the software developer case, is just looking for two things. You know, they're looking for aptitude, right, the potential of that employee or a candidate in terms of their skills around learning different programs and their thought process and, you know, the speed at the speed at which they can think and problem-solve and getting to the simplest answer. And then the other is empathy, right, because, you know, our software developers, they pair. And so every day the pairs change and they have to interact with one another in terms of building software. So empathy is important. And also a lot of our developers interact with customers. And so empathy becomes super important there as well. And so, and then we've also taken that approach on the product design side. And then if you pass the one-hour interview and we have different gratings, you know, depending on how strict we want to be. And it really takes the subjectivity out of it. So either you can do the job or you can't. So there's a lot of focus in the industry these days on unconscious bias and, you know, making hiring decisions based on your culture, you know, what you think is the cultural fit. But you're really just imposing your own biases on someone. And so this really helps take a lot of that subjectivity out of it. And then if folks pass that RPI, then they're invited back. They're invited for a two half-day pairing interviews where they'll pair in the morning, then they'll go to lunch with some other pivots, and then do a pairing interview in the afternoon. So we want to take that concept and bring that across other functions.

So the America's field team last year, sales team, piloted this with, you know, stand and deliver. So we would give a sales candidate a problem to solve. A lot of it would be around the pitch and how to position Pivotal. And they would come in, and in front of a panel, they would have to articulate that and essentially go through how a day would look like, you know, them going and talking to a customer in terms of how they would position, you know, Pivotal or PCF or labs or data based on, you know, the audience that they were talking to. And whether it was, you know, whether it was, you know, the CIO or whether it was DevOps or what happened. Yeah. You know, I always think salespeople are particularly interesting. And I mean, this is a little self-serving or biased to say this, but I was, I've noticed that our salespeople are like painfully honest. Like, to a certain extent, of course, you need them to be honest. But they're very humble about, like, what our software does and, you know, what labs is capable, is the way that labs likes to work and things like that. And so I imagine, I don't know, I mean, you tell me, but I imagine sort of there's a trick in programmer interviewing that you can do sometimes. And by trick, I just mean a clever way of getting, of figuring out how someone operates. And that is you sort of inject an error into the interview process and see if they spot it and, or, you know, in the problem you have for them. And I imagine with salespeople, you could also do things where you're sort of testing at your role playing, like, their, their sort of over honesty and humbleness and things like that. And, and it's interesting to, to plan ahead for those types of traits, those cultural things, if you will, that, that you want to identify not only positives for, but negatives for as well. Yeah, for sure. And I mean, I love our sales organization. We have, you know, a great group of men and women, you know, within the sales organization.

And, you know, they have not had it easy over the last couple of years, right? That's right. As we've been focusing, you know, our strategy really hasn't predominantly not changed over the last couple of years. But, you know, the, you know, the focus in terms of our selling motion has continued to evolve. We've continued to learn in terms of, you know, what's going to resonate better with customers. Obviously, things around Spring Boot have become much more prominent and important part of our sales cycle. You know, three years ago, we were not monetizing, you know, Cloud Foundry and, you know, and, you know, everyone's familiar with, you know, the growth in terms of from zero to roughly 30-ish million to, you know, over 100 million, you know, two years later and so forth. So they have not had an easy time, but they've done, I think, really well in responding. When you're coming around, you know, customer sales teams doing a good job in terms of listening and being humble to our, you know, with our customers and, you know, I think hopefully, you know, anyone listening to us today, you know, who heard some of the customer testimonials from Worldwide Kickoff were amazing. Actually, I had a chance to review them again the other day and just the conviction that they have with Pivotal and that they really view Pivotal as true partners. I mean, that's a team effort. That's certainly our sales folks. Those are our field engineers. That's our folks within the, you know, the product teams and the R&D teams, you know, across the board. And I think it does talk a little bit to our culture as well, right? We're not one of those enterprise sales organizations where, you know, we're just trying to jam a lot of software, right, and stuff them in ELAs and then, you know, let the customer figure out whether they're going to use it or not, right? We very much care about doing the right thing for our customers. We care very much about, you know, that customers extract value out of our software, right? And one of the big things from Kickoff was around, you know, retention and renewals and usage, right, and that they're actually consuming APIs.

And so it all fits together in terms of the culture and our approach in order to do what's right for our customers. Yeah, no, and I think that's – having worked in strategy for a couple of years in my past, like, I always key into strategy platitudes. And you just pointed out one that I think is very easy to trace, which is we're a renewals business, so customers need to be happy, right? Like, which has very, I don't know, palpable effects that trickle down to how we need to behave not only internally but externally, right? Like, it's much different if we're on, like, a, let's say, three-year turn of renewals. Like, we have to maintain and actually deliver on things, which means we need to have a very collegiate, like, a very – I don't know, a very team-based way of dealing with people, again, internally and externally, which for y'all means, like, that's the kind of staff that we need, right? They need to be of the mindset where they're – to use the platitude word, like partnering with people and helping them solve problems and figure things out, which is definitely the culture that I find around here. There's always people eager to solve problems. And we're also pretty introspective about we have a process for figuring out process, which I think is always a difficult meta thing for people to wrap their heads around. Yes. And within HR, I try to limit as much process and policy as possible, and that may sound a little odd. And I remember my staff coming to me about two or three years ago in the early days of Pivotal, and said, hey, we need a policy for this, and we need a process for this. And I kind of joked. I said, the only policies I want are the ones that are going to keep me out of, you know, an orange jumpsuit. Right. You know, that really need to just – you know, obviously, you need some guardrails and need process, you know, in order to help folks do their job.

And I know what you're talking about from a field and an engineering perspective. But really, you know, part of our approach within HR when we think about policies or processes, really, I'd much rather focus on just treating employees like adults, right, and allow them to, you know, make decisions in what's in the best interest of Pivotal. Right. And one of the words that has been used a lot over the last couple years is, right, we don't want to act like a big company. You know, I never really know what someone means when they say that because it's such a loaded term. But, you know, but I think it does go back to our kind of philosophy of just trying to be agile and doing the right thing for our employees and just keeping things simple and focusing on the experience. Yeah. I think the metaphor of guardrails, like what I think about when people talk about wanting to avoid being a big company is, well, they want to avoid the drawbacks. And those drawbacks being that there are so many constraints that it's hard to quickly make decisions and do new things. And to that end, you know, I think the metaphor of guardrails is good because it's often when you want to be agile, so to speak, at least in my thinking, it's more valuable to know what you should not be doing than it is to know what you should be doing and how you should be doing stuff. You know, hence guardrails, right? Like to know where the limits are. And then whatever else is left over are things that you can, you know, you have the flexibility to do as whatever problem is in front of you is warranted, which I think, yeah, I think does promote, as you were saying, especially when it comes, you know, from the, you know, a lot of the stuff that G&A organizations do. It's sort of reducing policies and reducing paperwork and reducing all these things. And you're trying to have the bare minimum possible. Yeah, and I mean, I certainly love, you know, my fellow HR colleagues, you know, especially, you know, even outside the company. And, you know, one of the things that we really try to do, and we're certainly not perfect, and I'm sure the audience will certainly can send me an email on 20 things we can do better.

Right. And do differently. But the, you know, we just don't want to, you know, do things just for the sake of doing things. And this, and what I mean by that is, you know, a lot of, you know, when I grew up, I've been doing this for quite a long time now, but when I kind of grew up in kind of the professional world, you know, this mantra around kind of self-service. And I was drinking the Kool-Aid along that, you know, back then. And it was really around having the managers do more of G&A type work. And I remember telling managers much earlier in my career, oh, it's good for you. I mean, it's empowering you. We're being more transparent. But really, as I've been in this role for the last three plus years, we've actually been trying to go in the opposite direction. Right. We, while we certainly want to make sure employees and managers have access to data and access to cool tools and can do things on their own if they want them to do, but we don't want to push, I personally don't want to push work on managers that could be done by a support organization. Right. Right. I want our technical teams spending time with our customers. I want our technical teams thinking about how to outpace our customers. I want our technical teams building great product. And we want our sales folks selling and taking care of our customers as well. And that really the support organization's job is to provide, you know, those teams what they need in order to do their job, but not putting work on them that we could do ourselves. And that includes, you know, directly or indirectly with process and policies. So one of the areas, and this is actually like, I'm always painfully abrupt when I just walk up to people and start talking to them. Well, not always, but frequently. Like when, one of the areas that I was interested to hear your take on is what we do around here with performance reviews and like feedback and that kind of cycle of things. Because we have more or less like, there's a lot of guidance that you guys provide, but it's pretty optional to be stringent about performance reviews.

Like we don't have, in other places I've worked, you know, there's the, I'm sure there's all sorts of official and unofficial words for it. But there's sort of like the trickle down KPIs of other places I've worked where it, it, it, it, it's, it can be wonderful or completely absurd. But, you know, there's like five corporate goals that the CEO signs off of and then those trickle down to someone else, which, you know, turn into something. And then, and then all of a sudden, if you go all the way down to the janitor layer, for some, for some reason, like increasing shareholder value is directly aligned with reducing the amount of gum on the floors or something like that. But there's this like connection of everything that you're going to do. But I think to the point of what you're saying about, we have a much, a much looser way of doing that. And I'm curious to hear like how we go about, because on the other hand, performance reviews are, it's good to have feedback, but how we balance getting the appropriate amount of feedback without it being too much of a process. Yeah. And again, that's really where we're going to continue to learn here. And we're still on our journey of feedback or continuous feedback. And we're coming up on the two year anniversary of where, you know, I kind of made the decision that we weren't going to do performance ratings at Pivotal. And also, you know, we weren't going to do a formal annual performance review. And some of my peers at other companies said, oh my goodness, you did that. Oh my goodness, what's going to happen? Can I see all the research that you did to make that decision? And I'm like, well, the research that I did was I just talked to people. And what I found out was most employees hated it. And most managers hated writing them. And there was no real perceived value in them. And when we took the number of employees and managers and we multiplied it out by the approximate number of hours a year spent on writing your self-appraisal and writing and delivering performance appraisals,

the number of hours, the number of hours was staggering that was spent on this and with no real perceived value. And so I said, that was my research. And, you know, one of the approaches that we also take within HR is we're going to try it. We're going to try something. And if it doesn't work, then we'll learn and we'll try to iterate on it and make it better. Or we'll throw it out and try something different. And so we're not afraid to, you know, try new things. And so getting rid of the performance appraisals and the ratings was actually an easy decision. But then the journey we've been on is like, well, how do employees get feedback? How do employees continue to learn and how to do their jobs better? How do employees get feedback in terms of their own professional career and career growth and development? And so, you know, we've embarked on this agile people development strategy, which includes feedback, leadership development, executive coaching and mentoring. And, you know, the HR teams and the managers are really over the last 18 months have really been focusing on, hey, how do I give feedback in the moment? But I think we're still probably, you know, we're still early in that journey. And we've been providing the teams with a lot of tools and tips and having lots of conversations to try to break through this inertia. And, you know, based on our last poll survey, you know, we are trending up in terms of employees feeling like they're getting feedback. But it needs to be more. And certainly in our development space where, you know, they do lots of collaboration in terms of how they're writing software and solving problems. That's probably the best place in terms of where feedback is happening today in terms of the day-to-day job because just the way that their roles are structured. But I am encouraged in terms of how it's happening and in other functions as well. Yeah, I mean, I'm curious to hear what you think of this. But I remember, so it's about 10 years ago now that I shifted over from being a programmer to, I don't know, a knowledge worker, like a white-collar worker.

Or I guess they're both knowledge workers. You're a overhead like me now? Exactly, exactly. I moved out of the factory into, as a friend of mine likes to say, I used to be good at my job and now I'm good at PowerPoint. But, you know, one of the things I'm constantly, in the same way that your HR peers were interested in the, they're interested in, you know, like, is this going to be a train wreck or awesome, right? Like, in watching how your experiment pans out, like, I'm always interested in the difference between an engineering mindset and the white-collar mindset. And I've noticed exactly what you're saying is that, for whatever reason, programmers tend to be a lot more introspective. And to some extent, they give each other feedback a lot more. Like, they're more interested in the process than white-collar workers tend to be, which at first I found jarring and now it's been so long I'm kind of used to it. But it's, I've never really figured out why that exists. Like you said, why it is that someone who's doing programming or being a sysadman or closer to the computer, if you will, they, it seems to be part of their workplace mentality to have a lot more feedback than people who go to meetings all the time. I don't know. It's a weird mystery to me. Yeah, I'm not an engineer, so I can't speak for an engineer. And certainly a great question for, you know, Edward Hyatt or Rob May or some other technical leaders or any software engineer for that matter. But I would venture to say part of it is around the feedback that's happening focused around a process, right? We talked about a process early on in the software development space. They have a pretty defined, opinionated process. And so I think when feedback is happening, it's not personal. It's not about, you know, really the individual.

You know, it's really around kind of the process and the work and solving a problem and doing the right thing for the customers. So the feedback is always around, you know, how do we make the team better and how do we, how do we make the customer successful versus, you know, this uncomfortableness, sometimes in exchange between one human and another. So I think it's directed more at the process, the project and the customer and overall making the team successful would be my guess. Yeah, that's interesting because one of the things I think about when I reflect on this is to a certain extent or in the context of what we're talking about here, getting feedback, a programmer's job is a lot more structured and straightforward where, where what, as you say, overhead does is often like no one really knows what the outcome should be except awesome. And so, so it's, it's, it's hard to kind of rate how you're doing on something and you often have to, I don't know, you've got to come up with a different, different way of, of rating or not, whether it works essentially. And, and also it's, I mean, I think, I think engineers are kind of trained to always be evaluating and checking and seeing if something works or not. Whereas other types of knowledge workers are not so much in that, that area. Well, it's really powerful. And I've seen this actually happening outside the engineering organizations. And I know Edward Hyatt can be doing a lot of things like this around the broader, his broader new org. But one thing that, at least within HR, we've, we've learned from kind of the, you know, kind of the traditional Pivotal labs way is retrospectives or retros. And that's, we found that, you know, as a very kind of good self-healing way, at least for us. And we've seen some parts of the sales organizations use them as well as that after, you know, a meeting or a project or some sort of event, you're doing a retro, right? And that's been very good, at least from my perspective, in terms of, you know, providing feedback on a process or the initiative where maybe it wasn't so much structure. I mean, field engineers and sales reps and, you know, the rest of the field organization and technical teams involved in accounts, right?

They could be doing retros after customer meetings, right? They could be doing retros, you know, at any, at any time, you know, after any sort of kind of event. And so I think that's going to be one of our, it's one of the ways in which feedback takes place. Yeah, that's, that's interesting. And it raises a question of, so, so would you, would you say like, or I shouldn't say, would you say, do you think like the part of what, what yourselves, like someone in an HR function in this kind of, I don't know, transformed organization, part of their role in so much as they're changing how feedback is happening. If, if they're sort of like the guardians of feedback, then, then it would imply that they would sort of go out and train people about giving feedback and doing feedback in the same way that, you know, our customers will hire people from labs to help them kind of, to coach them and help them do like pairing literally about how to do software in a different way. And it seems like, therefore, HR people could go out in the organization and help people learn how to do feedback better. Yeah, you know, the, you know, the HR teams and recruiting teams, you know, their responsibility is to one is, first and foremost, understand the company, right? And understand our business strategy, understand what we're trying to accomplish as a company. You know, then their, their need to understand, you know, what our people philosophy is and what we're trying to accomplish in the type of environment we're trying to create here at Pivotal. You know, you know, the other responsibility that they have is to then really work closely with their respective business leaders and functions, you know, whether it is, you know, Sung Hae, you know, really working closely with James Watters and his leadership team in ANSI, or whether it's Nicole from my team working closely with Andy O'Brien and Andrew Ettinger, or Louise working closely with, you know, Alan and Amia, you know, the list goes on. So the expectation there is that they really get in and understand what those business units are doing and then help support them, right?

You know, I know Marcy Giovanna works very closely with Edward Hyatt and Drew McManus in terms of, you know, the challenges that the labs and the CSO organizations having this year and what they're trying to accomplish. So that's where then they're allowed that level of, as long as they understand where the companies go in terms of business strategy, they understand some of the people philosophy in terms of what we're trying to do, whether it's around feedback or manager development or compensation philosophies. So then they're asked to then just really get to know their respective client group and tailor everything they do to make sure that that business unit is successful. Yeah. Yeah, no, I like the way you've been illustrating thinking through all this because it matches very well. I don't know, a general principle that isn't always spoken about very explicitly, but is a foundational principle of like agile think and DevOps and cloud stuff nowadays. And that is, you know, it directly steals from lean manufacturing thinking. And that's to like look at your entire end-to-end process, like everything you're doing as a company to, you know, think of a product, make the product or service and deliver it. And every step that you take, ask if it's valuable to the customer or like if it adds customer value. And, you know, if the answer is no, then it's considered waste and you try to figure out how to remove it. And with that effect, you like free up all these resources to focus on what's valuable, which seems like a – and it takes that, as you were saying, it takes that understanding, not only the end-to-end process, like the tactical things that happens, but the principles and the reasons that you're doing things. Like that's the first principle that's important to understand. Absolutely. And part of HR's job is to work closely with business leaders and help solve problems. And one of the things we – and you just mentioned lean. So I'm not sure if you saw the announcement that I sent back in December, but we expanded some of the service offerings within HR, within our L&D organization or learning and development organization.

And it's just two people, by the way, and they have other jobs as well, so I don't have this big learning and development team. Right. But Janice Frazier moved over from the transformation team to the HR slash learning and development team. I'm not sure if the audience is familiar with Janice, but actually Janice spoke at the worldwide kickoff. But she is an expert in lean and lean startup, and she's worked very closely with Eric Reeves. And so we brought her within HR because one of the things that she was doing – she's been doing lots of things, but one of the things she was doing in labs was really doing a lot of facilitation workshops within labs. And we thought that bringing her within HR would be an opportunity to offer this service across all functions globally. And so she even did a workshop for Andrew Ettinger's team on the Monday of kickoff. And so we're starting to – she's starting to train some of my other HR business partners on really the fundamentals and principles around lean. And we're going to continue to – they're going to take those skill sets and those knowledge to then go work with the business and help them solve problems because Janice is just one person. And so by the end of the year, our hope is to have six experts or master levels within kind of doing these facilitation workshops and then basically have them all over the different functions and geographies to help businesses solve different programs or different problems using kind of lean startup methodologies. Yeah, no, and like you're saying earlier, the great thing about that – and again, it starts with the sort of goal. But as long as you have the approach of like, well, we should try this out and see what happens, which is a flippant way of putting basically the scientific method, right? Like we have an idea, a hypothesis of what would work. Let's do an experiment. How do we gather data? Let's analyze it and like come to a conclusion about if that theory was right or wrong.

And if it's right, then we can improve on it. And if it was wrong, we need to come up with a new theory and test it out again. But it's a very deliberate way of, I don't know, to borrow a really old term, sort of getting to excellence, which I think is a much better approach than, you know, the typical like tops down like 12-month multi-year plan of stuff with a bunch of platitudes and things like that. Like it's – you're just trying to figure out how to get through the fog of things and get to the best possible result. Absolutely. And I think we, you know, we hit a nice inflection point as an HR organization about a month or two ago when I was meeting with a couple of HR generalists. Let's just say they're within, you know, three to five years post-college. And they said, Joe, we just need to get to an MVP. We just get to an MVP and we can figure it out. And I'm like – Perfect. And I'm like, this stuff's starting to sink in. That's right. That's right. Well, great. Well, this – is there anything else you want to edge in before we wrap up? No, I think we're good. Just really appreciate your time and I really enjoy doing this. And, you know, if your audience has any interest in any other topics, happy to, you know, chat with them. Yeah. We'll have to check in at some point and see how these experiments are going. Because, again, like I was saying at the beginning, I think questions of how you do HR, to put it painfully broadly, come up all the time. And it's especially true because I think a lot of – the history of agile software development has been largely about the team and how a team can do something. And that part is documented really well. But what's not always documented well is what the company, the organization should be doing. And I think it's only just now that we're really figuring all that out in a way that's repeatable and successful. And certainly, like, our customers get a lot of benefit from that. And they're also figuring out in their various organizations how it works out. But I think any discussion that we can get out there in public about how to help organize stuff is helpful.

So I appreciate you taking the time. Cool. Anytime. All right. Well, great. Well, as always, this has been Pivotal Conversations. You can go to pivotal.io slash podcast to find the show notes for it and get the RSS feed and everything. And as I said, if you have any questions, feel free to send them along. And we'll see if we can get people back to you on it. And as always, thanks for listening. And we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.