How to manage hybrid remote/colocated teams with Greg Starling of Monscierge

Transcript

Ledge: Greg, thanks for joining us today. Really cool to have you.

Greg: Ledge, I really appreciate the opportunity, man. I’m looking forward to talking today.

Ledge: Very cool. Can you give just two or three minute intro of yourself and your work so the audience can get to know you a little bit?

Greg: I’ve been in the technology space now for just a little over 20 years. I got a pretty lucky break. Stupid kid out of college not knowing what I was doing, but nobody did and they didn’t want to invest a whole lot in starting up an ecommerce division at a crafting store called Hobby Lobby, something you probably have heard of. So, I was able to start Hobby Lobby’s ecommerce right out of college.

Went from there and ran a decent-sized .dev shop at a place called MTM Recognition. If anybody into sports, it’s the cool place that makes pretty much all the trophies you see, like the Heisman Trophy, Super Bowl rings, things like that.

Then bounced from that after 12 years of technology there to a startup called WeGoLook, where we did some third-party crowd sourcing stuff. Things like Uber for third-party inspections. Did that for little over two years, we were acquired.

Took a little break. Moved to nonprofit space for a couple years and now I’m back running an older startup, a little more mature startup in that B round phase called Monscierge, where we do the connecting between the guests and the staff at places like hotels, hospitals, things like that. We’re an Apple mobility partner, so get to fly out to Cupertino quite a bit, and the Apple guys come in and hang out with us a good amount. It’s been a fun adventure this last almost year now.

Ledge: Awesome. Tell us about that mobility play. You got all kinds of technology, I imagine, going on. Obviously, there’s Applecentricity. I’m sure you have to be cross-platform so you must have a pretty substantial stack behind all that.

Just walk us through what some of that looks like.

Greg: Some of the interesting things are we, do lot with Apple TV, which is a little unique in this space. We put Apple TVs in hotel rooms. We put them in hospitals. We even put them on cruise ships. That allows the guest whenever they come into their room – hopefully I hope it’s a good circumstance and it’s a hotel and not a bad circumstance as a hospital – but either way, we have some custom remotes, because Apple remotes don’t necessarily play well with some of the restarting devices in the mobile device management we have to do. But that allows us to tie into a request system.

We’ve done some interesting things. We’re pulling in TV and being able to be pretty much provider agnostic. So if they want to do something over the air or they want to use Comcast or Cox or DIRECTV, whatever it is, we bring in the television and then we wrap that around the ability for somebody to make requests.

If you’re at a hotel, the ability to request an extra towel, or to have somebody come up and clean the room, or to order room service. Anything along those lines. As well as just quickly being able to see amenities that are on site.

Yeah. To your point in terms of being on both sides, both the Android and the iOS side, anything that we feel that a guest is bringing in, we are straight cross-platform. We can’t dictate to a guest what device they’re bringing in, so we have both Android and iOS technology in place for anything that a guest would bring on site.

But we have been pretty fortunate that we’ve taken a relatively hard stance that anything that’s on the provider side is Apple only. That allows us to focus in a lot better and not to have to build out a team so much. Honestly, it helps us to have a really good relationship with Apple.

As being part of that mobility partnership program they like to be able to say, “Hey, this provider is providing an Apple environment.” Selfishly, I guess from my point of view, it’s really easy to only have to develop for a few different devices and OSs, not have to chase the kit-cats and all the various versions that we have on the client side.

Ledge: What’s that like from a mobility partner side? A lot of times people are thinking about, real basic; I have to get my app in the app store and get approved and then that feels onerous.

You’re way up there at the top of the chain. Can you maybe extrapolate some tips and tricks that people would be able to use even on the smaller company side or companies that are a little larger?

Greg: Yeah, for sure. I would say we’re definitely on the smaller company side so I can definitely help out there. We’ve worked with some on this mid-size as well so, yeah.

I think some of the tricks is to make sure that you’re utilizing all of the newest features that Apple is rolling out. Whenever Apple is talking about things like Face ID, they’re going to want you to have Face ID. If they’re talking about 3D Touch, they’re going to want to make sure you also have 3D Touch. There’s not going to be a partner brought up on stage at an Apple event that doesn’t have that kind of technology, that’s not doing things that are native.

We do our fair amount in React, React Native, but the really deeper integrated things, especially when you start messing around with sensors and things like that, almost everything we do is in Swift. That’s important to Apple, in terms of them wanting to show off that their technology can handle everything and you don’t need some third-party vendor.

On the other hand, on the client side, it’s nice too whenever we’re on both Android and iOS, to be able to have the common core base with React Native.

In terms of just advice, we’re not really a whole lot different than anybody else. You just get your license – whatever that costs, 99 bucks or whatever it is – to be able to submit to the store. I think what’s helped us get to where we are is, we’re in a relatively niche environment in this staff-to-guest communication piece and in the hospitality industry. Apple has several different verticals that they go after, and hospitality happens to be one of them. That being the case, there are not a lot of people doing what we do and so they approached us about joining the partnership program.

That’s not really advice. I guess the advice might be to find something that’s not overly crowded and is relatively niche, get really good at it and make sure you’re following all of the latest, greatest things that Apple is rolling out.

Ledge: What’s your engineering team organization look like? How are you deploying people and managing and pushing out new features, dealing with technical debt, those types of things?

Greg: We have, like I said, a pretty small team. We only have 10 engineers on our team. It’s the smallest team that I’ve worked with in a very long time but we’re really good.

We do work with a couple of various contractors who help us out in some of the more niche areas, specifically around some things like DevOps, some CI/CD type things, making sure that we’re good there. We do run testing. That was something that wasn’t necessarily in place before I came, and something that terrifies me when it’s not in place just because you don’t know what it’s going to break when you update some small piece that you don’t think is a big deal and all of a sudden you’ve brought the whole app down.

We’re in the process of getting some good infrastructure in place. We’re improving our test coverage. It’s still not anywhere where we’d like it to be but it’s significantly better than where it was, and we’re moving in that direction.

Our stack, currently we use GitHub and Jira in terms of project management and code. We’re actually looking pretty hard right now at GitLab. That seems to be doing some interesting things for us.

All of our backend is Node. We have some legacy .NET. We’re based out of here in Oklahoma City. It’s a relatively energy-happy area – oil and gas. For whatever reason, that particular industry is pretty heavy into the Microsoft stack, the .NET stack, and so there is a lot of engineering available. Whenever the company kicked off about 10 years ago, that was familiar in that stack and so that’s something we’ve slowly transitioned over the last year or so to getting on a JavaScript stack with Node.

We run a Kanban style Agile. I’m a big proponent of lean. The 12 years that I worked for that manufacturing company that made all the trophies, it was a lean manufacturing shop, and so that made it really easy to get really familiar in the software side of things. The have a really great book on lean software development. It’s probably getting older now but it’s still very, very applicable.

We run our sprints. If you want to equate it to more of a scrum style, we run our sprints around features times. Focusing on doing things like eliminating waste wherever we can, and so that’s why CI/CD is so important to us, testing is so important to us.

We’ve reorganized our teams where we actually sit. Our teams either sit physically in the same area or, if there’s somebody remote, their screen is up where we can see that person in the same area. We’re trying to eliminate any kind of detraction or any kind of negative… I’m trying to think of the right word. Any kind of distance, I guess, that somebody has to go, where we’re constantly in a spot to where people can always ask questions.

I think that’s one of the hardest things about being remote versus being local, is all those little side conversations that happen that people don’t think necessarily are important, but are oftentimes really critically important. We try to eliminate that by having an always-on camera, where people are always there and always in the loop. They’re catching some of that side chatter, those side comments, and making sure those are not something that happen off to one side.

We’re really pretty hardcore about our communication. Making sure that everybody on the team is constantly in the loop, be that on Slack or verbally through some kind of a video chat.

Ledge: Talk about how you set that up, specifically that remote video chat, always on? Because I think that’s something that people struggle with. Like you’re saying, managing particularly the mixed on-site versus remote.

You want to be able to support the remote workforce, because we know things are going that direction, but that persistence and that frictional communication, huge deal. How do you actually set that up and make that effective?

Greg: I think you’re right. More and more people are going remote, and so it’s something that we took on when we first came here, is to say, “We’ve got to be good at remote.”

We have beautiful offices here and really nice chairs and things like that, but we know, one, we can’t always recruit people to come to Oklahoma City. As beautiful as I think it is, it’s not top of everybody’s list of places they want to live. Two, sometimes people just want to work from home even if they are here. Maybe they come into the office one day a week. Maybe they come up to the office every other week.

In order to attract the best talent, which was our driver, we knew we had to be good at remote. So, we immediately started putting a lot of things in place whenever I came on and brought some of my team with me. One of that is that always-on video piece.

We utilize Zoom primarily. We just have Zoom rooms open all the time, and basically it’s almost like somebody’s desk. It’s part of this pod system. They sit there, and different computers can see different computers. You can see if there’s multiple people up in that Zoom meeting. We run the grid, the square grid. You can see the different faces, and the mikes are always on.

That’s not to say that somebody may not step away and walk away for a bit, but the mikes are always on, just trying to catch any of those kinds of side conversations. It’s crazy how often that happens.

I think one of the fallacies of open environments is that people will catch a side conversation and they’ll say, “Hey, I don’t understand something about that,” and actually be able to work. I think, if you walk through most environments, you realize most of the time people have headphones on.

But on the other hand, a lot of times people will take their headphones off and spin around and have a quick conversation. We wanted to make sure that was easy to do for the people that are remote as well as the people who are here on site.

Honestly, I didn’t think it was possible to run a mixed team really well. I think it’s really straightforward to run an all-on-site time and I think it’s really straightforward to run an all-remote team. But the mix is where it gets pretty complicated.

So, we’re still learning. We’re still very much learning but that’s been a pretty good solution for us so far. It’s just having that screen up to where people can be there and be present, for lack of a better word, in that team and to be able to chime in. Maybe they just ping somebody on Slack and say, “Hey, turn around, I got a question for you,” just like you might if you’re sitting in the office.

I don’t know that Zoom is the best technology for us forever, but that’s what we’re using right now. It’s super low tech. It’s Zoom on an old outdated laptop that people don’t want to work on anymore, and just up in the background. Between Zoom and we use Slack for our screen sharing as well as our communication, it’s working pretty well so far.

Ledge: Anything you ran into that would be a ‘gotcha’ that others could avoid when they’re starting to getting into trying to do this kind of thing?

Greg: I think that – and that’s a good point – the microphone issue can get really bad, especially with crosstalk. If you’re listening in, if you’re remote… I didn’t realize how bad it was until I was remote and I was trying to call in. I was like, “I don’t know how you guys do this on a daily basis.” So, we invested in some pretty inexpensive mikes that we have on everybody’s computer, and that helps a lot with not catching so much of the crosstalk.

But that was the worst, was the lack of microphone situation there for the people, the local. The remote people, for the most part, had pretty good setups. But it was the people who were here, local, who didn’t maybe have headphones on, didn’t have any kind of a microphone other than just using their computer and you’re picking up all kinds of sounds. So, switching to where we have mikes on everybody’s computer was a huge help for us from that kind of thing to avoid.

Ledge: Excellent tips. Thank you so much for that. I’m sure that a lot of people are thinking about doing things of this nature.

I’ve seen some really advanced implementations of this where they’ll have top to bottom entire portals where people can walk up and talk to their colleagues. But I don’t think it’s necessary to go that crazy, that you need that audio channel, you need that video channel. There’s the audio-visual component. But that that really can’t be enough when you have tools like Slack and Jira and other things, where you’re collaborating anyway. We do have, many times, a chat-based culture in a lot of our work. It’s a minimal thing for people too.

Greg: Right.

Ledge: How are you evaluating engineers? I like to ask all tech leads that I’ve talked to. Particularly because we’re in the business of vetting and hiring really, really high-end engineers and we take that seriously start to finish on our process.

But I always like to know, what are you doing in the field? What are the heuristics when you’re hiring, to bring people on? How do you know they’re the best?

Greg: I get to speak usually once a year at the University of Oklahoma and talk to the engineering groups there, the computer science teams. One of the questions that always comes up is, what’s the most important language that I should learn? I always say English is the most important language you should learn, because communication is such a big deal.

We look really hard to make sure that we feel like somebody is a good fit. That they can communicate and talk. I don’t know if that’s different than what other people do. It’s different than a few places that I’ve been involved in. But it’s really, really important to me that we can have conversations, that we can go back and forth. And I say English flippantly. If somebody’s native language is Spanish or whatever it might be, but the ability to communicate on a human level, we place an enormous amount of weight on that.

Also do a lot of actual background check calling. I don’t know if a lot of people actually call the references, but I usually do. I’m always amazed at how many people will say things like, “Off the record,” and I was like, “Yeah,” and then they give the real lowdown. I’m always confused at why somebody would have put somebody like that as a recommendation.

I think it’s more important than people give weight to because, for us, fit is incredibly important. That they come in and they fit our team. I tell people this all the time. I tell people this all the time, I spend more time with engineers here than I do with my son. Maybe that’s because I’m a terrible dad, but the truth is I’m only home three or four hours a night before he’s in bed, and I’m here eight to ten hours every day. So, I want to make sure that we work with people that fit our culture, that fit in with our team really well. So that’s why that follow-up.

Then we do some whiteboarding. We don’t go super, super hardcore but we do enough to where we’ll ask enough pretty pointed questions. Our director of engineering is a really smart dude and he’ll ask enough pointed questions to get a pretty good baseline of, what you said on your resume, is it true?

We do that. We take a good, hard look at the resume. We run a couple of questions. I say a couple, it usually takes about 30 to 45 minutes of just Q&A. We’ll whiteboard sometimes. Sometimes we’ll just go through like, if you were in this kind of situation, how would you set up this environment, depending on the role. Just to make sure that what they said is true.

Call on those references and then make sure we feel like that they would be a good fit on our team.

And we put a pretty high value on diversity, just because I feel like having a lot of different voices on your team and a lot of different backgrounds brings a lot of… produces better software in the end. That’s something that we look forward to. Not just racial diversity, socio-economic differences, gender, anything like that. We’re trying to hire the best person every single time that we can, and sometimes that means looking for people who have come from different backgrounds and may approach problems in different ways.

But, yeah, for the most part, we’re looking at the resume, making sure the resume is legit, calling some references and making sure that they have the ability to jump in and fit in with our team.

Ledge: Last question. You made reference to your 20-year career. I’m interested how those views on what makes a great team member maybe have evolved. Some things that you used to think that you don’t think any more in your wisened years in tech.

Greg: Yeah, so a few things. I started off originally writing in ColdFusion, if anybody remembers the old Macromedia ColdFusion days, then quickly did Classic ASP.

I’m not COBOL old, but I’m close.

I think some of the things that have changed more for me, one was I used to just straight hire for fit and figure that we’d work out skill. I think the downside to hiring for fit followed by skill, as opposed to skill followed by fit, is you end up with a team that looks and acts a lot like you do.

So, by trying to take a broader view of, “Hey, this person has the skillset that we need. Let’s make sure that they’re a fit.” As opposed to just go, “Okay, hey, we like hanging out with this guy at this user group, let’s see if we can get him on the team,” I think that’s allowed us to hire a wider range of engineers that are, honestly in the end, more talented because they do bring some different perspectives. They’re not just necessarily hanging out doing the things that we do.

I probably place less of an emphasis today, than I would have 20 years ago for sure, on education, and more of an emphasis on experience. I don’t necessarily mean years of experience, but I love finding that 21, 22, 23-year old guy or girl who’s been coding since they’re 12. Finding those types of people and not putting as much of an emphasis on those degrees as I used to.

I still think they’re important, I still think they provide a good foundation in terms of actual doing computer science work, but I think you can miss a lot of really talented engineers if you have this set of requirements upfront, “This is what we require. We require four-year degree in this and we require a masters in that.” I think you end up missing some really good people, if you’re really, really rigid in that way.

I’d say that’s something that I’ve changed a lot, as well as going back to that initial piece of trying to find skill and then fit after that.

Ledge: Great insights. Well Greg, thanks so much for joining us. We enjoyed talking today.

Greg: Absolutely. I appreciate it. Any time.