On this week’s episode of Dev Interrupted, host Dan Lines speaks with Mike Hamrah, CTO at Flowcode. Together, the two detail the fundamental responsibility of developers and tech leaders: shipping code.
Mike shares a candid view of the industry's current state, lamenting how the focus on code shipping is getting lost amidst the complexities of agile methodologies, stand-up meetings, and sprint planning. He urges developers and leaders alike to recenter their conversations on the essence of their roles, serving as a call to action in the episode and reminding listeners of the importance of understanding what code needs to be written and the purpose it serves, all while avoiding detrimental practices that can hinder long-term development success.
Dan and Mike end the episode with a conversation on goalsetting and OKRs, translating classic business goals into engineering execution and emphasizing the need to turn general business goals into concrete, actionable plans.
Episode Highlights:
- (2:20) Mike's start in engineering
- (9:00) Pursuing projects you're passionate about
- (14:05) Shipping code is being abstracted away
- (20:55) No engineer wants to be a code monkey
- (26:30) Don't be afraid to refactor
- (28:00) Goalsetting & OKRs
- (32:15) Crafting and setting business goals
- (38:20) What's going on at Flowcode
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Dan Lines: Hey, what's up everyone. Welcome to Dev Interrupted. This is your host, Dan Lines, LinearB cofounder and COO. And today we're joined by Mike Hamrah, CTO at Flowcode. Mike, welcome to the show.
Mike Hamrah: Hey everybody. Dan, thanks for having me. I'm really excited to be here.
Dan Lines: Yeah, so awesome to have you with us today.
You 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, 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 a little more about their background and their career and how you got into engineering and how you eventually became a CTO.
Mike Hamrah: Great 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, as we're coming out of COVID, but, I've always loved technology. I've always loved building my dad.
was a Apple computer reseller in the 80s and had a small business in the 80s selling Macs. So I grew up around computers and I didn't really start programming until I was in college. And then when I entered the workforce, I was You know, it was coming off of the dot com bubble. So a lot of my CS grads were actually going into finance.
And I 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. It was a great first job because I really had to connect with customers, being that young and just being like dropped in and having to chat with people and figure out 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. And 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, this little small startup I joined in 2015, and if you've seen the Showtime show I've, 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. There's 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 Bluecore and now at Flowcode.
Dan Lines: That's so cool. You got to see the queen bee, Beyonce.
Mike Hamrah: I did. I did. It just, standing somewhere and, next thing I'm like 20 feet away from a private Beyonce concert. It was something else.
Dan Lines: One of the things that I notice in a lot of the, 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.
Mike Hamrah: And I think yeah, absolutely. And I, you struck something out, which I think is like directly to the, like the heart of, what I'm passionate about is I see a lot of engineers wanting to get into the management track as an avenue for empowerment.
It's like you feel like, Hey, I'm 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'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. 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. I was an IC at Uber. I was IC at management at Namely. I was full on management at.
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. And 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?
Dan Lines: Yeah, great point.
I mean that 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.
Mike Hamrah: Yeah, absolutely.
Absolutely. And I think, the technology aspect, we focus a lot on, code and technology. I want to learn Go, I want to learn TypeScript, I want to learn Rust. I want to learn Kubernetes. And those are all important. You should know those, but those are tools in your toolbox. And knowing Kubernetes or knowing Rust isn't, doesn't mean anything unless you're applying that effectively.
And, you can know how to use a hammer, but, do you want to use a hammer to build a house or do you want to use a hammer to craft a chair? 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.
But 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.
Dan Lines: Yeah. Perfect. That'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, 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, but I, and I actually don't know what it is for you, but when you, I saw that you went from like a VP.
Of engineering to a CTO and typically maybe like most of the time when I think of a VP of engineering It is more so okay. I have a larger engineering team. I'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 in, I'm meeting with 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?
Mike Hamrah: No, I, I really loved blue core and I wasn't looking for. Another switch. I actually like blue cores very close to me because the CTO and co founder of blue core.
Mahmood Aram was one of my good friends. We 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 health care. We're actually friends. So our kids were playing with each other and I was getting gossip from our nanny.
It's oh, 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, 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.
I saw Bluecore go from having a office, we work 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, befriending Mahmood and we were exchanging like technical growth ideas. And, they went through a round of funding.
I went to Namely and eventually the paths cross that Mahmood was like, please, finally join me. And I was like, I have to. I have to work with him because we're not going to be friends anymore. If I keep on telling him, no. And, that company, we went through a series either over the past two and a half years.
It's a great product data science as a service, really great team. Great people. And it was hard for me to leave because I was so closely connected to it. But there is this opportunity that, that came up, to join a QR code company. And I was like, 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 it, we are a very early stage company.
The 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, QR codes for us. is really an entry point into a much larger experience.
We say you're in the real world all the time. You're walking around, you're going to restaurants. I love living in New York city because there's just so much to experience and QR codes. You think about, oh, just like I'm scanning a QR code, but 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. I'll just stop talking. I like that. But I was personally like very fascinated and very passionate about the project, the product and being there a year now. And you just, it gets into your DNA and there's all of these possibilities that we talk about.
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 and 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, if you're listening and you're.
Precede your 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.
Dan Lines: Yeah, it's like the same message that you've said from the beginning, which is choose projects you're passionate about. That will probably lead to career success.
The first topic is around shipping code and maybe that it's getting abstracted away a bit, which I think, you've said a few times here, the job of the developer, of course, is a 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?
Mike Hamrah: Yeah, absolutely. And I think 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 create chaos, but making sure that we're doing the right thing.
And I think that at the end of the day, as developers, And this, I think that this could be like a controversial statement. But even like my job as a CTO, it's to ship, right? 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 and I think this is the curse that we're all realizing of agile is We 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 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 we're not contextualizing the work that we have to do effectively. Now, certainly like there's 18 million do we go in, in down this road or this other road?
There'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 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. Do I know what product changes do I have to make and can I do it effectively? And I do have that, that right context in order to do it. And I, we just, we lose sight of that. I think too much in the just process ceremony that inevitably happens with trying to organize efficiency.
Dan Lines: Yeah. No, you're preaching to the choir here because for sure on, 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 high quality.
And it's in the mission of company value. That's probably the other key there or the art of it is how much value are we able to shift, ship is in the, with the right goals and all of that and. Obviously for us at LinearB, we're measuring this kind of stuff. We're finding bottlenecks, our customer base is obsessed with it.
Yeah. But it's, what's funny is you said, Hey, this might be even a controversial statement. And what made you like double think that is it like the agile ceremony stuff or cause I know for your team, you're measuring.
Mike Hamrah: I was just gonna say look I'm here I, I use LinearB one of the first things that I did when I came on, certainly not on, on day one, but after just, getting my bearings is I brought LinearB to the organization, because I love I love the DevOps metrics.
I don't want to try and dress into the Dora metrics versus the space metrics versus, DevEx and how as an industry we're evolving in the metric space, but I love LinearB because it takes a code first view of engineering teams, right? 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, banging away. 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, like 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. And 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 and which is not what anybody wants, right?
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 LinearB. Is it helps teams take a code first view of the work that they're doing, right?
It's if you're shipping code that is not associated with the shortcut story, because it was like this left field bug that came in and you're just like getting it done. You see that. So 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, that, right?
You're not looking at a shortcut ticket that you forgot to move into code 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 the momentum that is going to help shape future investments very clearly in terms of what the work the engineering organization has to do.
Dan Lines: I 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 okay, engineering, we just tell you what to build.
And that's it. And so I think if you have 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. Usually you can get out of 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 like a buzzword of interest right now. But 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 often.
Mike Hamrah: Who would've thought often, right? Who would've thought, yeah. Yeah. So it goes hand in hand.
Dan Lines: And 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 I don't know what my worth and value is to this company. Yeah. And yeah. And so it's good. I think it's good. It goes hand in hand, right?
Mike Hamrah: Yeah. And I, I also think that the friction that you experience, and I. So many times I just wish I had a magic wand that could just fix stuff, right?
And I know that, a lot of people like, and I think that this is one of the love and challenges of being a leader is I know that people are like looking up to me to 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, 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 like that experience of together goes into like the teamwork and the camaraderie that we have to foster and just that ruthless transparency of What do we need to prioritize?
Do 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 a 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 Go.
Creating for success and in any system, there's entropy where things, even if it's perfect, like 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. Okay. We're in a, 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.
Dan Lines: I love the way that you described it because for engineering leaders, like your VP, your CTO, or you're like a director at a big company, it's almost I don't want to say like God power, but you're like creating this field or this world or this ecosystem that your developer or your development team is playing in.
And the field hopefully is very smooth. If we're doing sports analogies, nice turf, it's easy to pass the ball. It's a easy to like shoot on goal, like soccer or 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 ship on. It's hard to test. And that's when you were talking, that's like the mind I had, the mindset I had. Do you see it that way? Like you're creating this like playing field?
Mike Hamrah: Yeah, totally. I think having again, like lived in Brooklyn.
I like the urban studies or like civic analogy, where it's I want to, Be able to walk out the door. I want to be able to get into the subway. It's, 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, 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. So the train gets rerouted and like my, your whole day is like, it's like developing is like the same way.
But it's you're never going to consistently get that, like you, green light everywhere and. Like fixing a signal problem in the New York City subway. It's it's a massive change, which is like the same thing. If you have a huge monolith or, or a monorepo and, like those tests that you were adding caused Cyprus to take too long.
And now you're scaling up your infrastructure, but then your costs are too high. So and then you have to do this massive refactoring. It's 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. And the theme that I always see that I try to preach as much as possible. And I actually I think 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 running a complex pipeline of like even more than a dozen engineers, where we're at.
40 plus engineers, at Flowcode, and I've, seen thousands of engineer organization teams. It's it's a lot 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 maintain and run that infrastructure.
And it's not always gonna 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.
Dan Lines: And of course, like when you talk about signals, all of this stuff is measurable. Now you're up to 40 engineers.
Then maybe you're growing again. Things are good. Double in size. It's harder to get these signals. They're all there for you. I do want to take us to the next area. I want to talk about goals with you. Yeah. And aligning either engineering goals or goals to the business. Like how are you approaching that at Flowcode today.
Mike Hamrah: Yeah, absolutely. because this is fundamentally the most important thing, right? It's like we can talk about shipping code, but if you're shipping the wrong thing, that's not helping the business. You're working hard, right? But. You're not all actually aligning to the outcomes that you want. And it's probably no fault of your own, right?
Yes, of course you can, as the manager, we'll get more aligned, get, pay attention, but it's nobody's I'm actively going to derail our business. Or I'm, maybe somebody's, messing around with a new language when they should be like shipping something, but that's usually.
More of an isolated incident. Everybody really, means well, they, they are doing the best of their ability in order to do what they think is right. And so the question is how do you give them context? And we're a huge fan of OKRs at Flowcode. I've used OKRs at several times, but I think that the interesting thing at Flowcode that we do with OKRs is we talk about them constantly, like every day.
What are our OKRs? Are we moving to our OKRs? How do engineers or anybody in the company know exactly how they're tying to the OKRs? Which gives the most fundamental thing when it comes to talking about are we shipping code? Is are we shipping the right thing? Is do we know what our business alignment is?
And then what is our strategy to execute on those goals? And are we following and aligning to that strategy? Or are we Unintentionally going down a different path. And so thinking about OKRs and just talking about them every day, because I've worked at companies that have had OKRs and we just we didn't talk about them.
Like before it's you talk about them at the start when you're forming them of the quarter and you talk about them at the end of the quarter, but in the middle, you like, you just forget about them. And then all of a sudden it's you've never moved forward over your OKRs and there's 18 million yeah, bots, why did this happen?
And so talking about them. And looking at them in our standups and making sure that as we're planning sprints or we're thinking about roadmap items, we, to the best of our ability, feel like the work that we're doing is going to advance the OKR. And if not, and we're calling it out. We have to reset and the deliverables that you're talking about, we have to shrink it down.
And this is the phase that we're at now, it's I'm constantly talking about how do we take this goal or this idea or this strategy that we think is going to help execute and improve our key results and our objectives and shorten that into some signal that gives us confidence that we should continue.
Because if that's a six month project, Too slow, too long. If that's a three month project, too slow, too long, right? And a lot of the work that does take some time that like, yes, detracts against shipping code is like, what is that milestone that we're trying to hit? But again, We're not going to hit that milestone if we can't ship code faster, right?
So that alignment and that entropy and that context is really important, which is having a fanatical level of detail of what we're doing, de risking that execution as much as possible, and then trying to validate it as fast as possible.
Dan Lines: That's amazing. I gotta ask you a few questions here. Usually when I see like OKRs at the business level.
So we're not talking like engineering, but like the CEO comes on, oftentimes they have to do with like dollars or something like that. So it's like we need our net ARR or a new ARR to be this, and then we need our retention numbers to be this. And then we have like pipeline generation for marketing and then, customer success support and then maybe sometimes it's We need to deliver on a certain project, but do you have any tips of how you're like translating kind of classic business goals?
Do you do like business goals, projects, engineering, execution, or what are you doing there?
Mike Hamrah: Totally. It's the question is like, how, right? this is exactly I think where companies focus on the wrong thing. It's we agree, we have this business goal. We want to be the best.
And we know that we're gonna be the best if we are, number one in X, right? That's not an objective and a key result, right? And don't tell me to go read, measure what matters. And that 'cause it's like totally, it's that's all mamo agenda stuff is the more concrete example is okay, you wanna increase revenue by X.
How are you gonna do that? What is your goal, right? And can we have a conversation where we're connecting the dots because we've done the due diligence that some change and we're projecting that some change because it's like we've talked to our customers and we know how many people, want this feature and we've done a projection on what we can charge for it or like what the cost reduction needs to be and are we aligned on the how as a company?
As everybody in the company knows what the how is. I'm not talking about like a prescriptive okay, I'm like, here's all of the requirements and I'm sure, and we have to check this step, but it's like, it could be as something as simple as like lowering or improving our NPS score.
Do we know what the biggest aggravation in NPS? And do we have proposed solutions that we've like maybe done a Figma mock up and shipped it to the people who've complained about the most and get a read? Can we refactor something in our user experience that we think is going to move the needle on the NPS score?
And can we even get a better signal of validation? Like maybe the amount of users that are going through this journey. We need to improve. And can we make a change to improve that number? That is just the fanatical level of detail on the how and the alignment where everybody knows and we're constantly talking about what piece of his of it is there.
And as a counterexample to this, it's like I've had, I've seen two different departments have their own department OKRs. That both rolled up into the same company. Okay. Are that we're totally different and totally count going to negate each other, right? Both wanted to increase customer happiness and this team was going to do a bunch of manual stuff.
In order to work much harder that they thought that they were going to do a brute force attack in order to fix customer happiness. And this team was going to automate something that was completely opposite of what the manual team was going to put in place. And nobody was catching this, right?
And so this team burnt themselves out with an inevitable goal. This team couldn't deliver what they needed to do because this other team was undermining the work that they were trying to automate and it just wouldn't work. And both thought that they were completing their company OKRs, but what we weren't talking about was the how and clearly communicating the how and getting alignment, which goes into that fanatical level of detail of what you need in order to like, Execute and move the product accordingly and vetting that was the solution we're going to get behind and making sure that everybody was aligned and we weren't doing anything to degrade it.
Dan Lines: Think like a great, if you want to improve NPS or we're talking about customer satisfaction, let's say, or customer return. The cool thing with engineering is usually it relates to a product or like a product project. So you can say, okay, we want to increase NPS by X amount.
Usually that's associated to something in the product. That we need to improve. And when you're thinking about engineering metrics, you can say, okay, first and foremost, do we have enough people allocated to that project? Yes or no. Got it. Okay. Yes. Now, do we have goals and milestones? Cause usually there's a timeframe of when we need to deliver.
It's not infinite. It's like this quarter. Okay. We have project milestone. Now you can say in order to deliver quick with high quality. Yeah, we have to have great cycle time and less bugs found in production. So we're not swarming over the weekend on some different, so it's like it all relates together.
And I would just say my advice, cause I love like the detail that you're getting is to make sure that your engineering organization has goals on those details of. enough people on the project delivery, my milestones, engineering efficiency and quality metrics. And it all rolls up to that business goal.
That's what I've seen be successful.
Mike Hamrah: Yeah. And I would actually, I would just do a little tweak where I think that you have to start with the goals and you have to start with the champion of who can really. Own that and make it happen. And then you can talk about resourcing. Cause I think that like a, one of the misalignments is you throw too many people at it and there isn't that consensus of how you're going about it.
Like people feel like you're spinning your wheels and they're not tied into it. I do think that you have clear ownership and you could start small. And then the real question is do we need to accelerate this roadmap or these goals and would more people help that? And then how do you divide it before you just think that like throwing more people on any one problem is gonna fix it?
Dan Lines: It could be a yes, it could be a no, but at least know.
Mike Hamrah: Yeah, exactly.
Dan Lines: We could probably spend a full pod just on this topic.
But we're going to have to wrap it up for today. And before we go, definitely want to give you an opportunity to let us know what's going on at Flowcode.
How can we sign up? How do we get involved?
Mike Hamrah: Absolutely. So I definitely obviously visit our website, flowcode.com. I think. The thing that is interesting from my standpoint is, people think of QR codes as Oh, I use them to scan a menu. And, I get a PDF, but we see such success across so many different industries.
That can get the direct connection from things in the physical world to like understanding and promoting your business. And it could be something as simple as, you're a restaurant, maybe you're using them for QR codes, but, you put a QR code in your window and you're closed, you can go to a mobile optimized version of your website, you can sign up for.
A mailing list and get deals and specials there. You run a yoga studio, you want to put your class online to see what's there and available. It's you don't have to, what was the name of the yoga studio? And I'm searching Google and I'm doing my, I have to get my advertising spend.
It's like a, it's like a headache. It's like really leverage just how much foot traffic and how much presence there is, and. I love the technology because it's such a seamless enabling experience, like I never want to have to enter in a URL again, like I sharing my contact information, you can scan a QR code, get my get a V card with all of my data on it, you can find me on LinkedIn very seamlessly.
And I as just somebody who just like loves technology and making things easier. This whole platform that I encourage people to explore, and you can definitely apply it to, to whatever it is you're doing. It's so enabling, and it's huge, it's funny because it's like, it's huge in Asia, it's huge in Europe, but I think in the United States we're just starting to incorporate it, and really use it as a tool to just drive connections, which, Like anything, it's just like connecting with people makes everything more fulfilling.
Dan Lines: I guess if you're in the U S and listening, let's show a little more love to Flowcode. And probably if you're looking, developer for your next opportunity, it sounds like with Mike a wonderful culture and place to work. Mike, thank you so much for coming on the show today.
Mike Hamrah: Absolutely. It's great to be here.
Dan Lines: And thanks for listening, everyone. I hope you enjoyed this conversation as much as I did. If you haven't already, please remember to rate and review the pod. It only takes 30 seconds, and I promise it means the world to us. Thanks again, everyone. We'll see you next week.
Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!
gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.
The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!
Learn more about how gitStream is making coding better HERE.
