Eric Müller lives in San Francisco, and explored many different paths before landing in tech. He looked into architecture, photography, but ultimately, he settled into the creativity, building and planning aspects of building software. Outside of tech, he's married with one kid, and a great tradeoff with his wife - he does all the cooking, while she does the cleaning. He still loves photography, and takes pictures regularly with his Olympus OM-1.Eleven years ago, Eric joined his current venture as a consultant, taking on projects and delivering value. He was brought on board 6-7 months later, and started down the path where he would lead the engineering and security arms of your partner in creating digital products.This is Eric's creation story at Presence.SponsorsSpeakeasyQA WolfSnapTradeLinkshttps://presencepg.com/https://www.linkedin.com/in/ericmullersf/Our Sponsors:* Check out Kinsta: https://kinsta.com* Check out Vanta: https://vanta.com/CODESTORYSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
We had a deadline. We had overcommitted. There was an expectation that the work was going to be, that we were going to get a release out that day. I'm sitting at my desk. The product manager has his desk next to me. I looked at everyone and said, all right, we're clearly not going to launch today. The product manager raised his eyebrow at me and I said, we're not going to get this done.
So how do we solve this? And we'll launch when we launch. I was going to go to our boss and say, I'm sorry. We did our best, and it's on me, and it is what it is. My willingness to say, look, I screwed up, it's on me, it took the pressure off of them. And suddenly, people are relaxed, identify the source of the problem, and we actually launched.
I'm Eric Mueller, VP of Engineering at CISO at present.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as a group. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve, my dear.
Took it off the shelf and dusted it off and tried it again. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on Code Story. I'm your host, Noah Labpart. And today, how Eric Mueller... leads the engineering and security charge at a business who aims to be your digital partner. This episode is sponsored by Speakeasy.
Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolf Pack at qawolf.com.
Eric Mueller lives in San Francisco and explored many different paths before landing in tech. Architecture, photography, but ultimately, he settled into the creativity, building, and planning aspects of creating software. Outside of tech, he's married with one kid and a great trade-off with his wife. He does all the cooking while she does the cleaning.
He still loves photography and takes pictures regularly with his Olympus OM-1. Eleven years ago, Eric joined his current venture as a consultant, taking on projects and delivering value. He was brought on board six to seven months later and started down the path where he would lead the engineering and security arms of your partner in creating digital products.
This is Eric's creation story at Presence.
Presence is a digital consultancy. So we build digital products for folks and we really like to make that distinction in digital products. We're not really focused on building like marketing websites or anything like that. Our goal is to help companies take an idea or a business or a product and put it into the digital space. And that could be obviously on the web, it could be mobile devices.
We've done IoT implementations in the past, and we can help a company think through a strategy, we hook them up with designers, but more importantly, as we get in there, we really push forward on their actual build, what they're gonna put out there in this space. We've worked with small companies, we've worked with large companies, so startups all the way up to large enterprises.
Personally, I'm VP of Engineering and our CISO primarily been focused on building out our team, working on our process, and then making sure that the teams are able to deliver for our clients. And then on the security side, helping our clients if they have any questions around security, and then also drove our SOC 2 process. So we've had four audits.
So we went from nothing all the way up to our fourth audit, and they've been really good. And then I've been with the company for, it's 11 years since August. And the reason I always draw that is I started with the company as a consultant. So everyone started in the company as a consultant, except for our founder. And then at some point, I'd say about six, seven months in, he brought me on board.
And then as we grew, I started off leading projects and then started to take on leading the overall development team.
Normally I'm interviewing, you know, product builders, like specific product builders, and you are running a team that's building those products.
So lots of different products, but I'm curious about what was your MVP, Eric, when you joined the company, those early days, maybe it was when you were a consultant or maybe it was when you were brought on board, but what was the MVP of when you joined the company and how long did it take you to bring it to life?
Someone once said it's not minimum viable product, but minimum lovable product. I actually prefer that. And the reason I say that is like, what does viability even mean? You can have so many different ideas around that. Engineering might have one idea. Product might have another idea. Design might have another idea.
And you put that in front of your clients and none of them think it's actually viable. They're like, why are you showing this to me? But I think lovable says something. When they're working with it, you look at it, it should give them a smile. They should feel proud about it. That's what they're getting out there into the market.
And when you have that feeling about your product, I think your clients are going to have that feeling about the product. The first one of those at Presence was actually a really small product. We were working on a redesign and API rebuild for a gaming company. There was this moment, I remember our CEO came by, I was sitting at my desk and the team was remote, we were all remote.
And we were really just trying to get it into the perfect place to launch it. And I remember I was like maybe inches away from my screen. I just really wanted to know, is this lined up the way we want it lined up? I know there are better ways to measure that, but it just felt like I had to have that level of intensity. And not long after that, we launched and everyone was very happy.
The reason that kind of comes to mind is I think when you're thinking about minimum viable, minimum lovable, you're sweating those kinds of details. It's not about just cobbling something together and pushing it out the door. It's about we're proud of it. We love it. We're going to put our name behind it. This is our first step out the door, and we are just so pleased.
With any sort of minimum product that you're building, you got to make decisions and trade-offs right around maybe how you're going to reduce scope or what is that minimum lovable piece of functionality, right? That people are going to get jazzed about.
So tell me about some of those decisions and trade-offs you had to work through either with this, you know, first MVP or mini and how you've coped with those decisions.
Every product that I've ever worked on, we go into thinking we have all the budget in the world, and everyone has very lofty ideas, and you have that first round where you decide, what do we absolutely need to go live with? And that first pass at that early on in the project, I think is really critical, right?
Because you've got everyone together, everyone's very focused, everyone's very optimistic, And you can put the brakes on a little bit and say, let's do this thing, right? Let's think about it, but let's be realistic, right? What you're describing is not what you need for the first version. You're describing what you need, maybe five versions. This is 10 years from now. So that's my first pass.
And I love taking advantage of that because like I said, everyone's very optimistic. Everyone's very happy and very excited. And so it's very easy to rein people in because it's like, yeah, we can have that conversation. It's no big deal. And we can make trade-offs. And so you really want to take advantage of that.
Then there comes this moment in the middle of the project and people are trying to increase scope. There's always that opportunity, right? That's often someone deciding they want to impress their manager or they really have a feature they just really love and they don't want to let it go.
I always like to look at them and say, if I get a bad feeling around that decision, I look at them and I say, that's a great idea, but I'm concerned about its delivery. Is this something that you want to go to your CEO and say, we are late because of this feature? There's a lot of different ways to phrase it, but that's the bottom line question.
And you would be surprised, probably not, at how many people look up to the sky and scratch their head and go, we can wait until the second version of the product.
This episode is sponsored by Speakeasy. Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product.
Shorten the time to live integration and provide a delightful experience for your customers. With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination.
Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag. Visit speakeasy.com slash codestory to get started and generate your first SDK for free. This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API.
With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices. Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators.
Get started for free today by visiting snaptrade.com slash codestory. This question is going to be interesting because so it could be roadmap for a product, which I think you just kind of touched on there. But I'm curious about, you know, how you approach that with presence as a whole for the products you're building, but also for presence itself.
What does the roadmap look like and how you decide what you do next for your digital partnership?
Our roadmap was very loose. We focused on finding very interesting work. When Jason founded the company, he was like, we're not going to be a designer. We can work with designers, and we're going to have people who are thoughtful about design on our technical staff, and we're going to have product managers and all that. We're going to think about design, but we're not a design firm.
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.
Okay, I'm curious about team. To do things at the caliber that Presence is doing, you have to have the right team. So tell me about how you go about building that team and what do you look for in those people to indicate that they're the winning horses to join you?
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?
This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs? Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. This message is sponsored by SnapTrade.
Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This episode is sponsored by Vanta. You're a startup founder. Finding product market fit is probably your number one priority.
But to land bigger customers, you also need security compliance. And obtaining your SOC 2 or ISO 27001 certification can open those big doors. But they take time and energy pulling you away from building and shipping. And that's where Vanta comes in.
Vanta is the all-in-one compliance solution helping startups like yours get audit ready and build a strong security foundation quickly and painlessly. How, you ask? Vanta automates the manual security tasks that slow you down, helping you streamline your audit.
And the platform connects you with trusted vCISOs to build your program, auditors to get you through audits quickly, and a marketplace for essentials like pen testing. Join over 8,000 companies, including many Y Combinator and Techstars startups who trust Vanta. Simplify compliance and get $1,000 off at vanta.com slash codestory. That's V-A-N-T-A dot com slash codestory.
This will be probably a unique answer because there's a different, I think there's a different approach to this for the industry that you're in. But I'm curious about scalability. How do you go about or how did you go about scaling presence? There's people there, there's technology internal, and then there's probably tech that you're building. But I'm curious about how you approach that.
And if there's been interesting areas where you've had to fight it as you've grown.
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.
Bringing on a DevOps team is challenging, particularly with what I do. No one's going to hire me and my team to have a full-time DevOps person for the length of the project. They need that DevOps person, but they don't need them 40 hours a week for 20 weeks. It's hard to keep someone busy, particularly when maybe two or three projects have to start at once. How do I scale that?
And because the nature of DevOps goes up and down, how do I ensure that I can get hired guns back? Because I don't want to constantly meet new people and get them used to the way that we work and teach them how we're using Terraform. But if I don't have them on my staff, I have no guarantee I'll ever see them again, no matter how much they like working with me.
DevOps is just the hardest area to manage, to scale, to keep those people engaged, to keep them busy, to justify that expense. And I think you have to get to a certain size before that becomes an easier lift.
So as you step out on the balcony and you look across what you've built and created with presence, what are you most proud of?
There are a number of folks that I have worked with, not just at Presence, but at other companies who I brought on board, I mentored them, and they've gone on to do great things. I know folks who are running their own engineering teams now. I know folks who started their own consultancies.
I know folks who just went to other companies that are doing the same thing, but they wanted to be on the product side. That just makes me so proud. There's just something about helping someone grow and that they get to a point where they feel like they can't learn anything more from me. It's sad on one hand, right?
But on the other hand, it makes me feel good because it's like they've gone as far as they could and they want to go somewhere else. They want to run their own team now. And I'm very proud of that.
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
I remember one time where we had a deadline, we had overcommitted. This is when I was actually working a mechanism and we had overcommitted. There was an expectation that the work was going to be, that we were going to get a release out that day. And everyone was willing to work till midnight. But the expectation was we're going to get the release out. And it's about two o'clock in the afternoon.
And I'm sitting at my desk. The product manager has his desk next to me. And everyone's freaking out. We're all mostly working in the office at the time. And I called everyone over to my desk with the product manager. And I looked at everyone. I remember the look on this guy's face. I looked at everyone and I said, all right, we're clearly not going to launch.
And the product manager raised his eyebrow at me. And I said, we're not doing this. We're not going to get this done. And I said, so let's just take a deep breath. Let's figure out what the problem is. How do we solve this? And we'll launch when we launch. And I was quite serious, actually. I was going to go to our boss and say, I'm sorry. We did our best then. It's on me. And it is what it is.
That moment, my willingness to say, look, I screwed up. It's on me. It's all good. It took the pressure off of them. And suddenly people are relaxed, identify the source of the problem. And we actually launched. Not every mistake or error has that kind of a happy ending. But I think the key for me in any mistake as a leader is to own it. You have to own it. You put the team together.
You made the commitments for your team. If you are in a bad situation, you let it get that far. So you got to own it. When you own it, that takes the pressure off of the team. And now you have a chance to fix it.
Let's switch to you, Eric. Who influences the way that you work? Name a person or many persons or something you look up to and why.
There was this guy by the name of Brian Gilpin years and years and years ago when I was working at Wells Fargo Bank. I was very early in my career. There was an HR situation with one of his staff members. I believe he basically put his career on the line to take care of this person. I don't remember the names of everyone I worked with from all those years ago, but Brian's name is still there.
That he was willing to go that extra mile to take care of this person is mind-blowing to me. To this day, it still is. And that level of commitment to his people has just stuck with me, obviously. The next person is someone by the name of Ron Lichty. We actually worked together at Charles Schwab and then he went over to Razorfish and he hired me over at Razorfish. And he has this amazing empathy.
He's an agile coach, and he helps build teams and solve problems. But the thing that really struck with me around him is his empathy for his team, his empathy for clients, for his partners. He was always calm. He always had a smile. He was a technologist. He could think through problems. And I've just always tried to bring that empathy that Ron had and that passion for the people that Brian had.
Those two people together, I think, really helped inform the way that I manage people today.
Okay, last question, Eric. So you're getting on a plane and you're sitting next to a young entrepreneur, builder, leader, engineering leader. who has created the next big thing or is about to go create the next big thing. They're jazzed about it. They can't wait to show it off to the world. Can't wait to show it off to you right there on the plane.
What advice do you give that person having gone down this road a bit?
One, this is so cliche, but don't forget to stop and smell the roses. It's so easy to get caught up in your next big thing. And I think when you have that passion, work on it for a while. However, take a step back. Make sure every once in a while you're catching your breath. Your kids are young for only so long. You don't want to turn around.
You missed when they learned how to walk or you weren't there. You skipped a bunch of Halloweens, take them trick-or-treating and stuff like that. Your product can afford to miss a couple of those days so that you can have those special moments that never come back.
The second thing I would say is get a skeptical eye to come in and take a look at whatever you have that you're ready to launch to the world. Get someone that you know is going to be honest with you and is not worried about hurting your feelings.
You don't want them to be a jerk, but you also don't want them to be like, oh gosh, I don't want to tell my buddy that this isn't really hitting for me, right? No, no. You want someone who's going to be willing to look at the product and say, you know what? You need to rethink this portion. You know what? You need maybe a couple more months to make this. You want that person.
You want someone who's going to be willing to give you those truths. And you don't want to surround yourself with yes people.
That's fantastic advice. Well, Eric, thank you for being on the show today. Thank you for telling your creation story at Presence.
Thank you. It was my pleasure.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.