Pay transparency, being public, and hiring for culture, with Joe Militello (Ep. 103)

Episode 88 · 46:47 · SRT · archive.org · all Tanzu Talk

Well, my audio quality this week isn't too great because I'm here in London where mysteriously it's very sunny and like perfect weather. People are wearing shorts, things like that. But I have a really nice microphone that I used to use, but I don't have a tripod for it. And I tried holding it, but that doesn't really work. And you know how you're going on a family vacation. You think like, oh, I'm going to use my fancy work backpack. What could go wrong? And so you take all your work junk out of the backpack. And then, of course, you only pack your bag like 30 minutes before you need to leave. So you're repacking all your stuff, and then you forget to put the tripod back in. You don't want to take all that weight of a tripod, your special mic tripod. So that's the problems we're having over here in London. You'll make it, though. Stay strong. That's right. That's right. I might need to have a redundant backpack for family things. Well, we have a, I think, a thrice, if that's the right word, returning guest. You want to introduce yourself? Hey, everybody. This is Joe Milotelo and part of the people function here at Pivotal. That's right. Well, thanks for being on. We've had a lot going on since last we talked, so we'll have to see what's going on. Not only like a pivotal HR land or people land, as it were, but I think it's always interesting to see how the stuff that we are figuring out, how it equally applies to the customers and types of people we work with. Like I think in the past we've talked about, if you have these product or agile teams or whatever you want to call them, that's a whole lot of people policy and issue to deal with and all sorts of interesting things come up. So we'll see what we end up talking about this episode. But first of all, as always, we have a few little news items.

How about, you know, I was looking at the sort of like little three items we picked in here, Richard, and I was thinking, you know, a lot of it. It reminded me of one that was related, which, well, in my mind was related, which was Stephen O'Grady over at Red Monk. Like he wrote his sort of, I don't know if it's annual, but whatever a variable perennial is, I think some desert plants are like this. You just never really know when they're going to flower. But what's up with open source nowadays? And I think related to the two things, you know, as you have here, you know, there's a Redis service, and we can talk about these more from Google and a Kafka service that Microsoft has in Azure. And he was going over the kind of what does open source mean in a public cloud sort of mentality of doing things, which I think is always an interesting topic to get to. I think his summary was basically like a lot of public cloud people work on open source. So we're cool there. There's not like people who are, what do you call it, free writing. But then there's also the, and this is a little bit more of me reading into it, but there's also, I don't know, people don't really mind closed source things so much anymore. If they are run for them as a public cloud thing. Like, I don't, I don't know if there's that much hand wringing and freaking out about it. Yeah, I go to where I got to sit and watch our own Josh McKenty and Microsoft Distinguished Engineer, Uli Holman, last week do a presentation for a customer. And they've got a talk track, and I guess, pivotal plug, they have a webinar at the end of May on kind of, as they talk about cloud portability. And one of the things they talk about is a lot of these things depend on where you are in the app lifecycle. Like, if I'm crazy innovating right now, I don't really care about lock-in too much. I'm just trying to experiment. I'm trying to learn stuff. And then as I mature my application, maybe I do care more about bringing it back on-prem or moving it between clouds.

Then maybe I stop using that proprietary database and I use something more open source. So it's not even just like open or closed. Sometimes it's just where are you in kind of the learning cycle for an app. And that might also dictate whether I care that this thing is hyper-specific to Amazon or Azure or whatever, versus, hey, it's a generic database or everything looks like Kafka. So I don't know. I think that's an interesting hypothesis. It seems, I don't know, I can buy that. Yeah, yeah. I mean, definitely, to use Elon Musk terminology and Kubernetes terminology like open source is boring. Which is to say it's like part of the way things are done nowadays. So there's not a lot of controversy about it as a sort of means of production. And so you're bringing up, go ahead. I would say Google, I mean, to the point you raised, Google and Microsoft are surprisingly two of the best at this. I mean, their new Redis service from Google, now everyone seems to be running hosted Redis. And, you know, Microsoft adding this sort of Kafka looking head on top of event hubs means, look, I can use my existing Kafka stuff and just repoint it at Azure event hubs. They've done the same with Cosmos DB, which can look like Cassandra, can look like MongoDB. So sometimes it's interesting, even if the service is proprietary, you can at least put a head on it that looks like the open source interface so that I can make it more portable, not feel the same sense of lock-in. So that's an interesting paradigm as well that maybe becomes more popular. And in this context, I've never really heard the term head in this context. Is that like an API? Yeah. I mean, in essence, right. It's kind of a Kafka interface, if you will, or, you know, head is one way you can refer to it. But, yeah, it's an API on top of it that at least mimics the thing you think you're talking to. And then so is the idea that the implementation behind it can or is different or something? Or how does that? Like Azure event hubs has no equivalent anywhere else. It's a proprietary Microsoft service. But by making it look like or fake a Kafka interface, I can still use Spring Cloud Stream or I could use all these other things that talk Kafka.

Now, it's not fully featured. It doesn't support everything Kafka does. But the idea is, hey, if I want a hosted version, this can kind of do it with no code changes besides a connection string. That's kind of neat. Or same with MongoDB or Cassandra for Cosmos DB. So that's an interesting trend of saying, look, we're going to keep our proprietary interface underneath the covers. But we're going to put more of an open source, if you will, API on it so that your common tooling and things like that work fine. Yeah, yeah. It's interesting. Because, I mean, it's, yeah. Best of all, well. And I guess everyone's cool with that. Like, it doesn't get you some weird Oracle, like Google strange territory of the copyright of the API. Well, that's a whole other question. But I think for the time being, I think you're cool with it as long as it's a wide enough API surface. Like, right now, the Event Hub's one that supports Kafka only supports the bare minimum. So if you're trying to do, like, legitimate Kafka stuff and you're doing more sophisticated things right now, you couldn't. So I think what's going to be interesting is how much is enough when you do these sort of pretend interfaces on top of proprietary platform. Yeah, yeah. Yeah, and I guess depending on which license it has. I mean, if it's, like, MIT or Apache or whatever the kids use nowadays, like, you can write your own implementation behind it and not have to open source all of that. So that's completely within the realm of the games, if you will. Yeah, it's neat stuff. Of what people are doing. Yeah. That makes sense. Yeah, that's interesting. And then there's a Vita service from Google, as we're mentioning. Right. Yeah. I mean, everyone, I think we talked about this a few months ago. Everyone seemed to be having Postgres services. So Azure does and Amazon does and GCP does. And now everyone does Redis as well because apparently that's just the new. And it's been around for a while. It's crazy popular. But now this idea of hosted service for this, it handles some of the resilience because typically sometimes this is just a single instance cache. But you do want to scale it out for geo redundancy and things like that.

So having a provider do that for you. And, of course, Pivotal sells a Redis service. And we work with Redis Labs, who does a great job. And we have Pivotal Cloud Cache. So all these sort of caching solutions seem to be having a, I don't know, a bit of a resurgence, it seems like. Yeah. And I was noticing in the blog post, as you were doing, they sort of list off all the, as we would say, day two problems that you have. Actually operating and running it, which it'll be interesting to see if, as these things happen more and more, if the, you know, almost the default developer mentality. I mean, there's a reason we've called out day two stuff for so many years is developers don't really think about that so much. And so, you know, people like Google and others, public cloud services have a pretty big, what would you call it, thought leadership voice. I mean, you can see that with the rise of Kubernetes and all sorts of other things. But it'd be interesting, it'll be interesting to see if people take on that mentality, if developers take on that mentality of like, oh man, running this stuff is a hassle and not something I want to concern myself with. Whereas I think nowadays, I mean, I was even thinking, you know, that I should go over to Hacker News and see how many people were like, I don't see what the big deal is. I could just run this on my own with like R-Sync or like some nonsense. Yeah, it was, I think, yeah, it was pretty positive. Yeah, but then I thought like, oh, I have some work to do, so I'm not going to do that. But, you know, it seems like that's, it'll be fun to see if that sentiment shifts to like, it's better to have someone else run this stuff than us worry about it. And then also, I was going to say, I'd only say I contend, and you've talked about this a bit with your DevOps talk track as well, as well as, I think to some extent that let me just run it myself has come from the fact that having someone else run it internally has been such a pain in the neck. So, it's not that it's hard, it's just that it's painful. So, I think people have been taking it on themselves, and if it's easier to run it to the platform, or you do have an ops team that actually works with you versus is hostile, I don't think you want to run this stuff.

So, hopefully this transformation of just making ops better with dev solves it regardless of cloud. Yeah, yeah, that's a good point. I also figure there's like, you know, thinking back to my, I don't know if you were this way, maybe you grew up being a Microsoft programmer and they always seem somehow more responsible. Yeah, no comment there. You know, me and all my friends in our 20s, me and all my other friends when we were in our 20s, I think it was considered the height of maturity to like write all your own stuff. But sometimes there's also a, you know, you got to break a few eggs to be a mature enough programmer in your later decades and realize things. So, also, you know, when it comes to the running things, we had a good write-up of how we at Pivotal, and I don't mean to put myself in that set of people, but some of my fellow Pivotal people, they were detailing how they ended up saving, like, what was the total? It was quite a bit of money. Yeah, it was like $675,000 a year projected. Yeah. Yeah, just by sort of tweaking the way that they were running their build environments and their test environments, because it runs on Google Cloud, if I remember correctly. And I don't know, I mean, there was some, like so many of these great things, it seems mildly obvious once you go through it, but it's probably not, it's like all common sense. It's common because it's uncommon for people to do it. And I don't know, there were delightful little things like, we should probably not run it over the weekend. And just other things of, you know, I think the thing that as they wrote up, which was most challenging, was we need to enforce that, like build times are much shorter, and that at most, to do a full build and test, it should take like five hours. It's like the maximum. And it is like having those things in there, you know, brought down their bill by a significant amount. And it's, I've been, another thing I've been curiously tracking is like, how, how is sort of like micromanaging that kind of costing affecting how development teams think about what they do?

Because sort of like in the past, or the present for many people, you don't really think about the cost of things as a development team very much. It's almost like you pay a flat rate for something, and you might have to wait forever, but you don't really like get the chance to optimize on cost. So this is an example of like, not even in production, how you would optimize on cost, but it could be all sorts of interesting things that you do to drive your, your costs down. No doubt. I mean, we talked about this, I think on the podcast, if not, somehow offline, but I think there was a, it was a Forrester study, or someone recently showed that still like half of organizations aren't really managing their cloud spend. And so some of this lends me to think that again, as you described, sometimes it's just this feeling of let's just build stuff and eventually a janitor comes and cleans out our old stuff and, you know, hey, we're just kind of learning. So we're just kind of sprawling things out there, which from a security perspective is risky in its own way, ignore cost. But this idea of if it's easy to get compute resources, it's easy to give them up. And I like this model of like, yeah, in this article, hey, we blow away build environments every day and test environments, because you're just going to recreate them the next day. Why keep them running? And these are, as you say, very common sense things. I just don't suspect most are doing it. But the cost savings on even Google Cloud, which is really cheap for us in the scheme of things, was significant. So I think that's pretty cool. Yeah. Yeah. The reoccurring theme in our news items is if you, if you make resources hard to get, they're more expensive. I guess that's basic economics. You think so, but that's one reason right now I am writing a white paper on how you can use AWS spot instances under, under PCF. And what does it mean to really manage your compute like a market? And how does the platform actually help you do that? That if you do take a proactive stance, I mean, this can mean significant amounts of money, probably enough to pay your bonus, just barely, Coté. So this is important money. Whoa. I need to go. Did I get a raise? I need to go check this out. No, no. Joe's on the line. So I'm just going to make a Valerie-related joke. You may want to talk to somebody in HR about that.

There you go. That was a good transition. Yeah, you know, that's perfect. Just one more thing before we go to that, because this brings to mind, I forget what I was listening to, but maybe we'll set this up for a topic for some other time. You know, speaking of basic economic principles, you know, there's sort of like the, what's the guy's name, Ricardo or something? And he's the person, I forget what it's called. It's like, it's not competitive advantage. That's Michael Porter, but it's some other competitive thing. And it's basically like, you should only do the thing you're best at. And the example in like the 1600s or whatever he came up with is like, the English are really good at making wool. And they can make port, but they're not very good at it. Whereas the Portuguese are good at making port. So the English should not make port. And then they'll just trade the wool to the port. And somehow that's better. And like, I've never, like, I need a chart that kind of shows why that's better. Because it doesn't intuitively make sense. But I think it's the basic basis for like, like, all sorts of decision making, including not building your own platform. So when we do, when we do another revision of that DIY platform, we should have a special sideboard on wool and port. Man, people are going to be holding their breath till that podcast episode. I can, I can. So if anyone, if anyone knows, I think his name is Ricardo, like a good explanation of why that works. I don't want any like calculus or curves, because I don't know anything about that. But like just something they should write in, if they still write. Give me some education on that. So anyways, back to my compensation. Yeah, I think it's a better topic. That's clearly. So, so, so what I, you know, I think it's probably been at least like nine months, or maybe, maybe around that time since we talked last, Joe. Like what, has much been going on since then? Well, we can talk about this later, but since you brought up your salary, I can give an update on pay transparency and tell all your, all your listeners exactly how much you make.

Oh, that'd be great. Yeah, we'll have 45 seconds of silence in this podcast episode once we wipe it out. Be good. We can, we can talk, we can talk about pay transparency later if you want. But yeah, I just, maybe just, you know, first to start off, just, you know, just saying thank you to all your listeners, right? I know you have, you know, a couple of pivots, you know, that listen to it and assuming some customers and partners, you know, I said, it's just been a real true team effort to get us to the IPO several weeks ago. So just a big thank you to everybody, you know, like I said, it was just a real true team effort over the last couple of years and building this company and getting it to a point, you know, where investors want to invest in it and, you know, see our customers and partners played a really big role in that. So just a big thank you to everybody. Yeah. And also maybe just one thing on that that may be interesting is I remember talking a couple years ago about, you know, IPO, because that seemed to be a question that came up at every town hall, right? It was, when are we going IPO? And the leadership team was really conscious about making sure that, you know, if we did go IPO someday, that it was just a milestone, right? And that we weren't going to let it define us. I think that even to some employees, you know, you know, you know, getting feedback where we weren't talking about it enough. And that was all by design, right? We wanted to make sure that, you know, if it did happen, it was just a milestone. But the next day, right, you know, our mission and our vision, you know, continue. And I remember, you know, the leadership team got together at the end of that Friday and we were talking about, well, we'll see you on Monday. And that see you on Monday was really a, hey, today was great, but the real work, real work continues. Yeah, I like that. I thought that was a good message.

Good. So what else is, new in HR in general, what else changes, Joe, as a public company? I mean, for us, it's new. So, I mean, in your world, does something have to operate differently? Do we think differently? How do you think about HR differently? Did you have a meeting that Monday morning going, all right, team, everything's different now? Or was it business as usual? Yeah, and it kind of goes back to the kind of the milestone, right? It was, you know, at some level, you know, business as usual. You know, we've been practicing at some level of being a public company for quite some time, right? So if you think about the last couple of years, just in terms of, you know, how focused we are on a quarterly basis. You know, think about from maybe a people in a G&A perspective, you know, we've been putting infrastructure in place, you know, for the last couple of years so that, you know, if and when we did go IPO, by and large, not much, you know, has changed. And, you know, with the people team, really, our focus has been and continues to be is, you know, how do we make, you know, Pivotal continue to go fast? And so that's really where our focus is, is really continuing to just keep doing what we were doing, continue to learn and get feedback from, you know, from all the employees on what they need from us in order to help them, you know, be more successful. You know, I think there may be some misconceptions that, you know, when you go public, right, you got to put in all these processes and all these policies and maybe that, you know, will choke, you know, innovation. And yeah, obviously, you know, as a public company, there's a couple more rules that we need to follow. But, you know, we're not focused on, you know, putting things in place just for the sake of putting things in place. We're very, you know, conscious about, you know, what we do and how we do it to make sure that, you know, we're helping, you know, the field teams, you know, take care of customers.

And we're helping the R&D and engineering teams, you know, build great product. You know, that's where our focus is, not about trying to slow things down. So more on that, like, I mean, I don't know, maybe this is more in like the finance area, but are there like different sort of regulations that need to be put in place for a public company? And more specifically, I mean, obviously, there's, there's some and things, but I'm interested in like software, right? Like, and because it's sort of like would affect our customers a lot, right? Like, I always get a lot of questions like, oh, we're a big old giant company, we're going to switch over to doing things in this agile, wacky, weird way. And I mean, I don't imagine from a people perspective, there's any things, any regulations a public company has to put up with people wise, but like, I mean, I know, there's always this concern about how you like in the financier area, how you like capitalize software based on when it was developed and released and all this stuff, which sounds like a delightful thing to do if you're delivering software every week. So maybe someone figures that out. But I wonder if in the area of people, there's, there's any other like, new regulations that would affect the process of how, how we do software in an agile way. Yeah, no, I think the good thing, you know, for, for our teams is that not much has changed. You know, if you think about, you know, regulations that are out there around, you know, Sarbanes-Oxley or, or HIPAA in the US, which is around, you know, privacy within benefits. And other, you know, other government regulations across the world, you know, we've been, you know, addressing those, you know, for years. And, and one area, you know, as you know, we sell a lot to the federal government, right. And in order to just do business with the federal government, you know, there has to be a certain level of compliance and criteria that's met in order to just do business with them.

And we've been doing business with them for years. And so, you know, the last couple of years has really been the getting us ready so that when we do go public, by and large, you know, not much changes. You know, our identity should stay the same, our culture and values should stay the same. And, you know, our, by and large, our strategy and mission hasn't, hasn't changed, right. It's, you know, it's, you know, the, the sense of urgency may increase and maybe, you know, the, the pressure a little bit of, you know, the, the scrutiny, you know, that comes with, you know, the public markets. Certainly, I think our teams are going to be feeling that, but, but how we do our job shouldn't change all, all that much. Got it. So. Go ahead. Yeah. Yeah. So, I mean, is there anything specific you think that may? Well, there's things that I think we should guard against. And I think there's things that we should, you know, have a healthy paranoia about. You know, we are, you know, we're hiring at a pretty good clip. You know, we're hiring about 90 people a month right now. Wow. And so I want to make sure that, you know, when we continue to hire at that pace in order to support the growth of the company, in order to take care of our, our customers is that we're not diluting ourselves too much. Right. There is this, you know, this, this ratio. I don't know exactly the number yet, but you can kind of figure it out by local teams of, you know, how many, how many new people you can bring on to the team so that, you know, they understand, you know, how things work at Pivotal. And that's really, you know, with that growth, you know, one of our biggest focuses right now is around enablement and learning and development so that as we, you know, welcome all these new colleagues to Pivotal, you know, that they are, you know, they have the tools and resources, you know, to be successful and that they get acclimated in a way that doesn't dilute, you know, who we are as a company.

Yeah. So, I mean, speaking of hiring, there was, I think at the end of last week, a bit of a flurry on Twitter. I think it was some executive type had made a comment that, look, if I see a candidate who's been bouncing between jobs for a while, that's a red flag for me. Like, that's not a great thing. And a bunch of people piled on then after that saying, hey, look, are you encouraging people to stay in toxic places? And many of us in our careers may have stayed in places too long because we didn't want that reputation on our resume. So, isn't that, you know, actually encouraging bad behavior, especially in tech where sometimes it takes some work to find the right fit? It was an interesting discussion because on one hand, if I'm interviewing someone and over the course of 10 or 15 years, they've stayed everywhere for nine months, that would be a red flag to me. I would ask about it or I would wonder if they either at some point just make bad choices at some point or are they just, you know, maybe the problem themselves or just unlucky. Like, what is the factor there? So, as you talk about us hiring, you know, 90, 100 people a month, how do you look at history? I mean, where do you see a red flag there if someone moves around a lot? Or is that just an area for you to explore then when we're trying to find out if Pivotal will be the right fit for them for hopefully much more than a year? Hopefully, it's a good part of their career. Yeah, no, that's interesting. I mean, my advice to anyone, whether they're an employee of Pivotals or not, you know, there's this, you know, life is too short bucket, right? And if someone's not happy in their job and they're, you know, you spend way too many hours, right, you know, in the day, you know, on your job. And so, if you're not happy, get out. Don't worry about what your resume looks like. Obviously, you need to take a calculated risk around how you provide for yourself or provide for your family. But I would never advocate anyone staying at Pivotal or anywhere for that matter, right? If folks at Pivotal are, you know, folks who are not happy and they want to talk to us, then, you know, we'll talk to them and help them try to, you know, figure out how they can be happy in their jobs.

But if not, you know, they should go and look to do something else. As opposed to how we look at it from a hiring perspective of, you know, if we see someone that's jumped around a lot and, you know, they have an average of, you know, year, year and a half tenure, you know, it does, you know, raise some questions. And I think to your point, you know, Richard, you know, I think it's just an opportunity to go explore. You know, so, for example, I was interviewing a candidate last week where literally every 18 months for the last four jobs, you know, they were in a new job. After exploring it further, it wasn't so obvious on the resume, but, you know, their company kept getting acquired. So every time they went to a company, you know, 12 or 18 years later, it just got acquired. So they were changing jobs or changing companies without any fault of their own. Right. So I think seeking to understand is really important and not being judgmental. But the number one area of focus for us from a recruiting perspective to ensure that we are getting the best possible talent is making sure that we are, you know, bar none, number one, in terms of how we screen and evaluate talent. And a lot of companies may surprise you or not, that they're just not good at it. And, you know, that's one area where I've been driving really hard with recruiting organization is that we have much more consistency in our screening and evaluation process. And that we are continuing to hone what I like to call a practical interview. So that when we do make the offer, you know, there's a high degree of probability that that person is going to be successful. And if you rely on that and you have a good process, then the traditional metrics and data points that you look in a resume or a CV, they end up becoming less relevant. Because you're relying more on that practical interview, which should be really the true evaluation, whether someone's going to be successful or not in your company.

Yeah. So related to that, and I mean, actually, both of you could, since every now and then Richard manages people, is my understanding. It would be, and hires as well, you know, again, for a company like ours, and also, I think, highly related for those kind of organizations we work with who are, as we say, trying to become software companies or more like software companies. Like, I wouldn't say straightforward, but hiring technical people seems more straightforward than hiring, I don't know how you would classify the three of us, the ancillary support people, right? Like, we're in marketing and HR, and there's all these other roles that are in the organization and are as necessary as, like, the designers and developers and things like that. But, like, you can't really sit down and, like, pair program with those roles. I don't know, I guess you could pair write a press release or something, but, like, how do you, how do we, how do we sort of, like, screen for cultural fit with those roles? That it's not, you can't just, like, see if they ask enough questions to figure out the requirements for code that they should be writing. And how do you sort of, how are we sort of putting that into a policy that would regularize, like, when we're looking for a marketing person or, you know, an HR person or, I don't know, a receptionist or whatever. What are the kind of things that we put into there or think about? Yeah, interesting. I'm interested in Joe's response. I can give you mine as well as I've been somehow doing a lot of hiring lately. Sure. When you go first, Richard Miller. Well, I mean, I guess I'll first candidly admit I don't think I'm very good at that. And that's one area I'm trying to get better at is that sometimes I focus too much on the squishier stuff. It's just trying to get a sense of their fit and what they, what motivates people, you know, what do they like working on. And that can be risky if I don't focus on the areas I think I need to. So I'm actually trying to get better at that.

But one thing I'm trying to focus more on is like a bias towards action and outcome. Like I ask someone frequently, what's the last asset you created that management, you know, lauded or praised because it was actually useful? Or what was the thing you've created recently that you're proud of? Or something that indicates not just we, like our team, because sometimes that might mean you don't do anything and that you actually just kind of provide feedback to other people who do the work. So what is that thing that you're proud of, that you worked on, that you did something? And yes, are you a good teammate? I want to make sure you can work and collaborate well. But, you know, we are an enormous team. So I definitely bias myself towards people who can work in somewhat fluid environments, get stuff done. They're focused more on kind of outcomes versus motion. Yeah. And I guess, I guess that's, that's the thing I was rambling towards is like, you know, when you talk with, with the product team people, there's dealing with unknown ambiguity stuff. And then also making sure people know how to like write code or, you know, like think about design thinking, things like that. And I don't know, it's, it's, it's, it seems like a challenge to bring that up in other contexts in a way that's not like super cheesy or whatever. Yeah. So I mean, Joe, when you're looking at people manager types and the like, I mean, how do you, right? I mean, I don't know if you do pairing interviews or what, but how do you kind of determine if they're a good cultural fit? Yeah. And it's, and it's beyond the cultural fit and also be, be careful of cultural fit because you want to make sure the interviewers are not putting their own biases in terms of what they think is a cultural fit. Right. And that's really thinking about what's, what's needed at, at pivotal. Good point. But with, you know, really any area where you're doing any level of volume of hiring, and it could be, you know, our concierge or receptionist, or it could be, you know, sales reps, or it could be market, right? Wherever you're doing more than, you know, maybe, you know, half a dozen hires a year, you know, putting in place what I like to call a practical interview.

And, and it does stem from, you know, what I believe the engineering organizations have perfected in the RPI and the PPI. And, and yes, there is a pairing aspect of it because that's what they do in their job day in and day out. But really the, the, the secret sauce and the power of really nailing the, the practical interview and, and a lot of the functions have implemented over the last couple of years. And there's some refinement that needs to happen. I mean, Rob's got 30 years on us with the RPI, you know, with the engineering pairing interview. But, you know, there's, there's still a lot of value out of doing it in the other functions. And so, for example, you know, within HR, we've been doing it for two and a half, three years, and we've had some great success with it. And really just for your audience to think about is like, what is a practical interview? And all you're doing is, and you can, you can weave in some of the, the, the traits and the things that you're looking for, Richard, that you mentioned. But it's really around simulating an environment in which the candidate is going to actually have to do their job. Right? Nothing drives me more insane in the interview process when we're evaluating candidates on things that they're never going to ever do. Right? And so, with an HR, if they're going to be responsible for building programs in the learning and development space and creating different manager training, then during the practical interview, that's what we're going to ask them to do. Right? We're going to give them a couple prompts, and we're going to ask them to build and design something based on a set of problems. And then they're going to get evaluated by two or three peoples, by members of people team. And sometimes we'll bring in, you know, folks outside of the people team because, you know, their products are going to get evaluated. You know, when they become an employee, right, they're going to get evaluated by managers as well. So, it's really around simulating as much as possible what the actual job is going to be like. And what it also does, it's really powerful for the candidate because the candidate can then get a sense of what the day in the life of work at Pivotal will be like.

And so, that will then give them the opportunity to opt out. Right? And so, if, you know, they're like, oh, I can't do this type of work or I don't want to work in this type of collaborative way, it gives them an opportunity to kind of self-select out as well. Yeah, it's interesting you say that. Like, I don't think I appreciated that side of things until I was much, much older in my career. I think I would often just like, when I was building my own software, as I mentioned earlier, my own platforms, I would just go get a job with anyone where my friends were at the time thinking about, do I want to work at this company day to day? And so, I think, not to be all self-horn-tooting, but that's like, whenever I interview people, that's one of the first things I try to generally get them to do is like, you know, you can ask about whatever you want to know about working at Pivotal. And I just want to make sure that when you show up here, you know what you are getting into, especially if I'm a referral, so you can be here at least 90 days and I can get my referral. But I think it is, and, you know, as a whole other layer, like, it is always interesting to hear what questions, if any, people have when you give them that sort of prompting. But, yeah, I think it's, it is, I think it's really vital in the interview process to make sure people know what they're getting themselves into. And, and also, like, kind of to the part of, like, the negative part of job hopping, right? Like, you want to get, at least I want to get a sense that there'll be some amount of commitment from them. Yeah, it's, it's such a big decision. All the work you'll have to, or not you'll have to, but you'll want to invest in them. Yeah. It's such a big decision. It's amazing how sometimes candidates don't do enough diligence themselves or companies don't invest enough in, you know, what I like to call the practical interview or really focusing on the evaluation and screening phase, right? It's, it's, you know, it's so expensive to find candidates, expensive to hire and train them.

It's disruptive if you make a bad career move, right? And you join a company and all of a sudden you've got to be looking for a job in six months because you, you made a mistake. We wanted to make sure we did hit on pay transparency a little bit. I mean, what's the progress there? How are we making progress on pay transparency and what does that look like? What do we think the end state is? So, so Coda, you should feel rest assured that the end state is not to publish your salary out to the world. So that is not, that's not the end state. The end state is really to ensure that there's no mystery in terms of how big pay decisions are made at Pivotal. And that also that everyone believes that they are, you know, paid fairly for the work that they do. Really, that's the ultimate goal. You know, the, the journey that we've been on and it's not just so simple where, okay, we post everyone's pay bands and then folks know where they fall within the pay bands. Because you have to first just start off with, you know, publishing our pay practices, right? In terms of what is our philosophy around comp and equity, which is actually something, you know, I could have touched on earlier when you asked about, you know, does life change, you know, post IPO? You know, we do continue to evaluate, you know, our comp and equity strategy, you know, as a public company or just even every six to 12 months to make sure we're being competitive. So we can come back to that if you want. But we also had to go and make sure that, you know, everyone's, you know, leveled in the right job levels, right? So before you post folks' salary bands, not the actual salary they make, but the actual bands in which you measure them, we have to make sure everyone's, you know, in the right job level and the right job title, right? And we have, you know, 2,700 employees to ensure that that's accurate. We have, you have to train all the directors and the managers to be able to have salary conversations, right? So for you, Richard, right, if all of a sudden we just, you know, shared all of your teams, like where they fall in the pay bands, but we haven't equipped you or your peers in terms of having that career conversation and that development conversation around, well, why are you in that level?

And how to equip our 550 people managers around having the career conversation around helping folks get to that next level, right? It would be, it just wouldn't go well because we wouldn't, we didn't equip the managers. And so once we get to a point where we feel all the managers are capable of having these type of conversations, which we're, which we're approaching, we will then, the end state is to make sure that we, that we will publish to each employee where they fall. Within the pay band. So we're probably, we're not putting an exact timeline on it, but we're probably, you know, two to, you know, four quarters away from, from that ultimate goal. And, you know, and some things we've done, you know, we were actually one of the first companies to get ahead of legislation in the U.S. And we're going to make this a global practice where, you know, we don't ask employees salaries anymore as part of the interview process, right? If you remember, maybe when you look for a job, right, you know, you know, many years ago, the first thing employer would be is like, what's your salary history? You know, in a couple of states in the U.S., that's illegal. And we were one of the first companies to, to not do that. Which actually posed some challenges for our hiring the sales reps, because traditionally, you know, the way a company would try to figure out whether a sales rep was good or not that they want to hire, is they would say, well, did you meet your quota? Did you, did you blow out your quota? What was your, send me your W-2, right? And so, hence why going back and relying on that stand and deliver, that evaluation and screening process is so important, because you're not going to be able to look at someone's W-2 to see if they were, met their quota or not. And that's, and that's thought in itself, but. And do you want to provide quick context for that? I mean, I know, I think some of the reasoning behind not asking for salary in general, ignore the legislation part, is sometimes gender differences and kind of how people position their previous salary, or sometimes getting people stuck in lower bands when they should be leaping forward or trying to low ball.

So, what is the motivation, let's say your motivation, for not asking for salary history? Yeah, the motivation is, it's around, goes, actually stems with a lot of our value systems in terms of just doing the right thing. Like, let's pay people for the job that they do, and not just because, you know, regardless of the salary that they had, you know, maybe they weren't a good negotiator, or maybe their company that they were at wasn't doing well for the last four or five years, and while they gained a lot of skills, their salary increase did not, you know, did not increase with that, right? And so, if they go and look for a job, and the company that they're looking at, you know, normal play is, oh, we'll just give them a 10% bump from what they had, and they'll be happy because it's a 10% increase, well, yeah, maybe that's a nice increase, but is that fair, right? And then you have folks within the organization, you know, doing similar jobs with wide disparity. And so, as part of our pay transparency efforts, there is a big focus on pay equality. So, within the next month or so, I'm actually going to release a blog that will show specifically in the U.S., and we're looking at how to do that in certain markets outside the U.S. around, you know, how we pay men to women at Pivotal, so how many cents on the dollar, you know, differentiated or not, right? Do we have pay parity with men and women, and then also with people of color within Pivotal, we're going to publish that data as well. So, we've contracted with a third-party firm who's looking at all of our salary information by demographics, and I'm going to get that report in the next couple weeks. I haven't seen it, so I'm committed to releasing it regardless of what it looks like. But, again, you know, to ensure and bring visibility to not only our Pivots, but to the world that, you know, Pivotal is committed to, you know, doing the right thing and committed to pay equality.

What a great answer. Yeah. Yeah, well, thanks for being on again. I think, particularly that last conversation, right, like, as I keep coming back to, I'm always interested in things I can tell our customers and people I talk with about how they need to switch over how they're doing things. And I think the idea of, like, removing all the fuzz around pay transparency or pay, what would be the opposite, obfuscation, so that people can just focus on, like, not only doing their job, but enjoying the environment that they're in. I mean, I think, I mean, pay obfuscation has been so weird for so long that it's bound to be one of those things that negative energy it puts into the system that you could just, easily is the wrong word, but, like, you have the levers to remove that energy. You might, as you're going over, you know, you need to train people and transition them and make all the studies. But at the end of the day, it's sort of like, well, do we fix these, do we fix these people by paying them more or not? Right? And it's, it seems like something that is fixable rather than sort of like some negative thing you have to live with. Yeah, with the customers, you know, I was talking to our head of engineering last week, and whether it's our field team or engineering teams, one of the things they talk to our customers about that are looking to, you know, change the way in which they build software, which obviously results in an organizational change. The focus is a lot on the balanced account team or balance team, right? You know, whether it's the engineer, product manager, and the designer, and the R&D, or in the field, right, we have now the balanced account team. But the customers also want to understand how that ecosystem around it works, right? And so your HR, your finance, your IT, your support systems, because, you know, we can have the most effective balanced account team or balanced team. But if the ecosystem around it is not supporting it, it's not going to be nearly as effective, right?

And so when we talk to customers that are trying to build software in a new way, and we talk to them about our engineering practices and our design and our product management practices, the conversation also has to transition into, you know, what are the support functions around that team and that ecosystem? How are they going to change and evolve in order to change the overall mission and objectives of your company? Yeah, that makes sense. Well, it'll be fun to see how this rolls out. And so thanks for being on. And thanks to everyone for listening. As always, this has been Pivotal Conversations. If you want to get the most recent episodes or bruise our back catalog, you can go to soundcloud.com slash pivotalconversations. And about every Thursday, we'll post the full show notes with links to things we mentioned and other references. And you go to pivotal.io slash podcast to find those. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.