Building a Recruiting Pipeline for Engineers Who Want to Win with Steve Prosser of Guaranteed Rate

Transcript

Ledge: Steve, thanks for joining us.

Steve: Ledge, thanks for having me. I’m pumped to be here.

Ledge: If you wouldn’t mind, give your two- or three-minute background story of you and your work and what you’ve got going on.

Steve: I’m vice-president of software development at Guaranteed Rate. We are one of the largest residential mortgage companies in the U.S. doing well over twenty to twenty-five billion a year in home loans. I currently manage really all of our consumer-facing software and development which includes our digital mortgage platform which supports the majority of our sales as a company.

Ledge: Off-mike, you and I were talking a little bit about some team innovations that you all have been doing over the last year or so. I’d love if you would dive into that because it sounds really interesting.

Steve: It’s been quite a wild ride since I’ve started here. To give a little bit of background, historically, the department didn’t have a lot of very strong leadership coming in. So, actually, Martin Logan, the CIO who brought me in, had this really interesting idea to move to an autonomous structure for managing software development teams going away from that traditional hierarchical management structure.

It’s been an experiment over the last three years. I think it’s safe to say it’s not an experiment anymore. It’s worked out pretty well. But in the first to two years, there’s definitely been a lot of lessons learned and a lot of attempts at trying different solutions throughout the process. And I’m happy to dive into sort of what that looked like.

Ledge: Yes, please. We love the stories of rising from ashes of failure. Where did you bump your head and how did you get out of it?

Steve: First and foremost, one of the biggest things we were trying to accomplish is ─ the mortgage industry is extremely complex and this actually translates to most companies and most industries. The amount of complexity from the business side really cannot be understated.

So we wanted our engineers, our designers, and our product people to not have to work through projects, requirements, and multiple layers of playing the game “telephone” to understand what the business wants but we wanted them to really become experts on what they’re working on and understand their slice in depth.

So by moving to a self-managed organization, the thought is that even down to the engineer level, they’re sitting with our executives; they’re sitting with everybody in the business; they need to become subject-matter experts in the field that they’re developing.

This is quite a shock, I think, to a lot of engineers, at first, who preferred to sit down and just write code, put my headphones on ─ “Leave me alone.”

But one of the things that we realized out of the gate is that it’s a bit of a fallacy that engineers just want to be left alone and write code. What they really want and what dev teams want is to win. They want to win on what they’re developing. They want to make an impact.

One of the first things we realized out of the gate is that it is painful to switch habits; it is painful to have teams spending more of their time communicating, going to different offices, sitting down with business folks, and getting to know them and their business lines more in depth.

But once they did, the outcomes of the software they’re building were so much more impactful. The understanding they had on what they were building was so much richer and deeper than it would have been otherwise. And once you’ve kind of experienced that, there’s really no going back.

Ledge: Do you have any particular stories? I’m just curious. No names, obviously, but maybe somebody who made just some really good insights into the customer journey, internal customer, and just sort of left that coding in the dark with headphones on kind of thing and really blossomed into a customer empath, I guess.

Steve: Yes. I think there’s been a handful of those that we’ve experienced. I think the one that jumps out to me most strongly is thinking about how we collect documentation from borrowers specifically to the mortgage process.

If you’ve ever bought a home, there are so many steps you have to go through to actually get that loan to purchase that house; and it’s very frustrating.

We really believe that technology can help automate that process and make it a much better user experience for the end customer.

And we had some engineers sort of digging around on their own thinking about “How can we recognize the data that we’re receiving upfront from an application?” and then try to turn that into what we’re going to expect down the line from them so, that way, we don’t have to have all these different human components analyzing that data and making possible mistakes. And we can just automate what documents we need from the borrower.

We were able to take a pretty good first stab at this. The engineers were on their own. Actually, one of the main engineers just had this as his side project. He had to take the train in and out of the city everyday so he just made this little side project that he worked on, on the train. It was really kind of cool.

It made some really awesome progress and was able to get an MBP out that started to automate about 50% of what we would expect from a borrower coming into our pipeline to get a mortgage.

And then, once we released that, we really started synching with the business and we were able to expand it greatly to cover many more documents and also just provide a better experience for when we do have to have a human component come in for a unique situation.

Ledge: So what’s the stack look like for something this massive? I mean, you’re chunking tons of data. I just wonder, back to front, what kind of technology are you using and then from a skillset perspective, how are you staffing on engineering?

Steve: We have a pretty unique stack. We’ve actually gone off the deep end with Clojure so we are a functional programming shop through and through. This started as an experiment about four years ago. We brought in a few Clojure engineers to start building out some basic Clojure services to either third-party integrations kind of what functional programming really excels at. Over that time, it’s allowed us so much flexibility in the applications and services that we’ve built.

I remember one of the first big projects that I took on was to completely revamp our primary website which was, at that point, a 40-year-old PHP website and it looked like a 14-year-old PHP website.

And then, investigating what technically we could to or should do, we didn’t really need any sort of large framework of ORM like Rails or Django or something like that because, really, all the data that we needed was available over and these Clojure services that were insanely fast.

And so, we were able to take just a JavaScript First Approach that allowed me to focus for that project on hiring and scaling a team of JavaScript developers who really understood SEO and web development and didn’t have to worry about all the data and data manipulations and that piece of the puzzle because it’s just there.

So over that time, we started with a few Clojure engineers and proved that it worked. We’re now up to I think over thirty engineers and growing everyday.

Ledge: So you have the market corner. You have all of them.

Steve: I think there are three or four sizable shop in Chicago that hire. We do work closely with all of them.

But in terms of finding people with Clojure experience, we’ve pretty much tapped that market. We developed something called “Clojure University” recently and the purpose of that is to be able to bring in good engineers that come from different backgrounds whether it’s JavaScript or Python or Ruby or Java or whatever and put them through a crash course of Clojure while on the job, while working on projects and working on a team.

So far, that’s been a huge success in being able to open up our pipeline to candidates that we wouldn’t otherwise have been able to bring on.

Ledge: Sure. What does that look like, just the operations of that? I think there’s a lot of engineering companies and leaders I’ve talked to that are really interested in upping their contribution to the learning and the development space.

How did you pull that off?

Steve: It’s been a lot of work, to be honest. We’ve brought in accomplished engineers from many different teams across our organization and we worked together with them to develop this program that not just really teaches Clojure but also just how we use Clojure because every company uses a language differently from another company or they take on different aspects of that language.

So it’s really a four- to six-week ─ depending on the people going through it ─ intensive program where they’re going through different courses every other day. There’s homework that’s actually expected out of it. There are projects that are expected out of it.

And when they’re not in those courses, they’re actually working on a Clojure team here so they’re fully immersed and they’re pair programming with our engineers.

Ledge: What have you seen from the tech side? We talked about the positive sides on the Clojure and the other sort of separation of concerns, RESTful and JavaScript. Where have been some of the challenges and some of the things that you wish you did differently?

Steve: That’s a good question. I wish we pulled the trigger a little faster on our experiment, that’s for sure. It’s really been great. I think that the education component, looking back, is so big that the fact that we’ve rolled out Clojure University in the last three months is great but that’s four years into this technical route that we took.

Looking back, I think if we have done this maybe two years ago or even a year ago, that could have helped our ability to recruit staff even sooner. So we’re very aggressive in that regard and we’re always looking at how we can better…

Ledge: Are you using a lot of public cloud technologies? What does the stack look like?

Steve: We’re pretty heavily leveraged with AWS. We also rolled out a pretty broad Kubernetes pipeline; this was actually about a year and a half ago so we were early adaptor with Kubernetes and that was both challenging and fun in how we actually wrapped up these services and projects and deployed them.

Our whole stack in the end, depending on which products and services a team would be working on, looks like you’re using AWS, Kubernetes, Clojure ─ a lot more Clojure script now that we’ve brought it in or JavaScript.

Some of our legacy stuff from years past is Microsoft and we still support those but take strong efforts in reducing that technical debt as we take on new projects.

Ledge: I wonder, you must have a pretty robust build pipeline if you’re able to have the self-managed engineering kind of vibe and a lot of prototyping. What does the CI/CD flow look like?

Steve: One of the interesting things with self-management is that it varies team by team and each team can come up with their own CI/CD pipeline and process based on their own unique applications and services as well as just how they work and what they prefer.

So there’s really no set standard and that’s something that, as a manager, you kind of have to learn to become okay with early on when you’re going down this autonomous path. You have to kind of take that approach of “I want to set a vision of how reliable the software should deploy and how scalable those services and applications are and allow the team to come up with solutions that work that meet division versus micromanaging and dictating “This is how the stack is going to have to be.”

Ledge: And how does that work on the budgeting side if each team wants to buy a different CI tool?

Steve: That’s a good question. One of the things that we’ve realized with self-management is there still has to be transparency in communication across teams and across the departments. So we have mechanisms like our architecture meetings. I know that architecture meetings are pretty common throughout organizations.

Ours is a little bit different, though, in that it’s not just a meeting where the architects come in and discuss architecture but it’s open to all engineers and it’s really an engineering leadership meeting with architecture being a component.

So if one team is looking at taking a specific build pipeline or bringing in a specific framework or language, that’s the meeting where it’s discussed. And, a lot of times, what we realize is if there’s a need on one team, there’s often a need on multiple teams.

Or, on the flipside of the coin, if there’s need on one team, possibly, another team has solved that and they have a solution that they’re able to work with Team A to help implement.

So we try to help consolidate those decisions where possible but if there’s truly a unique scenario where there’s a specific deployment software or a specific any type of software, the team or the individual will definitely take that under consideration.

Ledge: My last and favorite question ─ obviously, we’re in the business of evaluating and staffing the very high-end, the very best freelance engineers and we have a quite substantial process that we do to evaluate and vet and get that done. But I like to ask every tech lead that I talk to, “What is key for you? What are the key heuristics when you’re identifying and hiring the very best engineers that you want for your team?”

Steve: There are three primary buckets that I tend to look in. The first one is job competency. So if you’re an engineer, how technical are you? If you are a product owner, how well do you sort of live and breathe that product life cycle?

The second one is really business competency. But when you’re hiring, you may or may not know the actual business that you’re applying into so I don’t expect a lot of people from the tech side to understand mortgages. So “How coachable are you? How well do you take direction?” is a big part of that.

And then, the third main bucket I look for is leadership qualities. How well do you naturally lead others or help gravitate others to your ideas, communicate well, mentor?

I’ve had junior engineers mentoring senior engineers on things. I’ve had principal engineers taking half the department by storm on new architectural vision so I think that leadership component can be really powerful if done well with a healthy culture.

Ledge: Steve, thanks so much for the insights. Great to have you on!

Steve: The pleasure is all mine. Thanks for having me here.