InfoQ HomepagePodcastsFounders, Friction, and Focus: Building Engineering Teams at Early-Stage Startups
Culture & Methods
Online InfoQ Engineering Leadership Certification (Sep 18): Lead strategy, systems, and teams.
Founders, Friction, and Focus: Building Engineering Teams at Early-Stage Startups
In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to David Gudeman about the unique culture of early-stage startup engineering, how founder personality quirks and premature process impositions can derail teams, and how engineers can build influence and make deliberate career choices without formal power.
Key Takeaways
- Early-stage startup culture is disproportionately shaped by founders’ personality quirks, which can balloon into major organizational issues.
- Hiring overly junior engineers too early, without enough experienced guidance, leads to costly architectural and technical mistakes.
- Engineers gain real influence by cultivating long-term relationships with stakeholders and staying engaged with product and customer-facing conversations, not just technical debates.
- Miscommunicating a technical decision — such as announcing “we’re not doing React” instead of explaining a course correction — can demoralize a team and drive away top talent.
- Career choices between big companies, growth-stage startups, and early-stage startups should be driven by what someone wants out of their career and life, not just financial upside.
Transcript
Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with David Gudeman. My little starting point for these conversations is who’s David?
Introductions [01:10]
David Gudeman: 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, 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, Tappity had gone through Y Combinator. I worked there for about a year. Went to another startup called Triumph Arcade and I was a kind of engineering lead there, led their backend 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 Commons, 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.
Shane Hastie: So what’s special about working in that early stage startup space?
The Double-Edged Sword of Early-Stage Startups [02:18]
David Gudeman: 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. 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. You have to figure things out and oftentimes you’re making decisions under limited resources, limited time, not ideal conditions. So I guess I love the thrill, I suppose.
Shane Hastie: Given that experience and working in multiple of those companies, what are the gotchas? What are the things to be aware of?
How Founder Personalities Shape Organizations [03:04]
David Gudeman: 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 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.
So one of the things that I often seen when people 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, this person does this”, and that defines their experience 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 maybe not as talked about and understood maybe.
Shane Hastie: What’s it take to grow a well-crafted engineering team from nothing?
Growing a Well-Crafted Engineering Team From Nothing [04:37]
David Gudeman: Well, it depends on the conditions. 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 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 being a little penny wise, pound foolish at the very beginning. 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 suboptimal or unforced errors that maybe a more experienced individual who might be more expensive might avoid and then set up things correctly.
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. They just view it sometimes, unfortunately, they view it as a cost center as opposed to an investment. So 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 have to take a philosophical approach in building a good engineering team.
Shane Hastie: In your experience, what’s made a team great?
What Makes a Team Great [06:21]
David Gudeman: 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, at 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 breakdown. And when you have alignment, you have trust, then you can 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 a situation.
And I’ve seen it go in the other direction. I’ve seen it where it’s like the trust becomes so lost where you have JIRA burndown charts and it’s like you’re going over every ticket and then they become litigating the language in the ticket and it just becomes like a grudge match. To me, that’s the opposite. It’s like there’s a lot of slack in engineering, but they’ve given up, so to speak. They’re just 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, if you’re at that level, you really lost something important that’s supposed to be a competitive advantage to allow you to move quickly and adapt quickly.
Shane Hastie: One of the things about startup teams as they grow of course is they grow, they change. The fluidity of the team’s team formation, people come and go. But also, those that stay are working within larger and larger communities. How do we create an environment where that sort of growing and re-teaming is done well?
Navigating Team Growth and Re-Teaming [08:35]
David Gudeman: Yeah, that’s a tough one because I have really only seen that once where the team really grew beyond the initial core team and it did become unwieldy. 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 at Actium grew, we added more and more engineers and there was tribes, so to speak. There were data people that had a different stack, had a different cadence, the way they interacted with customer success. And then there was some product which had answered to the product team. So, each of those teams kind of grew, but they were heavily dependent on each other in many respects.
The Danger of Predictability over Progress [09:35]
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 we are 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 we’re working towards this.
After the top-down imposition of this scrum process, the predictability became “better”, but the velocity was destroyed. So in some sense, yeah, 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 look back on it, things were being shipped more. Sometimes it’d have 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. 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. 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. We’re delivering product that has no bugs. It was delivered exactly the date that we specified, but we are ultimately not discovering product market fit quickly”. And I’m like, “This entire enterprise depends on that”. 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, let’s push back on a lot of these requirements. Let’s really talk to sales, let’s talk to leadership and to 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 taking this sort of scrum, JIRA-led 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 your junior, I would say. But as someone who’s went on and did many more startups, I look back on that and I’m like, “Yeah, that wasn’t right. That was the wrong move”.
Shane Hastie: What’s just enough process though?
Finding the Right Amount of Process [12:41]
David Gudeman: 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 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 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. 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, “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 choose a couple key bets and then focus 100% on that.
I don’t know. That’s what I probably would’ve done, given the experiences I had afterwards and now that I’m a little bit more experienced, but I can’t really replay history.
Shane Hastie: Useful stories though and I 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?
Influencing Without Positional Power [15:18]
David Gudeman: Oh, man, that’s very difficult. I think the most effective way, I’m not saying that there is a perfect solution to this. Again, you want to cultivate relationships with the important stakeholders and that is a long-term process. 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. If you talk to people, let’s say, and again, this comes down to culture. If you can have an open communication with people that are interfacing directly with the customers, you don’t have to be on calls, 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 you might know is 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, 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 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 don’t really know why they’re making these trade-offs. 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 a visionary type or something like that, but they definitely need to be open to real-world feedback and constraints. That’s kind of a messy negotiation a lot of times, but that’s where I’ve seen it work the best. 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.
Shane Hastie: Who’s the court jester? Who gets to speak truth to power?
Who Speaks Truth to Power? [18:14]
David Gudeman: 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. Sometimes it’d be quite unpleasant. But I have found that in organizations that are truly focused on trying to succeed, they’ll begrudgingly admit what you said, “Okay, fine”, something to that effect.
Engineers can be, but again, where I’ve seen it not work 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…
The “We’re Not Doing React” Communication Failure [19:30]
I’ll give you an example. At the first company, the tech stack was a really antiquated tech stack even when it was first started, unfortunately picked kind of a weird technological choices. And this was during the time where React was really blowing up. And in order to recruit high-quality talent, there’s only a couple levers you can pull. Salary, like in a rocket ship, then you can do equity. And then if you don’t have those, well, you got to be competitive on tech stack and dev quality of life. If you don’t have any of those three, you’re in trouble. And most startups, for the most part, they’re poor for cash and they might not be well-known, and so the cheap thing is dev experience.
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? Only a few people know what React is. It’s a library for building UIs.
And I remember at 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. I remember watching that unfold and thinking, “Oh my God”.
So I think the best way would’ve been if I was an executive, first of all, I’m not going to say we’re not doing a specific technology. That’s a kind of insane statement. It would be more like, “We’re going to have to make a course correction because there’s other business..”. And I’ll first explain we have to focus on the things that make the company successful. 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 new features.
Once I left, I checked back. They ended up migrating to React because it’s impossible not to. The entire industry was 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. 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. So yeah, communication, know your expertise, and stay in those expertise and acknowledge when you don’t.
Shane Hastie: What’s your advice for the early, mid-career engineering professional thinking about what’s their next step? Where to go now?
Advice for Early- and Mid-Career Engineers [22:50]
David Gudeman: 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 life, optimize for that. And that would be a 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 Meta or if you’re lucky enough to work at OpenAI maybe, that would be quite exciting.
If you want to work at, you want the startup experience, but you don’t want to just be really in a rough spot, I would say post-Series B, Series C, maybe 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 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 could be lucky. You could also be unlucky, as unfortunately we’ve seen with Figma. It’s, I don’t know, pretty rough. I have friends that went to work at Figma and stock price is in the gutter. So that can also happen.
And if you are looking for something where you really want to wear all the hats and you want to try to really learn to build something from scratch, you could join a really early stage startup like Series A seed. I always caution people on that. 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 equity to be worth anything”. I really mean that. It can be someday maybe, but many times it won’t be. You’ll get zero.
So for those situations, it’s really about the experience, the people that you’ll meet, interesting characters, learning about new fields, drinking from a fire hose and just seeing 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 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.
Shane Hastie: Dave, a lot of good advice and interesting ideas here. If people want to continue the conversation, where do they find you?
David Gudeman: Oh, well, I’m not on Twitter a 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.
Shane Hastie: David, thank you very much for talking to us today.
David Gudeman: Oh, it was my pleasure. Thanks for inviting me.
About the Author
David Gudeman
More about our podcasts
You can keep up-to-date with the podcasts
Apple Podcasts,
Spotify,
Overcast
and YouTube.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio
Previous podcasts
Culture & Methods Trends 2026: The Human Side of AI Engineering
Formal Methods for Every Engineer in an AI-Powered Future
Craig McLuckie on Culture as a Team’s Operating System in the AI Era
The AI Joy Gap: Why Some Developers Thrive While Others Struggle
