Why Remote Teams Don’t Always Work, With Kyle Gunderson
Today, we’re joined by Kyle Gunderson. Kyle is the President and CTO at Revel Health, a Minneapolis-based software company that uses advanced analytics and AI to create health action programs that improve the health of people on an individual-basis. He’s a tech veteran, with over 20 years of leadership experience and multiple high-growth teams under his belt.
In this episode, we talk about…
- Using data to navigate tough conversations about his product roadmap
- How to attract top-talent without building a remote team
- Using a scorecard to make smarter hires
Listen to the full episode here
Kyle Gunderson, thanks so much for joining us today on Scaling Software Teams.
Yeah, really happy to be here.
What got you into building software, Kyle?
Wow, that is a way back question.
I was just telling somebody the other day that that is the result of what happens when 18 year olds make decisions on their professional career. I landed in an applied mathematics program – so I have a mathematics background – and it turns out when you have a mathematics background some of the jobs that are available [end up being] in software engineering and computer science. I ended up with a mathematics degree and found myself in this business.
I guess after you’ve lived through it long enough they let you try to lead teams.
How did you make your transition from a builder to a leader of teams?
The same things that made me successful as an engineer started to make me think about how to lead teams, and how to be productive in building software. [It’s still] looking for logical approaches to solving problems, it’s just a different problem set – and it was thinking about how to improve operational efficiency. I think I just was naturally drawn to a different set of problems to solve. I had solved software engineering and architectural problems and I became intrigued by solving these “people and organizational” problems. The challenge – which seemed really interesting to me – the challenge of marshaling a group of really smart people around the goal of creating solutions that would help people [excited me].
Distributed systems are fun. Human distributing systems are fun, and maybe even a little harder.
Yeah.
We talked earlier about how, as an industry, we’re moving towards more agile responsive processes, but often the business is not. [The responsive process is] more a quarterly basis, monthly basis. How have you been able to square those two things?
Yeah, it’s a really interesting challenge and I’ve been in a number of different businesses [helping with] that challenge. I don’t think I bring it to every business, I just think it lives in our industry. Businesses get themselves in a cage, and understandably so, where they want predictability on these natural cadences. Many businesses, most businesses work on those 90 day cadence, so they get comfort from the idea that they can look out 90 days and say with certainty this is what’s going to happen.
The reality of it, though, is that’s not really what they ask for in the day to day. What businesses really ask for from software engineering teams is to adapt all the changes that they see, right? The changes that the sales team would see, or the changes that the customer support team would see – they would love this really adaptive and responsive engineering team, and the engineers are usually these really team oriented problem solvers so they don’t have any problem jumping on these things and helping out.
The heartburn comes at the end of the 90 days when everybody wants to know if you made any progress on those things that you said you were going to do, [but] you’ve spent your time doing something else. I think the way around that is really through data… transparency, [and] some objectivity. As the business asks for those changes, you need to acknowledge those changes, and you need to provide transparency and visibility that you’re not working on those things anymore.
I think what I always try to do is shift the conversation a little bit to some objective data around, what’s the value of the things we’re working on? [I try to find] ways to objectively evaluate and value the things we’re working on, then [we know that our] teams are working on the highest value things.
Then the question should be, are we doing it in the most efficient way possible? Are we getting the most amount of work done possible? Are we demonstrating that we’re getting better at that over time? Are we quantitatively demonstrating that the quality of the work product that’s coming out of it is good?
If we look at an engineering team and we can all agree to the fact that they are performing at a high level, that they continue to perform at a higher level, and that we’re making the right decisions on the things that they’re working on, I think everybody should be happy with that.
Yeah, I love the [idea that] if we’re working on the most valuable thing, then we’re going in the right direction. I love to hear an example – just kind of walk us through. We’ve all been there; something changes, something sales person had a conversation, he talked to a customer, and then that comes back to the team…
You talked about bringing data and objectivity into that process – could you maybe walk us through something that’s happened to you? You doubled your team last year so I’m sure you’ve had a lot of that kind of change, I’d love to hear how it works.
Again, really smart people. These are non-agile concepts, but we started to sort of track and quantify where the teams were spending their time, right? How much of our time is being spent on things that we thought were on the strategic roadmap? The backlog? How much of our time did we think we were spending on those items that we’re talking about, right? A customer asks for something, we had a sales opportunity that requires something – so we know how much time we spend on that. How much time do we spend on doing operational things where the engineering team is asked to help either deliver something or support something or do something with the data – I thought we found a lot of power in that.
What we’re able to do with that, then, is tie that allocation back to what the goals of the company are. We are all here in business, we’re all here to serve our customers, and so we have to get comfortable with the notion that we’re going to spend some percentage of our time with these ad hoc requests that come in from a customer that we have to do. That’s real in our business today, and we just provide visibility that the engineering team spends 10% or 15% of their time doing that.
If we think, again, those are the highest value things in our organization, we shouldn’t sweat it if that leads to helping grow our business and serve those valuable customers.
Does that look like, [for example] the tickets or issues you’re working on that have a tag as far as one of those categories? How do you actually implement that tracking of where your time is going between strategic and ad hoc?
We use Gira like I’m sure many other companies do… We identify the tasks that come through or stories that come through the teams, and we can put a tag on there. We don’t try to overcook it, I think we have fewer than a handful of categories that we put on there. If it’s some in our 90 day backlog that’s obviously a thing that we thought we were going to work on. If it’s something that we accelerated farther down the roadmap we call it a “non-90 day roadmap” but it still is moving us in the direction that we want to take our product. If it’s something that comes in as a customer request that we haven’t found a way to apply directly to our product strategy or direction we call that a “non-roadmap item”. We would value that as maintaining the relationship with a customer or opening up a revenue opportunity with a prospect.
The one that’s kind of got my attention lately is if… I said we went from 35 people to 75 people, I want to make sure those 75 people are in their lanes. Anytime I see the engineering team doing operational things, being pulled in to doing implementation or to support or working on a data pipeline – how data comes in or goes out – that stuffs got my attention. We raise that up… transparency and visibility is how we manage our business. We pivot a little bit of our roadmap priority now, [so] our shorter term strategic roadmap is to work on things that will automate the operation and delivery of our platform so that we can get all teams in their lanes.
It’s paying off. It’s not something we want to do forever, but if we make that short term investment now we’re going to be increasingly more efficient and productive going forward.
I like that, so then you’ve got a pie chart you can share with the rest of the business. This is where we spend our time, this is the right mix.
Everybody can say “well that looks good”, or we can assert that it doesn’t look good and we change our priorities accordingly.
I love problems that we can solve with transparency. That sounds like a great way to do it.
Data and transparency. We’re sort of a data analytics company anyway, so we solve all of our problems by bringing visibility to data.
That sounds very on brand. You doubled your team in the last year. What’s the biggest scaling challenge that you work through as you went through that rapid growth?
We have a company goal this year to transform from “brilliant individuals” to “high performing teams”. You scour a market – I’ve learned that here [and] other places; when you scale fast, you scour the market and you try to suck up as many of these “A-players” as possible and get them on your team. It’s so important that when they get you, you have a framework for how you bring them onto the team as fast as possible – how you get them into teams, how you get them thinking about doing things in the way that the team wants to do things.
For better or worse, often times really smart people often bring to their new jobs the things that made them successful in their previous job – and you love that. That’s what you kind of hope they would do, but one day you wake up and you’ve got 20 people who all have this different perspective on how to be productive. Getting them all to kind of figure out how to come together and work as a team… it’s a really big challenge. It’s something we think about quite a bit.
What are some things that you’ve seen, you know they’re “A-players”, they’re meeting your definition of top performing individuals, but they’re bringing in stuff that’s disruptive to your organization? What are some of those things they’ve brought in that can cause that misalignment?
An example that comes to my mind right now is we’ve invested in a cool space here where we all come together; I’m trying to create a culture where everybody wants to come into this cool space.
It’s tailor made for us, it’s a place where we’re suppose to come together and do this cool thing at Rebel. I want people in the building and in our space working together. We’re not yet at a spot where we need to have distributed teams, [and] we don’t need to have work from home. Sometimes you’ve got people who have been successful in that model before and think that they’re more productive if they work from home. I think an A-player not only makes themselves productive, but an A-player makes everybody productive.
When you play next to an A-player, you get better, and they make everybody better. If somebody doesn’t buy into being in this space and they think they get more done by going some place else and doing their work, that doesn’t work for me.
That seems like a tension I see pretty often. It seems like there might be a trend towards that expectation. Have you seen that through your career, that expectation of work from home [being a regular part of the job] increasing over time?
Yeah, I think to be competitive now in terms of recruiting, I want to be flexible. We have things in place like flexible time off. Our only policy is we want to make sure you’re taking time off. We haven’t capped time off – we have a flexible time off policy. We’ve got a lot of people with young families and busy lives. If there are things that you need to do and you need to be gone or you need to be early or come in late, that flexibility is there. I have zero problem with that, and I think I can recruit with that.
In the selection process I just need to make sure that we all understand that, by and large, we are a culture where we want to be in the same spot and work together. If that’s not what the individual we’re talking to wants to do, no matter how talented they are, it’s not going to work.
How much longer do you think we’ll be able to keep our teams together? In a thousand years probably we’ll have some sort of space helmets. It will happen then, probably not next year.
I wonder if the question should be how much longer can we… or how much longer should we?
Yeah, I like that question too.
I try not to be old fashioned, right? I can’t be old fashioned. I got to lead a lot of really cool, smart people who are progressive thinkers. I’m just not yet ready to surrender the value of human interaction. I’m not yet ready to surrender the value of sitting down and being able to read body language and read a room and sit down in the break room and have lunch together or sit down and have coffee together. I just haven’t given up. I just can’t give up on the value of that yet.
I know there are technologies like the ones we are using right now that make it easy to work together and collaborate. I know there are technologies that allow teams literally a half a world apart to feel like they’re in the same room. That’s great. That’s allowing us to attack talent that is literally world wide and me, with a company of 75 people right now, I think I could keep them all at one place. I don’t know what the tipping point is – I don’t know what the number would be where that’s no longer realistic.
Yeah, I heard a “but” and I’d love to hear what the “but” is. I think this is a topic that has a lot of opinions floating around; it’s kind of an inflection point where this coming up in more.
It is. I have worked with people who are at different ends of the spectrum. I don’t know where you land on this – I’ve worked with people who don’t even think we need an office. You know, why do we need an office? We have the technology, we can all just sit at home in our pajamas and do what we do. I just don’t feel like that is the most effective way to communicate. Maybe I’ll be put out to pasture at some point in time for those views.
I think you nailed the tension exactly, which is, people need to connect. We need to be able to read body language. We’re fooling ourselves if we think that Slack and text communication is a subsidy for the high bandwidth communication. I think you also nailed it with [needing] a way for team mates to make us better. I think a lot of that standard way is… you sit next to somebody, you see what they’re doing. The thing that I see some companies doing is taking that first principle and then figuring out a way to meet those needs for connection and high bandwidth communication with the tools. It’s like wearing ankle weights, it’s absolutely hard. You just don’t get it for free. You can’t just show up on your first day, and someone meets you at the water cooler. It’s harder.
The thing that I can fall on, though, is, you said you’re at 75… eventually everybody is a distributed company. We all split on multiple floors. It’s kind of what do we do when we have to split on two floors in a building? What do you think the first thing we’ll have to change will be once that happens? I think you’ve been through companies that did that before, so I’d love to hear kind of what breaks whenever you split?
These are all social experiments. Do we group teams that work together on different floors? Or do we group teams that work together on [the same] floors? The floors are mixed to force people to get up and out of their chair. My inclination would be if we grew, you’ve nailed our plan exactly. When we grow in this space we will be adding another floor. We’ve got the option to move up or down in our space here and that’ll be an exciting day when we do that. We’ll have some separation and that’s the first step to separation. The next step is we’re starting to find talent… we’re in Minneapolis and we start to find talent on the coast, right? We start to find talent on the east coast and we’ll start to find talent on the west coast. How do we do that? Do we start with engineering teams or do we start with our revenue generating teams? Those are different questions.
I try not to be old fashioned right, but I’m just not yet ready to surrender the value of human interaction.
— Kyle Gunderson
I think the fortunate thing is that the technology now is emerging to allow us to do that and to support that. I just think maybe it’s a different perspective on how you leverage that technology. Are you starting from the perspective that you want to be a distributed team, work from anywhere and you’re going to do that because these technologies are available? Or are you starting from the perspective that you value human interaction – you value co-location, you value what that does for the fabric of your culture? As you have exceptions to that, do you leverage technology to help accommodate those exceptions?
I think I’m obviously in [the latter] camp. When I have to make those decisions as my company grows, or if we find talent elsewhere, [I’m] happy that there are technologies that are making it easier and easier. I love the way you said it, we’re playing basketball in ankle weights. It’s harder!
You’ve got knuckle heads like me who you can’t figure out which headset to put on when you’re going to a podcast, right? You know, and I get into these Zoom meetings and the first ten minutes of my Zoom meeting is figuring out how to get everybody on that Zoom call, and how to get everybody’s face up on the screen. That frustrates me – yhat we spend time wrestling with technology so that we can communicate versus spending time on our business.
There’s definitely some frictions to be addressed. I think people that are going into a distributed team without realizing that they’re going to have to plan to address those frictions – I think they’re decreasing, and I’m happy about that. I’m going to plug a product and this is my favorite. The hole for me has always been whiteboarding. Whiteboarding remote has always just been way worse.
A Google doc is no substitute for a white board. There’s a tool called Miro, M-I-R-O. If you ever have remote white boarding session, it’s a game changer for us. My team is… mostly we’re in the same city, but we’re all distributed. Miro is awesome.
Is that right through your laptop or your desktop. you can whiteboard right there?
Yep. Sticky notes, diagrams, dropping videos through video chat, timers, doc voting – all of the nice design thinking stuff. It’s pretty great. If I was a start up investor, I would be investing in that company because it’s so great.
That’s a really good topic. I think it’s one that’s going to continue to change and evolve in our industry for sure.
Absolutely.
Now Kyle, you’ve got a magic wand and you can spread one idea out into the zeitgeist about hiring that’s going to improve hiring for our entire industry. You can kill an idea, you can create an idea… what’s the idea to make hiring better across software engineering?
I think just hiring in general is… I would like to get rid of happy ears. This isn’t a magic wand, this is just hard work. We have to be more thoughtful about it, right.?I’m afraid too many hiring decisions get made by the first impression when you get in that room and you sit down in a chair across from somebody. We really have to be thoughtful about how we tease out a cultural fit, how we tease out their proficiency to do something, how we tease out their desire to work within the environment that we have. I wish there was a magic wand that could solve these things, but I this is one where it’s just going to require some heavy lifting and commitment to a process like that.
I understand you’re also a fan of the book “Who: The A Method of Hiring”. I also really love that book. It’s got a lot of great insight. I understand you incorporate scorecards into your hiring process. Can you tell us a little bit more about how you use scorecards?
Yeah, so we use a hiring and recruiting tool and we found that it was flexible enough that we could create a template for each interviewer to follow during the process. Within that template we have built in a flexible scorecard that starts with a job description or the things that we want from a particular candidate. It also includes specific questions around the culture that we have at Rebel or that we try to create at Rebel. We were really thoughtful about – when we hire somebody or when we go through an interview process – we get the hiring team or the interview team in a room and we go through the scorecard and we divvy up who wants to cover what part, and gather certain pieces of information that are important to us.
We’ve got some people who are really good at gleaning or teasing out technical proficiency. We’ve got some people who are really good at teasing out cultural fit. We’ve got some people who are good at teasing out desire and environmental fit.
We’re just intentional about it. We’ve got that in our tool. Sometimes for whatever reason we get away from that. It comes up in a situation where we don’t use the things that we know we should use. Those are the times when we haven’t hit the mark.
It’s always tempting to bend the rules for one person. Happy ears like you said or sometimes the opposite. That’s a hard lesson that I’ve had to learn myself. Who is the best engineer that you’ve worked with that was maybe bad on paper?
I have a colleague whom I’ve worked with for a long time who, on paper from an education background and from an experience background, does not scream at you that this is a person who should work in the technology industry and is going to set it on fire. Every time I get a chance to work with this individual as we each change positions, I jump at it because the intangibles of this person are [fantastic]. They’re innately intelligent and they are innately curious and they want to solve a problem. Give them a problem in a technology space, they are able to quickly do the research, acquire the knowledge, apply it in a very efficient way, and come up with solutions. They’re just tickled and delighted that they could do it. That person, again, their CV or resume or background or education wouldn’t scream to you that they have that talent.
When I talked about the scorecard and being intentional, I think it’s really interesting how to identify intangibles in the hiring process. This person has intangibles. They’re just innate intelligence, curiosity, problem solvers, humility, right. Team first, goal first, they don’t think about themselves. It’s just amazing.
That sounds like a great team mate. I don’t know where someone puts that on a resume. If they put that on a resume I wouldn’t believe them, right.
I even had a hard time hiring this person in the past because, I introduce them to the organization and say “This is a guy who if I ever get a chance to work with, I want to work with him”. Comes in and interviews and they say “Well, I don’t know what he’s going to do” and I said “Whatever you want him to do.”
It’s time for our rapid fire round. I’m going to ask a question and you’ll give us your quick reaction. Let’s do it. What’s the most impressive thing a candidate has done in an interview that helped you realize they were a great fit?
They come in prepared. They come in prepared, they know our business, they know the role, they know about me and they’re just on target.
What’s a mistake you seeing an engineering candidate make in an interview that they didn’t realize they were making?
I think confidence is a slippery slope. You want to portray a competency and a proficiency, but I don’t think that you want to portray over-confidence or hubris in an interview.
Hard skills versus soft skills, catalytic skills. Which is more important for an engineering candidate?
Soft skills. I mean if I have somebody who is a brilliant engineer and it just destroys the chemistry of the team, I’d just rather not have part of the business.
What does a six star culture fit, even better than a five star culture fit look like for your team at Rebel?
A six star culture fit to me is – I like working with smart people, so it’s a smart person. It’s a humble person. This is a team first person. They have to be driven, want it, in our business. I like somebody who displays a high degree of personal ownership. Those are some traits of people I think make six star people.
My guest today has been Kyle Gunderson. Kyle, thank you for being on scaling software teams.
It’s been my honor. Thank you for having me.
Thanks again to Kyle for sharing his experience with us. Here are a few take aways I had from our chat.
Number one: data is your friend when talking product roadmaps. We all that hitting date based product roadmaps targets can be tough. It’s double hard when ad hoc requests eat time. All of Kyle’s Gira tickets are tagged based on their relation to the current product roadmap goals. That allows him to say what percentage of his team’s time was spent on non-roadmap goals when talking to other executives. His categories are: strategic roadmap, customer requests, new business requests, and ad hoc operations.
Number two: remote work is not a free lunch. Kyle points out the many ways in which remote work is harder than co-located work. Culture and camaraderie are more difficult to spread – management is harder. As a leader of a remote team, I absolutely agree. Running remote requires extra effort in order to reap those extra rewards.
Number three: the best hiring process is built to uncover evidence. One of the things that makes hiring so hard is that few of us were taught how to hire. We know how to conduct an interview maybe and read a resume, but many of us operate more on gut than on science. That’s a problem, which is why Kyle’s team uses a scorecard for every interview. He divvy’s up line items on the scorecard to different members of his team. Then each team member searches for evidence that a given hire has the required technical aptitude, culture fit, and desire to make them successful in the role. This helps his team make decisions based more on facts than on opinions.
Thanks again to Kyle for coming on the show, now I want to hear from you. Please leave us a review on iTunes, Google Play, or wherever you get your podcasts. This will help others find our community. Thanks and I’ll talk to you next week.
Scaling Software Teams is brought to you by Woven.
In our interview, Kyle emphasized the importance of finding objective ways to evaluate candidates. When used effectively, these tools can reduce disparities in hiring and in compensation. That’s the reason why we started Woven. Woven is a developer screening platform that reduces bias and noise in software hiring. We empower hiring managers with a detailed assessment of every candidate based on an hour long work simulation. Our clients make decisions about who they spend time with based on ability to do the job, not just on a resume.
If you want to learn more about how Woven can you help you scale your software team, request a demo today.
