Founders, Friction, and Focus: Building Engineering Teams at Early-Stage Startups

Speaker A: 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 16th through 2060 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@qconessay.com foreign. Folks. This is Shane Hasty for the InfoQ M Engineering culture podcast. Today I'm sitting down with David Guderman. My normal starting point for these conversations is who's David?

Speaker B: Well, you could say I've been a tried and true startup operator. I started my career as a very junior engineer at uh, 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 had Tapity, 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 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 years. Yeah, I've had a lot of experience at the early stage startup and uh, uh, I love it.

Speaker A: So what's special about working in that early stage startup space?

Speaker B: 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 um, love the thrill I suppose

Speaker A: given that experience and working in multiple of those companies. What are the gotchas, what are the things to be aware of?

Speaker B: 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, uh, you know, founders 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 that can thrash the team. You know, if they're excitement seeking, they can get bored when something's working, but then it's like 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, um, 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, uh, maybe.

Speaker A: What's it take to grow a well crafted engineering team from nothing?

Speaker B: 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 pennywise 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 suboptimal or 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, you know, 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 in building a good engineering team.

Speaker A: In your experience, what's made a team great?

Speaker B: 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 uh, 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. And 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 uh, don't say great quality because sometimes you have to make, you know, 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 for, 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 Jared 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 and engineering, but they've given up, so to speak. They're just kind of like putting in the 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 uh, adapt quickly. Right.

Speaker A: 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. Uh, but also those that stay are working with in larger and larger communities. How do we create an environment where that sort of growing and re teaming is done?

Speaker B: 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 sort of product which had answer to the product team. And so each 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, you know, process which I think you uh, know 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. 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 are ultimately not discovering product market fit quickly. And I'm um, 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, 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 process became the focus and ultimately the company got acquired for not a lot. Okay. I mean it was fine, you know, but um, it wasn't ultimately people wanted and um, you know, I think it wasn't great. Right. So if you're measuring that intervention on, oh, did we become more predictable? Like, sure, but is that really the goal? Like, I don't know, you know, maybe it was, you know, I was your junior, I would say. But as uh, someone who's went on and did m many more startups, I, I look back on that and I'm like, yeah, that wasn't right. That was the wrong move.

Speaker A: You know, what's just enough process there?

Speaker B: Well, that's depends on the team really, the composition of the team. It 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 don't. I, I think that uh, 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 and that needed to be addressed. I think ultimately the biggest issue, and I don't know if this uh, 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 uh, 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. Um, I'm not sure actually what happened. I end up leaving shortly after. But um, 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, uh, you, uh, know that's what I probably would have done given the experiences I had afterwards. And now that m. I'm a little bit more experienced, but um, can't really replay history, you know.

Speaker A: Useful stories though and 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?

Speaker B: Oh, uh, man, that's very difficult. I think the most effective way. I'm not saying that there is a perfect solution to this.

Speaker A: Right.

Speaker B: 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 um, 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 uh, 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 is like, hey, this doesn't really make a whole lot of sense or there's gotta be a better way to do this. You're going to have those relationships to call upon and maybe take 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 uh, 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 what, why they're making these trade offs. Right. If you can speak to the concerns of the product sales are 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 uh, 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. 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.

Speaker A: Who's the court jester, uh, who gets to speak truth to power?

Speaker B: Well again, that's very personality dependent. Right. 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. Right. 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. Um, for better or for worse, it's sometimes can 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. Uh, okay, fine, something to that effect. Right. Engineers can be. But again where I've seen it not work.

Speaker A: Right.

Speaker B: 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. Uh, the first company, the Tech stack was like a really uh, antiquated tech stack. Even when it was first started it was unfortunately picked a, uh, 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 gotta be competitive on like tech stack and kind of like dev quality of life. If you don't have any of those three, like, uh, you're in trouble. Right. And most startups for the most part, you know, they're poor for cash and they 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 end engineers quit like the next day. And uh, 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 post mortem 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 we're, 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 a kind of insane statement. Uh, it would be more like, you know, we're going to have to make a course correction because there's other business and I'll first, you know, explain. We have to, we have to focus on the things that make the company successful. Okay. 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 and delivering new 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 uh, 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.

Speaker A: What's your advice for the early mid career in engineering? Professional thinking about what's their next step, where to go now?

Speaker B: Mhm. 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, uh, 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, and also are growing. 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 could be lucky, um, you could also be unlucky. Right. As fortunately we've seen with Figma. Right. It's I don't know, pretty rough. 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, wear all 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 uh, 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, uh, 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 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.

Speaker A: David, a lot of good advice and interesting ideas here. If people want to continue the conversation, where do they find you?

Speaker B: 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, you know, and get in contact me that way.

Speaker A: David, uh, thank you very much for talking to us today.

Speaker B: It's my pleasure. Thanks for inviting me.