Hiring and Pipeline With James Governor

Transcript

Episode Transcript

Quintessence Anx: Welcome to Page it to the Limit, a podcast where we explore what it takes to run software and production successfully.

Quintessence Anx: We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems.

Quintessence Anx: I’m your host, Quintessence or Quintessence Anx on Twitter. Welcome back to our interview with James Governor at RedMonk. This is part two. If you didn’t listen to part one, please take a look at our website at Page it to the Limit to see part one of this interview. Welcome back and hello, James.

James Governor: Hello.

Quintessence Anx: We were talking a bit about how people can make good decisions with their buying power with tooling, but I actually wanted to leapfrog a little bit further back into the conversation. We mentioned about onboarding developers into tools and into their roles. That kind of got me thinking about our pipeline and setting expectations. We know that we’re going to be choosing tools and we know we’re going to be choosing procedures around those tools. First and second word decisions as you say. What expectations should we be setting for the new people we’re bringing in to augment our workforce, about how much knowledge they should have, what they should expect to learn when they’re coming in?

James Governor: That’s a really good question. I think that there’s an aspect of, you can never have enough information when you’re walking onto a job, from the perspective of, certainly, expectation setting. We’re not always as good at fully explaining. Particularly in start ups where people could do a lot of things. We’re not always super great at being like: “This is the role. This is the one thing that we’re going to measure you on”. I know we have an industry. We talked about OKRs and, at the end of the year, and this is going to be the review and everything else, but we’re still not great at being like: “This is what you’re judged on.” There’s been an industry conversation recently about the glue work.

James Governor: You can be doing all of the great. Bringing teams together, doing extra documentation across two systems, helping people in chat, going out and forum, answering questions and not be fully acknowledged for that work and that’s bad. I do think being really clear on, “This is what we need from you. This is what we expect.” Also, “What do you have?”

James Governor: Generally, in tech we’ve been through, and it depends on the organization obviously, but there can also be some mismatches. A great example. If we think about the hiring processes at a Google or an Amazon, you can go through that whole hiring process, certainly in Google, and it’s the famous “Go and whiteboard out a binary tree. I’ll run them all” or whatever it is. Then you’re like: “Well, I’m never going to do that in my day job.”

James Governor: There were interesting things there where actually, what’s really valuable at these companies, Amazon and Google, is technical communication. Right? Your ability to communicate with your teams and your peers. A good friend of mine works at Stripe, Penelope Phippen. She’s an incredible, Rubyist, knows more about Ruby than pretty much anyone on the planet. If you’ve got a system that has to scale and not fall over and all of those good things, she will build it for you and she will maintain it for you. She’s just amazing.

James Governor: As she has reports and other people in the org that have to work with her, it becomes more and more important. Stripe definitely is all about the API, but it’s also about clear written communications. As she has become more of an engineering manager, the big thing she said, is about learning how to communicate.

James Governor: I think we don’t do a good job. I feel like a bit like I’m rambling. If communication is important, let’s do it. Let’s support it and let people understand that is what they need to do. Set the expectations, train them in the tools. If you’ve gone through a process where you’re like: “Oh, you’re amazing at these computer science algorithms.” Then they come in and they don’t actually know the nuts and bolts of the technology. Make sure they are trained to do that rather than being like: “Oh, anybody can learn anything. You learn Java, you can learn Go. Boom.”

James Governor: If somebody that’s perhaps, coming from a different background that isn’t computer science degree, but they’ve got good skills. Perhaps, they’ve taught themselves. Been through a bootcamp. They may have a different set of expectations. Again, make sure you communicate effectively about what’s expected. Find out what the skills lacks are and invest in training. Nobody wants to invest in training. To finish my rant, invest in training to support your people. You have to invest so they can learn so they can be more effective. I think training is super important in onboarding and very few organizations do it well.

Quintessence Anx: You thought you were finishing your rant, but actually. With the pipeline problems that the industry has as an overall. Right? In aggregate. We have teams that are existing. “Oh, we’re hiring mid to senior level roles because we don’t have the ability to trade juniors” is usually, some variant of that is given as the reason. If you don’t bring in the juniors, you don’t have more mid to seniors. The seniors can’t grow up, grow old, retire and then you’re always landlocked in the same pool of people. However, on the other hand, mentorship is usually viewed as glue work. To your point, you have your core role, which is infrastructure or platform or whatever it is. Then the mentoring and some of this onboarding aside from what’s codified, maybe by the company, is going be viewed as glue work. If it were me, I would say, “Okay, well let’s make mentoring part of core.” How would you even have that conversation? What do you think? What do you think the way to proceed is?

James Governor: Oh yes. I see what you did there. Okay. Mentoring, I believe should be part of core. If you want to progress in your career, you should be able to help people along that journey. That said, there’s already trigger words, that sort of glue work. I said, “This is your responsibility to do a thing.” There are dangers for an organization that this stuff can become gendered in a really unhelpful way.

James Governor: Women being expected to mentor women that have come into the org: “Oh, here’s yet another woman that needs mentoring. You’re the woman in the org. You should mentor this person.” And/Or we then go into other perhaps, intersectionalities perhaps, there’s a black woman. Well clearly, every black woman that joins the team should be mentored by the black woman. Whereas, in fact, that doesn’t actually make sense that there’s a huge amount of responsibility placed on people and that can be very, very unfortunate and very uncomfortable.

James Governor: If there’s a white dude sitting in the corner quietly, not doing any mentoring, getting on with his job and he just got promoted without doing any glue work, then yes, indeed, the corporation has a problem. I think that not everybody is going to be good at mentoring, but everybody should try and get better at it and everybody in an engineering org should be supporting folks to get better. It really grinds my gears. This idea that you shouldn’t hire juniors There were so many amazing, amazing, amazing people. I was going to say amazing kids, but they’re not because they could have come in. I’ve met a ton of amazing women that were in finance that I’ve retrained to go into tech. They could be any age. They could be any gender.

James Governor: Any organization that can not train and make people more effective, I don’t think they’re a truly successful organization. These things definitely, going back to the onboarding point, what the onboarding experience should not be is: “Oh, you’re a woman joining the team. So you need to therefore be mentored by that woman.” It’s like making sure that you have a set of good mentors that are able to work effectively with a wide range of people. End of the day, why would you not do this? Because the war for talent isn’t going away anytime soon. It’s actually a huge advantage bringing juniors on. Or bringing less experienced team members. This is something I feel quite passionately about. I think if the answer is: “We can’t hire juniors”, then that’s a problem.

Quintessence Anx: I agree. Very vocally. On the mentee side, and I’m curious to your thoughts on this, I normally set mentees up with the expectation that they probably will have more than one mentor. They might have someone they work with primarily, or they might have someone who overlaps very heavily with their intended area of expertise, but they might also have other mentors who are able to help with other areas of industry. That goes to your point about having a team of people who can work with other people.

Quintessence Anx: I’m curious as to your thoughts on the junior side. Instead of focusing on the mid to seniors, who we hope are listening to this and be like: “You know what, I am going to try mentoring and bringing more people into our interest rate”, but on the junior side, what would they expect to see? If they’re in a company where we’ll say mentorship isn’t strong, right? Cause it’s not strong everywhere. How can they advocate for themselves and get those connections that they need in that company?

James Governor: Oh, you’re asking so many good questions. I don’t have the answers to. I think it’s difficult because one answer is: “Oh, let the new person take responsibility for themselves and ask for stuff.” Obviously, you’ve just entered the org. You don’t know everybody. You may feel that you were lucky to get in there. You are not always going to be as confident of your skills as you could and should be. The making it the responsibility of the individual can be difficult. That said, I do think there can be value to looking for mentors. It’s okay to ask. It’s okay to say, “No.” If anyone is listening, I’m happy to help and mentor if I can. I’m an industry analyst. I’m not a practitioner. Although, every day I spend with practitioners. I have years of experience of working with tech companies of all different sizes.

James Governor: I may be able to help you in your career. So, @Monkchips, feel free to contact me on Twitter or just email me, james@redmonk.com. Stephen, who you mentioned earlier, Steven O’Grady. He just put out a thing offering to help people with their resumes. The next day, he was helping a young student in Lagos, in Nigeria to hone their resume. We want to help.

James Governor: Don’t be afraid to ask for help. Even though it can be really, [vocalization that translates to “even if it can feel bad”] and perhaps that’s where an external mentor rather than internal one, because you’re worried like: “Oh no, if I’m asking for a mentor internally, everyone’s going to think I don’t belong. Like I’m not good enough.” That can be a psychological thing. Maybe mentors outside can be super helpful.

James Governor: I don’t know. It’s really difficult but to answer the question. If you’re a senior engineer, if you’re in middle management, in tech, heal yourself, fix yourself, take on mentoring responsibility. It will make you feel good. You will be a better person. Your organization will become more effective. You be the one that agitates for glue code as a value, you go and change the stuff in your company so that your mentoring gets respected and everybody benefits. Let’s not make it the responsibility of the new person. Those senior people, directors of platform, all of you people, it’s your job to fix this in your organization.

Quintessence Anx: I wholeheartedly agree. To piggyback a little bit, I also have DM’s open to perspective that teas or anyone who just wants to set up a coffee or tea and chat. Feel free to reach out to me on Twitter at my Twitter handle, which is in my bio or at Quintessence at PagerDuty. Hopping away from mentoring for a little bit, because we could probably do a three-parter if we stop on this topic. Between the two of us, we could totally do a three-parter.

Quintessence Anx: Let’s talk about role specialization a little bit-

James Governor: Yes.

Quintessence Anx: within an organization. We’re talking about cultural transformation. Let’s talk a bit about role specialization and, to get started, let’s talk briefly so that we can dive in what the different roles should be within an IT org or within platforming application and that sort of thing.

James Governor: Yeah. I think that’s one of the things that we’ve been getting wrong. We’d go through a period. It goes a bit to this plethora of choice. We’re like: “Well, everybody can make choices, so they should learn everything.” We’ve sort of been through it and we see a lot of this, especially in the Kubernetes world. Everybody has to know everything about Kubernetes and these other technologies, as it’s mentioned in a Grafana Prometheus and they’re going to do [difficult to hear, approximated “home grown stuff”] got all of this stuff that they need to know in order to use the system. That’s sort of a sign of, of an immature ecosystem. You don’t need to hack the Linux Kernel in order to use the Ubuntu. That makes no sense. I think that Linux has shown us specialization and some people, by all means become a Kernel hacker or perhaps, you’re doing something in storage or file system or whatever it is.

James Governor: Just because you’re using a tool doesn’t mean that you need to understand all of its internals, frankly. I think that in that Kubernetes world, and we sort of saw this and it’s interesting because the folks at pivotal had understood this. This goes back to the idea of building and rebuilding Heroku. Cloud Foundry was established as this idea that I could just do CF push and the developer didn’t have to know everything. They just wrote the code and the platform did the work. I think that was honestly a highly valuable way of thinking about this. We’re beginning to see a bit of return to that in the Kubernetes world, where you should have an ops team and you should have dev teams. They both do dev ops. They both have responsibility for managing, understanding and observing the systems that they run.

James Governor: That doesn’t mean that they need to know everything about the internals of each other’s systems, in fact. Platform operators, and I think the industry is beginning to shake out on this a bit. Product owners running platforms with responsibility for platforms, and then application developers, writing digital products and services that, again, run on those platforms. We need some specialization. It was funny because I had a conversation once. The full stack developer. What does that mean? It was interesting because I was thinking I was sort of a slightly absurd, like nobody can really be full stack developer. Then it turned out other people like: “Whoa.” You use that as an insult to people. The idea that you’re going to understand everything about, react on the front end, and then you’re going to understand exactly how Redis works at the back end and you’re going to understand the container orchestration system that your database is sitting on. We’re asking too much of people.

James Governor: Specialization, training, this is what you do. Those T-shaped skills can be highly valuable, but I think the industry needs to move a bit more to skills certification. Some people are really good at managing systems. That is okay. There was interesting conversation recently. I saw where someone was saying, “Oh yeah, no, it’s saying the opposite. Oh, everybody should know everything. You know, if you’re on the team, you have to know how the underpinnings of what it works on.” The idea that at Google, every person writing code knows how Borg works at a deep level. That’s not it. You have SREs with the set of skills, they take advantage of a set of platforms, but not everybody can know everything.

James Governor: Let’s solidify what it means to be an SRE. Let’s solidify what it means to be a platform ops person Let’s have platforms that can make those people more productive without knowing everything. We’re here supposed to be doing automation much as we go into a bit more of a platform era. I think we’re going to go into a bit of a specialization. Tech is at its best from a bringing everyone in when we have those waves of certification and alignment and training where you can get paid to come and do this job and hopefully paid well and then we can create jobs accordingly.

Quintessence Anx: I wholeheartedly agree and that makes sense. While you were talking, I was thinking a little bit about these role definitions. Specialization is important and thank goodness because in my career I was a database admin for a while and did some introductory when I was a junior in cloud engineering, I was mostly doing what’s platform and then later doing SRE. It was very helpful to me to not necessarily need to dig deep all the way down, but one of the things that I noticed crop up every so often early and even so now is when teams who are very heavily specialized don’t necessarily know what is happening on the other side of the fence. For dev and ops, dev ops, unsurprisingly, it does solve this problem.

Quintessence Anx: One of the things I was thinking about is how sometimes will he be here? We shadow to try and learn about what other teams are doing not in a sense of like: “I need to be a network engineer”, but being aware of what that network engineers process flow is, what their expectations are so that you can vault requests to each other productively is, I think very helpful. I’m curious to your thoughts and, and your thoughts in general about having these highly specialized teams work together in a way that moves them all forward.

James Governor: Yeah. That’s a great pushback cause knowing a little bit can help you to understand the challenges of the other person but of course a little knowledge can be a dangerous thing also.

Quintessence Anx: Yes.

James Governor: I don’t want to come across as saying there isn’t value to learning different things deeply. It’s funny, you’re talking about database admin. My colleague, Rachel, who’s very brilliant and a delightful human. She joined the team and we were talking and after the meeting, she was like: “James, Steve, do people not like DBA’s.”

James Governor: … She was like: “When I was at DBA and I didn’t know.” It’s the classic like: “Oh, it’s the DBAs fault. They’re not being flexible enough. They’re not responding to my changes.” You’ve been there, right? You’ve been in that world, but let me tell you her understanding what it means to manage a database is highly valuable in so much of the work she does with our clients and across the board. She’s got this rich, I mean, she’s been a DBA, she’s got business skills, she’s an MBA. Rachael’s brilliant. All of those skills, they interlock. I, as somebody that she works for, consider it my responsibility to be like: “How do I”… and I haven’t always done this well, I haven’t always done as well, but increasingly it’s like… okay I’ll be honest. I’m going to take a step back.

James Governor: Steve and James at RedMonk historically I think, have been a little bit like, in fact, we have been classic tech pros. We have been a bit: “Hire people like us and let them do the work.” Right? That’s been fine. We’ve hired brilliant people and they’ve done tremendous work and everything else, but I’ve been on a journey over the past, maybe five, six years where what I’ve understood is: “No, hire people because of what they’re good at and then find ways for them to mesh those skills and up-level so that the one plus one equals three and really don’t have people like you. Hire people because of what makes them brilliant.” Like: “Oh, Hey look, these skills, these two skill sets, they’ve got are somewhat close together.”

James Governor: If we can help overlay those or make that their coverage area…I think I’ve been really blessed in a way that I didn’t fully expect to be. I think that, yes, there is a huge advantage to having multiple areas in which you’re quite deep, the idea that everybody can deepen everything is crazy.

Quintessence Anx: Fair enough. This has been a wonderful conversation. Thank you so much, James, for meeting with us. And this is the part where we ask our two recurring questions. Since we kind of been a little over the place between tooling and cultural change in people, I’m just going to ask you very broadly. What is one thing you wish you had known sooner in your career?

James Governor: I wish I’d been a better manager. I wish that I had been better at truly listening to the skill sets of my colleagues and supporting them to become more effective. I think when you do this job, sometimes it’s like: “Oh, well, maybe watch us and learn.” The thing I wish I had known better was being a better manager in that regard of and related to that and all of the other conversations we’ve had, understanding people’s need for clear career path. At RedMonk again, you’ve got these two founders and we found titles don’t matter. I’ll call myself an industry analyst and titles don’t matter when you’re the business owner. Maybe for someone else they do. Structure and support and listening… I wish I’d been a better manager. I wish I’d been better at listening and better at supporting people. Then that would have been good.

Quintessence Anx: Thank you for that very candid answer. I know I appreciate it. I hope our listeners do as well. On the opposite side for the question, is there anything you’re glad we didn’t ask you about in this recording?

James Governor: Yes. What is the total addressable market for dev ops and/or incident management tools in 2023 to 2025? That is the worst voodoo in this industry. I have no idea. I have no idea total addressable market…I’m glad you didn’t ask me that.

Quintessence Anx: Fair enough. Thank you again for joining us, James. It’s been an absolute pleasure.

James Governor: Thank you. It’s been a pleasure and possibly a bit relaxed. I’m a bit worried at listening to this back. I said before we did this podcast, there was no off-limits questions. I think honesty is important. I may have said things that make me look bad. Honesty is probably the best policy. There you go. Thank you very much.

Quintessence Anx: Absolutely. This is Quintessence wishing you an uneventful day.

Quintessence Anx: That does it for another installment of Page it to the Limit. We’d like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast, if you like what you’ve heard, you can find our show notes at pagelimit.com and you can reach us on Twitter at @pageit2limit using the number two. That’s Page it to Limit with the number two. Let us know what you think of the show. Thank you so much for joining us. Remember our uneventful days are beautiful days.