John Blythe: The Power of Adaptation - Thriving in Dynamic Tech Environments

This transcription is AI-generated and may contain errors or inaccuracies.

Matt

My name is Matt and I will be talking with John Blythe about the challenges of moving between startups and larger organizations and how leadership strategies differ in each environment. You work on a startups, you work on a bigger organization side. And I think during our last conversation I really like the talk about your experience from Kyruus and you will tell me, sorry, how do you approach building the entire engineering structure and based on that experience from the Kyruus, how do you approach the things in the smaller organizations with a lot of spaghetti, code and duct tape solution?

John Blythe

Yeah, good question. So I guess, you know, I'll say this, probably with every answer your mileage may vary. It's very, very based off the context of the organization and what the appetites are. So at Kyruus it was a larger organization, late stage, growth stage startup. If anything, we had tried to be too big for our bridges and went for the full SoC2 compliance and trying to really position ourselves for potentially an ipo, eating up different companies that were adjacent to what we were doing so that we could build out a much larger value proposition within the health care space. And then because of being in the health care space, obviously you have to be buttoned up really well versus jumping into a more direct to consumer early stage startup, pre funded, precede and it's the wild wild west which has its benefits and also its drawbacks. And so I was hired at the current company, combined curiosity to help build the organization towards something more, I hate to say mature, but less early, scrappy, proof of concept kind of organization, not just the code.

And so those two, you know, good old classic team topologies, they mirror one another. It's not one versus the other. If you do one, the other's going to either drag it down or dragged along with it.

So there's a mix. I joined with a junior engineer who left soon after because of a visa misunderstanding issue. I rebuilt the org with an application and analytics engineering teams. Big part of our secret sauce is the insights we can gain from the clickstream user flows within our marketing experiences online. So we needed applications to be built. We also needed lots of software services, APIs, infrastructure built for servicing what was actually coming through and doing something with it meaningful. So building the team and building the future at the tech side, like you said with spaghetti and lots of duct tape and bubblegum, was not without its challenges.

That's because the third layer of this kind of stool of building an org, which is the culture and I kind of hinted at it earlier with the appetite of the organization, which ultimately is the Founders at that stage, and really in all stages, but especially preeminent and prominent in that stage is a company is always going to reflect the personality of the founders, for better and worse. So their strengths are going to be highlighted, their weaknesses are going to be highlighted, and you have to navigate both of those simultaneously. So trying to get buy in, it's like somebody who says that they want to lose weight, but then when you start to throw away the Oreos or you start to get the meal plan, it's like, okay, I want to be the person who has lost weight. I'm not sure the journey is quite for me. Mark Twain has a great quote about books. He says a classic is a book which everyone wants to have read, but nobody wants to read. And I think that kind of organizational maturity and the scale of both the org and the tech supporting it or the product that's leading it, it's a far cry between knowing that you should have that, wanting to have it, and actually doing it.

And so, if anything, the last three years, the difficulties have been, and I'm not by any means framing my founders as difficult. People love them and they're great, but it is difficult to try to take what has worked and how people have worked and transition it into something that is more sustainable, more replicable, and ultimately scalable. And again, that's across at least those three legs of the stool of the organization. Organizational culture, the kind of process and procedure for the organization. Getting people hired in pipelines, managing people. It's kind of awkward when it's small, but you got to lean into what the next stage is. And then of course, the tech itself.

And there's so much to do and so much spaghetti. Where do you even start? So certainly a problem. But one of my favorite quotes you'll, you'll see I'm a quota file is by philosopher David Deutsch, father of quantum physics. And he says problems are inevitable, but problems are soluble. And so there's a great hope on as you solve those, what you're doing is really ratcheting up to the next level and getting new problems that are better problems and solve them one day at a time.

Matt

I feel that the people who are working enterprise, they want to move into the startup world. And people working in startups, they want to move sometimes in enterprises, so the grass is always greener on the other side.

But you experience that, right? So you move from bigger organization into the startup world, into the chaos. And I'm just wondering, what advice would you give to other leaders who are making Like a similar journey, like, is there something that they need to be aware of or how they should prepare themselves.

John Blythe

I started with a very small. My career began as writing the first line of code for a startup prototype and then end up getting hired as the first hire there to build it out, and did that for seven, eight years before jumping to the larger organization, before jumping back to the smaller organization. So I've done the dance a couple of times in both directions and you know, as you said, everybody wants the other. And the advice I would give is really to count the cost because there's no free lunch. It will cost you your sanity at one level or another. At Kairos, there was a lot of red tape that was being built in and we had a scrum of scrums, which drove me absolutely crazy that we were being that inefficient because people couldn't talk to each other, they couldn't write a good ticket or a project charter or whatever it is. We had to get an incredibly expensive meeting with all the managers, all the directors and all the product managers and directors together to every other week talk about what was in the works that others needed to know about.

And that sort of inefficiency drives me absolutely bonkers. So I was, I was losing my sanity around things like that at Kairis, but then coming to combine curiosity, the dark side of the moon, there was. I didn't have to worry about that. But then trying to make a plan, everybody agreeing and then people actually following through with it versus just the slipshod nature of scrappy startup, which the good news is you can't be scrappy. The bad news is any bad decision or lack of discipline can be kind of sold or framed as we're being scrappy. It's like, no, you're, you're just making bad choices or not doing what you said. And so that's been part of the thing that's driven me crazy on this side, is the exact opposite of the scrum of scrums.

Issue is can we have a little, you know, modest amount of discipline in what we're doing and how we're doing it and see something through. So the advice to those who want to make the jump is take your wisdom there. If the grass is always greener, take a step back, measure thrice, cut once, ensure that you really want to pay the tax that you're about to pay in whatever size organization you're about to join. Unfortunately, some of that, you know, there's variance on how bad or good it could be at Those levels of optimization, and that's all it is, is an optimization problem. Different orgs have to optimize for different things naturally. But how variable, what are the error bars on those optimizations is the real thing that will get you and that's hard to suss out. You can have a conversation with a founder.

I did that with my CEO and founder because I didn't want to repeat some of the pains from my first small startup making sure that some of the things that were painful whenever I left there weren't repeated here. And so I tried to vet some of those things and so far so good. But there are other things I didn't know to vet. And so what, whether it be listening to podcasts like this or finding other resources online to help you know what to think through before you get there instead of just being an unknown unknown and then you're a few months in or a couple years in and you're saying oh shit, this is not what I expected. Just definitely dive in and make sure that the rose tinted glasses have been taken off. Because every job is going to have its problems, right? So it's a matter of what can you live with and what are you optimizing for and can that coexist with what the organization is optimizing for?

Matt

I feel that we live in a really weird times and the last two years, I would describe like one keyword for the big tech lasting years. It's like the, I would say optimization, productivity, that kind of stuff, especially for the engineering product teams. So there are less budgets, you need to be more full stack, have more responsibilities, smaller teams, the backlogs are piling up but still you need to deliver. And last time when we talked you were describing me that your team is pretty much full stack. They have many responsibilities and this is your approach to do it like could you elaborate on that?

John Blythe

Yeah, definitely. You're exactly right. We have to kind of optimize for everything which is difficult and painful and you know, spoiler alert, not truly possible. Something has to give again, there's no free lunch and the team has variation amongst them. Where at the. What's a good analogy? Like if you, if you watch the flight pattern of any bee, you won't have a clue what's going on.

But that's not to say you can't see the swarm kind of go still in a. That we've got. You may say, you may think that oh it's. They're really focused on this and this is a tight bound of their capabilities. But there's the broader team that is actually covering the full stack nature of things without it being discrete silos of here's our front end team, here's our back end team, here's our infrastructure team, here's our platform team, any of that kind of subdivision. So we have people that are strong in certain areas and others who are capable but weaker. And the real optimization problem for me as their manager is I am a steward of the resources that they represent to the company and make sure the company is getting a good return on the investment being made with paycheck.

But I'm also a partner in stewarding their own career. Not because they aren't adults who can actually do this on their own, but you know, whenever you join a place, you need to make sure that you have a good partner with you, with your manager, with your whoever you are reporting to because you've got again, optimization. I wasn't intending to be a dead horse with that word today, but here we are that there's a career path you want, you want to learn, you want to grow, you want to become a full stack engineer or you want to go to a big fang company and you want to optimize your skill sets, your unique giftings and interests towards a certain goal. Could be compensation, it could be stack, it could be whatever. It's likely, you know, a hodgepodge of things and so trying to balance and counterbalance. We need X done and so and so is best at that and can get it done in two days versus the other person taking a week and there being more potential problems with it during QA or post release. Can we afford that right now given the swarm of everything else going on?

Because it may be better for that second person to do it so that they can grow. They need that, they need the at bats, they need the reps in order to get better at this thing that they have highlighted that they want to get better at. Or based off the career ladders that we have, that we have highlighted together and agreed upon is the thing for this year to really try to work on another element of that for me, and there's obviously disagreement on this across the board with people is do you work really hard to get better things that you suck at or do you work really hard to use your highest point of leverage and protect the downside? Which is more of my bent if I had to choose one. I do try to help people level up and you know, starts with me my own progress and opportunities for growth is what's really bad that I Can without too much effort make decently better. But then beyond that point, I'm not going to try to get my worst qualities to be as good as my best qualities. I think that that's a fool's errand.

Versus protect the downside. You know, Peter Drucker management OG talks about with him and Warren Buffett, it's not that we are particularly brighter than anybody else. We just tried to not be as stupid as anybody else and make less mistakes, you know. And so protecting that downside to where you can't have a devastating effect of your, your weaknesses or your faults or your opportunities for growth is much more important than ratcheting them up. So anyway, that's slight discourses there but trying to figure out what to work on is a mix of what does the company need, what do the engineers need and how do we make those over, you know, some period of time and in the aggregate balance out. They won't always be balanced. Sometimes they'll be like this, sometimes it'd be like this.

But over the long haul, how do we make sure everybody's moving forward without. This is an academia, this isn't just for the to come play. And we have a company that is the sandbox for their, their own improvements necessarily. But it's also not just task mastering where you need to do this and the company dictates it and we don't care about your growth. It's finding a nice little threading of the needle there.

Matt

And with such a, let's say diverse team like the full stack team and the team is not really, not really big. I'm just wondering how, how do you set up the priorities? How do you decide and when do you decide what to build? Because you have for sure you have some legacy application, you need to rebuild the stuff, you have some tech depth, you have new features to deliver and the business is pushing. I know how it is. And especially with a small team, there are so many, you know, priorities. What is your approach here?

John Blythe

For the most part we don't have a big go to market kind of push from sales or anything like that. We were in this weird blend of approaching consumer E Comm basically as a sassy company. So it's a little bit of a stretch, but it's also not untrue. We are sort of B2B with our own internal marketing and support teams. And then to see on the other end of their work is the direct to consumer purchase of a premium aspirational learning product like piano lessons or painting courses. And so the campaigns Are the campaigns that's going to just kind of roll ebb and flow throughout the year. There are times like Black Friday where we definitely have a.

An inflection of investment and support that we have to provide for our marketing counterparts. But there's.

There's not like this big Q3. We want to release such and such product so that we can capture some new corner of the market or sell us as a grandiose idea or whatever the case is. So we don't have those kind of pressures for two. But we do nevertheless have a. I think it was Shopify.

I may be wrong about that. But like this pendulum approach where the constant debate of tech debt versus new features kind of paradigm and there was a lot of legacy stuff that would bite us in the ass consistently and that are misdirections. And when we already have so much ground to cover, you can't really afford to have extra layers of heuristics that you can mess up, that you can forget that can be buried in some documentation that one of the original team members knows but nobody else does. Like trying to smoke those out and get rid of those. Was that that organizational tech debt more so than we built something new and you know, as soon as you launch anything, it becomes in its own way a part of tech debt because you have to carry it. Right. Question is, is it good debt?

And so that was always. It took us a couple years, but last year that was even one of our themes was the year of the ax where we would take the ax to different integrations because that was our spaghetti code, duct tape bubblegum approach was proving out this business initially was just tons of integrations. All these third parties and getting them to talk to one another is you have to do all sorts of gymnastics and hoop jumping to get good data flow across them. And then because we are doing quick stream analytics, having first party cookies, all these different things are very advantageous for us that we lose whenever we're on some third party server showing a webinar, for instance. So we lose some of the juice that we could have for decision making, for feeding the Facebook marketing engine with ads, all those things. So getting everything into into our world so far as we could, lowered cost, lowered complexity, it required building.

But one of my. I hope it's okay to cuss on this because I have been. But one of my little mantras is if you're gonna eat a sandwich, eat your own shit sandwich. Be the one who makes it. And so if we're dealing with fires, we're dealing with issues, don't, don't have it beyond Google's Tag Manager with their terrible documentation. Build your own. And obviously that's, it's not as simple as, hey, just build everything.

Obviously we couldn't do that. There wasn't a magic wand. But progressively we did build a lot of our own stack strategically and purposefully. And every time we did, it was a painful transition because in the midst of transitioning, there's gaps and things that you miss for that transitional period. But once we were on our own stack with any of those kind of elements, it got so much easier. So much. You had one place to look for issues, you had one place to look for improvements.

You had one piece of code that everybody knew is in our repo. It's not out there floating around in GTM or wherever it is. So at this point I've forgotten the question, frankly. But how we chose was at times related to maybe the ebb and flow of the marketing campaigns. But for the most part it's what's the biggest pain that gives us the highest leverage moving forward. And sometimes there's small things, sometimes there's big things. But that kind of incremental improvement across those legacy stacks has compounded and become a big game changer for us in lots of ways.

Matt

So you did like some not popular decisions, like last time when we talked, you said that you build your own version of a stripe for the usage of the company, which is not a typical approach, I would say, because usually you take the solution out of the shell, especially for the payment. But maybe like I, I think you gave a lot of reasoning behind it, like how do you approach it? How do you, you know, why do you do those kind of things? But maybe you wanted to add something around it because this is interesting.

John Blythe

Yeah, sure. I'll give two examples. One is stripe. And we did not rebuild the payment processing part. Like, they are good at that. They are dealing with banks and localities and all that. We don't want to mess with that.

But we, you know, we only need 5% of what stripe provides. So when people swipe their card, we don't need stripe to create an invoice. We can do that and avoid a half percent invoice charge. Stripe does not provide installment plans. And we roll our own installment plans. Because when you use a firm or some of these others, they don't do a credit check, but they take you to another page. They make you think they're going to do a credit check.

They spook people. We saw conversions dip when we Tried to use those out of the box. Plus you're losing some percentage of your your own sales. So we did the math and carrying our own installment plans despite the bad debt that we would incur was still a lift over, you know, year over year with our revenue and contribution margin. So from the organizational standpoint, we rolled our own there. So then on the tech level, we rolled our own. We had previously used Stripes subscriptions to do the monthly charge.

But then we have to do these again. Gymnastics for sussing out. Okay, has it been the 10 months that that the payment plan was supposed to be because we need to cancel it if so. Or it's been 10 months, but maybe they had month five the charge that it runs so they haven't actually paid 10 times. So we have to check on. So you have to do all these like bolted on things to force the subscriptions service from Stripe to work as your payment plans. And you're paying a fee and each one of those is an invoice, you're paying another fee.

So rebuilding the 5% of stripe that, well, using the 5% stripe that we need and rebuilding the rest ourselves for payment plans, for invoicing for all that saves us about 100,000 a year. And because of our, our the way that we are playing the game of portfolio building with different brands in the market, that savings grows with each new brand that we bring on. Another one is Google Tag Manager where for each brand if there's something happening with event based throwing on the client side whenever somebody goes to register for a webinar or checkout, we need that data to go back to our Facebook ads to help find more people like that that is critical to our success getting the data to the ads networks. If Google Tag Manager is installed per brand that we have, then something goes wrong for let's say brand A but not brand B. You go suss out in Google Tag Manager.

Okay, this is the checkout tag. What could have gone wrong?

Let me fix it. Well, the naming of brand B's checkout tag maybe is slightly different, the code slightly different. There's drift. And so now you're not sure. Has that error not shown up? But it will. Is there something here that I need to fix?

And you do that times in versus. All right, here's our Tag Manager.

It's our code. We inject it into our landing pages ourselves and it cuts across the brands because it's dynamically pulling in the brand specific stuff since we're right there in our own stack means that we fix it in one place. If it goes wrong, we have one place to look whenever we want to improve it. There's no chance of doing brands A through F and then forgetting to do G. Like it's one thing. And so that kind of simplification matters a lot. It's ultimately Occam's razor, right, that the less assumptions you have, the more likely it is the right solution.

And whenever you have one assumption, you can replicate that across a billion entities and it still be just as simple because it's one assumption versus five assumptions. Five entities seems like it's less complex because it's five versus a billion. That's just not the case. Now you have five discrete mental paths to think through and work through. So those are two really rich examples for us that just have cut a literal cost down, but then again, heuristically and just mental models. So simplifying and much more manageable.

Matt

Who is your partner in crime on a leadership level, with whom do you have the most of the calls to discuss the business and life goals that shifts?

John Blythe

The CEO and I are really close. We were partners in crime for a portion of the time here, and we're still close as friends. That ebb and flows based off of just life and life within the business and personal lives. And then the COO has been my other partner in crime and is kind of the current flavor of more of a partner in crime because he's running both support and marketing at this point. And so very practically, we have to coordinate what we're doing, how we're doing it, getting the two teams in lockstep to where engineers aren't just throwing code over the fence and saying, hey, we released it. Good luck with the new checkout experience or this or that. And then marketing doesn't implement it in the world for six months or six weeks or whatever it is.

Like it's not complete when it's code complete. It's complete when it's out there used by people sending the right events, helping us actually, even if it's lowering our percentage rate of conversions, at least now we, we know something and we can change something, but until there's some sort of movement in our numbers based off of what gets released, it's not done for us.

So Cameron is his name. So Cameron and I work really closely with the team coordination, the project management, all that.

Matt

As a technology leader. And I mean, like, I'm always trying to look for the lessons learned from my guests. Right. And in your case, do you recall, like the most important lesson learned that you have learned throughout your career, either at the current company or a previous company, that you had this, you know, aha moment and you say, like, okay, now I get it now I do it this way. Now I understand why we are doing it this way.

John Blythe

I have an answer to the first part, but then the do it this way part maybe makes a bad answer. We'll see. I think it really comes down to something I said at the beginning, and it probably came out in the beginning because it's been another. I've had the epiphany again at this point. Sometimes you learn the lesson, and sometimes you learn that you didn't learn the lesson fully the first time and you have it again. And the one for me right now that I'm really mulling over is what I talked about with Grasp being greener. The best way to protect against that and a slew of other problems is to know who you are, play the game that you're good at.

That your distinct unique blend of interests, experiences, ideas, thoughts, personality traits, all that contribute to. There really is only one of me in the world. There's only one mat in the world, and there's something there to leverage. The question is, what? But so many times people play games that they've seen other people play or that they hear people are playing, and that seemed like it's really fun to play. But that's even been one of my current advocacies towards playing founders recently is I think we're playing a game that my founders aren't the best suited to play. And there's.

We're close to what they're really good at playing. And some of what we're doing is what they're particularly gifted for and towards. But there's some level of it where we're playing it because it seemed like a good idea. And there's just, you know, swinging a bat out of basketball is never going to have the same outcome as a baseball. You got to. You got to be playing the right game with the right tools, and otherwise. I forget who said this.

I think Naval Ravikant is where I got it from. Play stupid games, win stupid prizes. And so if you're playing somebody else's game, you're not going to get what you want anyway. So it's kind of in vogue now to talk about, take time for yourself, be mindful all those journal some, do some reflection, but it's true. You got to figure out who you are and who you want to be and line up the right work for that. Find the right organization for that. It's not going to be, you know, just one day's epiphany of journaling and then you find the right fit.

But you won't know what to swing at if you don't take the time to actually see it. And it'll take some time to get there. But that's been my big epiphany for a second time is am I going to play the right game or am I going to try to, you know, be Sisyphus and roll the boulder up the hill constantly every single day? That's. That's the way to live.

Matt

I think I understand it really well and I was in that position and I think like each co founder is at some point in that position. But you need to learn first to put the ego inside your pocket and be bluntly honest about it that hey, I cannot do it. I'm not the best at doing it and sharing it with your team and you know, them hiding it like focusing on highlighting your real strengths. So I think it takes some time and changing the mindset, but it's really, really helpful. So I think it's a great lesson that you mentioned, John. And the last question that I have and I ask all of my guests, are there any books, maybe conferences or resources that have been particularly helpful to you as a leader to have this aha moment to understand some kind of concepts that you could recommend to other people?

John Blythe

Oh sure. As I've already hinted, I'm a walking set of quotes and I love books. I love reading. My answer to this is we'll see if it's somewhat off the beaten path, but it's not typically engineering or managerial type books. My go to is Meditations by Marcus aurelius.

So Stoicism 101. The Tao of Seneca.

Great Audible book. I don't know if there's a printed format. There may be, but just letter after letter of Seneca that help you set yourself up for success as a person. Laws of Human Nature by Robert Green and just a lens into the different personalities and types of people that you'll deal with in your career and in your personal life. On managing oneself, which again, if you can't manage yourself, you can't manage others. More industry focused stuff would be Michael Wapp's books. Random Repose Guy, if you're familiar with him.

An elegant puzzle by Will Larson I think is his name. Former stripe, maybe Uber as well. Forget where he's at now. Five Dysfunctions of a Team Classic. Not entirely accurate or all encompassing, but helpful tool in the toolkit. I love, you know, pop psych, pop sociology stuff just to at the end of the day, leading an engineering team, that that's the ultimate engineering problem. It's not the, the tech itself, people are squishy and difficult and variable and surprising.

The tech is going to do what the tech is going to do. People. Big question mark. So personally, the, the things that are most impactful for me are in terms of getting that kind of center point for myself and an understanding of human nature more generally and broadly. So I could be the best people manager I can be because I trust that, you know, we're. So long as we hire decent, hard, skilled people, it's going to work itself out with proper decisions. But making sure that you have the right people, making sure that you know how to navigate those people is the ever pressing question.

Matt

Thank you for that. I'll surprise you. But like a lot of my guests mentioned stoics, a lot of, I guess mentioned books that are outside of our tech bubble. And I think, I absolutely agree with that. You can get some learnings that are, you know, a bit outside of the box and it's all about people, especially on the leadership side. So I think it makes a lot of sense. John, thank you for the conversation today. Thank you for a great insightful talk.

I really appreciate that. It was a pleasure to talk to you today.

John Blythe

Yeah, likewise. Thanks for setting this up. All right, see you, Matt.

Matt

Follow Matt and Leshek on LinkedIn.

John Blythe

Sa.

‍