Eric Müller

We are here to build products. We're here to help strategize and build the products. That was like that key moment in the roadmap, because then what it meant is we could focus on everything needed to build out a digital product team that could build exciting and well-realized products. From there, it was like, what kind of people are we going to hire? That was a part of our roadmap.

Are we going to focus on consultants or are we going to focus on full-time employees? Every quarter, we would sit down and we would basically survey the company. What are we doing? What do we like? Is there a product area, a vertical, a technology that we want to focus on? And then we'd go out and focus our attention for new work in those spaces. But all that was very loose, right?

It was intentionally so because we didn't want to be one of those companies that was so hyper-focused that they missed wonderful opportunities. Or they were so hyper-focused that when, if a particular, their area of focus dried up, that the company went out of business. Like I'd seen that, right?

Companies that are focused on a particular technology or a particular vertical or even a particular client, like maybe a specific client, and things went bad in that area and then they were gone. And I think the best definition or example of how we succeed in that is we survive two fairly significant economic time periods.

We got through COVID with no problem, and we've made it through the times that are going on right now successfully.

We have a couple of skills that were always very important to us. So obviously JavaScript, React, Node on the backend, and then AWS in the cloud. And then obviously we'd bring in other technologies as we needed. So when I'm looking for folks, the first thing is obviously their skillset. Do they have the technologies that I'm interested in? And then we do the technical vetting. Can they program?

Do they understand how to solve problems? I think that's more important than pure code writing. And then I start looking for intangibles. And this is, in some ways, very important. So, one, I want every person to be able to interface with a client. And I'm not looking for everyone to have perfect people skills.

But I don't want someone who is so uncomfortable working with other people that they can't have a simple conversation. And that's important if I've got a developer who needs to figure out how to hook up with the client's API. I need them to be able to have a conversation. So I look for that ability to talk to other people. Another thing I look for is something beyond technology.

The reason that is, is that I think that we in our industry have done a disservice to folks in basically convincing them that if you're not writing software all the time, that you are somehow not passionate about writing software.

And I have seen a lot of very good developers who had convinced themselves of that, and they write code for 40 hours a week to get paid, and then they have their own side project, and then they have their contributions to some open source projects, and it's 15 years in, 20 years in, and they absolutely hate their jobs.

Obviously, I brought in folks who do nothing but write code in their private time. That's great. I've had some very good programmers. I'm encouraged when someone says, I love what I do, but I want something away from this to recharge my battery. And oftentimes, their thing away from programming is very geeky, right? Like, I love photography, but it's very geeky, right?

All the settings and there's a lot of math and... It's an incredibly geeky endeavor, right? I look for things like that in people. One of the best programmers I ever worked with, he's a brilliant architect. He was also a great guitarist, and he was into these bands like Dream Theater, which was a very technical math band, math rock they call it, right?

And you can see how those play into each other. Here's a guy passionate about programming, but it still has that connection because of that geekiness. Does someone cook? Do they like to jog? Do they meditate? What are the things that they do to recharge their batteries so they stay in love with being a programmer, not burn out on being a programmer?

Scaling a product or development team inside of a product consultancy in many ways is like scaling one inside of a product company in that you are thoughtful about when you bring staff on as opposed to when you are engaging with consultants. You never want to get to a place where you're like, oh, the money's always going to be there. I'm going to hire 50 people.

And then it's six months later and you've got to lay off 25 of them. That first layoff in a company is devastating to everyone inside of the company because they're like, wow, I thought we were a family and I thought we were going to be taken care of and while working hard and like my buddy who's sitting next to me is now gone and I know they were working hard.

I think the other thing to think about, there's a million technologies out there. We can't do everything. I'm more than likely to hire people in some of the core technologies we have and then occasionally hire folks if I start to grow in a niche area or bring in a consultant. Work with me six months, a year, two years. Also try to think about processes.

And that's really difficult when you're working across a bunch of different companies where everyone might have a different process. And so you have to be flexible around that. But I think there's something to be said for when you bring someone into the company. And I've always done this is you bring them in and I talk them through what are the expectations.

And so like from day one, they're coming in the door and I'm like, hey, this is how we write code. And this is how we use GitHub. And we have two people do poll reviews. And a lot of that stuff is boring. They're already doing it. But you're setting a marker, right? This is how we do things. And yes, things are going to be flexible.

We may have to change because of a situation of a client or we're in a rush or something like that. But you're setting that cultural beginning. I would say to answer your other question around the challenges of scaling, it's interesting when we started doing this, AWS was just becoming a new hotness. And I think building out that team has always been a challenge for me.

From talking with people in product companies, they have the same challenge as me, other leaders, which is, It's really easy to say, I've got a developer. I need to bring him in. I'm going to keep them busy. I can justify that. I can go to the board. I can go to whoever and say, give me the money for five developers. They're going to be busy all the time. Don't worry about it.