# SaaS Resilience and AI-Driven Team Strategy

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-09-04

## Transcript

Postgres shouldn't force you to choose between transactions and analytics.
TigerData, creators of TimescaleDB, adds hybrid row and columnar storage, 95% compression, and continuous aggregates, so both run in one Postgres database.
Try it free at tigerdata.com forward slash go forward slash trial.
Good night, folks.
This is Shane Hastie for the InfoQ Engineering Culture Podcast.
Today, I have the privilege of sitting down with Adam Wachtell.
Adam, welcome.
Thanks for taking the time to talk to us.
Well, thank you very much for having me.
My normal starting point on these conversations is...
Who's Adam?
Well, my name's Adam Wachtell.
I'm the Chief Technology Officer with Clickboarding.
We offer a web-based SaaS product that automates processes around onboarding and offboarding of employees in generally the enterprise.
I've got, let's see, coming up on 25 years in the SaaS B2B tech area.
I started as an engineer years ago, built up a couple of small teams, went through a couple of acquisitions, and then got the opportunity to circle back to Clickboarding, which at the time was a very small company.
We've built it up over the last few years, but enjoy getting in the weeds myself, writing code when I can.
Less these days than I used to, but when I can get in the weeds, I do that.
but enjoy building teams, building technology, mostly in the Microsoft stack, but moved into other areas as well.
What's the difference between building teams and building tech?
I think you have to have a team to build technology, particularly in the hiring space.
In technology, obviously the thing most people focus on is skill set.
I've found in my years of experience building teams from scratch that personality is arguably the most important.
portion of that.
And that's not just necessarily hiring people that I enjoy working with, which I do, but having that problem solving mentality, the ability to analyze, you know, kind of what the challenge is, use the tools necessary to figure it out.
Working in small teams, we don't have reams of project managers.
We don't have reams of product owners.
It's usually a pretty small team in that regard.
So engineers on the team are expected to kind of say, you know.
Here's what we're looking to solve.
Here's the tech stack.
Here are the parameters that we're working in.
Go figure it out.
So as long as we can find folks that are ready to do that and enjoy that kind of environment, thrive in that environment, we can make a lot of progress very quickly with a small amount of resources.
You've mentioned some of the characteristics of the people you look for and that personality is more important often than the technical skills or certainly equally as important than I would say in my experience.
What does career pathway and growth look like for people in our organizations today?
In the small organizations, and we typically focus on mid to senior level, right?
It's a small team.
We got to get people that have been doing this stuff for a little while, and that's normally where we hire from.
But the career progression is generally we bring folks in that have skill set that we're looking for.
They've got the personality type that we're looking for.
We'll bring them in, have them work on the system.
Over time, if they're interested in people management, not everybody is, some people are, but if they're interested in people management, that typically starts in a mode of mentoring other new hires and working in small, almost like Tiger team type of groups to get that sort of experience around, here's how I help guide others, not dictate, not tell them everything they need to know, but help guide the direction of the company and the direction of the team.
You know, I found that that prepares them well for management later on in their career if they want to go down that path in earnest.
But team leadership, pair programming, that type of thing helps build those social skills while at the same time they maintain their technical skills, grow their technical skills, and then kind of do all those things at once.
Our industry is quite notorious for short tenures and people moving on.
How do we keep them?
And do we keep them?
Well, and sometimes they're just not the right fit.
I've had particularly good luck with keeping engineers around for a long tenure.
Most of my team I have today has been with us for three and four years, which in IT is an eternity.
I've found that people stay engaged, particularly technical folks, right?
They're high intelligent.
It's more of a creative function than I think people who haven't worked in technology realize.
There's almost an artistic aspect to it.
So as we're building technology and moving things forward.
giving them a sense of ownership of the product.
And it's more of that, here's kind of what we're looking for.
You go figure out how to implement it rather than here's a very rigid waterfall style definition of everything.
Here's the parameters.
Here's what we're looking for.
Go figure it out.
That lets them be creative.
That lets them solve the problem the way that they think it ought to be solved.
Obviously, there's oversight and everything with anything else.
But that sense of ownership, I think, is what keeps them engaged, what keeps them interested.
We're talking onboarding and offboarding is not the most thrilling topics, but when we're doing it in an engaging, fun team environment, I found that people stay focused.
They like the job.
They like the team.
Obviously, compensation is very important.
We pay people well.
You have to.
But that team orientation, I think, is a very strong, important thing to focus on.
And when you do that, people hang around.
To answer the second part of your question, some folks just turn out not to be the best fit.
And we part ways.
We try to do that as professionally as possible.
But in my experience, I've found that we don't have to do that very often.
And when you get the right team working together, they stay together.
The longer they work together, the better they understand the stack as a whole, the entire product.
So we can do things more and more efficiently over time.
So as organizations grow, teams have to evolve and grow and shift around.
And the reteaming activity can be quite disruptive.
How do we do that well?
In my experience, I've been through a couple of acquisitions where you're working for a small company that gets acquired by a larger company, not necessarily large.
And in my case, started with a 30-person company that was acquired by a 200-person company.
We grew that to about 300.
Then we're acquired by a company with 10,000 people that was eventually publicly traded.
Gigantic.
In my experience, kind of how we've attacked that is as we're exposed to new.
products and new areas of the business that have their own tech stack, their own technology that they're already working on.
We try to get as much of the team cross-pollinated as possible.
So everybody gets to work on everything rather than a siloed approach where this team only works on this module or this area of the platform.
Everybody kind of works on everything.
People naturally hover to one area or another, and they're kind of the specialists in that area.
Like if we've got a high severity issue or something, these are the folks you call.
But we try to get everybody exposure to all of the stack, at least at a basic level.
So when they need to shift around or we have high priority over here, we can move people there and it's not completely foreign to them.
What's the culture that underlies all this?
Collaborative, I'll say, right?
You got to have leadership.
You have to have centralized guidance of here's the company goals or goals from a product perspective, kind of where the business is going.
But as far as the team culture goes, Collaborative, right?
We're all professionals.
We're all here because we know what we're doing.
So collaborative where everybody has an equal say, everybody is willing and able to speak up if they don't agree with the direction or they think we should do things differently.
What I tell everybody, especially when they join the company is hang out for 30, 60 days, do things the way we think that you ought to do them.
But you come here with experience.
And if you think there is a different way to do things or a better way to do things.
bring it up and we'll try it out.
That could be new technologies, the new frameworks, new processes, you know, what have you, but try to let the smart people be smart and everybody ends up benefiting as a whole.
And when we're under the pump, when the pressure comes, so you mentioned when we were chatting before we started recording that when you joined your current organization, the team was in trouble, the tech was in trouble.
How do we turn that around?
Yeah, it was in a bad state when I first got to clickboarding.
The platform was falling over every couple of days.
We had a very small team in the US.
We had a contingent of outsourced labor that was in Ukraine, which is a different story.
This was right before Russia invaded Ukraine, like 60, 90 days before that happened.
But initially, we kind of have to stack rank our biggest problems.
Here's where.
things are falling over here's our biggest bottleneck in our case it was our sql server we had at the time kind of what's referred to as a multi-tenant sql database where we've got all client data on one big database we have enterprise clients some in the fortune 50 areas so huge clients a lot of transactions huge bottlenecks so one of our first early focuses was to shift to a single tenant approach where we could split off the biggest clients into their own database which was a huge lift But to answer your question, it's kind of here's our biggest problems that are killing us every day.
Start chunking through them.
Let everybody, again, have a piece of the contribution.
Here's what we're going to do.
If you think we ought to do something different, speak up.
Otherwise, bam, go and run with it and kind of solve those problems.
And we found that when we laser focus on a particular thing, knock it out.
Let's move on to the next one.
We made a lot of progress there at the same time.
What little time we had left over were contributing to the product in terms of new features and things.
Over time, over the four and a half years I've been here, it's shifted from tech debt and new stuff to much less tech debt and much more new stuff.
But we had to get over that hump and prioritize the biggest pain points and solve them one after another and then get to a place where we've got a stable, scalable system that we can build new stuff on top of and not worry about firefighting.
And the people, how do we keep people, I want to say, engaged through what must be sometimes feel like a death march?
Yeah.
Again, back to the personality thing.
You really have to have people that want to solve problems.
They like a challenge.
Luckily, some of the folks that we had when I first got here were in that mindset.
I brought some folks over with me that I'd worked with previously.
And I told them straight up and I kind of do the same thing during the interview process to say, there's some ugly stuff here.
Here's what we're dealing with.
If that's not your cup of tea, then this is not the right opportunity for you.
But if you want to solve problems and fix things and see if we can turn this into something much bigger than it is, then come on and we'll figure this stuff out.
So, you know, that mindset is very important.
And then we're kind of in a.
To use the term death march when I got here, they were making a lot of progress.
Things were falling over all the time.
They weren't rolling out new features and it was very much a grind.
But I think we put resources in the right area, kind of isolated what the problems were and started fixing stuff.
And folks started seeing the progress and said, hey, this is not, it's not as bad as it was.
It's getting progressively better.
Our clients saw that we were moving in the right direction.
And then they start seeing that progress and say, okay, we're making progress here.
We're moving in the right direction.
So that kind of helps the morale.
So if I'm a reasonably new team lead in an organization, I'm facing an environment of absolute disruption and chaos around me at the moment.
And I'm trying to learn how to lead people quite often, as I more likely was a strong technologist and being put into that position of, okay, now you've got some people to look after.
Where do I start?
The most challenging things that I see with new leaders, particularly in this space, again, these are high performers, high intelligence.
They like to be hands-on and learning to delegate is very challenging to people who've been individual contributors their whole career.
And it might have been a short career if they're young.
They might have been doing this for a long time before they get any people management opportunities.
But that delegation is critical.
And that's a trust thing.
So one of the first things that I try to work with with new managers is, Again, making sure that they understand kind of the priority of things that they can trust their subordinates to do the work that's been delegated, that's been tasked with them.
And here's how you can kind of set up some simple oversight processes to make sure they're doing the right thing.
They're doing it timely.
And it's kind of a crawl, walk, run thing where they're still doing a lot of individual contributor stuff.
They're delegating some small pieces here and there.
And then over time, more delegation.
more leadership and less of the hands-on.
Never completely get away from the hands-on because you want to stay, you know, 100-foot level, not 10,000-foot level so you know what's going on.
But I think a big part of it is delegation, building that trust layer.
And then that also helps the folks that are on their team with, you know, kind of how they lead as a manager, how they can work well together.
And then you'll see that productivity grow and grow over time.
And if we think of looking outside at the wider ecosystem, teams are very, well, are they very different today than they were even two or three years ago with the new tools and technologies available to us?
You know, I think AI has had some impact on that.
I think when we see like these huge layoffs and all this other kind of stuff that we're seeing in the job market today.
Some of that's AI.
Some of that was over hiring post-COVID, I think, depending on who you ask and who you talk to.
I think as far as the team makeup goes, particularly if you're in small team agile kind of environment, the composition hasn't changed.
I think with these AI tool sets probably provides the opportunity to shrink it a little bit.
You know, I get kind of the way I rationalize it is if we've got junior to mid to senior to enterprise architect level.
I think that kind of stays largely intact and maybe you don't need quite as much depth at every level.
If you're using these AI tools appropriately, it's an extra set of hands or two sets of hands.
But I think the composition still stays the same.
You've got to have somebody running the product side.
You've got to have somebody doing the testing, DevOps, engineering, all that stuff is still going to be required.
Over time, it'll get more and more automated, but you've still got to have somebody sanity checking, setting the direction.
and making sure that guidance is followed.
So I say again, I think it probably shrinks the total number of required people for a team that accelerates the output, but the makeup of the team, you know, I think stays largely intact.
That's somewhat contrary to the, oh, woe is us, all of the junior engineer roles of disappearing.
You know, folks are going to age out of the system.
You got to bring new people in.
They've got to learn somewhere.
You know, where typically junior engineers today come in and they're doing the low-level tickets.
Again, there's probably less of that over time, but it doesn't completely go away.
They still have to get exposure to this stuff and you still have to have SMEs against all of these things.
You still have to be able to read code, understand code.
What is it doing?
The further we get away from the code that's being written and being submitted, the harder it's going to be to diagnose problems.
I know firsthand, again, when I got to clickboarding, it was a new team, this outsource team, and very few people knew.
how the guts of the system actually works, which was incredibly painful.
It took us a while to get our arms back around it.
It's a legacy system that had been around for a while.
So that's a similar parallel, I think, with AI.
If people over-leverage it, it's writing all this code.
It looks great.
It works great.
When you have a problem, if you're too far away from it, that's going to be very difficult, I think, to diagnose.
So I'd say again, I think, short of AGI and some of these very far-out technologies, that will be solved eventually.
But I think short of that...
You still need junior engineers.
You still need mids.
You still need seniors.
Might not need as many of them, but they're still going to need to be there.
You got to train them up, skill them up, you know, that type of thing.
What's the really important question I haven't asked you?
Probably in our space, I think the biggest controversial topic is the quote, the death of SaaS, right?
Enterprise applications are all going to go away.
We are working for a SaaS company and that's the impact that our sales cycle.
We're seeing a huge amount of consolidation in business technology.
At ClickBording, we're a small company.
We're about 45 employees.
We've been consolidating technology.
We've got two or three tools that do almost the same thing.
Get rid of one or two of them.
So we just got one left so we can save it a few bucks.
We're seeing that all over the place.
And I think the, again, people overreacting to the advent of AI saying, well, SaaS can completely go away because I can just write my own software or I can use.
agentic services to do everything that I need.
I can do it completely custom.
I can do it from scratch.
I don't need Workday.
I don't need Salesforce.
I don't need SAP.
I don't need Oracle.
It's the death of everything.
I can see the justification for some of that, but at the same time, I think as AI continues to pan out, one of the immediate things that we're seeing right now is that there are these massive cost increases, these consumption-based increases for tokens, right?
Where They're giving away for 20 bucks a month all you can eat.
That's free.
I now have an engineer, an extra set of hands for $20 a month.
Well, we're going to quickly see that change to 40, 50, 60, $70,000 a year, depending on how much you're using it, where, okay, now it's not 99% discount.
It's maybe 50% discount off of an engineer.
So I think people need to be more mindful of how they use this stuff.
On the same token, companies that are not versed in software development and building these types of tools who run out and build something that works and serves the purpose today, six months from now, a year from now, 18 months from now with security updates and everything that we know that goes into software development, are they still going to have the appetite to continue to maintain this stuff?
Who knows?
And maybe they shift back.
So I think it's all very fluid right now with the AI technology, where it's going.
how it's going to be leveraged, how much it's going to cost to leverage it.
I think all of that stuff's very much in flux, but it's having a huge impact on the software industry as a whole.
You look at stock valuations of like the Salesforce and Workday and these guys, they're just getting killed in the market because of the perception that all of the SaaS-based stuff is going to go away overnight.
And I think that's vastly overblown.
I think there's some truth to the fact that it will shift.
But I don't think it's the death of SaaS yet.
Thank you.
A lot of good and interesting points there.
If people want to continue the conversation, where would they find you?
They can find me on LinkedIn.
And I'll make sure we include your LinkedIn profile in the show notes.
Thanks very much for taking the time to talk to us today.
I appreciate it.
Thank you for having me.