From talking points to tangible outcomes: How we built an engineering culture that actually works

Much has been written about engineering culture at mature organizations. But case studies of early-stage, focused, high-growth companies are rare. I have worked on engineering teams at several different organizations, and I’ve been with mParticle for nearly two and a half years now. At this company, I have consistently observed a culture of intent and cohesion across the organization. This culture is reflected in everything we do; from the way teams operate on a day-to-day basis, to the source code that makes our product so exceptional and unique. 

These are rare characteristics to have in any organization, let alone a high-growth software company, as egos and strong personalities so commonly inhibit this type of culture. That’s what motivated me to write this post: How did we do this? What’s different about mParticle that allows us to maintain this unique and intentional way of approaching work? 

After reflecting on my time here and speaking to my engineering leaders and colleagues, I’ve pinned down four key reasons why mParticle’s engineering culture goes beyond words to day-to-day practice: 

1. Good ideas are heard and respected, no matter your level of seniority
2. Clear and open communication is strongly encouraged
3. Our leadership walks the walk. They promote and foster these values across our squads 
4. Our forward-thinking Engineering Ladder highly values individual contributors

Let’s go into detail on each of these points. 

Many engineers who work at mParticle have been with us from the beginning. In fact, a good number of them followed our co-founders from other successful ventures. The product has been created and raised by professionals who have proven themselves to be phenomenal engineers for more than a decade. The standards are high, because when you build something here, you’re not simply building it on the shoulders of giants; you’re building alongside those giants.

In many companies, a well-entrenched senior echelon can often turn into a senior elite clique. This is simply not happening at mParticle. First, the founders instill a zero tolerance policy for pulling rank.  The result of this is that reason and good ideas always prevail over the force of egos. I think this tendency flows out of a paradox within mParticle. The success of the company rests on the output of the Engineering team. Management trusts in not just their ability, but in the fact that they take that responsibility seriously enough to try to understand deeply what the customer wants, to write thousands of tests, and to undergo rigorous security reviews before anything is shipped. And because of that autonomy–not in spite of it–there’s an unspoken understanding that each relies on the other. Each individual feels like their contribution is critical to the collective success.

The sense of mission that motivates our Engineering team manifests, for example, our extensive rollout requirements. A project is not considered for rollout until a comprehensive checklist is completed. The checklist informs things like service security, monitoring, costing, startup and shutdown, SLAs and more. Greater than the sum of its parts, it sets a spirit of quality that is characteristic of the mParticle.

One crucial benefit of shared values is clarity. While this post is focused on the engineering culture at mParticle, the fact is that the engineering culture and the mParticle culture are the same. Like Engineering Manager Kevin Prudente told me, “This is a result of leadership’s willingness to communicate as directly as they can—there is nothing left to interpretation.” The same level of dedication and deliberation in the Engineering team are evident throughout the organization. Wins in any department are felt and shared throughout. Every arm of the organization informs the others, creating a constant feedback loop that enables the evolution of the value that ultimately arrives to our customers.

An excellent example of how we try to integrate different parts of the organization can be gleaned from our onboarding efforts. For engineering newcomers, our Solutions Engineering team, the same folks that wow prospects on live demos, hold hands-on, in-depth run-throughs of the platform on a variety of mParticle features. While these courses could be run by Engineering, instead they are very intentionally offered by the solutions team, and used as an opportunity to share the customer’s perspective whenever the opportunity arises. 

When I began my journey to identify the “how” and “why” behind our unique engineering culture, I started at the top, and reached out to Andrew Katz (or AK, as we call him), mParticle CTO and co-founder. He explained it to me like this: 

“It’s a virtuous cycle. You start with a hard problem. To solve that problem you’ll need some smart people. But smart people are important to hold on to, so you have to keep them happy. And when you keep them happy they go on to solve bigger problems, and now you need more smart people. As the problems you get to solve become more interesting and complex, the company grows to include more smart, talented, and curious people interested in solving those problems.”

This process is a natural extension of the philosophy on which mParticle was founded. The company was designed to evolve. One of AK’s maxims is that you want to build software that will last around two to three years until the next major revision. If it lasts longer than that, it’s likely you spent too much up-front cost on it. If it doesn’t last that long, then too much cost is sunk in refactoring. The software we build at mParticle is always complete enough to tackle the known problem, and flexible enough to adapt to the next one. Engineering economy and elegant simplicity are behind everything we build at mParticle.

Many companies have values. Often, these are written on a mission statement on a website, and people tend to forget about them in their day-to-day work and interactions. That isn’t the case at mParticle. Like Michael Katz (yup, MK), our CEO and co-founder, has immortalized, “It's important to create an environment where we have consistent values that serve as the basis for our operating instructions. We are ALL accountable for upholding our values and standards, and must relentlessly eliminate fear across the organization to truly be successful.” 

Every team at mParticle is responsible for sketching out a V2MOM (it stands for Vision, Values, Methods, Obstacles, and Measures), a template designed to help fast-growing organizations communicate and align on essential values. Even at the Individual Contributor level, no one has to guess what decisions are important for the company. 

The V2MOMs are very much living documents at mParticle, actively updated and frequently cited. V2MOM’s from the CEO down to Engineering Managers are very visible, and carefully crafted in proportion.

Out of a shared sense of responsibility, important systems have emerged that help our engineering community scale. One program that I personally admire is mParticle’s Engineering Ladder–a document that describes the behaviors a Software Engineer exhibits at different levels in their career. It sets clear expectations for engineers, and provides managers guidance on how to help their reports push to the next level. 

What makes this structure stand out from those at many other Engineering orgs, however, is that it lays out not one but two possible career paths for the engineer, and allows for steady advancement while remaining an individual contributor. At every other company where I’ve worked, all engineers were eventually expected to take on team management responsibilities. Leadership requires a unique skill set that does not necessarily overlap with being an excellent engineer, however, so not all high-performing developers would excel as managers. In fact, this ends up being a setback, both for the company and the employee.

The mParticle Engineering Ladder describes an engineer from E2 (E1 is reserved for temporary engineering roles) all the way up to E8 (Distinguished Software Engineer), and while management paths emerge at level E5, the individual contributor (IC) path continues up to level E8. mParticle recognizes that not every engineer aspires to management, but cultivates a stable of highly expert folks. 

Not only is this a very progressive attitude that engineers benefit from on a personal level, but the practice also enriches the organization as a whole by generating increasing numbers of highly-productive people. One way mParticle helps the organization grow is by assigning those with deep understanding of an area of the product to the position of Practice Lead. As a Practice Lead, the engineer devotes some of his or her time to act as a resource on their domain. Having individuals like this in all areas of the application drastically reduces the time and friction spent on solving problems. 

“Investing in your people always gives you a greater return on investment than anything else,” says Lee Morris, a Senior Vice President at mParticle who was instrumental in developing and rolling out the Engineering Ladder. “It’s an honor for us to have these amazing engineers here, building their skill sets and developing their careers at mParticle. It’s our responsibility to make sure they succeed and grow, and that’s reflected in the way we structure advancement, our mentorship initiatives, and everything else we do.”

Applying best practices uniformly in the source code is a high priority. Practice Leads play an important role here, but they can’t be everywhere at once. The next best thing at mParticle are committees charged with clarifying Standards for the various areas of development within the organization.  For example, the API Committee focuses on standardizing the interactions between our various API endpoints, and code quality standards are becoming more common. As this work is ongoing, one thing we’re learning is that coming up with meaningful standards is far from trivial, and right up there with naming variables and cache invalidation, finding time to do this right is an area we’re growing in.

While the engineering culture we’ve built is working well, we view it as a work in progress. At the end of the day, we’re engineers. We never consider any product to have arrived at a final, perfect, complete state. Everything we build is open-ended, waiting to be stress tested, iterated on, and improved based on real-world use and feedback. Of course, this includes our internal culture. But while the specifics may change over time, the principles that guide them will remain constant. If you have found the aspects of our culture that I’ve laid out here to be inspiring or interesting, I hope you can apply them on your own team in your own way.