Adapting to Change in The Workplace with Steve Cumbia

Ledge: Steve, it’s really good to have you on. Thanks for joining us today.

Steve: Hi, Ledge. Thanks for having me on. I’m excited to talk to you.

Ledge: Can you just give a quick background story of yourself and your work, so the audience can get to know you a little bit?

Steve: I’m the Vice President of Technology at a company called ACS Technologies. We’re based in Florence, South Carolina. What we do, and have been doing since 1977, is build software for churches and other faith-based organizations.

I lead all the technology development, the IT and DevOps at our company.

Ledge: Before we hit record, you were telling me some of the history stories. You guys started when this was a pretty radical thing.

I’d love it if you told a little of the stories of the legacy technology going back.

Steve: Well, yeah, I like to tell people we started in 1977 and built software for churches, which was a crazy idea. I like to tell people, we were a startup when it wasn’t really cool to be a startup. It was just seen as dumb.

Where we started was a computer system called Datapoint, which the term used to be a minicomputer systems. All there were at the time were big mainframes and then this new version of a smaller business-oriented product, and that’s where we first built our first applications on. They were running on like 8-inch diskettes and maybe 64K memory. That’s of course the character-based user interface.

Ledge: Good old monochrome.

Steve: Yup.

Ledge: Did they even have like dot matrix printers for those back then, or was it sort like…?

Steve: Yeah, we had dot matrix printers. There were some hard drives. I think the first hard drive we got was maybe 5 MEG, and we were incredibly excited.

Ledge: That was huge, yeah. Absolutely.

1977, and here we are 2019. That’s an extraordinary longevity for a software company. I’m going to take the leap that that really has something to do with the grounding and mission and vision of what you guys do. Off-mike we were talking about that, that this anchoring mission.

Talk about how that fits into the corporate culture in the development of a software company because it’s not something you hear all the time, although I think there are examples of pet projects or things like that. But that core ethos of ministry, how does that fit in the world with you guys?

Steve: Well, it’s really interesting. I’ll start today, in 2019. When we go out and when we talk with other companies that are trying to appeal to millennials and to the younger generations, they want to do cool things and they also want to have a mission associated with their company. It might be anything, but for us that’s how we started.

When we started in ’77, the company was started by a man whose father was a minister and another man who was a minister. They got a group of like-minded people to put out some investment dollars to start the company.

As we’ve grown from there, one of the things that we’ve seen is that in Florence, South Carolina, there’s challenges in hiring people in the computer industry, and that’s the case anywhere now. What we found is we’ve been able to hire people who thought of the job as part of their personal ministry and enjoy the work and enjoy who their clients were.

We’ve been able to keep our good people for much longer than average in the computer industry. That’s still true today in our outreach to new hires. It’s not required, but often people find us very appealing as an employer because of the culture and because of the folks we serve.

Ledge: Yeah, and I imagine that that does fit well into the particularly generational changes. Being there from the start, you must have seen… Now you’ve worked with four different generations of ministry-minded individuals and software engineers.

Let’s talk a little bit about some stories there.

Steve: Well, that’s an interesting question. I think programming itself, the heart of it, hadn’t really changed in all this time. You’re still solving problems. You’re still writing code.

You mentioned that for our company, being around since 1977 is pretty good longevity especially in our market. We’ve seen several revolutions of change as we’ve progressed through the years. First, as I mentioned, the birth of the personal computing industry started with CPM and we made that transition from Datapoint. Then when the IBM PC came out that’s when the church really started to adopt our solution. IBM was king then, so being able to look at the device and see the IBM logo on it gave us some trust.

We went through this long period of success with DOS, and then Windows came out and so we had to make that transition. In today’s world, we’re trying to enable our products for the internet, so they should be accessible from anywhere, with any device. Now there’s a lot more need to specialize in front end, backend service, mobile development, whatever, but at the heart of it they’re all still doing the same thing, and it’s the same things we look for when we hired somebody in the ‘80’s. Is really very similar now.

We’re looking for people who see the work as what they do for fun first. One of our big interview questions is, “What do you do for fun?” Often they’ll say, “Well, I like to play around with technology. I like to code. I like to do this or that.” Maybe that’s more prevalent these days because there are so many more avenues where a person could do that. It’s different but it’s really the same.

Ledge: Absolutely is. How many full rewrites have you done in that period? Can you even count? Even the way you manage yourself or a project has fully evolved. There was just no such thing as agile or any thinking of that nature years ago.

You’ve seen so much in the industry, I don’t think a lot of people can tell those stories.

Steve: Initially, there was me and a couple of other programmers and we did everything. We wrote the code, we designed the screens, we designed the reports, we tested everything, we built the deployment, we made the diskettes and we sent them out, and often we supported the product. That lasted through the DOS age.

When we started building the product for Windows, first of all, our first Windows product was Windows 3.11 – I don’t know if you know what means but it was not a very stable platform, especially for a database. There were a lot of issues.

When we started building for Windows, we actually created a testing department. We had people dedicated to testing the application itself. It just wasn’t sufficient for developers to do that anymore. That transition from DOS to Windows, there was probably 100 church software products out there and only two or three made the transition to Windows.

We were successful with that. We still have a very large desktop solution out there – install base out there. But, when we started our first web application things got even more complex. That’s where we started having to get into automation and automated testing and things like that.

The other thing that changed, and this is another big revolution in the industry of course, is when you build a web-based product, your user base expands. You go from a couple of staff people that you can train and help all the time, to anybody in the world using your application. These are people you can’t really train, and they have high expectations because they’re using their banking software, they’re using Facebook, they’re using whatever, and that’s what they expect.

When we started building web applications and mobile apps, what really changed there was getting into design and learning how to work with and understand what user experience was and how to fold that into the development process.

Along with that, we started out with the agile practices. Our process was waterfall before that, so we took a bit of time to decide what we were going to do and plan it out. Then we took a block of programming time, then we took a block of testing time – and I’m talking months – and then we documented the process. Of course, what always happened was programming time took longer than you thought, so your tests and your documentation time gets compressed and you don’t get a good result that way.

As we approached agile, we really saw that as a quality initiative. How can we build quality in every sprint so that when we do release this, which we do more frequently, that they’re much more quality based?

Agile and then folding in UX to that. Now, thinking about DevOps in the sense of, we’re building the architecture with the infrastructure for hosting in mind and we’re building the infrastructure with the architecture in mind. Having that permeate our culture, that’s where we’re at now.

Ledge: You have personally had to learn all these things enough to both lead them and teach them.

What’s your learning investment and philosophy? It must have been just absolutely constant for that entire period of time.

Steve: Yeah. Absolutely. That just comes with this type of a job. You have to always be learning. Things are changing all the time.

There was a point in time where I transitioned personally from doing, from actually writing code, into managing projects, managing people, et cetera. So then you have to hire really good people and you’ve got to be smart enough to understand what’s going on behind the scenes. The concepts still apply. You’re still trying to write efficient code that manages resources effectively, et cetera.

I’ll tell you where the biggest barrier for us, being in Florence, South Carolina – and we’ve had offices in Seattle, in Phoenix, and we have a new office in Greenville, South Carolina now. For us, it was design, it was user experience and learning how to bridge that gap.

I actually got a master’s degree in Human Factors a couple of years ago because I felt like there just isn’t a design community anywhere near us that we have access to. I felt like I had to make that investment, and it was really beneficial for me and I think for our company.

Ledge: The next evolution probably in the workforce and in engineering really becomes, we see it all the time, is the sort of remote and distributed teams. Are you dabbling in that at all? You’re actually not going to be limited to geography anymore and the technology infrastructure has evolved rapidly to support that.

Steve: Yeah, we do way more than dabble in that. About 40% of our development group is not in Florence. We have offices – and like I said we have one in Phoenix now and we will have one in Greenville, South Carolina now – but we also have folks who are all over the place. Just, wherever. We’ve had to embrace that just to get the talent that we need to be able to do what we’re trying to do.

So, now how do you manage? Well, agile helps you with that. You have a daily scrum and you have a very set rhythm of meetings, or we call them ceremonies, but you have a set rhythm where you’re in contact. Then we use tools like Slack. We couldn’t live without something Slack. The teams are constantly in conversation over Slack. With tools like Slack and with Google Hangouts, if the conversation becomes more complicated you can always jump online and have a video chat. That’s how we operate now.

One of the things I’ve found, though, we have some teams that are co-located. So we have some teams here and they’re full here. Then we have teams that are fully remote. If you’re the team that’s part one way and part the other, those are the ones that struggle. If you’ve got one guy that’s remote on a team of five or six people, that doesn’t work very well. It’s just hard to make that leap and to do the things that you have to do to have effective communications.

That’s a challenge. We try to stay sensitive to that. But, anyone who’s launching into the remote worker world, it’s all about communication. You’ve got to be disciplined about it. You just can’t let that one person slide. It just won’t work.

Ledge: Yeah. A lot of the tech leaders that I’ve talked to also are trying different approaches to that hybrid team, where there’s four people together and four people distinctly remote, not co-located together.

Some of the best practices seem to be, well, everybody who’s in the office you’ve got to act like you’re distributed and remote so we have effectively eight individual remote people – some of whom actually sit in the same space. You need to use the tools as if everyone was remote. That seems to be the only way that folks right now are bridging the hybrid gap.

Steve: That’s for sure. Sometimes you have to be at the other end of it. If you’re on a team that’s mostly co-located, work from home one day a week and see what it’s like.

Or, here’s what we could see. It’s kind of funny. We have people who are spread out and then now they’ve come together in this Greenville office, well they don’t embrace to being together as much. They still act like they’re remote. It’s just interesting. They’ll still talk on Slack even though they’re sitting right next to each other.

Ledge: I remember when worked in that direction for the first time for me and like, this is funny, we all just sit here and chat each other. Yet there was no session for structure, for even everything about thinking about being remote, but the workforce quickly co-opted AIM instant messenger, because it was just, “Wow, this really works,” Management didn’t know what to do with that. This was a security disaster.

It seems like teams are going to take to the course of least resistance to get the work done.

Steve: Right. That’s what happens. I’ll tell you, for a company like ours, we still struggle with it.

The development group is pretty comfortable with the remote management stuff. The rest of the company, not so much. Their talent pool is restricted. We were talking about, before we started, how hiring and keeping technical folks these days is really hard. There’s just way more demand than there is supply. It’s almost a negative.

Ledge: I’ve heard some people describe nationally that we’re at a 20% shortage of qualified engineers. Mash that up with a growing economy and software eating the world, it’s almost unavoidable that we’ll face some kind of issues.

Which I think broadly speaking, in a macro sense, helps to explain major culture shifts like DevOps and things of that nature. If you can’t get more humans, you need to get more productive with every minute of human time.

Steve: That’s our story. We have to be. I think, to get back to the mission idea, that’s one of the things that helps us keep good people. They like what we’re doing. They like our clients. They use our products. We have a solution for checking in kids on Sunday morning. It’s a security measure isn’t it? If you think about it, 9:00, 10:00, 11:00, all up and down the East Coast, and it, our system is peaking because there are folks, thousands and thousands of parents dropping off their kids, printing badges, interacting with our product.

Ledge: I do that on Sunday myself, print out those little badges.

Steve: The cool part of that is, we do that. Our folks do that. Our employees do that. Our developers do that. They run the kiosk sometimes.

We use the product and we make sure that thing works, because that’s a big black dye if you’re going to church on Sunday morning and that system is down. That’s chaos.

Ledge: Right. It’s always chaos when production is down but, yeah, nobody has a backup plan.

It strikes me, everybody in your customer chain or your value chain is reasonably capital constrained. That’s the nature of that type of environment. You have to do more with less, broadly speaking. Let’s face it, we have churches and especially in the south that are pretty big and pretty well funded, but overall that cohort from a non-profit perspective – schools, churches – is not someone that you get into SaaS software and think, I’m going to make a killing here.

Steve: No. It’s like I said, we build an enterprise solution but we don’t really charge an enterprise price for the most part. How can we provide in today’s world a system that does the job? Those are our challenges. We have to be really efficient and focused, and we have to make sure we build the right things.

That sometimes goes without saying, but there’s a big effort in this company to make sure we’re building the things that people need, and we measure that. When we release a product or a feature, we look immediately at how it’s being used. Almost always our stuff gets used heavily, but sometimes we miss the mark there too.

Ledge: Steve, last question. Appreciate all your insights today.

Advice for folks who are trying to build up an engineering team and are looking for that mission-driven maybe even ministry-driven kind of approach. You’ve done a lot, you’ve seen a lot, probably tried some things that didn’t work. What are some major takeaways for that?

Steve: Well, let me go a couple of different directions with this one.

One of the things we’ve had most success with in the last five years is interns. We did a really strong outreach to the local university here, Francis Marion, but we also have the University of South Carolina, we have Clemson College, we have Furman University. There’s several others in South Carolina that we built really tight relationships with. We have good relationships with the professors that lead computer science and other departments.

These departments, especially the smaller colleges, they might graduate seven or eight people a year. The programs are hard, and those seven, eight people are pretty good and we’ll get the best one as an intern. When we get an intern, we give him real work to do. We’re doing some stuff with Go and Go language and Couchbase now. These are newer technologies. They’re more cutting edge. We’ll get them to learn that stuff and build something with it.

You pretty quickly… It’s a job interview really for us, and for them its’ a good experience. We’ve hired a number of interns, probably 15 the last three years, somewhere in that number. They are some of our best performers, even more so than someone who’s been doing the job 20 years, sometimes. There’s that angle.

The other angle is, as much as possible, give the development teams autonomy and ownership of the problems that we’re trying to solve. We’ve made the mistake of saying, “This is how you’re going to do it, and do it this way and then we’ll talk about it.” They do a lot better if they feel like they have some room to learn, grow, explore and come up with their own solution to the problem. That could be the tech stack, it could be whatever.

One of the companies we’ve looked at and learned from is Spotify. They have a series of videos about how they’ve launched agile, and really post-agile, and there’s a lot of really smart thinking in those videos.

But, definitely embrace agile or some component of agile. I know there’s a lot of stuff out there that’s negative but you’ve got to make it work for you and find your sweet spot with it. Everyone will appreciate that if you do.

Ledge: Steve, thanks so much. Fantastic insights. Great to have you on today.

Steve: Great. Thanks for having me.