Back to overview

Navigating Growth and Innovation in Tech with Dan Farrelly

This episode discusses the challenges and strategies of managing growth and innovation in the tech industry with Dan Farrelly.

In this episode, Kent C. Dodds interviews Dan Farrelly, the CTO and co-founder of Jest, about his journey from front-end engineer to CTO, the challenges of scaling a tech company, and the importance of staying small to maintain agility and innovation. Farrelly shares insights into the evolving challenges of a tech team, from infrastructure to front-end development, and emphasizes the value of a generalist approach in a small, dynamic team. The conversation also delves into Farrelly's upcoming conference talk on improving long-standing APIs and his enthusiasm for learning from and contributing to the developer community.

Watch this episode.

Meet Dan at Epic Web Conf.

Guests

Dan Farrelly
Dan Farrelly

Transcript

Kent: Hello Hello everybody, I am excited to be joined by my friend Dan. How are you doing, Dan?

Dan: Great, how are you doing Kent?

Kent: Doing awesome. So Dan, actually this is the first time we're meeting, but I know people that have worked for you or do work for you and they speak highly of that experience. So yeah, I'm excited to get to know you a little bit. I want folks who are potentially gonna come to the conference or at least watch online to get to know you a little bit before as well. So can you give us a little intro to yourself?

Dan: Yeah, sure. Thanks. Yeah, so my name is Dan Farrelly. I am the CTO and a co -founder at the company called Jest. Previously, I was the CTO at Buffer .com. And previously, I worked up from like a front -end engineer, full stack engineer to become the CTO of that company. And across my career, I've worked in, started in the front end and then worked across the full stack, got into infra and DevOps. And I've kind of worked in all the different areas. So I

Kent: Hmm.

Dan: really enjoy all the aspects of building software and everything's been, you know, been in the cloud since day one. So it's just, it's where I feel, feel comfortable. And I think it's just a lot of fun problems every single day that you get to solve and, you know, jumping into, you know, I guess like interacting and learning from the community has been really big for me for the last, you know, 10 years since I was a little bit longer than that now, but yeah, it's, but yeah, it's been, it's been fantastic.

Kent: Wow, yeah, time flies and our interests change over time as well. And so, yeah, bouncing around the whole stack is fun. Do you still find yourself doing front -end, back -end web stuff or are you all in for now?

Dan: Uh, it's all, it's all across the board still, cause we're, we're a small team at ingest and we have all types of engineers, full stack front end and, uh, like infra heavy folks. And there's always new problems, right? As you're scaling your product or finding cracks in, in, in, you know, assumptions that you made at the time that, you know, the scale changed in six months. Uh, it kind of pulls you in different areas, which is, uh, which is fantastic. It's like fun. There's always new challenges. So, you know, I think we were just. researching something with our, uh, with like a database that we have that kind of has reached the scale that we, we feel good about and we need to like separate it and have a plan. So we're all researching, comparing database options. And that's just like, that's fun. And yesterday it was maybe dealing with some front end stuff. So I

Kent: All

Dan: love

Kent: over.

Dan: the variety. Maybe I'm a generalist, so

Kent: Yeah,

Dan: I love it.

Kent: that's fun. So I take it that it's very intentional that ingest is trying to stay small and not just like grow to this massive as far as the like number of employees and everything. I always admire companies that try to maintain a reasonable size because I think there's a lot that you can do with fewer people. And as you grow it, there's... There are just new challenges that you have to face that don't involve the core offering that you provide. Would you say that's kind of your goals there?

Dan: Yeah, yeah, I think, you know, of course, you know, you need over time, it makes a lot of sense when you grow the team to bring in new talented folks. But I think, you know, ideally, like when your team is small, that is sometimes so fun. And because also you can touch and get context on like what is going on. So you don't over specialize and. you can understand about the user and about what the problems are on different parts of the system, which I think also exposes you to the whole picture because, you know, the reason why your app might be slow might be because of your database, or it might be because of this one service, or it might be because of how you're handling something in your API. And I think if you're, if you're heavily compartmentalized, you may not have exposure to that. So I think that's like when you're trying to move quickly and trying to solve. things net new for a customer, I think it's amazing to stay small. And

Kent: Mm.

Dan: then just like the communication overhead is also extremely small too. So it generally tends to like when you, I think hire people in the beginning to like attract like more generalist folks. And as you get bigger, maybe some more specialization. But yeah, I think being intentional there is always key because I think, you know, we've all heard it probably worked in orgs where, you know, you hire a bunch more people and it doesn't solve problems, right? It maybe takes some problems and... makes them larger, just

Kent: Mm

Dan: over a

Kent: -hmm.

Dan: bigger

Kent: Yeah.

Dan: scale. So I think it's really key to be intentional about how you're growing a team and get the input also over your team to feel back to say like, all right, how should we grow this and make sure that their stakeholders, because that's, I think anyone who joins an early team wants to, wants to feel like they're part of something, like they can contribute on different levels. So I totally agree. I think we had a relatively small team at. And I think the best thing that we tried to do over the years there were like improve the tooling and allow people to do more with like having to worry about like, I don't know, we didn't have a gigantic infrastructure team. We had a very lean team that was like very good, but we streamlined and automated as much as possible. So like adopted DevOps principles very early to

Kent: Mm.

Dan: enable product engineers to just ship and not have to worry about anything.

Kent: Mm

Dan: So,

Kent: -hmm.

Dan: um, You know, I think that's just some intentions about how you need to grow. And I think at this stage, like, it's blast. And I'd like to stay small as much as we can.

Kent: Yeah, yeah, well that's cool. And so because you're a small team, I'm guessing that you find yourself even as the CTO, you find yourself doing quite a bit of development on the platform as well, is that right?

Dan: Yeah, yeah, jumping in here and there. I find myself in the last year we've grown from maybe like three or four people to just over 10 and we're going north of that a little bit, you know, little by little. And I don't have the, I used to be writing a lot more code. I

Kent: Mm

Dan: don't have the

Kent: -hmm.

Dan: time for it right now. It's too many, you know, jumping around. So I try to unblock people mostly. I end up trying to do the things that people don't want to do.

Kent: Yeah.

Dan: So that's like, you know, Swiss army knife type thing. And I think that... That's what you end up having to be to not allow your team to really do what they're great at and really motivated to do the hard stuff that they can build out and own long -term.

Kent: Mm -hmm.

Dan: So yeah, it's still a fair bit of coding and yeah, the stack always changes. You always get to learn new things. So you got to stay sharp, I think. That's one thing that like, when I was CTO at Buffer, I maybe didn't code as much. And then coming back starting in Jest, I was like, There was, you know, coding and building products that are full time again. And that was just like very fulfilling to me. I kind of forgot how much I missed being hands on.

Kent: Yeah, yeah, creating and building stuff,

Dan: Yeah.

Kent: yeah. Very

Dan: Yeah.

Kent: cool. So at the conference, you're gonna be speaking. Do you wanna give us a little preview of some of the things that you're thinking about, including in your talk?

Dan: Yeah, yeah. So I think, you know, I kind of hinted at it. It wasn't really intentional. It just kind of came out that way before, but about how, you know, APIs can become slow or bloated on over time. They often like start really small and nice and clean. And then your application gets more complex, right? You add new database, database models. Maybe now you're, you're writing to multiple tables in, in, in an endpoint and your application starts to, it starts to get a little bit slower. Maybe there's there's transactions that need to happen. Maybe there's third party services that you need to communicate. And what originally started to be so like small and beautiful and simple ends up sometimes just getting more complex over time, maybe more bloated and like that's natural. That's totally natural. There's nothing wrong with that. Every, everything I think goes through that. That's, that's growth and expanding and making your application more powerful.

Kent: Yeah, that's

Dan: And

Kent: the real world.

Dan: yeah, that's just what it is. Right. And it's, I think what's, what's, what gets hard over time is like, how do you approach those problems? How do you improve an API that's been around for eight years, right? Even four years. And how do we make this faster? But we don't reduce any reliability for our users because

Kent: Mm -hmm.

Dan: you know, they get longer, the APIs can get slower. Your application might get a little bit slower. The user experience gets slower. It's like everyone starts to feel it and. Sometimes they're those things you're like, I don't want to touch that one.

Kent: Yes.

Dan: So really, really, and like I can, I know a lot of examples. I'm sure you can, I'm sure

Kent: Yeah.

Dan: other people that are listening are like, I have that function that's 500 lines and no one touches it.

Kent: Uh -huh.

Dan: And so I, you know, it's a short talk, but I just kind of wanted to talk about some basically like fundamental patterns and I think considerations for approaching and improving those, those types of applications, those, those challenges over time, because you know, it's like, any, you know, sometimes those core functions or those core endpoints are the most important part of your entire system. And so, you know, it's key to be able to maintain and improve that, right? It's like taking care of, you know, your own home or something that, you know, your hobby that you like, you know, it's maintaining that. So I'd like to talk a little bit about that and how to like break out of some of those systems and improve things. with use of background functions and events and different type of ways to ensure reliability when you do that. So

Kent: Cool.

Dan: yeah, it's some fun stuff. It's a topic that I'm passionate about.

Kent: Well, yeah, clearly. I'm looking forward to hearing that talk. Now, while we're at the conference, we're gonna have plenty of people watching online, but people are gonna be there and they're gonna wanna talk to you, Dan. So what are you hoping that people come in and talk with you about and what are you hoping to be able to talk with others about?

Dan: Yeah, yeah. You know, I'll be totally selfishly, you know, it's, I'll be honest, it's at ingest, we're building a developer tool. So I've just been, it's the previously I built consumer, like B2B tools, but for marketing teams. So I'm just like so excited building ingest and talking to developers every day and learning what their problems are and what are their challenges and how do they think about it? how do they approach the problems that they wanna solve? And I think that's just, for me, just personally, it's always been interesting, going to meetups, local meetups and conferences before in the day, like back in New York and I've been in SF and I live in Detroit and it's amazing interacting with folks. And that's really what I'm all looking for is just hearing what people are working on and sharing stories and ideas and stuff. Because I think that's like, in when I've... been to all those events over the span of my career. That's where I've had like light bulb moments and leveled up and been like, Oh my goodness, I did that just clicked. You

Kent: Hmm.

Dan: know, like the first time I saw someone do unit testing, it was a meetup and I was like, what is this going to be? But I was just like, Oh my God. And it was very early on in my career to just help so much.

Kent: Hmm.

Dan: So I think that's just like what I, it fuels me also for the next few months to go out and be inspired. So like that's, that's, I'm excited to chat with other folks about that. And, uh, Hopefully they can inspire me, hopefully I can inspire them and just build off that. Cause I think that's what's beautiful about the like software community in general and how it's always been.

Kent: Yeah, yeah, that's the sort of connection that you can only really have in person where you're looking at each other face to face and having these conversations. And I've had lots of experiences where you develop that relationship and now, like you may have known each other online before, but now that you've talked to that person, your conversations online are just deeper as

Dan: Mm -hmm.

Kent: well. So I'm looking forward to meeting you in person. for that and yeah, super happy to have you on that stage in April. So looking forward to seeing everybody there and thanks so much for giving us your time today, Dan.

Dan: Yeah, of course, excited for the conference and thanks Kent.

Kent: Okay, bye everyone.

Sweet episode right?

You will love this one too.

See all episodes

Featured episode

Deep in Databases and Full Stack Dev with Tyler Benfield

Season 5 Episode 21 — 11:32
Tyler Benfield