An Innovative Approach To Building A Software Organization That Doesn't Frustrate Engineers

This CTO explains how a flat organizational structure and a methodical employee offboarding process can help engineers flourish.

After an engineer is hired at MX Technologies, but before that engineer touches a single line of code, there’s a reading assignment that has nothing to do with company policies and procedures. New MX engineers are given two books: Zen And the Art Of Motorcycle Maintenance: An Inquiry into Values by Robert Pirsig and This Is Water: Some Thoughts, Delivered on a Significant Occasion, About Living a Compassionate Life by David Foster Wallace. Teaching engineers about an industry — banking/ finance in MX’s case — is the easy part, says cofounder and CTO Brandon Dewitt. Teaching them about a company’s purpose, the importance of quality, and individual accountability requires something more. And that “something” cannot be found in the pages of the employee handbooks so often distributed to new hires. At MX, that “something” is rooted in philosophy.

The philosophy Dewitt describes when talking about MX is more than just a list of company values adorning office walls. It’s a fundamental way of creating software, shipping that software to end-users, and then doing it all over again that seeks to alleviate both the fear and the discontent that plagues so many software engineers today.

Talking philosophically instead of discussing database structures or management layers with new engineers is certainly a unique approach. Then again, there’s much about Dewitt and MX that is unique. In 2010 Ryan Caldwell founded what is now MX, while a few months later Dewitt cofounded MyJibe, an Indianapolis-based personal finance web application company. In 2011, their paths crossed at an industry conference, when they discovered both a mutual love of philosophy and that their two companies — and complementary skill sets — could perhaps unify and build something bigger.

Before they teamed up, though, Dewitt had a cash offer on the table for his company from a third party. He flew to meet with Caldwell in Utah to check out MX and never left (MX still calls Utah home today). High-level strategy and roadmap discussions turned into Dewitt’s crashing at Caldwell’s place and borrowing his car so they could keep cranking out code instead of Dewitt flying back to Indianapolis. In November 2011, they merged their efforts when MX acquired MyJibe. The rest, as they say, is history. Except MX’s history with how it hires, manages, and parts ways with engineers is markedly different from most of its software company peers. And in being different, Dewitt and MX might have found a cure for an epidemic in the software industry.

A Philosophical Problem Facing Software Developers

“Frustration.” “Disillusionment.” “Atrophy.” Those are some of the words Dewitt thoughtfully uses to describe a cadre of talented developers who are less than happy to go to work every day. For those unfamiliar with the software industry, it might be hard to understand why some of the most sought-after, highest-paid group of people in a generation can be frustrated. Here’s why, in a simple, hypothetical scenario Dewitt describes.

Bright, hungry, excited new computer scientists and mathematicians enter the workforce. They find a job making a lot of money. The job is to optimize a single pixel to make it the most attractive pixel that’s ever existed, a pixel that can generate the most clicks. They then have to measure and analyze why many people didn’t click on that pixel. They’re told to build something solely to generate more clicks. That cycle repeats again. And again. And again. The code they write might not got out to production for months. In a given year, they might work on only two or three pixels. They get restless. They look for another job at the software firm next door that might just give them a few more thousand dollars to work on a different pixel.

Dewitt likens the scenario to domesticating a wild animal (and he means no offense to software engineers with this comparison — or, depending on how you look at it — he means no offense to dogs either). Dogs need to run and play and hike and bask in attention. Too much time in a crate or too many toys, and that dog will become frustrated and resort to lazy, nap-filled days. “There is this atrophy that has happened in our industry over the last decade,” Dewitt says. “Heaps of toys have been given to this generation of developers. We’re telling them ‘Use the ping pong table and optimize that pixel, and if you do that, we’re going to be okay with whatever you do.’”

“THIS FEAR WITHIN THE SOFTWARE INDUSTRY EXISTS IN QUESTIONS LIKE, ‘AM I GOING TO BE PART OF A LAYOFF?’ ‘AM I GOING TO BE FIRED?’ ‘IS MY QUALITY JUST NOT UP TO WHERE IT NEEDS TO BE?’ AND ‘WHAT ARE GOING TO BE THE SIGNALS THAT SHOW ME THAT I’M GOING TO BE FIRED?’”

Brandon Dewitt, Cofounder & CTO, MX

This generation of developers is too often boxed in by corporate structures. They’re not able to run with their innate curiosity. Dewitt says, “It’s this thing that has grown in our industry, at least for many engineers I know well. Yes, they’re earning six figures, but they’re getting paid to sit through bureaucratic proceedings and not necessarily to express their own creation and creativity.” To solve this, Dewitt and his team did away with the bureaucratic proceedings when building this company. MX has a saying: A well understood philosophy will subordinate any policy. Those policies are governed by a flat structure.

An Engineering Team With A Flat Structure

That “thing,” that disillusionment of software engineers, is something Dewitt sees when MX works to fill open positions. “I’ll be talking to people in interviews and they’ll start to ask questions like, ‘Okay, where do I go to get the things that I need to do? Who’s going to sign off on what I need to do? Where do I go to check in the code? How long is it going to take me to check in the code? How long is it going to take any user to use it?’”

Engineers are accustomed to too much bureaucracy and not enough engineering. At MX, a developer might work on 200 or 300 releases each year. As CTO, Dewitt doesn’t dictate who works on what and when. He’s out on the floor with the engineering team, and all leaders on that team spend a minimum of 50 percent of their time contributing code. He explains, “If you’re going to lead from a service-oriented perspective, you have to have actually served in that role and have intimate knowledge of what executing in that role requires.” Dewitt isn’t the only member of the engineering team who knows what it takes to do the job. MX has several engineers who were C-level or VP-level executives at one point in their careers. At MX, they’re equals in a flat structure, where instead of being stuck in the day-to-day management grind they could be “part of a creation story again.”

So, what does this look like in practice? Well, if engineers find something that resonates, or something that could be improved, the expectation is they’ll go down that rabbit hole. Dewitt sees something like this play out regularly: An engineer will come in with database experience or mobile experience, and that engineer will pick up on something in the UI that needs changed. So, it gets changed. And quickly. And without Dewitt needing to approve the work or oversee the process. It supports another one of those sayings at MX: You should be making mistakes of boldness, not of timidity. “You watch people go from this place where they were stuck in this grey bureaucratic world, and then they bloom into individuals, some of whom are now doing hundreds to thousands of pull requests a year.”

This flat structure that produces empowered engineers wasn’t just something that happened. It was a decision the company chose from the start. After Caldwell and Dewitt joined forces, they brought their engineers together. They wanted to automate as much as possible in order to be as passive as possible so that responsibility rested at the individual level and not at a management level. Dewitt presented two ways they could build this newly formed software organization:

1. They could bring in directors and managers and VPs to be in charge of communication and accountability. Engineers will be responsible for executing the orders given by those directors and managers and VPs.
2. They could not bring in directors and managers and VPs, and individuals can be responsible for discourse and quality. Plus, individuals will get paid a little bit more because they won’t have to pay directors and managers and VPs.

No surprise, number two was the choice. It was a unanimous choice, but it still wasn’t an easy choice. The hard thing about a flat structure is that it requires accountability. How do you decide whether something is good enough to push out? How do you measure the quality of your code? Answers to these questions can be found in those philosophy-heavy reading assignments given to every new engineer. “One of the foundations we want to lay is the concept of, ‘What is quality?’ It’s not quality to do the very least that can be done and to push it out to millions of users,” Dewitt explains. “When you really start diving into that age-old argument about quality, it really forces individuals to think more deeply about these endeavors — whether it’s to create an experience or a platform or even just an administrative tool for the rest of the organization. Accountability has to be viewed in this idea of quality.”

Accountability In Offboarding Employees

Quality and accountability are even at the center of how MX parts ways with employees. While many executives are eager to talk about how unique their hiring processes or new employee onboarding procedures are, Dewitt is an open book about how MX fires people. To him, a well-constructed offboarding process is one of the most important things any company can do. “We do part ways with individuals who do not end up finding that ability to contribute, communicate, have the accountability, and hold the standards of quality,” he says. “A lot of people ask me, ‘When do you start firing someone?’ My answer to that is, ‘I start firing someone the first day that I meet them in an interview.’”

Taken out of context, that soundbite might make an engineer think Dewitt is a nightmare of a CTO. But that couldn’t be farther from the truth. “There is no more powerful force in our industry than fear,” he explains. “This fear within the software industry exists in questions like, ‘Am I going to be part of a layoff?’ ‘Am I going to be fired?’ ‘Is my quality just not up to where it needs to be?’ and ‘What are going to be the signals that show me that I’m going to be fired?’” MX’s offboarding process is designed to remove that fear from day zero, before someone is even hired.

During the interview process, candidates learn exactly what the offboarding process entails. If you’re struggling, you’ll start by having one-on-one meetings with a lead engineer. If that doesn’t resolve the issue, Dewitt will then meet with the engineer on a Friday to officially start the offboarding process. From there, the engineer will have at least six weeks (sometimes up to 10 weeks) to turn things around. Every Friday during that time period another one-on-one with Dewitt will take place to discuss progress being made (with measurable data, of course). It’s very rare that someone makes it to the end of the time period — Dewitt can only recall a handful of times that has happened. Usually one of two things happens first. One, the person course corrects, maybe by starting to work on a project that is a better fit for his or her skillset. Two, the person decides MX isn’t the best fit, and for the rest of the time period the company will assist the engineer with searching for a job elsewhere that is a better fit.

Skeptics might question why MX will keep someone on the payroll and help that someone find gainful employment elsewhere. But the true benefit of the process is best explained by another one of MX’s sayings: The offboarding process is not for individuals who are being offboarded; it’s for the ones who are still here. “Yes, it costs us money because we’re going to pay people to find other jobs,” Dewitt says. “But this helps make us more cohesive, more outspoken, and so it’s worth it at every single step.” Engineers don’t have to worry that speaking up in a meeting or experimenting with a new feature will put them on a fast track to unemployment. Instead, they can speak freely and code freely without that stress.

“Simply by taking a fear of unknown to a known fear, we see individuals proliferate without questioning every step of their day.”

Building The Impossible

As Dewitt talked about the reading assignments and philosophy and his idealistic view of how work can be more meaningful when given the right organizational structure (or rather, lack of structure), he admits it might sound “squishy” to someone unfamiliar with MX. And that’s fair — it’s not as if Dewitt redirected the conversation to the “non-squishy” topics software companies so often discuss when describing success, things like growth rates and capital raised. For MX, the definition of success expands well beyond its bottom line.

To explain that definition, Dewitt compares the ideal work environment to El Dorado, the mythical city of gold. A person’s conviction in defending that myth wouldn’t be very strong without proof that it exists. But if someone could see a city of gold, capture video of it, show it to friends, and know that it’s possible, then the conviction would be much, much stronger.

“I wouldn’t claim in any way that MX is the city of gold,” Dewitt says. “But what I would say is the goal here is to create an organization such that when someone leaves here for another organization and they’re asked to compromise their morals, they absolutely defend until the very end of their careers that they do not have to compromise. And that’s because they have seen what is thought to be impossible here, when individuals who’re aligned with one another philosophically can achieve a unified goal.” And just as executives leave companies to join MX, there have also been quite a few people leave the MX engineering team to start companies or join the C-suite at other companies.

Dewitt seems very content to stay put at MX. The company is growing, is cash-flow positive, and is profitable. The code he deploys makes a tangible difference in the lives of financial institutions and in the lives of the customers who rely on those institutions. His job allows him to create both software and a team of happy, fulfilled engineers. Dewitt doesn’t personally feel software developer frustration he so eloquently describes, and that’s despite the fact that he was diagnosed with a rare type of cancer in January 2016, at age 33. More than a dozen tumors littered his lungs and the left side of his face. Doctors gave him an initial prognosis of far less than a year. More than three years later, Dewitt has proved that prognosis wrong, though his treatments continue. In fact, he phoned in for an interview with Software Executive the morning of a chemotherapy treatment. And it was his birthday. And he likely did some coding and creating that day, as he continues to build an organization many engineers think is impossible.

MX Technologies

CEO & Founder: Ryan Caldwell
CTO & Cofounder: Brandon Dewitt

Headquarters: Lehi, UT
Year Founded: 2010
Number Of Employees: 200+

Vertical: Banking

Funding: $72 Million

Key Investors: USAA, Digital Garage, Commerce Ventures, TTV Capital

Honors, Awards & Recognition: American Banker 2019 Best Fintechs To Work For, Entrepreneur 2018 Top Company Cultures, Salt Lake Tribune 2018 Top Workplaces,Utah Business Fast 50 for 2018, Finovate Best of Show (6 Years)