The Engineering People Show, Episode 26: Kevin Skibbe

“I heard feedback a while back described to me as you’re making a deposit or withdrawal from a bank account. Every time you give a bit of positive feedback, you’re making a deposit. And every time you give constructive feedback, you’re making a withdrawal.”

Today on Engineering People:

Kevin Skibbe is the VP of Engineering at BetterCloud, where he is responsible for the day to day duties of the Development, Test Engineering, and Architecture teams. Kevin’s passion is to continually bridge the gap between technology, business, customer, and partner teams.

Before joining BetterCloud, Kevin held several positions as a software engineer and engineering leader. Kevin is a native Georgian and holds both an MS and BS in Computer Science from Columbus State University.

(Original episode released on September 17, 2018)

 

Show notes:

Kevin on LinkedIn

BetterCloud

The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford

Spotify tribes

 

---

Ryan Carson: Welcome to Engineering People, the show where we interview the world’s leading engineering managers so we can learn from their experience and ideas. I’m Ryan Carson, the founder of Treehouse, and I’m your host.

In case you haven’t come across Treehouse, we have a ton of experience creating talent. We’ve created 850,000 new developers and designers, and if you’re struggling to hire enough developers or product designers, we can help. Just head to teamtreehouse.com/go/talent.

Let’s get to the show. Today I’m joined by Kevin Skibbe from BetterCloud. Thanks so much for hanging out.

Kevin Skibbe: Yeah, thanks for having me, Ryan.

Ryan Carson: It’s good to have you on the show. Before we started recording, we found that we have this almost weird parallel path, where we graduated from computer science just two years apart. I got in just before the dot com bubble burst, and you got in just after. Nice difference there. [laughter]

Kevin Skibbe: Yeah, timing is everything.

Ryan Carson: Yes. Oh my gosh. Tell us more about your job title and then more about BetterCloud please.

Kevin Skibbe: I’m the VP of engineering at BetterCloud, and what BetterCloud does is it allows companies to create and enforce policies for various SaaS applications. For instance, if you use Slack and Salesforce, Dropbox, with BetterCloud you can create a workflow policy that handles the provisioning and de-provisioning of accounts for those particular SaaS products. These policies may be security focused, so if you want to make sure that none of your finance team’s spreadsheets are shared publicly, we can detect that and alert you to it.

Ryan Carson: That’s great. We may need to use you then, because one of these things you’re thinking, “Who is this shared with and does anybody know?”

Kevin Skibbe: Oh, you would be surprised some of the things we come across. It’s pretty interesting stories. Yeah, none I can tell on tape here, but maybe some other time.

Ryan Carson: I bet it’s things like “Our financial two-year model is shared publicly by …”

Kevin Skibbe: We have seen stuff like that happen. We’ve had schools as customers too, and they will use that same feature to look for things like when teachers would accidentally share answer keys for tests. Weird stuff like that that people use us for. It’s pretty cool.

BetterCloud’s org chart

Ryan Carson: I’m always interested in company’s org charts and how they work. How do you fit into the org chart?

Kevin Skibbe: I report to our CTO, David Hardwick. Got a couple peers, a Chief Architect and a VP of Security, that I work closely with. We also have a Director of Product that reports to our CEO that I work with pretty closely. Then I’ve got a couple directors under me that manage the individual engineering teams directly.

Ryan Carson: How many people do you currently manage directly, and then underneath the total organization?

Kevin Skibbe: Directly, just four — which is actually the lowest number I’ve had since I started there. Originally I had 20 or so direct reports. At some point, it just didn’t scale. Just down to four now, but the engineering org in total is about 70 or so folks.

Influences on Kevin’s managerial style

Ryan Carson: What’s your favorite book or course or person that’s really affected you as an engineering manager?

Kevin Skibbe: Yeah, it’s a real good question. A book that I really enjoyed — that I didn’t think I might — wasn’t so much about managing people as it was managing teams and putting effecting processes in place. It’s called The Phoenix Project. I don’t know if you’ve read that or are familiar with it.

Ryan Carson: No, I’ve never.

Kevin Skibbe: It’s actually written as a novel, which is kind of an odd format for a tech book. You don’t see that that often. It’s really cool story, though. It tells, it’s about an IT director who was thrown into this complete mess of a situation, but he ends up meeting this eccentric mentor. The guy has a background in manufacturing, so he teaches them to applying the lessons learned in manufacturing to building software, which sounds weird but if you just break it down, he talks about these three ways of manufacturing.

The first way is the flow of work, from left to right, and making sure defects are never passed down. Then he goes into the second way, which is this constant flow of feedback, making sure that, from right to left, you’ve got feedback going back up the chain. And then finally, the third way talks about embracing experimentation and practicing. It made me think of this quote I heard a long time ago from, I believe, Jez Humble, one of the early DevOps guys. He was talking about doing releases and he said, “If it hurts, do it more often. The more often you do it, the easier it becomes.”

Ryan Carson: Gosh, that’s a good motto for life, right?

Kevin Skibbe: Yeah, exactly. I thought it was really cool. The book — I know a lot of engineers. They may not like comparisons to manufacturing or assembly lines. They may like to believe that what we do is more creative or challenging or whatever the objective is, but to think there’s nothing we can learn from that is a little bit shortsighted. I’d ask them maybe not to take themselves so seriously. [laughter]

The worst job Kevin ever had

Ryan Carson: I think hearing you’re a VP of Engineering at a big organization — you said there was something like 80 plus people in your org — it can look like you always had it figured out. I want to go back to a place when you didn’t have it figured out. What’s the worst or most interesting or funniest job you’ve ever had?

Kevin Skibbe: Right — man, this was probably early 2000s. I worked at a place called Betty Bass Flower Shop in Columbus, GA. I delivered flowers. I did it for a couple months. This was close to 20 years ago, so GPS wasn’t really a thing yet or it was so expensive that this flower shop couldn’t really afford one, so I had this Rand McNally map of town. I would load up the van, and go about my way. It was really interesting because everyone I interacted with was always super happy to see me, which I was not used to. Everybody likes flowers, right? I was always showing up for flowers for people. It did not at all prepare me for the real world [laughter] but it was a very interesting time.

Ryan Carson: That’s so great. It’s always fun to hear that you could be a flower delivery boy and eventually end up being a VP of Engineering. I’ve heard it all: People sweeping greasy floors with dust bunnies in the corner. [laughter] And then hearing the guy in the window saying, “All right. Get ‘the special!'” And it was for people who were really mean to them. They would wipe the burgers on the floor and then give them to them. [laughter]

Kevin Skibbe: Oh, god. Ugh, that’s terrible.

Ryan Carson: He didn’t do that. He saw these things happening, and he’s like “I’ve got to do something different.” Being a flower delivery boy is pretty good though.

Kevin Skibbe: Great job.

Two things engineering managers need to know

Ryan Carson: I’d love to ask if you could go back in time to a younger Kevin and say, “Listen to me. These two things will change your life as an engineering manager.” What would they be?

Kevin Skibbe: Yeah, it’s tough, because one of the first big things that I realized that I wasn’t very comfortable with is that giving feedback is really important. It’s something I wish I was a lot better at doing. I think that-

Ryan Carson: Gosh, yeah. It’s hard at first.

Kevin Skibbe: It is, yeah. I still think that introverted engineer side of me has a tough time with it, but I think for it to be effective, you’ve got to have a pretty good relationship with the person you’re giving that feedback to, and sometimes it’s something you got to work up to. I would say that if the first time you give someone feedback, if it’s of a constructive or negative nature instead of something positive, you have failed as a leader. Because you have to start off with something positive or reinforcing to start to build … credibility is the wrong word, but to help-

Ryan Carson: Trust, right?

Kevin Skibbe: Yeah, trust, exactly. That’s a really good way of putting it. And it can be something small like, “Hey, the unit tests you wrote for that ramp-up project were really thorough,” or something cheesy like that. I heard feedback a while back described to me as you’re making a deposit or withdrawal from a bank account. Every time you give a bit of positive feedback, you’re making a deposit. And every time you give constructive feedback, you’re making a withdrawal. It’s always tougher to take constructive feedback, generally for folks. so you have to make more of those deposits than you do one of those withdrawls. They’re not exactly equal. retty common analogy, I’m sure.

Ryan Carson: No, that’s great.

Kevin Skibbe: You’ve heard of that one. But giving feedback and being able to receive it is support important.

Ryan Carson: But how do you get good at it? Do you just do it and get better at it?

Kevin Skibbe: That’s the thing. You just have to do it. I, at one point, literally put a sticky note on my monitor at work that said, “Give feedback to someone.” It was just this reminder that at least once a day if I had not done it, I just I had to force myself to do it. Even if that meant walking back through the course of my day and the things that happened. You just have to practice it until it becomes more natural, I think. It’s still not completely natural for me. It takes work.

Ryan Carson: No, that’s so smart. Great. That’s a really good first piece of advice. What would be the second?

Kevin Skibbe: The second is when it comes to building an engineering team, you have to focus on balance. You can’t just take your three best engineers and put them together. They could end up being a terrible team together. There’s a lot more that goes into software than just writing code. You’ve got to be able to balance experience levels, strengths and weaknesses. I’ve seen someone who is maybe a QA person or maybe they’re a developer but they’re earlier on in their career. They’re not this rock star yet but they’re an amazing scrum master. Putting somebody like that on a team, I’ve seen, have a much more positive impact than bringing in someone who is maybe the strongest Java dev that you’ve got in the shop. Just making sure that you’re balancing out the skills and personalities on a team is very important.

Building diversity by showing it

Ryan Carson: We talked a little bit about the importance of diversity, equity, inclusion before the call. I know that you’re passionate about that, and you’re discussing it a lot at BetterCloud. But tell me about just one tactic that is working for you in either hiring or retaining diverse talent.

Kevin Skibbe: One that is traditionally worked for us consistently is probably one of the easiest ones, and that’s going to the folks we already have in the door and asking for referrals. That’s something that I highly encourage people to do because it doesn’t take a whole lot of work. So there’s that, that we’ve always done.

A thing that we’ve started in the last couple of months is if there are certain meetups or job boards that are frequented by certain groups, we try to make ourselves visible there. We recently did a diversity survey on the whole company and one of the things that came out of that particularly from people that are from what are generally considered underrepresented groups is that they told us that when they’re looking for jobs, they want to know that there are people already there that are like them. Making sure that we’re doing things like updating our website and any other public-facing assets that we have to make sure that they convey the diversity that we already have on staff. That seems obvious now that I think about it, but that was a blind spot that we had until we asked folks and they told us, “Hey, this could go a long way.”

Ryan Carson: Don’t feel bad about that, because we actually had — you know we’re a school and we have a lot of motion design in our video. It was insane, one of these things where you can’t see it until someone points it out. We had mostly light colored skinned drawings in our animation. I mean, because our motion designers are white and they’re just drawing people like themselves. And then we thought, “How are students ever going to feel included if it’s just white people in these motion videos? This is insane.” And like you said, it’s obvious in hindsight, man.

Kevin Skibbe: Yeah, yeah. Sometimes somebody has got to point it out for you.

How to find great talent and then retain it

Ryan Carson: Next question is where do you find talent? If you need to hire designers or developers, what’s your go-to method?

Kevin Skibbe: Well, it’s changed over the years. When I started at BetterCloud, I was wholly responsible for recruiting, which was tough combined with all the other stuff that I had to do. I relied heavily on external recruiters, which is not usually the best way of going about it. There are a lot of nice people, but they don’t always have the company’s best interests in mind there. We’ve since shifted that.

We’ve got internal recruiters now that handle a lot of the sourcing and logistics of setting up interviews and all that stuff — which is cool because it allows myself and others to focus on what we call building our brand. It sounds kind of weird when you talk about an engineering organization, but we do things like a tech blog that we contribute to on a regular basis and try to get out there. We’ve had multiple people speak at conferences. We host hackathons and happy hours. We’ve contributed to open-source projects, and opensourced a couple things ourselves. We host different groups in the office; there’s a girl’s code group in Atlanta that we’ve had in. Things like that. Really, anything we can do to get our name out there, and position ourselves in a positive light. It’s not a secret: The really good engineers, they have their choice of job. So anything we can do to differentiate ourselves is good.

I was going to say one of the big things we’ve found is that if we can just get people into the office, we’ve usually got a really good shot at them joining the team. They see the culture. They get to talk to members of the team. We’ve actually flipped our interview process around a little bit, whereas before, the face-to-face interview was the last step in the process, we’ve actually made that the first step. We realized “Well, once we get them in here, we got a pretty good shot at landing them.” That was another one of those “Duh, why didn’t we do this earlier?” kind of things, but … [laughter]

Ryan Carson: Right. The good stuff is always obvious in hindsight.

Kevin Skibbe: Yeah.

Ryan Carson: That’s great. I think I’m going to steal that. [laughter]

Kevin Skibbe: Please do.

Ryan Carson: What is one way you increase retention of your best talent on the technical teams?

Kevin Skibbe: What we try to do is give people interesting problems to work on. I mean, at the end of the day, that’s what a lot of engineers enjoy. If they’re working on stuff that’s boring them, then they’re probably going to want to move on. We try to give them as much autonomy as we can while balancing it against the needs of the business. We’re at a point now where we’re big enough that let’s say a particular engineer has been on team for a year or two years or three years, they’re probably going to get bored of working on some of that same stuff or the same services for a period of time. So just simple things, like moving engineers from one team to another, giving them that opportunity. That’s something they really seem to enjoy and it keeps them energized.

We’ve got a career guide that we invested a lot of time in that maps out the different levels of engineering at BetterCloud. Especially for folks that don’t have a desire to go into management, we want to make sure we’ve got a laid-out technical track that gives people a path for growth.

The balance of shipping with innovation

Ryan Carson: The last question is about balancing the urgency of shipping versus the need for creativity and research. How do you do that?

Kevin Skibbe: That’s — man, so that is, I think, a struggle that a lot of teams face, right? Luckily, we’ve got cover from the CEO on this, which is great. Two weeks ago in our company meeting, he brought up innovation himself and was pushing it, which is great, and not just in engineering, but across the org. Innovation doesn’t have to just come from the technical folks. There’s all areas of the business I think that you can or you should always be looking to do new things. Innovation, for us, we’ve had to change the way we approach it.

A couple years ago, we went through this pretty long period where we were building out this new platform that we were working on. Then, it was all brand new. It was a new problem that no one had really solved before. It was all innovation. We had to figure it all out — and in a situation like that, it’s really easy for folks to be happy and productive and fulfilled because we, as engineers, that’s just what we love to do. Over time, the product matures, the architecture matures, the code base matures, and there’s just less unknowns, I think. It doesn’t mean that things are easy by any means, doesn’t mean the challenges go away. It just means that you have a lot more experience that you can leverage. A situation like that, there is no balance. You’ve been asked to solve a problem that you don’t know how to solve. You have to innovate and figure that out.

But when you don’t necessarily have to innovate — like if you’ve done something the same way with a pretty good result 10 times in a row — it’s hard to convince the business to let you try out something new. For us, it puts the onus on engineering to present a hypothesis of some kind. “If we do X, we expect Y result,” that kind of thing. And the more evidence we have to back up that hypothesis, the greater the odds that we’re going to be willing to invest time to take on whatever that innovation or that new approach is. So it can be tough, because some people see that as a barrier to innovation or anti-innovation. It’s not true. It’s not just red tape. It’s actually there to force us to think through the problem and make sure that we’re investing in innovation where it makes sense, as opposed to just because we want to. When you’ve got customers and investors that expect certain things, it’s just a balance you’ve got to strike.

Ryan Carson: I think that’s a realistic answer, and so I appreciate that. And literally every single person I’ve interviewed sighs whenever I ask that question and says, “That’s hard.”

Kevin Skibbe: Yeah. It’s tough, man.

Ryan Carson: 100% of the people I’ve interviewed.

Going from 25 directs … to four

I did want to ask you that final one though about how did you go from 20 to four directs? Can you tell us the story?

Kevin Skibbe: Yeah, definitely. When I started there, it was me, Head Of Engineering, and all of the engineers reported to me. [laughter] I think I got up to 22, 25 direct reports at one point, which is kind of crazy.

Ryan Carson: That’s insane.

Kevin Skibbe: Yeah. The first iteration that we went through, and we’ve gone through a couple, we’re on our third now — but the second one was we had this team of architects, who were the more senior engineers on the team. They had started to take ownership and responsibility for various parts of the product, and they had teams that they generally worked with. So, we made the call to have them be the engineering leads for these teams that they worked on and they took on both the technical direction and the people management of the teams that they worked with — gave some folks some opportunities to step into roles that they might not have had before. But one thing we’ve learned is that sometimes, if you try to shoehorn a technical person into a management position — especially if they don’t necessarily want to take that on — that is probably not going to get you the best result you’re looking for.

That approach worked for probably a good year and a half for us before it just started to strain a little bit. The people-management and team-management aspects of the job were starting to outweigh some of the technical management, and it was just really hard to ask those people to wear both hats. So we switched again and separated the architect part of that role from the director part of that role. The people that wanted to go the technical route, we made senior engineers, technical folks, and we ended up actually having to hire a couple folks to take on that director role. We didn’t have a ton of people that were interested in the management side of it so we had to look outside, which was fine. We ended up with some really great folks.

Now we have a director of engineering that manages they have a couple of those architects, and then three or four teams underneath them that they direct. Each of those, we call them tribes. We stole that from the Spotify model that’s been talked about in various circles, and there’s stuff all over the Internet. I highly encourage people to search for that, because there’s a lot of good information on it. But those directors, they’re now over these different tribes that focus on various parts of the product.

Ryan Carson: Wow, what a journey!

Kevin Skibbe: Yeah, you learn a lot as you go. It’s like anything else, right? You iterate. You try things for a while. If they make sense, cool. If they don’t, then you figure out a better solution and go with it.

Ryan Carson: Yeah, you change them. Gosh, all right. Well, I appreciate you sharing all of that and dropping a ton of knowledge.

If people want to find you personally and chat, what’s the best place for them to go?

Kevin Skibbe: Best way to find me is on LinkedIn. Just search for “Kevin Skibbe, there’s not a lot of us out there. [laughter] I am the only one that I know of, so LinkedIn is the best spot.

Ryan Carson: What about BetterCloud and if any people are looking for jobs, where do they go?

Kevin Skibbe: Yeah. Bettercloud.com/careers. We are definitely hiring, so if you are interested give us a shout.

Ryan Carson: Nice. How many people are you hiring in the next 12 months?

Kevin Skibbe: Oh, next 12 months? We have, I believe, 10 spots open just for the rest of this year. Going into next year, if we did not add another 10 or 15 spots to that, I’d be surprised.

Ryan Carson: Got it. All right. Well, thanks so much Kevin. It’s been fun to chat and hopefully we’ll talk soon.

Kevin Skibbe: Sure. Thanks for having me.