Personality Over Skillset: How Adam Wachtel Builds Engineering Teams Transcript, AI Summary & Key Points

Postgress shouldn't force you to choose between transactions and analytics. Tiger data creators of time scale DB adds hybrid row and columnar storage 95% compression and continuous aggregates. So both run in one Postgress database. Try it free at tigerdata.com/go/trial. Good day folks. This is Shane Hasty for the InfoQ Engineering Culture podcast. Today I have the privilege of sitting down with Adam Wtel.

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 Martell. I'm the chief technology officer with Clickboarding. We offer a web-based SAS product that automates processes around onboarding and offboarding of employees in generally the enterprise space.

I've got let's see coming up on 25 years in the SAS B2B tech area. uh 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 is 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. You know, obviously the 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 rooms of project managers, we don't have rooms of product owners. It's usually 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 in 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 and 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 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 3 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, you know, 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. You know, we're talking onboarding and offboarding is not the most thrilling topics, but when we're doing it in, you know, an engaging, fun team environment, I found that 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 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 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 reeaming activity that can be quite disruptive. How do we do that? Well, >> in my experience, again, I've been through a couple of acquisitions, you know, 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 were 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? We, you know, 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's 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. And it was in a bad state when I first got to clickboarding. The, you know, 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, it's, you know, 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 Fortune50 area.

So, huge clients, lot of transactions, huge bottleneck. 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, you know, we made a lot of progress there.

At the same time, what little time we had left over, we're contributing to the product in terms of new features and things. Over time, over the 4 and 1/2 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 you know 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. 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 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 and we'll figure this stuff out.

So, you know, that mindset is very important. And they were kind of in a to use your term, death march when they got here. They weren't 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 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 is I more likely was a a strong technologist and been put into that position of okay, now you've got some people to look after. Where do I start? I think one of the the most challenging things that I see with new leaders particularly in this space again these are they're 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 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 you know 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, you know, delegation, building that trust layer. And then that also helps the folks that are on their team with, you know, kind of how they 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 the wider ecosystem, teams are very well are they very different today than they were even 2 or 3 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 postco 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 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 the guidance is followed.

So, I say again, I think it probably shrinks the total number of required people for a team. It accelerates the output, but the the makeup of the team, yeah, I think stays largely intact. >> That's somewhat contrary to the, oh, woe is us. All of the junior engineer roles are 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 SME against all of these things. I got to 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 source team and very few people knew how the guts of the system actually worked 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 people overlever it writing all this code it

looks great 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, like I think the biggest controversial topic is the quote the death of SAS, right? enterprise applications are all going to go away.

You working for a SAS company that's impacted our sales cycle. We're seeing a huge amount of consolidation in business technology. At Clickboarding, we're a small company. We're about 45 employees. We've been consolidating technology. We've got, you know, two or three tools that do almost the same thing. Get rid of one or two of them so we've just got one left so we can save 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 SAS 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, you know, 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, you know, they're giving away for 20 bucks a month all you can eat.

That's great. 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, 6

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 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 SASbased stuff is going to go away overnight. And I I think that's vastly overblown.

I think there's some truth to, you know, the fact that it will shift, but I don't think it's, you know, the death of SAS yet. >> Thank you. A lot of 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.