3 pillars for leading engineering teams with Adam Boswell

Illustrated by Matt Peet

We’ve all seen those motivational posters featuring fitness models, furry friends and buzzwords in all-caps across the bottom. They always offer some inspiring quote to accompany the photograph. There’s nothing wrong with cat posters eliciting motivation, per se—but these posters never offer practical advice on how to achieve it.

Now imagine if one of those posters transformed itself into a walking, talking example of how to achieve the call-to-action it portrays. That’s Adam Boswell, Director of Engineering at Kount. As the head of an organization offering AI-driven fraud protection for consumer and enterprise segments, the stakes are too high to rely on hollow motivational words. So when he offers to elucidate his three pillars of engineering leadership, he’s loading up actionable information as if the cat poster had an instruction manual beneath the meme-font text.

Adam’s three pillars are excellent engineering, awesome architecture and collaborative culture. These three principles uphold not just the work his Engineering organization produces, but their methodology and philosophy in accomplishing it.

In this interview, Adam defines the substance within each of these pillars. He offers concrete examples of these ideas in action and describes how, taken together, they can help engineering organizations reach their objectives with clearer value propositions, stronger communication, and deeper trust.

It seems obvious to say that an engineering organization is supported by excellent engineering. And, well, it is. But the methods of achieving excellence are much less self-evident.

Excellence cannot exist without a sound foundation in engineering principles. Adam defines these as discipline and replicability.

“We talk about best practices,” he says, “but really, here at Kount, [we emphasize] the ability for engineers to follow practices and patterns. An engineering excellence pillar plays into the ability to produce not just working code, but well thought-out, architected engineering.”

Establishing sound practices and patterns for engineers to follow is the groundwork for everything else to follow, because developers then are free to create truly exceptional outcomes.

Engineers in general, Adam says, are a passionate group of individuals. “When it comes down to it, there’s a lot of excitement around producing really impressive, amazing engineering, right?” he says. “That’s engineers at heart.”

But cumbersome engineering practices stifle that passion. When an engineering environment muddles the path for engineers—in other words, when neither their targets nor the practices to get there are clear—their energy goes entirely toward cobbling together functions. They’re stuck trying to accomplish the engineering part of their role and have no bandwidth left for excellence.

“When we talk about excellent engineering, what we’re identifying there is the ability to produce code that not only works, but that you're proud of,” Adam explains. Producing code that works relies on different methodologies, each one of which when used appropriately clears the way for engineers to do great work. “All of that rolls up to an engineer who is proud of their work and who is able to produce what they feel is excellent. A happy engineer always writes better code.”

So Adam helps employ the right methodologies, but then the fun really kicks in by identifying each engineer’s passions—the aspects of developing that excite them, and the types of work they most enjoy doing.

“There’s a space between the structure and the standard, and what you’re really passionate about,” Adam explains. “That's where excellent engineering thrives. You have a design where you know what success looks like. You have a different definition of success, and you're executing against that.”

Adam focuses on allowing engineers to produce things that they are passionate about while giving them guidelines, tools and structure to be able to perform to the best of their ability within well-defined criteria for success. 

This we appreciate very much: he likens the process to playing with Legos.

“Solution architecting is not an edict,” Adam says. “It's more like, ‘Here's a bunch of Lego pieces. At the end of this, we want a dinosaur. If you want to use blue pieces or two and two instead of a four piece, go for it. Do what you want to do to create it. Go and build it how you see fit.’ That has produced some exciting results. It gives latitude to the engineers. But the idea of success is really well-defined.”

Unfortunately (or fortunately—we’ve all seen Jurassic Park), Adam’s engineers aren’t actually building dinosaurs. But the terms of success are always made clear. Engineers know going in what the solution needs to look like, the impact it will have on the end user. That happens because Adam’s teams delve deep with solution architecting, working with Product on requirement-gathering and taking sufficient time to design and orchestrate what the success criteria are. 

The team requires these clear objectives and the correct tools to meet them. Then the engineers can engage their passion and creativity in solving how to arrive at those goals. Adam says, “You have the freedom as an engineer to solve the problem that's been put in front of you, in a way that you're really excited about.”

It’s no surprise that this next pillar actually supports engineering excellence. Adam understands how the tensile strength of solutions architecture actually bolsters the power of engineering. You can build a dinosaur much more effectively if you already comprehend how a dinosaur goes together.

“I'll start this off with a phrase that I didn't come up with, but has been branded on me since I've been here [at Kount],” Adam says. “And that is: a few hours of architecture saves weeks of coding. That is our core. We live by that pretty heavily. An opportunity to explore all the components and designs that we anticipate coming up, and doing the best to identify what it is that the solution needs to look like and what impacts that's going to have on the other components, is of utmost importance.”

Architecture, utilized this way, defines the solution. Engineers are free to build a dinosaur however they see fit, and it’s the architecture planning that decides the organization needs a dinosaur in the first place.

“We approach architecture as an opportunity to identify what a solution should look like, what the impacts and dependencies are,” Adam says. “And we go through that forethought beforehand.”

Adam hammers on that single idea that awesome architecture processes deliver clear, identifiable success criteria. From the outset of a project or sprint, execution plans and structuring are in place. But as so often happens, the process changes course mid-stream.

When that happens, Adam doesn’t let his teams flounder. They return to the core architecture every time.

“When something needs to change, we have the entirety of what the solution looks like laid down for us,” he says. “So those changes are easy to implement and to engage across. Now, sometimes they take a long time and they take a lot of effort depending on how far down the path you are. But the reality is, you're not guessing from the moment of change. You go back to the core, you have the design and the structure. You can make those changes at the solution architecture and push that back out.”

Because of their emphasis on these pillars, Adam’s teams are always solving for problems where they already know what the end result needs to be. So these mid-course adjustments end up being much less painful and much more powerful because they are still guided by a clear understanding of the dots they’re connecting.

Each time Kount’s engineers have such changes, they return to the core architecture diagram without exponentially extending the deadline. “We have the end in sight,” Adam says. “We’re able to apply to an architecture paradigm shift inside of there and quickly make adjustments. And it goes spectacularly, to be honest.”

When Kount first started emphasizing architecture-driven solutioning, the teams did a lot of handing off between the engineers and the architects. As the org progressed, they flipped things around. Now, the engineers don’t have to keep going back to the architects, because the architects are driving the execution through the entire development process.

“They’re engaged the entire time,” Adam explains. “They are involved less during the middle parts where code is actually being developed, but they’re really heavy on the front and pretty heavy on the backend.”

That means that the architects don’t simply design the end goal and then go hands-off. They’re present when Product comes back to Engineering with demo feedback. Instead of putting the implementation of that feedback solely on the engineers, the architect (who has the high-level vision of success in mind) can help make those adjustments.

“We learned pretty quickly that having that engagement from the engineer and from the architect together during those moments was significantly faster than queuing it up and pushing it back,” Adam says. “When a solution architect is responsible for creating a solution and handing it off to a team, she’s or he's always involved from concept to production. And those conversations can happen quickly.”

Constant, engaged conversations between architects and engineers (and between them jointly with other departments) are key to full integration of awesome architecture. But we all know about the conversations that don’t go that way. You know, the ones where other stakeholders say, “Just make this button work,” “Just get this feature out the door,” “Just do these things.”

“It’s a trigger,” Adam says. “We need to have better conversations and understand what everybody does here. Why do we feel like the things we’re asking for are so simple that we can use that word? That word indicates a lot of misunderstanding of what it takes to get things done.”

The (often unintentionally) demeaning use of “just” can generate resentment—in essence, dumbing down the effort and energy of an entire organization. Individuals and teams put in a high level of effort and work, and most of us never mean to demean that. So with the heightened frequency of conversations that happen with this style of architectural planning, Adam emphasizes “just” a litmus test for communication.

The test is essentially this: are you using the word “just” with your colleagues?

“Watch how you engage with each other,” Adam says. “A front-end engineer knows API connections are a lot of work, and a back-end engineer knows that it takes a lot of work putting things together. But a lot of times, you’ll still hear, ‘Hey, just write me a stub and get me the API working.’ You know what? That actually takes a lot of effort and energy.”

Becoming conscious of the ways we communicate with each other is a small yet radical shift in the sense of unity in a team. Again, engineers are passionate people who care about creating quality work. Engineers also have emotions tied into their results. Holding respect for those feelings and passions within the entire team is crucial.

“We want to work together,” Adam acknowledges. “We want to collaborate.”

The pillar of awesome architecture, then, requires the third pillar—a collaborative culture—to function at its peak. Adam understands that this culture of cooperation and collaboration extends not just throughout a project or a team, but through an entire organization.

When he first arrived at Kount, the organization ran in service teams that were more or less siloed with vertical reporting. He’s since helped blend those groups into singular teams that work together across a feature. “We make sure that that team is a cohesive unit with a lot of collaboration,” Adam says. “We allow that feature to engage across architecture. We have them talk to Sales. We have them talked to Customer Support. We make sure that there are no boundaries that are off limits for communication and collaboration inside an organization.”

Adam points out these additional beneficial results of this collaborative culture:

• Team members take greater ownership. Having conversations outside of the pure engineering team—with architects, for starters, and with other stakeholders—provides developers with a wider context for their work. “We find that context inside of those teams really fosters a collaboration of the ownership,” Adam says. “They take ownership of that feature. We work on this together, and this is our product.”

• Teams witness the impact of their work across the board. When Adam’s engineering teams develop something that goes into production, that team has the connections and context to understand what that feature does for other teams and for customers. “We make sure that the value of any given feature or any given product is understood, and that we foster those conversations outside of the organization,” he says. “And that has been a top-down approach. Our CEO sends out a weekly updates of life stories, things that are going well in the organization, things that aren't going well in the organization, how we can do better, what our metrics look like.”

• A collaborative culture has strengthened their resiliency. Like many organizations, Kount does team-building events—even during the pandemic. As distributed and remote organizations already know, building connections across time and space presents its own special challenges. But being removed is not an excuse for separation—and Adam has leaned into this collaborative culture when the times keep getting rough.

“We're making sure that we continue to engage as individuals with the rest of the organization, with each other, and making sure we foster and hold those conversations and those opportunities open,” he says. “Sometimes it works out great. Sometimes not so great. But we continue to try. It's definitely been a challenge to have that collaborative culture during the pandemic and with remote work. But we try to be clever. We try to find good ways to make sure that everybody's engaged to the best of their ability.”

Adam has found that building Kount’s Engineering organization on the three pillars of excellent engineering, awesome architecture and collaborative culture has driven his teams to establish sound processes and guidelines. It has given everyone the opportunity to create a framework for understanding the paradigm in which success is defined and for having effective, powerful conversations. And it has given everyone a shared language for discussing these principles.

“With these leadership pillars, I can go into a room and say, ‘Hey, we really need to focus on our excellent engineering. We're doing a good job, but here we can do better.’ And I don't have to unpack that,” he explains. 

It takes time to establish those pillars and their definitions across an organization. But that process brings Adam full circle: “I go back to the same thing,” he says. “It's architecture. Minutes of architecture save you hours of coding.”

This maxim holds true across all principles, he says, not just software development. It’s true for mentoring, management, even down to structuring and budgeting. But most importantly here, it’s true for leadership.

“The advice that I would give to anybody who's running an engineering organization is that taking time to critically identify what your success looks like and to know what you're driving towards is almost always the right answer,” Adam says. “It's almost always the right way to go.”