The Essence of Shipping Code: a CTO's Perspective | Flowcode’s Mike Hamrah

0:00And the thing that I've seen when I like talk to the community is the happiest teams and developers ship code. They ship code hosting, right? Yeah, yeah. So they go hand in hand. The ones that are unhappy are like, I've been working on the project for six months and it hasn't gotten to production. So it's like, I don't know what my worth and value is to this company. Are you an engineering leader and tired of constantly being asked, when will it be ready? Stay one step ahead with Linear B's project delivery feature. Our powerful dashboard lets you visualize key milestones, forecast delivery accurately, and align stakeholders effortlessly.

0:41With Linear B's product delivery, you can confidently showcase your planning, prioritize work effectively, and even make data-driven cases for additional headcount. Say goodbye to delays and missed milestones. Sign up for Linear B today and answer, when will it be ready, before anyone even asks. Hey, what's up, everyone? Welcome to Dev Interrupted. This is your host, Dan Lyons, Linear B, co-founder and COO. And today, we're joined by Mike Homra, CTO at Flowcode. Mike, welcome to the show. Hey, everybody. Dan, thanks for having me. I'm really excited to be here. Yeah, so awesome to have you with us today.

1:25You have more than 20 years of software engineering experience. But before becoming Flowcode CTO, you were a VP of engineering at BlueCore. You were a chief architect at Namely and a technical lead at Uber, you know, a small, little known company. Actually, these are like great engineering companies. And today, yeah, today you're joining us to talk about why the job of shipping code keeps getting abstracted away. what that means for engineers and the teams they work on. So we're going to dive into a bunch of those topics. But first, we always like to ask our guests kind of a little more about their background and their career and how you got into engineering and how you eventually became a CTO.

2:20Great question. I can't believe I've been doing this for more than 20 years. I've been definitely going through the midlife crisis and the midlife career crisis. as of late, I think a lot of us are in the, in the, as we're coming out of COVID, but I've, I've always loved technology. I've always loved building. My, my dad was a Apple computer reseller in the eighties and had a small business in the eighties selling Mac. So I kind of grew up around computers and I, I didn't really start programming until I was in college. And then when I entered the workforce, I was coming off of the dot-com bubble.

3:00So a lot of my CS grads were actually going into finance and I kind of stayed in tech and had an interesting job working at a Shakespeare festival whose director was a consultant that did programming for law firms. And he was like, needed some help. And I was like, I didn't have anything else going on. And it was a great first job because I really had to connect with customers, you know, being, being that young and just being like dropped in and having to chat with people and figure out what, what to do. It was definitely figuring out a lot of stuff, but that communication, which I think has enabled me to be pretty successful throughout my career and a forcing function of communication early, I think really helped me out.

3:42And then I stumbled upon a startup that was doing fashion imagery and entertainment imagery that eventually got bought out by Getty Images. And I worked at Getty Images, which wasn't on the hit list, but a very great company that I met a lot of wonderful people and I had a lot of wonderful mentorship on it and spent many years at Getty Images before I moved on to Uber because I did want to, you know, this little small startup. I joined in 2015. And if you've seen the Showtime show, I joined right before the Beyonce concert in Las Vegas. So I got to experience that. And Uber, I think, was a really great place.

4:24There are so many talented engineers that work there and the scaling challenges from an engineering perspective. I don't think that we actually talk about that enough and how interesting and challenging that was and how fast it was happening that you really had to be focused and sharp on what you were delivering and how you were delivering it, which I still have carried with me through Namely and through through BlueCore and now at FlowCode. That's so cool. You got to see the queen bee, Beyonce. I did. I did. Just standing somewhere and, you know, next thing you know, I'm like, you know, 20 feet away from a private Beyonce concert.

5:02It was, it was something else. You know, one of the things that I noticed in a lot of the, you know, CTOs or VPs, that style person that comes on the pod, you mentioned communication and customers. both of those words stuck out to me. And I think that's like a skill set that I see that people want to go on more of that management, leadership track, get into the C-suite. Think just for the audience, think about that. Get close to customers, understand the business. You have to have all the technical chops too. And then the communication skills. Yeah, and I think it's, yeah. Yeah, absolutely. And I, you struck something out, which I think is like directly to the kind of like the heart of, you know, what I'm passionate about is I see a lot of engineers wanting to get into the management track as an avenue for empowerment, right?

5:53It's like you feel like, hey, I'm kind of being told what to do. I don't really agree with what's going on. Like, why aren't we doing X? And you feel like the answer to that is to become an engineering manager. And the next thing you know, you're dealing with all of these problems that you had no idea what you're dealing with. And the empowerment that you thought that you were getting, you're not actually getting. And I think that communication is not just about management and it's not just about leadership. I've actually gone from IC to management in many times in my career. I was a manager at Getty and then I was a principal engineer.

6:32I was an IC at Uber. I was IC at management at Namely. I was full on management at BlueCore. But it all comes down to really understanding what are you doing and why are you doing it? And do you have alignment? And it doesn't matter if you're a manager or if you're an Eng Level 1 or an Eng Level 2 or a principal engineer. That context and that understanding and that communication and that really knowing who's using your product and what do you have to change is really important. And it's so key, I think, to that like Marty Kagan philosophy of empowered product teams that have control over their destiny and empowerment.

7:13And you as an engineer, can you prototype something or hack something or go in a different direction? And how supported are you in doing that? Yeah, great point. I mean, when you're an individual contributor, it's like your influence. And the way that you can influence more is knowing the business. And the way to know the business more is know the product and the customers. And then you're going to probably get people to move in the right direction. Yeah, absolutely. Absolutely. And I think, you know, the technology aspect, we focus a lot on, you know, code and technology. I want to learn Go. I want to learn TypeScript.

7:46I want to learn Rust. I want to learn Kubernetes. And those are all important. Like, you should know those. But those are tools in your toolbox. and like knowing Kubernetes or knowing Rust isn't, doesn't mean anything unless you're applying that effectively. And, you know, you can know how to use a hammer, but, you know, do you want to use a hammer to build a house or do you want to use a hammer to like craft a chair, right? Those are two very fundamental different things. And if you want to build a house, don't work at a place in a furniture factory because it's like, you're not going to be stimulated.

8:19But if you want the like artistic element of like building furniture, then don't go into construction, right? because it's like you're not doing what you want to do. And I think that there's a lot of interesting mismatches in how people are applying technology to the products and the industries that they're in. And that passion of being able to apply technology effectively to the product you're working on, I think a lot of people have to figure that out and find it. Because if you're not passionate about the work that you're doing, you're missing something. And I think that you don't really realize that you're missing it until it's too late.

8:57Yeah, perfect. It's a good time for everyone to take a beat after this pod and just think about it. Think about that. What am I doing? Is it, you know, my purpose and passion? The other thing, Mike, from your background that I wanted to ask you, and I know like CTO roles, they differ widely. It's probably like one of the titles that I can't say exactly what it means for every single business. And I actually don't know what it is for you. But I saw that you went from a VP of engineering to a CTO. And typically, maybe most of the time, when I think of a VP of engineering, it is more so, okay, I have a larger engineering team.

9:41I'm trying to deliver on a product roadmap. I'm dealing with a lot of people. And then sometimes, I don't know if it is for you with the CTO. It's like, I have a smaller team. I'm meeting with like, I'm trying to make sales, even meeting with customers and impacting the technology and the roadmap. Is there a reason that you went from, and I don't know if that's the case, but went from VP to CTO. Is there anything there for the audience? No, I really loved Bluecore and I wasn't looking for another switch. You know, I actually like BlueCore is very close to me because the CTO and co-founder of BlueCore, Mahmoud Aram, was one of my good friends.

10:25We actually met because we both have children of the same age and we live in the same neighborhood and our nannies that we hired for healthcare were actually friends. And so our kids were playing with each other. And I was kind of getting gossip from our nanny. It's like, oh, you know, he's in tech and his wife is a lawyer and my wife is a lawyer too. And we actually like saw them in Prospect Park. We live in Brooklyn. And I was like, I think that's, you know, who our son plays with. And we introduced ourselves and we just we hit it right off the bat. And I saw BlueCore at the time. This was in 2014.

11:00I saw BlueCore go from kind of having like an office WeWork space a little bit. just getting started to like the massive growth spurt. And I was just starting at Uber at the time and I was, you know, befriending Mahmood and, and we were exchanging like technical growth ideas. And, you know, they went through a round of funding. I went to Namely and eventually the paths crossed that Mahmood was like, you know, please, you know, finally join me. And I was like, I have to, I have to, you know, work with him because we're not going to be friends anymore if I keep on telling him no. And that company, you know, we went through a series either over the past two and a half years.

11:37It's a great product, data science as a service, really great team, great, great people. And it was hard for me to leave because I was so closely connected to it. But there was this opportunity that came up to join a QR code company. And I was like, you know, QR codes, like, how is that a business? I didn't really understand it too much. But as I learned more about the company and the product, I became fascinated. And the company has like six core cultural values, but the one that stood out the most for us is the team is the product and the product is the team. And we are a very early stage company.

12:13The product has transformed itself. And the teamwork that we foster there was so strong in the interview process that I just, I really wanted to be a part of it and be a part of what I saw was something incredibly special. And then on the product side, you know, QR codes for us is really an entry point into a much larger experience. You know, we say you're in the real world all the time. You're walking around, you're going to restaurants. You know, I love living in New York City because there's just so much to experience. And QR codes, you know, you think about, oh, just like I'm scanning a QR code.

12:50But for us, it's really this entry point onto a much larger platform and much larger experience where I scan a QR code at an art gallery. I can learn more about the painting. I don't need to go to Google and search. I don't want to go into a product pitch. Just stop talking. I like that. But I was personally very fascinated and very passionate about the project, the product. And being there a year now, and it gets into your DNA, and there's all of these possibilities that we talk about. But it's, I'm very lucky that I've loved all of the companies that I'm working at. And this was an opportunity that I just didn't want to pass up, which led to it.

13:25And it was a flex, right? It is that leadership, it's supporting people, it's all of the wonderful excitement and messiness that goes with early stage startups that, you know, if you're listening and, you know, you're pre-seed, you're Series A, Series B, you know exactly what I'm talking about, that you're just going through and you're doing it with people that you really care about and that you're excited to work with and a product that you're passionate about, which is what you really need, I think, at any company, but certainly to make early stage startups successful. Yeah, it's like the same message that you've said from the beginning, which is like, choose projects you're passionate about that will probably lead to career success.

14:04Well, the first topic is around shipping code. And maybe that it's getting abstracted away a bit. which I think, you know, you've said a few times here, the job of the developer, of course, is to ship code, but maybe you've noticed a trend across the industry that it's getting abstracted away a little bit. Can you expand on what does that mean and what are you seeing? Yeah, absolutely. And I think like this is definitely materialized as I've gone again into that early stage startup where shipping code is paramount, right? But not just thinking about 18 million different ideas and how do we kind of create chaos, but making sure that we're doing the right thing.

14:51And I think that at the end of the day as developers, and I think that this could be like a controversial statement, but even like my job as a CTO, it's to ship, right? Like if I'm not shipping code and not having my team ship code, I'm not doing my job. Even if it's fixing bugs, like in order to fix a bug, you have to ship code. In order to develop a feature, you have to ship code. And certainly if the only thing that we're doing is writing code, that's bad because it's like, what code are you writing? Do you have? And we'll get into that in terms of like context on it. But I think that the thing that we're really like losing out, having been on 18 million different stand up meetings and sprint planning meetings.

15:35And, you know, I think this is the curse that we're all realizing of Agile is we kind of forget that our job is shipping code. And if we're not talking about what code we actually have to ship or what we're changing with our product, and we're getting down to that essence of like, what are we changing and how do we do it in a way that we can keep on changing it without coding ourselves into a corner or causing a lot of technical debt, we're not having the right conversations and And we're not contextualizing the work that we have to do effectively. Now, certainly like there's 18 million, like, you know, do we go in down this road or this other road?

16:17There's certainly like alignment on it. But all of these things that we're doing, all of it comes down to, can we ship code faster, right? Is like, is using the CD pipeline going to help us ship code faster? Is using Argo rollouts going to help us ship code faster? Is using Kubernetes going to help us ship code faster? Is using this framework going to help us ship code faster, which ultimately means make product changes easier and better and make all of our lives easier? I know what product changes do I have to make, and can I do it effectively, and I do have that right context in order to do it.

16:49And we lose sight of that, I think, too much in the process ceremony that inevitably happens with trying to organize efficiency. Yeah, no, I mean, you're kind of preaching to the choir here because for sure on this pod, if you think about the purpose or the mission of a great engineering team or even what does an elite engineering team behavior look like? it's that we're shipping code rapidly really really high quality and it's in the mission of company value that's probably the the other key there or the art of it is how much value are we able to shift you know uh ship is it in the you know with the right goals and all of that yeah and you know obviously for us at linear b we're measuring this kind of stuff we're finding bottlenecks, you know, our customer base is obsessed with it.

17:50Yeah. But it's what's funny is you said, hey, this might be even a controversial statement. And and and what made you kind of like double think that is it like the agile ceremony stuff or like because I know for your team, you're measuring, you're measuring, you have. Yeah, I was just going to say, like, look, I'm here like I use linear B like one of the first things that I did when I kind of came on, you know, certainly like not on day one, but after just, you know, getting my bearings as I brought Linear B to the organization, because I love, like, I love the DevOps metrics. I, you know, I want to try and address into like the Dora metrics versus the space metrics versus, you know, DevX and how as an industry we're evolving in the metric space, but I love linear B because it takes a code first view of engineering teams.

18:44Right. And the reason why I say like shipping code is controversial is nobody wants to be treated like a code monkey, right? Like we're not talking about just arbitrary people like keyboards, just, you know, banging away. Like, and I think that's the controversial statement is that there is a fine line between our job is to ship code to being treated like a code monkey. And I've, I'm a huge Marty Kagan fan. And if you haven't read his books, Empowered and his blog, Silicon Valley Product Group, I definitely do that because that was very eye-opening when I came across him as an IC. He talks about the difference between feature teams and product teams.

19:24And if you can get into the product team mindset as an engineer where your job is to ship code, it's much different than being treated as a code monkey, which is not what anybody wants, right? Like I want empowered people, autonomous people, supported people that are bringing their best ideas to the table and know how to get them in front of customers and want to get them in front of customers. And the thing I like about Linear B is it helps teams take a code first view of the work that they're doing, right? It's like if you're shipping code that is not associated with a shortcut story because it was like this left field bug that came in and you're just like getting it done, you see that, right?

20:05So you see how well you're planning versus executing and how well your interrupts are doing. If you have a PR that you need reviewed at standup, you see that, right? You're not looking at a shortcut ticket that you forgot to move into ready for review and who's going to assign it. And that whole team is really rallying on this code first view of how your day-to-day and how the team is unfolding. That helps with the shared context of how are we changing our system and how quickly can we get that system into production? And what is our true bottlenecks in that lead time, cycle time, release time, failure rate that is preventing us from having like the momentum that is going to help shape future investments very clearly in terms of what the work the engineering organization has to do.

20:56I remember when I first started developing, there was that whole code monkey thing. yeah, we don't want to be code. And I usually only see that when engineering is like really disconnected from the business because it's kind of like, okay, engineering, we just tell you what to build and that's it. Yeah. And so I think if you have like a decent culture of your engineers should be able to impact the product, your engineers should be able to, while they're working on a story, give a better suggestion, get on to cut. Like usually you can get out of that that code monkey mindset. You mentioned something else that's interesting, which is that DevEx or like developer experience, which is something that it's kind of like a buzzword of interest right now.

21:41But what it really means is developers are vital to our business. Therefore, we want to make sure that they're having a wonderful experience and are happy. And the thing that I've seen when I like talk talk to the community is the happiest teams and developers ship code and they ship code right yeah yeah so they go it's hand in hand the ones that are on yeah the ones that are unhappy are like i've been working on the project for six months and it hasn't gotten to production so it's like i don't know what my worth and value is to this company yeah so it's good you think it's good it goes hand in hand right yeah yeah and i also think that the friction that you experience And I mean, I, so many times I just wish I had a magic wand that could just fix stuff.

22:32Right. And I know that, you know, a lot of people like, and I think that this is one of the love and challenges of being a leader is like, you know, I know that people are like looking up to me to like help solve systemic problems. Right. And deal with frustrations. And as much as I wish I could snap my fingers and just make everything like better, you know, I can't like, we have to work together. We have to prioritize. There's only so many resources. We have to figure out how to do stuff. And that experience of together goes into the teamwork and the camaraderie that we have to foster and just that ruthless transparency of what do we need to prioritize?

23:10Do we have a solution for this? Okay, we don't know how we're going to fix it. What can we proof of concept? How can I represent and communicate that to the rest of the business? why the team had a bug that they had to swarm on this weekend and we're going to be delayed this week and how do we eliminate the failure rates and all of that stuff, which is like the system that you're creating for success. And in any system, there's entropy where things, even if it's perfect, things will naturally degrade and you have to deal with that ebb and flow of, I changed something, I have to react to it, I have to fix it.

23:44Okay, we're in a swarming, storming phase. Okay, we're in a plateau phase, we're in a scaling phase, and just dealing with all of those transitions in order to stay focused on shipping code. What do I need? What's the pain point that we need to remediate? Let's prioritize that. Let's see how it changes the system and move on from there. I love the way that you described it because for engineering leaders, like you're a VP, you're a CTO, or you're like a director at a big company. It's almost like, I don't want to say like God power, but you're like creating this, uh, field or this world or this ecosystem that your developer or your development team is playing in.

24:28And the field hopefully is very smooth. Like if we're doing sports analogies, nice turf, it's easy to pass the ball. Yeah. It's, uh, easy to like shoot at on goal, like soccer or something, something like that. Or if you're in a situation you don't want to be in, you've created this world where it's bumpy. It's hard to get code out. It's hard to do a good pull request review. It's hard to actually push the shit button. It's hard to test. And that's it. When you were talking, that's kind of like the mind I had, the mindset I had. Do you see it that way? Like you're creating this like playing field?

25:06Yeah, totally. I mean, I think like, you know, having again, like lived in Brooklyn, And I like the urban studies or like civic analogy, right? Where it's like, I want to be able to walk out the door. I want to be able to get into the subway. It's, you know, totally clean. My tap to go works. The train just is right there when I get on. I get a seat. I go in, I get to where I need to go. But it's like when, you know, it's like raining outside and I forgot my umbrella and my tap to go doesn't work and the trains are delayed and it's like super crowded because the trains are delayed and then there's a signal failure.

25:43So the train gets rerouted and like, you know, your whole day is like, it's like developing is like the same way, right? But it's like, you're never going to consistently get that like, you know, green light everywhere and, you know, like fixing a signal problem in the New York City subway. It's like, it's a massive change, which is like the same thing. like if you have a huge monolith or you know or mono repo and you know like those those tests that you were adding caused cypress to take kind of too long and now you're scaling up your infrastructure but then your costs are too high so like and you have to like do this massive refactoring it's like that's just like all normal stuff that that is never going to go away and you just have to make sure that again like you're dealing with it you're not letting things fester you're being transparent about what the priority is to just make it as successful as possible.

26:32And the theme that I always see that I try to preach as much as possible, and I actually need to revisit this, is don't be afraid to refactor. And I think that it doesn't matter if you're refactoring your code base or you're refactoring your sprint processes or you're refactoring your infrastructure is if you're afraid to refactor, it's just an inevitability of problems like later on and where you can really focus on healthy refactoring and get that into your code base and get that into your practices. It's going to just help keep curation running because like running a complex pipeline of like even more than a dozen engineers, you know, where we're at, you know, 40 plus engineers at Flowcode and I've, you know, seen thousands of engineers organization teams.

27:22It's like, it's a lot, it's just like running a city and like making sure there are no potholes in the streets. And how are you prioritizing all that? It takes a lot to like maintain and like run that infrastructure. And it's not always going to be pretty, but you just, you have to stay on top of it as much as possible and stay focused and make sure that you're manicuring your lawn or your garden as best you can. And of course, like when you talk about signals, all of this stuff is measurable now. You're up to like 40 engineers, then maybe you're growing again. Things are good, double in size.