# Startup Engineering Culture And Founder Risk

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-08-14

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16 through 20, 60 plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pictures, just senior practitioners helping senior practitioners.
Learn more at kukonsf.com.
Good day, folks.
This is Shane Hastie for the InfoQ Engineering Culture Podcast.
Today, I'm sitting down with David Guterman.
My little starting point for these conversations is, who's David?
Well, you could say I've been a tried and true startup operator.
I started my career as a very junior engineer at a startup and kind of worked my way up at that company, Actium, and moved into product for about a year.
I was a technical product manager, so I wasn't writing code.
I did that.
for a year went back to engineering at another startup a friend of mine had tappity had gone through y combinator i worked there for about a year went to another startup called triumph arcade and i was a um kind of engineering lead there led their back end and back office sort of internal tooling and things of that nature and then i ended up starting my own company i went to south park commas which is sort of a accelerator community Started my own company, which is in conversational intelligence and sales tooling.
And I've been there for a couple of years.
Yeah, I've had a lot of experience at the early stage startup.
And I love it.
So what's special about working in that early stage startup space?
Well, it's kind of a double-edged sword, right?
I mean, you're in charge of a lot of things.
You get to wear a lot of hats.
You get to problem solve in a lot of different areas.
Which is quite intellectually stimulating and kind of exciting, right?
You're on the frontier embarking on something exciting and new, but it's also quite hard.
You don't have a lot of support, right?
You have to kind of figure things out.
And oftentimes you're making decisions under limited resources, limited time, you know, not ideal conditions.
So I guess I love the thrill, I suppose.
Given that experience and working in multiple of those companies, what are the gotchas?
What are the things to be aware of?
Well, I guess keeping in the theme of your podcast, I would say early stage startups are highly, highly dependent on the personalities of their founders.
So things that might be, you know, small personality quirks can then be ballooned.
into major organizational issues.
So if a founder is avoidant, cannot confront an existential issue for whatever reason, it can kind of fester.
If they're erratic, they can make decisions on a whim.
They can thrash the team.
If they're excitement-seeking, they can get bored when something's working, but then it's not stimulating them.
And I've seen a lot of those things.
Right.
And so one of the things that I that often seen when people kind of go into it coming from a stable corporate, they're kind of perplexed or shocked by that fact of the experience.
They'll be like, geez, you know, like this person does this and that defines their experience for like, you know, like, you know, much more so than maybe would be expected in a corporate setting.
I'm not saying that doesn't happen in a corporate setting, but it's just much more pronounced.
So I would say that's one of the kind of gotchas, so to speak, that's like maybe not as talked about and understood, maybe.
It's tight to grow a well-crafted engineering team from nothing.
Well, it depends on the conditions, right?
And that's a good word, grow, because in some sense it is like that.
It's delicate in the beginning.
And in order to build the processes and build the culture and build.
What later will be kind of an asset, wise heads must prevail early on and recognize that, you know, you need to invest in the team, make sure you hire the right people early.
And that's really one of the most critical mistakes I've seen is kind of being a little penny wise pound foolish at the very beginning.
Right.
So you hire excessively junior people too early and there's not enough guidance.
So they make a lot of decisions, architectural decisions, technical decisions that are as optimal.
unforced errors that maybe a more experienced individual who might be more expensive might avoid and then set up things correctly.
And so ideally, in order to build a functional team, you want to realize that that's an important asset, number one.
And that's not always obvious to people, right?
They just kind of view it sometimes, unfortunately, they view it as a cost center as opposed to an investment.
And so, you know, getting the right people early, Letting those people make a lot of important decisions in developing the team, checking in, making sure that things are working well.
And when things are working well, double down on those.
And when things are not working well, being quick to course correct.
I know it's kind of short on details, but a lot of times you kind of have to take a philosophical approach when building a good engineering team.
In your experience, what's made a team great?
I guess when the team is working correctly and working well, there is alignment along every level about what we're trying to accomplish.
And ideally, early stage companies, you don't have to have a lot of process to achieve that.
You want some process, but you don't want too much.
You want to have people, there needs to be trust along every level.
And I've seen that break down.
When you have alignment, you have trust, then you can kind of deliver things quickly, which is really critical.
The right amount of quality, I don't say great quality because sometimes you have to make trade-offs.
So the appropriate amount of quality, which is negotiated amongst all the stakeholders and then delivered on time with all the requirements met and not necessarily having to write a ton down, writing everything down that's necessary to keep.
the institutional knowledge permanent, but not as a measuring stick that will have an adversarial type of situation, right?
And I've seen it go in the other direction, right?
I've seen it where it's like the trust becomes so lost where you have like JARRA burndown charts and it's like you're going over every ticket and then, you know, they become litigating the language in the ticket and it just becomes like a grudge match, right?
To me, that's the opposite, right?
It's like, you know, there's a lot of slack in engineering, but...
they've given up, so to speak.
They're just kind of like putting in their work.
And unfortunately, I think that's a culture that makes sense at scale when you have 10,000 engineers.
But early on, when you're at a startup, you cannot, if you're at that level, like you really lost something important.
That's like kind of supposed to be a competitive advantage to allow you to move quickly and adapt quickly, right?
One of the things about startup teams as they grow, of course, is...
They grow, they change.
The fluidity of the teams, team formation, people come and go, but also those that stay are working in larger and larger communities.
How do we create an environment where that sort of growing and reteaming is done well?
Yeah, that's a tough one because I have really only seen that once where the team really grew beyond.
kind of the initial core team, and it did become unwieldy, right?
And the approach that I saw to try to manage it, I think ultimately was not necessarily the correct approach or it was done overzealously.
So I can speak to that experience and what I think should have been done, so to speak.
As the team and Actium kind of grew, We added more and more engineers and there was kind of like tribes, so to speak.
There was like data people that were, had a different stack, had a different cadence, the way they interacted with like customer success.
And then there was kind of like some sort of product, which had to answer to the product team.
And so you kind of, the age of those teams kind of grew, but they were heavily dependent on each other in many respects.
What ended up happening was.
We ended up hiring somebody that came from a much bigger company and they brought a very scrum agile process, which I think there's a reason why it's popular because it probably does work under certain circumstances.
And prior to that, there was kind of an understanding like we're all trying to get to this goal.
We're all trying to deliver this type of experience, this type of product.
And that was, I thought, critical.
That was kind of important.
that everybody understood that like we're working towards this.
After the top-down imposition of this scrum process, the predictability became quote-unquote better, but the velocity was destroyed.
So in some sense, yeah, like prior to this scrum process, it was a little bit more chaotic.
It was quite a bit more unpredictable.
But in the end, when I kind of look back on it, things were being shipped more.
Sometimes it had a little bit more bugs, but the actual product would get into the hands of the user much more quickly.
Again, I go back to a lot of my experiences at these startups.
A lot of things that you build aren't the right thing.
And so you need to really test a lot of these features, product ideas quickly and either disqualify them, throw them or tweak them or whatever, right?
They're kind of, you need to evolve them.
And that is the critical feedback loop.
It determines whether or not the startup as a whole is going to succeed.
And when I saw that time to do that, like double, and I'm like, okay, sure.
Like, you know, we're delivering product that has no bugs.
It was delivered exactly the date that we specified, but we're ultimately not discovering product market fit quickly.
And I'm like, this entire enterprise depends on that.
Right.
And so.
That to me was a major miscalculation.
I don't know what the right answer is exactly.
I think there should have been maybe more discipline.
Hey, like, let's push back on a lot of these requirements.
Let's really talk to sales.
Let's talk to leadership and figure out what do we really think is going to get us.
And let's just focus on that as opposed to engineering being completely disconnected and just sort of taking this sort of scrum kind of JIRA led.
The process became the focus.
And ultimately, the company got acquired for not a lot.
I mean, it was fine, but it wasn't ultimately what people wanted.
And I think it wasn't great.
So if you're measuring that intervention on, oh, did we become more predictable?
Sure.
But is that really the goal?
I don't know.
Maybe it was.
I was too junior.
I would say, but as someone who's went on and did many more startups, I look back on that.
I'm like, yeah, that wasn't right.
That was the wrong move.
What's just enough process there?
Well, that depends on the team, really.
The composition of the team really determines the process.
And that's what I think philosophically I disagreed with the approach taken there.
The idea was that this is a process.
It just works.
And I'm like.
I don't agree with that.
I think that you want to do a survey what you have and you want to identify, you know, kind of the strengths that you have and you want to minimize the weaknesses with process.
So if there's things that are working well, don't really touch it.
Leave it alone.
You know, you want a targeted approach, especially early on when you're making pretty serious changes.
So in the case of that company.
There were problems that needed to be addressed.
I think ultimately the biggest issue, and I don't know if this was fixable, but unfortunately there was a lot of thrash at the very top.
And at the other companies I worked at, this problem didn't really emerge, right?
And maybe it was an unfixable problem.
I don't know.
But I think the primary should have been less about...
getting predictability of engineering and more communicating the cost of constantly switching and being like, you're going to burn all the runway.
And I actually tried to communicate this at one point because at that point I was a technical PM and I tried to communicate more or less to the higher ups.
Like, you know, if you keep promising this new type of integration, when we have two or three already and you add a new vertical, you burn enormous amounts of resources for unclear.
advantage in the market.
I thought that was my place as a PM.
Ultimately, the advice fell on deaf ears, I think.
I'm not sure actually what happened.
I ended up leaving shortly after.
But that was the primary critical intervention that I think engineering should have done, was to really try to communicate the cost on the organization.
on the thrash and help leadership try to reduce the amount of crash and get them to kind of choose a couple key bets and then like focus 100% on that.
I don't know.
You know, that's what I probably would have done given the experiences I had afterwards.
And now that I'm a little bit more experienced, but you can't really replay history, you know.
Useful stories though.
Oh yeah.
Hope that our listeners are taking from that some solid advice.
You made the point.
It fell on deaf ears.
As an engineer in an organization, how do I influence without power?
Oh, man, that's very difficult.
I think the most effective way, I'm not saying that there is a perfect solution to this, right?
Again, you want to cultivate relationships with the important stakeholders.
And that is a long-term process.
You cannot come, like when you know something bad is.
You're getting told something bad.
If you haven't developed a relationship with the stakeholders and provided them evidence why they should invest in your opinion, when that moment comes, you've kind of already lost, so to speak.
I think the best way to do that is to stay engaged.
And this is oftentimes what I see with technical people who they don't show an interest in product as much as they should, right?
If you talk to big people, let's say, and again, this comes down to culture.
If you can have an open...
communication like with people that are interfacing directly with the customers you know you don't have to be on calls you don't have to but you can show an interest from the perspective of the people that are directly facing the customers what are they hearing what's useful then when something comes down that like you might know It's like, hey, this doesn't really make a whole lot of sense or there's got to be a better way to do this.
You're going to have those relationships to call upon and maybe to illustrate the stories that you've heard.
You'd be like, well, you know, I heard that they're using it in this way and that they were getting a lot of value from it.
Is that true?
And right.
And when you bring those types of stories to the conversation and you show engagement and interest in the product, you're much more likely to be heard as opposed to being kind of like, especially if you come in and you're kind of.
don't really know why they're making these trade-offs, right?
If you can speak to the concerns of the product sales or customer success, and you can identify with their struggles and then provide maybe an alternative solution, you're much more likely to be persuasive.
Again, that's part of the reason why I moved into product was because I was being inundated with so many things that I thought were misguided.
And I saw that product really was...
The place to influence those types of decisions.
Ultimately, product was unfortunately not really prioritized in that organization.
It was more of an order taker instead of trying to be engaged in driving the strategy and the vision.
The best types of companies, you might have kind of like a visionary type or something like that, but they definitely need to be open to real world feedback and constraints.
You know, that's kind of a messy negotiation a lot of times, but that's where I've seen it work the best.
And so just going back to your original question, showing an interest in what's going on in the business side and learning why people are thinking the way they think, you're much more likely to be heard.
Who's the court jester who gets to speak truth to power?
Well, again, that's very personality dependent.
You might have people who, in public forums, really cannot tolerate negative feedback or even resistance to their ideas.
But then one-on-one, they might be open to it.
Sometimes when something's floated in a public setting and it doesn't feel pointed at any individual person, then it can be absorbed by the group and then it can be socialized amongst the peers of, let's say, the decision makers.
I have often been that individual, for better or for worse.
It's sometimes to be quite unpleasant, but I have found that, yeah, in organizations that are truly focused on trying to succeed, they'll begrudgingly admit what you said.
Okay, fine, you know, something to that effect, right?
Engineers can be, but again, where I've seen it not work right is if they get lost in the technical implementation.
You cannot speak in that language and expect it to be, if it's going to be consumed, it'll be consumed in a confusing way.
They'll get hyper-focused.
And sometimes I've seen it where like, I'll give you an example.
The first company, the tech stack was like a really antiquated tech stack.
Even when it was first started, it was unfortunately picked a kind of a weird technological choices.
And this was during the time where kind of React was really blowing up.
Okay.
And in order to recruit high quality talent, there's only a couple levers you can pull, right?
Salary, you know, like in a rocket ship, like then you can do equity.
And then if you don't have those, well, you got to be competitive on like tech stack and kind of like dev quality of life.
If you don't have any of those three, like you're in trouble, right?
And most startups, for the most part, you know, they're.
poor for cash and there might not be well known.
And so the cheap thing is dev experience.
And so at one point we were trying to migrate to React and that became kind of a talking point, so to speak.
And at some point everybody knew the word React.
And then it became...
But then nobody knows what that is.
You know what I mean?
Like only a few people know what React is.
It's a library for building UIs, right?
And I remember one point there was a decision to pause on this major rewrite.
But the way it was communicated because of the confusion was we're not doing React.
Well, one of the quality front engineers quit like the next day.
And I was thinking, first of all, it wasn't true.
We were going to do React.
And so he communicated this.
insanely bad error, unforced error, caused one of the top engineers to quit.
I'm not sure if there was even a postmortem on that, right?
I remember watching that unfold and thinking, oh my God, you know?
And so I think the best way would have been like, you know, if I was an executive, first of all, I'm not going to say we're not doing a specific technology.
That's kind of an insane statement.
It would be more like, You know, we're going to have to make a course correction because there's other business.
And I would first, you know, explain we have to we have to focus on the things that can make the company successful.
OK, and because of that, we're going to have to refocus our energy.
We can't do this major rewrite.
We have to focus our energy on delivering your features.
Once I left, I checked back.
They ended up migrating to React because it's impossible not to.
The entire industry is moving to React.
So that was going to happen regardless.
But it had an extremely demoralizing effect on the team.
And it was just ultimately not true.
So I think communication, you got to know your lane, so to speak, in some areas, right?
And when you don't, if it overlaps, you have to recognize what parts you don't really understand and acknowledge that and say, hey, I'm not sure what's going to happen in this area, but I know this part we got to focus on X, Y, Z, whatever, right?
So yeah, communication.
Know your expertise and stay in those expertise and acknowledge when you don't, right?
What's your advice for the early mid-career engineering professional thinking about what's their next step?
Where to go now?
Well, sometimes I talk to people and I tell them, where do you derive personal and spiritual satisfaction from?
Just really think about that.
If you want to make money, which is fine, there's always a place for that.
And you want stability and you want maybe more structure and you want to focus on your personal, you know, like, you know, optimize for that.
And that would be kind of like big company.
Right.
And then at that point, I would try to work at one of the bigger companies that pay well and have a lot of structure and also are growing.
And that could be like meta or, you know, if you're lucky enough to work at OpenAI, maybe, you know, that would be quite exciting.
If you want to.
work at kind of you want at the startup experience but you don't want to just like be really in a rough spot i would say you know kind of post series b series c maybe like pre-ipo but it's on the roadmap because that point it's usually they have product market fit the roadmap is kind of clear the priorities are clear they're building organization you get to be kind of build up that organization.
Usually the compensation is okay.
And there's also a little bit of a lottery ticket element to it, which is kind of fun.
You know, you can be lucky.
You can also be unlucky, right?
As unfortunately we've seen with Figma, right?
It's, I don't know, pretty rough.
I have friends that went to work at Figma and stock prices in the gutter, right?
So that can also happen.
And if you are looking for something where you really want to be aware of the hats and you want to try to really learn to build something from scratch, you could join like a really early stage startup, like, you know, Series A seed.
You know, I always caution people on that.
It's a quite, it's a quite challenging environment and it's very likely to not be financially a wise decision.
That's the reality.
I always tell people, don't really expect that echo to be worth anything.
I really mean that.
Like, you know, it can be someday, maybe, but many times it won't be, you know, you'll get zero.
And so for those situations, it's really about the experience, the people that you'll meet, interesting characters, learning about new fields, like drinking from a fire hose, and just seeing like kind of how the sausage is made.
You really need to think about what are you trying to accomplish with your career move and be thoughtful and deliberate about it and recognize, you know, certain types of career moves are not necessarily about the money and you're likely to actually take a serious pay hit and financial hit.
David, a lot of good advice and interesting ideas here.
If people want to continue the conversation, where do they find you?
Oh, well, I'm not on Twitter a whole lot.
They can follow me on Twitter, I suppose.
I never tweet.
But if you'd really like to interact with me, you can just send me an email and get in contact with me that way.
David, thank you very much for talking to us today.
It was my pleasure.
Thanks for inviting me.