Explaining the “why” behind your features, with Mitch Stewart
Mitch Stewart is the co-founder of Guru, a software company based out of Pennsylvania that is working with companies like Shopify, Square, and Spotify to unify their team’s collective knowledge and empower them with information when they need it most.
In this episode, we talk about some of the management practices that have made Mitch successful at Guru. We dive into his transition from developer to manager, and the lessons he learned about building and motivating teams along the way.
Here is a transcript of our conversation. To listen to the episode, click here.
———
Wes: “What’s the career inflection point that’s led you to where you are today?”
Mitch: “So. I started at a fairly enterprise boring software company. It was warehouse management software and it was handling logistics, inventory, and shipping for some fairly large customers.
At the time I was a snarky sassy software developer, thinking that I knew everything in actuality I knew nothing. And and the systems that I was working with were just so they were old. They were intended for a much corporate, older technology base. This was 1999 and 2000, the dot-com era. Things were going bananas in the tech world. I wasn’t a part of that, and ten months into that job I essentially got fed up and wanted to start my own company.
I had an opportunity to join two other people at a company doing essentially UI work for for an enterprise piece of software. Now that company didn’t go anywhere. It took us about two and a half years to realize that the product we were making wasn’t very exciting. People didn’t really want it. We kind of kept ourselves afloat by doing consulting gigs, but at that point I realized that that working for myself and being able to make decisions and see the impact of those decisions really solidified in me that this is what I wanted to do. I wanted to be an entrepreneur. I wanted to be involved in a startup at that foundational level so that then I could be a part of a growing company. I wanted to have my hands and and brainpower working on solving the problems for the company.
That was a first inflection point for me and I really enjoyed that even though we you know we didn’t succeed because after that is when I found Boomi, which is which did succeed eventually. But I was looking for that other startup after my original one had failed.”
Wes: “I think that sense of impact immediate impact is something that draws folks to startups and draws us into management. How did you transition? So you started with two other friends and you were working together. When did you start managing a team of engineers?”
Mitch: “So that original startup failed totally and I was on the hunt for a new job and I ended up working at a company called Boomi, which is now Dell Boomi. It got bought in 2010.
I had started there as the first software engineer that day that they had hired. I worked on two different versions of that product, eventually three. But it wasn’t until maybe two or three years into working at Boomi that I transitioned from a software engineer into a manager. And what happened was, in 2006, the co-founder Rick Nucci, he was the CTO then and he’s he’s my current co-founder here at Guru. He was CTO and and and we had an idea for Boomi that basically pivoted us out of on-premise software into the cloud version that it is today. And at that time we we were looking at all of the work that had to be done for that and it was just a massive amount of work. And and he gave me the responsibility to build a team around around the new product and to hire the next set of people who would report to me.
To basically build out the product and all the architecture. This required step away from the technical aspects of the CTO position and move more into that visionary, sales-oriented CTO position. That inflection point was another change where where I had to start building out a team that would execute on an architecture and on a technical vision that we had. And that was a great experience to have.”
Wes: “You’re building a startup from scratch, within a startup. What was challenging about that?”
Mitch: “The biggest challenge is finding those core people that you can implicitly trust 100 percent. I got really lucky in the sense that I was able to find two people who were much better engineers than I was. They were able to join and really make an impact right away.
The challenge there was just trying to find that initial group of people that you could then build the rest of the team around. And and we did the same thing at Guru. Luckily I had an architect who wanted to join, and then we were able to build the team around around him. But, we also had to find those additional core people, who are still with Guru today, that that you’re able to build a team around.
If you can get that core engineering team with the right culture with the right mindset you can do a lot. You can really start to build out the rest of the team and the rest of the engineering processes around a team that is more or less autonomous in nature and you’re just kind of pointing them in the right direction.
You’re giving them the guidance, but they’re able to really execute using their skill sets, talents and experiences. And it’s a lot about, at the very beginning, making sure the guidance is right but also letting your team members execute really well.”
Wes: “So you found these two folks that you knew you could build a team around in the interview in that whole process. How did you do you remember the moments when you’re like ‘these are these are the two folks I could build a team around.’ What evidence do you have about that?”
Mitch: “Yeah. So there were both during the phone screens actually. I had a phone screen that, effectively went through a lot of just the bare minimum of Java experience. It wasn’t it wasn’t a crazy phone screen, but the level of detail that they were providing during that phone screen was just beyond anything that any other candidate had ever provided.
At the same time, we were sharing war stories about about previous jobs. The people that I was interviewing were senior-level people. They had been in my position before and they knew what I was going through in terms of trying to find good people. We were sharing war stories about that on the phone screen itself. It was a combination just gelling with the person and also just a level of expertise. They were answering questions that I’m not even sure I could have answered properly.”
Wes: “So, a level of detail that lets you believe that they have a deep understanding and then they exemplify their experience with stories of what they’ve seen in the past. Now that you’ve gone up another level of abstraction, what is hard that wasn’t hard a year ago?”
Mitch: “When you’re building a team and you’re able to focus on on developing the right features for the product, it’s very easy to work in that in that single track. You have one roadmap. You have one team. You have one set of designers one product manager and you’re able to mentally and sequentially put in all of the work that you need to do to get a product out the door.
Now we’re splitting the teams, and we’re creating multiple teams on purpose so that we can create autonomy in those teams. They can work independently and deliver innovative and impactful products to our customers. The challenge there is I can no longer think about all of the features that go into the product in a sequential manner. Everything now is happening in parallel.
There are so many decisions that are being made across the team that the teams that it’s impossible for one person to hold it in their head at the same time. So, you have to put in the right processes and frameworks in place so that the individual teams feel empowered to make the right decisions given the information that they have. A lot of what we’re doing today is ensuring that the people running the teams have the right information and are making decisions that are impactful to the business and our customers.
From a user experience from a value creation perspective it’s a challenge because you have to coach people right from a move from a single team perspective. I could manage all of that right. You know from top to bottom and get everyone aligned as to what we’re doing. With multiple teams, I have to trust the people that we’ve hired to do that for me as my proxy.
That’s and that’s a challenge because you have to have really good communication and really good trust with everyone.”
Wes: “What are some some tools or habits that you’ve used to improve that context passing to allow them to make those decisions on what’s valuable?”
Mitch: “It sounds really basic but surprisingly, a good functional spec helps align the team around around what it is that you’re trying to accomplish.
A functional aspect doesn’t have to be very detailed, but it does have to outline why you are doing a particular feature. That’s something that that I believe really helps engineers get behind a particular piece of code or feature, when they understand that what they’re doing is impactful to the business as a whole. When you provide the ‘why,’ they in-turn respond with with motivation and excitement and and a dedication to to completing that feature.
So, the functional aspect is explains, not only ‘you want this button to do a, b, or c,’ but you say ‘this is why we’re building this feature in the first place.’ If you can’t explain the why then you have to wonder why you’re even doing that feature.”
Wes: “Have you had any instance where you’ve passed along the why and you’ve gotten some pushback on whether that was the right what to go along with that why?”
Mitch: “Yes. It doesn’t happen all the time, but when it does, it happens in a way that is productive.
As a manager and executive, you have to create this safe space so that people can do that in it in a constructive manner. Software engineers are intelligent. They have ideas they have opinions. They want to be involved in that process as well.
A lot of times maybe the product manager or the designer may think it a certain features should be done a certain way and then an engineer goes well if we did x, y, or z, we already have all this data. We already have this feature set we could actually implement this really easily if we just changed it slightly. A lot of times, you wouldn’t know about those ideas unless you were knee deep in the code.
By having that safe space, you can allow engineers, designers, and product managers to really collaborate on what is the best way to try to implement a feature. You’ve talked about the why, you’ve put the goals in the functional spec, and and if this if the implementation solves those goals, it can be considered a win. It doesn’t always have to be dictated by the top.”
Wes: “What’s a belief about leading software teams the younger Mitch would have disagreed with?”
Mitch: “There was a great article and forgive me for not knowing the author but it was about giving away your Legos. And I think that this is gone through the startup world and it’s all about, as you start in your startup career, you’re handling everything. You’re making all the decisions around architecture and technology and features and so on so forth.
But as you grow, in order to grow you have to be willing to give away those responsibilities. Then, other team members that you hire can can both grow, and also invest and spend more time on those decisions than you could as one person. As you and as you give that away and empower people to make decisions as best as they are able, then the whole team is invested into the same goals and success criteria.”
Wes: “Switching gears to talking a little bit about hiring… If you had a magic wand and you could spread one idea out into the zeitgeist about hiring that would make it better for our entire industry, what’s idea that you would spread?”
Mitch: “You know the big thing that comes to mind is, don’t judge a book by its cover. That has a lot of implications. It has implications on diversity. It has implications on on providing opportunities for people who may not have them. It’s about entering into a talent pool that that you may not even realize has a lot of talent
The reason why I say that is because, not every good engineer is going to have a computer science background and have worked at Google or Facebook. There are great engineers out there who are changing careers. right. They didn’t go to school for computer science, but they’ve learned the skill set either on their own or through boot camps. Or they just have a passion for technology and are able to grasp it in such a way that they can apply it and be very successful.
Guru is made up of about 50 percent career changers. And they’re awesome, and I put them up against the the other team members who have computer science degrees and and no one you know even looks at that. They’re all working together to create an awesome product, and and they learn off each other.”
Wes: “Could you tell us a story about an engineer who you may have missed if you judged the book by the cover, and what makes that engineer so great?”
Mitch: “One of my back end engineers was actually at a boot camp down in Delaware that was sponsored by the big banks down there. Their goal was to was to have a talent pool of Java engineers because that’s what the big banks are in here use.
He was actually a psychology major in school. He was a personal fitness trainer as his career and then got into this boot camp. He just knew what he wanted to do. He had a passion for technology. And, after the first interview, I knew he was someone that had to work at Guru. He was a very early employee and he’s still here today.”
Wes: “What’s the most impressive thing a candidate has done an interview that helps you realize they were a good fit?”
Mitch: “Very thoughtful thank you notes after the interview.”
Wes: “If I were interviewing for a job on your team or one of your teams what could I do to stand out?”
Mitch: “Come prepared with knowledge of the company and why you want to work at Guru.”
Wes: “What’s a mistake that you’ve seen an engineering candidate make in an interview that they didn’t realize they were making?”
Mitch: “Trying to appear too smart and answer every single question as opposed to admitting that they didn’t know.”
Wes: “What does a six-star culture add look like for your team?”
Mitch: “Someone who doesn’t take themselves too seriously and enjoys working with others and raising everyone else’s bars.”
