# Balancing Coder and Leader Brains in Startups

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-01-30

## Transcript

If you're the kind of senior engineer, architect, or technical leader who people look to for what's next, QCon London is probably already on your radar.
Join us in London from March 16 to 19, where we go deep on the topics that matter, like the architectures you've always wondered about, engineering productivity, and applying AI in the real world.
This isn't about trends for their own sake.
It's about getting practical insights from senior practitioners to help you make smarter calls on where to invest your time and take.
With software changing fast, QCon London is the conference that helps you lead the change.
Learn more at QCon London.com.
Good day, folks.
This is Shane Hasty for the InfoQ Engineering Culture Podcast.
Today I had the privilege of sitting down with Trisha Balakar.
Trisha, welcome.
Thank you for taking the time to talk to us today.
Thank you so much, Shane.
Now, my normal starting point on these conversations is who's Trisha.
Sure.
So I am the CEO and co-founder of Points.
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.
And what brought you to be the co-founder?
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 of what I wanted to do with my life.
I was still a 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.
That's a very accelerated path.
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 freshman 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 of months, honestly.
So through that rapid growth in and early career software engineer, what are some of the the interesting and exciting things that happened to you?
Well, all of my internships in the past had been me contributing on a project that was already well scoped, that was already, you know, written in a language that I knew really well, be it Python or maybe Java script.
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 kind of, I like to say it, be the TAs for ourselves.
Like 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.
So a group of novices coming up with ideas, sharing them with the world, building product on the fly.
How do you navigate from that coder to leader?
I think one key point is remembering that all of my had training in becoming a computer scientist, both was extremely helpful to solving problems that came up at points 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 five to ten 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 like 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.
So the leader brain, the coder brain.
How do you know when to switch?
Yeah, 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 like 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 like 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.
So we can't expect the AI just to be replacing the coder brain entirely, and we're all just all gonna be leaders.
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 gonna 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 open evidence.
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 chat bot the ability to go and diagnose and report to patients, that's not gonna work a lot of the times because maybe there's a one or two percent 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 like a one or two percent 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.
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?
So starting with the coder brain, I think a lot of coders and programmers enjoy late-night programming.
We enjoy like 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 gotta kind of 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 gonna 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 like 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 gonna get paid or you're it's not gonna work.
You have to stop working on this.
And that definitely leads to burnout.
It has led me to burnout multiple times during points of life.
So give us some advice.
How did you avoid a robe account?
I'll first set the scene with the worst burnout.
So I was in a program which was awesome, lovely program.
Uh founder boot camp.
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 five or six, 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 were 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 Tech Stars, white companies 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 you know, 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 gotta do this one first before these other more maybe easier or fun or lighter tasks.
Hard.
It's hard.
It's really hard.
And I also like to say that I think software engineers in particular, there's always a hundred different possible test cases that we could choose or like think about.
But I think it's really that it's like solving the base case and solving like creating like an MVP and then going from there.
And that's how I think about like even more business side tasks.
Like what's the base case or the MVP that I could create here before I can then layer on top?
How important is having background and knowledge in the business domain or the product domain versus the technical skills in your experience?
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 you know, somebody who's more introverted, you know, talk to people and ask questions and learn by talking rather than just reading online.
But truly, like in a 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 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.
As you say, these are not the strong skills in the stereotypical engineer profile.
How did you build those skills?
I think I built them because I would say 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 like singing and I did dance class.
And now these aren't necessarily activities where you go and talk to people or like 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 yeah, 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 like 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 gonna be.
Luckily, doing startups really makes you practice because you have to talk to pretty much everyone.
What's the important question I haven't asked you today?
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.
Well, what did motivate you to grow away from code?
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 points with pointing it back to Shahill, 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 the larger companies.
Trisha, great story.
Interesting conversation.
If people want to continue the conversation, where do they find you?
Yeah.
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 Balakor.
Thank you so much for talking to us today.
Thank you.