Making the jump from line manager to director — essentially overnight with Christian Helvin from Tithely

Rebecca: Hey Christian. Thanks for joining me today.

Christian: Super, super excited to be here. Rebecca, it's good to see your face today. Or hear your voice.

Rebecca: Or both? My voice that is no longer broken like it has been for the last several weeks, so I promise this is like my good voice. Anyway, you are here from Tithely and I just wanted to first start out by what do you do there and what's your story? We're gonna talk about a whole bunch of things about kind of your experience in engineering leadership through this. But yeah, just give me the quick hit of what's your job?

Christian: Oh, totally. I don't know how I got this job, but I'm grateful for it. I lead our engineering teams as a director of engineering over at Tithely. If you're curious what that name is, that doesn't come up very often, but we are a financial processing or donation processing system for churches and nonprofits and faith-based organizations.

And we ended up branching into a number of other areas such as management systems and church apps and all sorts of fun things. So honestly, it's been really, really fun.

Rebecca: It's a whole industry!

Christian: It is a whole industry. And when I got into this, I didn't recognize that this industry existed, but it has been amazing to be a part of it.

Rebecca: Yeah. How long have you been there?

Christian: So I have been here right about a year and a half. I think October will be two years. I was also actually part of an acquisition, and so the company was acquired by Tithely. It was a company called Breeze and I was with them for a couple years ahead of time.

So I think I've been here close to four years. When we were acquired, I expected just to be a normal engineer again. I used the word normal and air quotes, I’m anything but normal, but they asked me to step in to lead the teams. I was blown away. I made the mistake of asking, how big is your team?

I was director of engineering at Breeze. It was eight people. And they're like, “Yeah, it's easy. There's 45 people here.” And I'm like, what? And we've continued growing since then. So it's been a lot of on the job learning and it's been fun. It's been really fun.

Rebecca: Whole big, big, big split between eight and 45. So that's interesting. You came in as part of an acquisition. Let's talk about that. What that was like to arrive at a company and kind of be ingested by the company. And I know obviously every company is different, but what was your experience with that?

Christian: The big scary words, mergers and acquisitions? You know, this is the first one I've ever been a part of company-wise and you read all the news and you hear how bad things usually are. I had some coworkers that shared some horror stories from previous experiences and in the moment, don't get me wrong, in the moment, it's daunting.

It seems really scary coming on the other side of it and looking in. I'll never forget the wisest words that my wife had shared with me which was, you can continue in this job and you know, a lot of what you're getting into, you have some friends around you, you know the role you're playing, you can continue on, or you can go find another job. And everything is brand new and you're starting completely over and there's something to that.

I think it really framed my thought process on instead of demonizing it in a way or really being scared of it, I started embracing it and honestly, I've loved the opportunity. Seeing the software that we build, getting to be a part of the decisions that we make, it really was exciting to be a part of it.

And it's just so many more opportunities. We went from a company size of close to 50 to close to 200, and so you, you see scale and so personally it's been really fun to grow in my career based around that.

Rebecca: Well, yeah, that part is interesting too. One day you're working for a small startup and one day you're not. What stood out to you, and I don’t know if anything stood out to you, about the difference between what it took to run an eight person organization and what it took to run a 45 person organization in a 200 person organization?

Christian: Yeah, that's a really good question. I think on the sub 10 person team, it felt very much like that: just a team that we were part of a larger organization. Getting close to 50 people and now we're past 50 people, there is a side where you are that organization and so, in a real way, instead of always looking to the CEO at the past company and saying, what should we do here? Where should we go? I've been that decision maker in this one and instead of just being like one team of eight people that are working together, we have 14 teams inside of our organization.

So it's really been interesting to see the dynamic of how you create cohesion among teams and collaboration. Also giving them the space to actually have privacy and be able to focus. I think more than that, it's also been the side of… At Breeze, we were a team of eight all in similar time zones. And here we're spread across Europe, North America, and Australia. And that dynamic becomes very interesting on how do we make everyone feel included and how do we actually make that a valid inclusion? So it’s been a really interesting and fun problem to solve.

Rebecca: With people in these different geos, I'm curious, have you tried to like co-locate team members or I should say, build a team around a location? I know you're not moving anybody, but I'm curious what your strategy's been as far as managing that geographic diversity?

Christian: Yeah, that I think was where it became really interesting. Pretty early on, a lot of the teams were actually spread across multiple time zones, and trying to accomplish something across multiple time zones becomes really tricky and inherently slows things down.

Even if it's good quality, it's focused on asynchronous, it slows things down. What we ended up finding was, really by focusing our teams on complimentary time zones. So i.e. there's a team of Australians that get a focus on a project. There's another team of Australians that get a focus on a product.

There's a team in Europe, there's a team in North America. That's been really helpful. There's been a few separations from that. So one of our larger teams, they actually are in North America and Australia, but the Australian team actually focuses a little more on the front-end.

And then the other side of the team focuses a little more full-stack, but a little more on the backend side. And so they've been complimentary and there's enough time zone overlap that things keep moving. But yeah, it's been fascinating.

Rebecca: Yeah, I had Japan for five years at Indeed, and it's, I think it's a little… I actually can't remember if it's better or worse than Australia, but it was rough. It was rough, but I got to go visit a lot, so that was cool.

Christian: That's really cool. I've not been to Australia yet, but I have made a list of all the people and places I want to see when I get there.

Rebecca: After you wake up from the day-long flight.

Christian: That's exactly right. But yeah, a 14-hour difference in time is pretty tricky to manage.

Rebecca: Yes it is. So what were you doing before? So before Tithely, there was Breeze, what were you doing before that?

Christian: Yeah, for years and years I actually ran a website agency, and so I was not in the SaaS space. I wasn't in the necessarily just software development. I was really focused on shipping client websites and e-commerce websites and mobile apps and things like that.

And that's what I've been doing since high school, to be honest, and had the opportunity as a 21-year-old kid to buy a business. And I said, “This sounds fun and this sounds easy,” and learned a lot of lessons, grew up really, really quickly. But agency life was where I kind of cut my teeth, so to speak.

Rebecca: Yeah, I've seen people who bounced back and forth from agency to product development. Will you ever go back? Is there anything you miss? I I also have done my share of agency work making those websites or even like the flash ads.

Christian: Oh, I love that.

Rebecca: So is that something you would ever go back to or is product the life for you?

Christian: It's a tricky one. So there is a side of, I think product development is where I love, love, love what I do. There is a side of agency life and I think there's a couple lessons that have aged well with me as I've moved into product development. Hustle is one of those things. So especially even running my own agency, if I didn't sell, I didn't eat and if I didn't ship, I didn't eat. And I think there is a side where that little hustle mentality has really helped me keep that reminder as we're building product development. I think that's helped a lot.

But there is a side where I think from product development, it's getting to pour yourself into the work you're doing, getting to own it, and really continue building it incrementally. Enhancing it versus six weeks from now, I have to ship it to you, and I might update it once a year, but that only happens if you pay me. And so there's a side where with software development, you really get to pour in. And I think that's what really unlocked it for me when I started on the SaaS world.

Rebecca: In one of our previous conversations, you said that when you showed up at this new company that is much bigger and they're like, “You can be the engineering leader.” What were your first days and weeks like making that transition?

Christian: Other than saying, holy crap, what have I gotten myself into? I will say, I think there was a side where being in engineering and actually coding for years and years and years, one of the things that I wanted to be really careful about was making decisions without knowing context.

And so, honestly, the very first, like three months, I actually did nothing but meet with people. And so I hate to be a person that threw a thousand meetings on the calendar, but I took about an hour with every single engineer to get to know them. There's a few engineers that we just got to talking and I scheduled a second and a third and a fourth conversation, and we just kept chatting.

But there's a side where I started to get to know the personalities. And the quality of the folks that worked at Tithely. And then was able to really see what are some inefficiencies or where are some areas where maybe an engineer's frustrated with this process or a lack of a process? And I really think it unlocked a lot for me in understanding where we probably should move and where would actually be harmful to engineering.

And so that I think was really some of my very first days. So it was a fun time. It was long hours and long days, but it was worth every bit of it.

Rebecca: Yeah. I've done the months of meetings when you're new. And that's like such an amazing way to learn. And I don't know how you could really learn any other way because you're dealing with fundamentally, humans, so we’re gonna talk to them.

Christian: There's a book a really, really good friend who recommended to me, that talks about this subject called the Skip Level.

And it's where your boss's boss gets to talk with you or not your direct report, but the person that reports to your direct report. You end up seeing a different side of people, like they're willing to share things with you that they probably would never share with their boss.

We've kept that trait going on at Tithely, and it's been really amazing to see just the retainment that we have from that, but also what we learned from those and what we can change. It's been, it's been really fun to see.

Rebecca: Yeah. What do people come to talk to you about when you're the head of engineering?

Christian: You would be surprised. It covers everything from, “Hey, can you do this code review for me?” But on a real topic, it really is just most of the time really good questions. And I think what I've enjoyed out of them is, people that are very much focused on the day-to-day shipping and coding and building and thinking through how we need to build things, you kind of get pulled back into that.

That's something that I personally crave. I don't code much anymore professionally. I spend my nights and weekends coding because that's my love language, I just code. And so there's a real side where folks like someone had mentioned in one of those first conversations like, “Look, it takes me about 45 minutes a day to spin up my local environment.”

That's a real pain point. And for that engineer, they're just working through it. For me, I was like, well, let's look at the gigs of RAM you have. Let's look at your CPU. I know that the local development should be working. They had a really old computer, like, let's fix that. And there's a moment where some of those things can be solved, because you know, you've got the power to do that. And so there have been really good questions that get brought up. Even just philosophical questions, methodology questions, everything. And honestly, in a real way, I think what I enjoy, I know it happens in multiple professions, but engineers tend to be very opinionated people.

I sure am. And I think there's a moment where I very much enjoy leading and working with folks that are very opinionated because you create a much better culture when people have opinions and thoughts and care about things, and share them, and are willing to stand up for themselves and share, look, “This is frustrating.” Or, “Hey, one of my coworkers was frustrated by this,” or, “Here's an idea that I spent the weekend putting together.” There's a bit of care that you see out of it. And so, yeah, it's been fun. It's been really fun.

Rebecca: So when you’re new to this, you’ve talked to all your people and you’re getting to know them, what were some of the themes that emerged as far as like what you needed to fix or improve in the engineering organization? Was it chaotic or was it like, “Oh, I need to do these three things and then we’re better.” How did you move forward from those conversations?

Christian: I think Tithely was really stacked up well to begin with. The one main area I had seen was Breeze wasn't Tithely’s first acquisition. They had continued growing and it's really cool because they've inherited really cool systems they've been able to offer customers along the way.

When I first joined, we had seven GitHub organizations. We had close to 300 repositories. It gets really, really complicated quickly. And what I noticed was just a need for clarity to be able to see, well, what do we need to build? Or hey, there's teams that are double building, triple building.

There's teams that are maybe building this really cool resource that could be used by other teams, but none of the other teams know that. And so they're building or they're using other services to do that. And so for myself, I wanted to quickly identify what teams, in a real way could be consolidated.

I want engineers to build valuable things. I don't want people wasting their time. And if at the end of the of the day you find we've been building three of the same thing, two of those teams are gonna be really frustrated in the end. And so that was one area was really how do we organize our organization about how we build and what we build and what we also don't build. But there's also a moment of actually finding the processes that we could implement that would help increase not productivity necessarily, that's included in there, but developer happiness, I think is what I'd call it.

Where, you know, there's a lot of PR shepherding or there's a lot of coder reviews taking hours upon hours or days upon days to get approved. Those kind of things where some simple processes could be added to alleviate some of those pain points. So I won't say it was chaotic, I think it was really “Where do I start?” And secondly, how do I make sure that it doesn't come across, it's not meant this way, but make sure it doesn't come across in a way that's like, “Oh, new boss in town, we're gonna change everything.”

Rebecca: “You're doing it wrong.”

Christian: Exactly. So we, we did pretty gradual changes across the board.

Rebecca: So once you identify that that was an area where you need to focus and you said, is it productivity, is it experience, is it happiness? Is it effectiveness? There's so many words for these things. But they all really blend together. Like part of the reason we can't choose one is because it's all of that, including the impact that it has has on the business. So once you identified that this is a thing that I need to make better, what changes did you see? What changes did you make and what changes did you see to kind of execute on that this needs to be better?

Christian: We started with an idea of creating internal services throughout our products. So Tithely has a pretty large product suite, and so there's a number of different products. Some of them are really disjointed, and the idea is how do we start bringing them together and some ideas thrown out. Like initially, can we bring everything into one repo, one codebase?

When you look at practicality, that's never going to happen. So one of the areas that I saw that could be very beneficial very quickly is, I'll use a hot topic, but it's microservicing. And we try to take a very common sensical approach to microservices, i.e. we don't want 3,000 of them, but a few of them can be really helpful.

So we created a few internal services layers that would help connect these products together. It does two things: it obviously makes the customer experience way better. They now have one login and they can go through multiple things, and we're still working on creating a lot of those product enhancements or integrations into these services.

The other thing that it does though, is it increases collaboration between teams because now you have a specific underlying system that is powering multiple different features in a product. That product now needs to talk with that service or that service can have those two products talking together.

And so it actually kind of broke down some initial walls between teams in engineering that just forced us to chat a little more and be able to meet and get to know other folks from other teams. And so that was a really cool benefit out of creating some kind of underlying services to begin with. And it wasn't something that I came up with. We had one main system and we just started enhancing and adding to that. And so that was a huge boost, not just to productivity, but also to how do we create clarity. Ideally, if we ever do another acquisition or when new codebases arise, like how do we connect them? And that was a neat way of doing that.

Rebecca: So as you’re doing these like organizational changes and architectural changes, how do you know you're doing the right thing? Were there metrics that you were trying to move? How do you know that you're doing the right thing? How do you know that what you're doing matters other than like the sniff test of, “Oh, it seems like we're talking to each other more?”

Christian: Yeah. For us, it was a tricky one to figure out. At Breeze and in previous companies, I've always had uptime metrics and some metrics around code delivery and how often do we have a successful deployment, those kind of things. We didn't necessarily have that here, and we have some of that now, but one of the big areas that I really wanted us to focus on was actually getting visuals into our software.

And so we've set up some reporting systems and we've set up some channels even in our Slack where we are told and notified of incidents. It was kind of a newer thing to us and it actually allows us to really mark the health of a specific product, but also see how often are we running into issues and just have never known that.

And so that was a lot of where our initial focus was: more on the production facing side of things. And how do we make sure things stay up and how do we know when things are actually going down before the customers find out? That's a huge key term. And so setting up some of those systems actually was more than a sniff test, but it really allowed us to see, is this working? Is it not?

Rebecca: I'm curious, I'm imagining that when you arrived, there was a team working on this product and there's a team working on this product and team working on this product? And like you said, there wasn't a lot of cohesion among them. Are you at the point that you're thinking about like, “Oh, we need a horizontal team layer here?” Or where's your thinking on that?

Christian: Yeah, we have started moving towards that so I am excited. So when I first joined for about eight or nine months, I chose to directly lead those teams. We didn't have a management layer, and I'll get to the word management really quickly because as an engineer still that scares the crap out of me. But there's a moment where we didn't really have any management structure more than just specific team leads leading their teams and doing a phenomenal job at that.

And so for a little while, I actually kind of stepped in directly managed 17 people. It was some pretty long days. It was worth it. I gained a lot of context about where teams had hiccups, where they had roadblocks, where their frustrations were, where they were delivering really well and could catch the ball, so to speak, and create those opportunities to say, “Hey, this team should talk to this team.”

Where we've moved to over the last like six–eight months is we've actually added an extra layer to help lead those so we can kind of divvy up our product bases into two main categories at least the customer facing side.

There's one we call finance, that is our bread and butter, so to speak. That is our main core area where we process donations and handle all the giving and all of that stuff for organizations. There's the other side, which is more on the back office for a church and for an organization and the engagement of members and we call that kind of our CHMS church management system.

So we've created these two houses more or less. And what we really did was my whole focus in creating that management structure. I put a lot of thought into, look, at the end of the day, if those managers just have to bubble up things to me, we're just going to perpetuate an issue that's going to forever exist.

And so what we actually did was created a ton of autonomy where those team leads and that manager can actually make a majority of the decisions about how the products work, how they collaborate. We have a product department that we work really, really closely with, and so it's actually allowed a lot to come off of my plate.

I can lead from more of a high level and I actually get to pour into some of the areas I love the most, like our DevOps area and some of those internal services. And so there's a few areas I'm still directly leading. But those two main areas have been allowed to give autonomy and honestly, they're moving far faster and far better than they were with me.

It's crazy when you're a bottleneck, you can immediately see that.

Rebecca: You were talking about those microservices. Is there also a team that owns them? I'm, I'm curious, as you introduce these things that are common or shared, how's that working and is there a team that is responsible for that? What does that look like?

Christian: So we have four main microservices or internal services, and each of those actually operate completely independently. There's an architect over each of them. And they get to really focus on how should they power. We want to be careful that we don't implement every single possible language and every single framework into the ecosystem.

But there is a point where I believe architecture should be focused around the needs of an internal service. And so each one of them actually look pretty significantly different from each other. There's teams that talk together to make sure we're not building in isolation though. But for those internal services, I actually still step really closely to them and lead them more on the management structure end.

They're really close to my heart. I think there's a piece where even from my side, I started down the path of those, and I don't want to just say, “Hey, have fun with those. Good luck.” I really am sitting close to help keep them moving, keep them unblocked and so it's been really good to see.

Rebecca: So let me ask you, we've been talking about what you do downward. We're all friends and there's no up and down, but we've been talking about what you do kind of downward. What about upward? What is the business like? What is the business expecting of you and how are you kind of communicating to the business that they're getting that?

Christian: One of my best friends in engineering management had given me some very wise words when I reluctantly, initially stepped back into this world of management. I told myself I'd never be a manager again after running a company. It was good, but there was a side where he gave me some very good advice, and that advice was create your own metrics that you measure for yourself because no one will create it for you.

And at least from my side, we are a very technical company. Our founders love technology. On the engineering front, they're not the most technical. They know technology well, they play and they're early adopters to stuff. But if I were to say, “Hey, our code coverage is this.” They could care less and I wouldn't blame 'em.

I call them normal people, and that's good to have. What I started doing pretty early on was creating my own metrics that I measure myself by. Attrition is a thing that I measure personally. Engagement, our ENPS score. Those areas I really measure pretty closely. And even from our area of production facing uptime, how are we measuring incidents when they happen, they're going to happen, but how do we handle them when they arise? How do we prevent additional ones from happening? Those are some of the main metrics that I really focus on. And I think it's really been learning how to speak to my role. One of the things that I love the most, at least to the other departments, is having a closer relationship.

So talking with our sales department, talking with our CX or customer service department, talking with our marketing department and saying, how can we help you? And also, how can we empower you to actually create a lot of your own needs inside of your department? Engineering is always going to be the most limited resource in a company.

And the problem is engineers want to build everything, but we'll never be able to build everything. And so I've been working really closely with other departments to say, well, how can I give you ownership over this? Or are there other tools that you can use that we can embed to where you can get something to show up inside of our apps?

And so it's been really fun to see some of that lay out. And we end up moving more quickly because not everything requires a ticket to engineering. And so we get to focus on the main outcomes of what we're focusing on and they are able to kind of self-service a lot too.

Rebeca: It's something I really didn't appreciate until I joined larger companies was how much, how much engineering work it takes just to keep the business running. And that like at a certain size, maybe you need to have a conversation about are we going to spend engineering time on this or are we going to buy something off the shelf, or are we going hire more people, though maybe we need a people engineering team just to build up systems for managing the number of people that we have?

It's been really fascinating to me. These whole new challenges that they just don't exist at an eight person engineering team. But the more people you get into the mix, the more you really want it. At at Stripe, we would talk a lot about the human-to-human problem, which was that like, I love you talking at lunch, that's great, but if you need to talk to somebody in order to get your job done, actually at a certain size that's maybe not good actually. Whereas you would never tell that to an eight person engineering team. Like of course they should be talking to each other. But anyway, it's always interesting to me how whole new needs emerged that you would never have thought about before. And you're right. Engineering is the bottleneck in the organization. Or maybe procurement. Maybe we'll give a nod to procurement.

Christian: That's a good point too. There's so much truth to that. I think it's easy to think even at scale, to think more on a team level or department level and forget the individual level. You know, there's been times, there's friends of mine that work in very large organizations where sometimes they'll go days and weeks on end without meaningful work to do. Like they'll find busy work to do.

But there is a moment where, you really want to empower your folks to keep moving on their own even if there's not always a ton and ton of clarity. Those problems of scale grow pretty rapidly. Pretty quickly.

Rebecca: How's Tithely doing in the current macroeconomic climate, which is the favorite thing for everybody? Are you growing are you kind of hanging out and working with what you've got?

Christian: Yeah, we're doing a bit of mixture of both, so I'm grateful that we didn't have to take part of, I'll call 'em the tech layoffs of 2022 and 2023.

We have always budgeted pretty conservatively, and I'm grateful for that. There's a moment in time where as the leader of this department, those conversations are never fun. And it's such a tough thing for a business to do. For our side, we actually originally had a decently aggressive hiring budget for the year.

We pushed pause on that and for very obvious reasons. And we're really hanging out with where we're at. We've got trickles of little career opportunities here and there, but very much focused on what we're working with and giving tooling to our engineers to make their jobs easier.

And you know, that's been a lot of what we're doing.

Rebecca: Sure. And I always remind people that even if your headcount isn't growing, your codebase is.

Christian: Well said.

Rebecca: So unless you just close the doors and go home, your codebase keeps growing. Are you experiencing any challenges on that front? Of course, it's growing more slowly than if you had twice as many engineers, but I'm just curious as the codebase grows with a large number of engineers what sort of problems are cropping up from that perspective, if any?

Christian: Yeah, that's a really good question. So right now we're very much focused on what I'll call a consolidation effort of bringing a couple of our codebases together and bringing some of our systems into alignment with each other.

And so for a lot of our teams, it's more code deletions than additions right now, which I'd argue in any healthy codebase is a good thing.

Rebecca: A great thing. So maybe your code base isn't growing.

Christian: It's definitely growing in the number of commits that we're making to it. And I will say it is one of those areas where we're really starting to ramp up again on more of what I'd call customer facing value work.

But we're very much focused on trimming the fat, so to speak, on those and how do we deliver a really functional MVP to customers first begin testing and expanding from there as we need instead of trying to build everything at once, and spending months and months on doing that.

I'm very much a fan of how do we incrementally ship little bits of value very consistently. And so we're finding that works well in our favor.

Rebecca: That is such a powerful change to just ship smaller things faster.

Christian: Yeah. It's a mind-blowing concept, right?

Rebecca: Yeah. It's so simple and it's pretty hard to do in reality. Well, I have one more question here before we wrap up. And this has been really awesome, but I heard something about tractor simulators?

Christian: Oh, you've done your research well on me. There is a very personal side to me where my favorite, other than my animals and my wife, my favorite thing is a game called American Truck Simulator. So it's not quite tractors.

Rebecca: There's not a tractor one?

Christian: So there's a farming simulator. That one's amazing. Wasn't quite my thing, but what I will say is there's a game called Euro Truck Sim and American Truck Sim. Literally my favorite pastime when I'm not coding, when I'm not leading, I literally just have a little controller.

I used to have a steering wheel and a whole setup at my last house, but I have a little controller and I'm just trucking through, you know, Europe or the West Coast. So real talk, the reason that I love it so much, I used to commute like an hour and a half or two hours a day for work and that was my podcast time. So that was when I listened to podcasts. And when I started working remotely six or seven years ago, I've got friends that are like, “Well, I do it when I'm walking around or when I'm doing chores or things like that.” I can't focus like when there's a thousand things in the house.

So what I do is I actually just play this game. I don't turn on music, I just listen to podcasts. The podcast, it's my commute, just my digital commute.

Rebecca: Disconnects your brain. That's amazing. So I have spent untold hours on flight simulators. And also at one point had the yoke and all that and I still to this day play a game called Transport Tycoon. It's not a simulator, it's a like building a transportation network. And yeah, that is also my happy place. I think it was written like in assembly in the nineties or something like that.

Christian: Guarantee one of the most performant games out there.

Rebecca: It's just incredible. You should see it run on like today's computers.

Christian: Oh, I love that.

Rebecca: Well, Christian, this has been a real treat. Thank you for sharing that personal side at the end. This has been great. Really love to hear about your experience and I'm curious what the next year will hold for you. So we should do an update check-in again.

Christian: I appreciate that. We'll have to wait and see, right?

Rebecca: Well, happy trucking and happy engineering and this has been great. Look forward to talking to you again soon.

Christian: Thank you so much. Thanks Rebecca for having me.