The Technical Founder’s Path: Code, Leadership, and Balance

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I had the privilege of sitting down with Trisha Ballakur. Trisha, welcome. Thank you for taking the time to talk to us today.

Trisha Ballakur: Thank you so much, Shane.

Shane Hastie: Now, my normal starting point on these conversations is who’s Trisha?

Introductions [01:17]

Trisha Ballakur: Sure. So I am the CEO and co-founder of Pointz. We have a safer bike mapping app that helps folks who are a little bit scared to hop on the bike. This is currently in the US, but looking to expand internationally.

Shane Hastie: And what brought you to be the co-founder?

Trisha Ballakur: So it was a really interesting journey, which started back when I was actually an undergrad. So it was 2020, prime time of COVID, and I was feeling a little bit unsure what I wanted to do with my life. I was still, at the time, sophomore in college, sent home halfway through university. And one of my friends had been sharing that she was working on a mobile app around biking. I basically contacted her. We decided to work together, and from there really grew from working and contributing as an intern, to founding engineer, to the CTO. At that point, becoming a co-founder to take it to the next level.

Shane Hastie: That’s a very accelerated path.

Trisha Ballakur: I think it’s like that in startups because the teams are so small. So at first we had about, I’d say, six, seven, eight interns. These were all sophomores, a freshmen like me just looking to see how they could get involved in projects and soon enough realized that, okay, we really do need to have some direction and worked with her to navigate that just within a couple months, honestly.

Shane Hastie: So through that rapid growth and early career software engineer, what are some of the interesting and exciting things that happened to you?

Learning without senior guidance [02:56]

Trisha Ballakur: Well, all of my internships in the past had been me contributing on a project that was already well scoped, that was already written in a language that I knew really well, be it Python or maybe JavaScript. And it was a lot that I had already worked on in school that was translated into a company setting. And so working on this, it was more of, okay, we were the ones who were coming up with the tickets because there was no such thing as a product manager in a tiny little startup. And also, we were the ones who had to go in, I like to say it, be the TAs for ourselves. There was no teaching assistant who could help us debug a problem, or there was no more experienced software engineer that could help us. It was really us and the internet.

And the more that I took on a responsibility, especially becoming a co-founder, that really landed on me with my experience at the time to just figure out how to learn at an accelerated pace and ultimately find advisors who could step in and really be that extra knowledge source because we didn’t have somebody who was more senior per se.

Shane Hastie: So a group of novices coming up with ideas, sharing them with the world, building product on the fly, it’s not quite the starting in a garage, but it is the founder story of today, isn’t it? How do you navigate from that coder to leader?

Transitioning from coder to leader [04:28]

Trisha Ballakur: I think one key point is remembering that all of my training in becoming a computer scientist both was extremely helpful to solving problems that came up at Pointz and also used to come in the way of a lot of the innovation that I had to learn taking on new leadership and especially working in a startup environment. For example, the first time I had realized that I needed to learn SWIFT, which was the iOS programming language that we used at first, I was pretty nervous because back in school when we were learning new languages, the way that we’d done it was somebody gave me about 5 to 10 projects week over week, and I slowly gained confidence in different realms using different data structures, using different types of algorithms. And of course, that wasn’t supplied very well here. It was, “Okay, we need to produce this. This is the vision that we have and get it done ASAP, figure out how to do it”.

I think school, and I would assume other projects that I did at work or at my internships, it was all laid out in a way that I didn’t need to think of taking responsibility for my learning. There was always someone who could hold my hand if I really needed it. So learning that as a coder, we have the abilities and we have the chops technically, but as a leader, you have to learn how to go and reach out and structure that for yourself so then you can pull in your coder brain to go and complete those sorts of things. I think that’s the best way to think about it.

Shane Hastie: So the leader brain, the coder brain, how do you know when to switch?

Switching between coder brain and leader brain [06:07]

Trisha Ballakur: Yes, right. I feel like it’s like being a Jekyll and Hyde sort of thing, possibly not as serious for your day-to-day work, but I think the coder brain really is one that I came into. That’s usually my resting self. If I were to go in and see a new ticket or a new project, what I typically do is analyze it, think about what the structure looks like, what the system design looks like, think about what types of additions are needed and go through the typical flow that I would get if I was working at somebody else’s company. And then as the co-founder, as a CTO, thinking about that, flipping the other brain, I usually think about, okay, so where does this land within what everyone else on the team is doing? Where does this land in terms of priorities for the business? And what resources do I need to pull in, be it advisors, be it other teammates, nowadays AI to just get this done the fastest?

I don’t really care if somebody, this person being myself in the case of I’m coding it, is the smartest coder and is really talented and loves the job. It’s more when I’m in the leader brain, how do I get this done the most efficient, and with the most impact, and ASAP? So it’s interesting to think of the two brains because the coder brain always wants to mull on a problem, understand it efficiently, but work on maybe new algorithms or test out new scenarios and edge cases and really take their time tying it up with a bow. Whereas the leader brain does not have the time to do that. I think most recently, this wasn’t coding, but this was me having to complete a presentation. Learning in the leader brain how to time box things was not something that I knew in the coder brain. Because in the coder brain, as software engineers, we can take hours upon hours and we have no idea if the bug’s actually getting closer to being done or we messed up something and need to just honestly scratch out the whole code, rewrite it.

That actually teaches a lot of skills that I think leaders a lot of times don’t have, which is why I personally feel like being a technical leader has a lot of merit in our society. Especially with this idea of AI coming in and trying to replace a technical team and understanding where the flaws are for that, which maybe non-technical folks wouldn’t really understand.

Shane Hastie: So we can’t expect the AI just to be replacing the coder brain entirely and we’re all just all going to be leaders.

AI as a tool, not a replacement [08:33]

Trisha Ballakur: No, I really highly doubt that. And I was listening to a podcast, a podcast within a podcast recommendation here, which is Lenny’s podcast with, I think it was the godmother of AI, and she is a fantastic researcher at MIT. I’m forgetting her name. However, she was discussing how she personally thinks AI is not something to really be scared of. Instead, it’s something to celebrate and it’s something to realize, okay, that’s just an extended intern or an extended tool. At the end of the day, nothing is going to replace the human intelligence, the know how of being a computer scientist and all of the different types of nuances that come with it.

I have some friends who are in medical school or doctors, they use something called OpenEvidence. Maybe folks have heard of it, but it’s the same thing there where it’s such a nuanced job. If you just gave the chatbot the ability to go and diagnose and report to patients, that’s not going to work a lot of the times because maybe there’s a 1% or 2% chance that there’s an anomaly case, which often happens in healthcare. And I would say the same thing in computer science where there’s usually a 1% or 2% chance there’s something you and the AI are not thinking about, which goes wrong and you need humans to be able to use their brains to really efficiently see what else is going on.

Shane Hastie: Thinking around your leader and coder brain and the founder aspect of that, this is cognitive shift on a fairly constant basis. How do you avoid burnout and stress in that space?

Managing burnout [10:15]

Trisha Ballakur: So starting with the coder brain, I think a lot of coders and programmers enjoy late night programming. We enjoy being up at different hours and putting in the time to really work on our projects and feel good about them. The same thing applies with being a founder because you got to just grind and have that interest in seeing what your project flourishes to or what the end of one particular task you’re working on becomes. And I think both have that desire for the quick reward, the dopamine that comes at the end, which I’m sure lots of software engineers totally get. That’s the same one that founders get, if not even stronger sometimes, depending on motivations. But I think that in itself causes burnout.

I would even say at the founder level, you only have so many teammates, right? Unless you have scoped out your work in a way where others are going to really take over some capacity. It’s really difficult to not have extra pressure or have to work extra long. I think for regular projects in maybe a company that has more than three people, it’s easy to maybe wait or pass off different things unless there’s a deadline. It feels like in a startup, especially as a founder who takes responsibility, you have to make the deadline. If you don’t make the deadline, you’re not going to get paid or it’s not going to work. You have to stop working on this. And that definitely leads to burnout. It has led me to burnout multiple times during Pointz’s life.

Shane Hastie: So give us some advice. How did you avoid or overcome?

Overcoming burnout through prioritization [11:58]

Trisha Ballakur: I’ll first set the scene with the worst burnout. So I was in a program, which was awesome, lovely program, founder bootcamp. It was in Portland surrounded by 10 other companies and all the founders were the same stage as me. And everyone was looking to everyone else as role models and examples of what to do. So you can imagine there’s an echo chamber of, okay, wake up early in the morning, do work, go to the office, do work until 5:00 or 6:00, get back home, eat dinner, and then do work until you sleep. And so quite literally, it was that for many, many weeks until there came a point where everyone in the group started getting really tired, they weren’t producing as much. And especially in our team, we’re feeling like there was way too much going on and just a drowning sense of feeling where there’s too much work and we need to either slow down the pace or hire more people, which is usually a good thing. But at the time, I think the real understanding was we needed to find a balance.

And so the way that I overcame it is pretty much by taking time to not work at normal people hours, which is before I sleep or even in the morning making sure I went to exercise. And that’s something which a lot of accelerators in general, which are the startup programs, some of them are called YC, Techstars, Y Combinator is YC. These all tell you to some extent, “Hey, make sure you sleep, make sure you eat food, make sure you do things as a human and socialize and get your work done”. But sometimes it’s hard to really know how to do both unless you’re put in the situation. And so nowadays, what I’ve done is I have a very strict time limit with myself where I’m good at prioritizing what’s most important for the day.

I really have gotten that skill and I’d say that’s a learned skill. Understanding what if I don’t accomplish today is really going to put us back for the rest of the week. And if I can’t come up with one thing, I do the next highest priority. And if I’ve done that one thing, I’m okay if I don’t finish the rest of the work at a cutoff of sometime in the evening. And that’s helped me a lot. I think that’s a skill that people can learn. And it’s really just based on getting burnt by not working on the most important things, seeing that those deadlines didn’t work out and maybe having some problem happen, like the customer understood and they’re upset, or your users were like, “What happened to the bug fix?” And then once you understand that you can calibrate, “Hey, for this next time, I got to do this one first before these other more maybe easier or fun or lighter tasks”.

Shane Hastie: Prioritization. Hard.

Trisha Ballakur: It’s hard. It’s really hard. And I also would like to say that I think software engineers in particular, there’s always 100 different possible test cases that we could choose or think about. But I think it’s really that. It’s solving the base case and solving, like creating an MVP and then going from there. And that’s how I think about even more business side tasks, what’s the base case or the MVP that I could create here before I can then layer on top?

Shane Hastie: How important is having background and knowledge in the business domain or the product domain versus the technical skills in your experience?

Building business domain knowledge [15:25]

Trisha Ballakur: It’s not something that someone who is only technical should feel scared about. I think that the number one and two characteristics that you have to really train in, and if you don’t have it, it’s okay, you could train in it, is one, being willing to learn and two, being willing to talk to people. And those go hand in hand. Unfortunately, I think they don’t go super hand in hand with the typical persona of somebody who’s like a stereotypical software engineer. And that might not be everyone, but somebody who’s more introverted, you don’t talk to people and ask questions and learn by talking rather than just reading online.

But truly, in the business world, you have to kind of talk to people in order to get the information that’s typically not found in research or in readings. It’s a very different world than engineering in that sense because I’ve gotten my most relevant information by conducting interviews, by talking to customers, maybe through sales, by putting out some sort of deck or some sort of product and asking people. So poke holes in it and hearing what their feedback is. By listening and having conversations with other founders, everything is conversational and it’s word of mouth and it’s knowing what questions and what information is relevant in the conversation and keeping that for yourself to ponder on as opposed to reading online. Because whatever you read online may or may not be the experience of your customer or of your unique unfair advantage that you are creating that nobody maybe online has ever thought of.

Shane Hastie: As you say, these are not the strong skills in the stereotypical engineer profile.

Trisha Ballakur: Yes.

Shane Hastie: How did you build those skills?

Developing communication skills [17:05]

Trisha Ballakur: I think I built them because I would say I was definitely more introverted when I started coding and programming. I’d say this was back in high school. Yet at the same time, I did a lot of activities that were performance-based. I enjoy singing, so I did singing and I did dance class. And now these aren’t necessarily activities where you go and talk to people or they don’t translate exactly. But what they do give you is putting yourself out in front of people and having them observe you and maybe even judge you and think you’re not the best dancer or singer. But you learn how to not let something get under the skin. I think that’s the number one trait that I learned from those. And that’s what you don’t learn in programming because you can just sit in your room and do your work and maybe if you’re getting graded or if you have to talk to one of your colleagues, it’s fine. But you’re always talking about the code or you’re talking about the program that you’re creating.

You’re not talking about, “Oh yes, and this is me and I’m talking about myself and I’m exposing myself”, because you can always kind of hide behind your code. I think in the business world, you could also try to hide behind your product, but you really have to relate to the person on a human level. And it’s not just about the product, it’s about the person you’re talking to, their experiences, what they believe in. And that gets ripped away even further when you’re speaking to an investor or you’re speaking to someone else who is judging you and is really thinking about you as a person. So there’s layers to it.

I think that people can figure out how they can put themselves out of their comfort zones. And it could be through any way, like going to a poetry slam and reciting poetry, or going and playing a sport with someone you don’t know, or just meeting someone new at a cafe. It could be through so many different ways that apply to this skill. The more that you practice, the better you’re going to be. Luckily, doing startups really makes you practice because you have to talk to pretty much everyone.

Shane Hastie: What’s the important question I haven’t asked you today?

Trisha Ballakur: I think you haven’t asked me what motivated me to want to grow in a way that was moving further away from the code.

Shane Hastie: Well, what did motivate you to grow away from code?

Motivation to move beyond coding [19:23]

Trisha Ballakur: I think the idea of having more opportunity to spearhead the direction of the product that was created by code is what motivated me. So of course, as a programmer, as someone who’s a software engineer, you are really the person who is directly creating the product. That’s why I personally think software engineers should get paid a lot. They should be valued. They’re the helm of what is done. Yet at the same time, you don’t know where that’s going and how that’s being presented to customers and how customers are receiving it. And I think that having no insight into that or having little insight to be the representative or the face of it always bothered me because, “Oh, hey, I’m the one who’s coding all of this. Why am I not getting recognition or my team is getting direct recognition? We’re the people building it. It’s not the CEO or it’s not this person”.

And so I then thought, “Okay, then that means I have to be the CEO. I have to be this person”. We’ve done a great job of that at Pointz with pointing it back to Shahil, who’s our head of engineering. He is one of our most cherished teammates and we really make it clear that his contributions are a huge part of this product and they spearhead the product as much as the rest of the team does. And that’s something that I didn’t have a voice in and I think a lot of places, especially in the larger companies.

Shane Hastie: Trisha, great story, interesting conversation. If people want to continue the conversation, where do they find you?

Trisha Ballakur: Yes. So thank you so much first off for this conversation, Shane. If anyone wants to keep chatting, they can message me on LinkedIn at Trisha Ballakur.

Shane Hastie: Thank you so much for talking to us today.

Trisha Ballakur: Thank you.

Mentioned: