How Moov thinks about engineering culture
What’s the best way to recruit phenomenal engineers? It’s not just the stock options and home office stipends (yeah, we do that, too). Engineers’ interest piques when they’re challenged. That’s why the best engineers want to attack gnarly problems.
But that’s only half of it.
Every technology company has problems to solve. Offering challenging projects isn’t enough to attract talented builders. The single best way to build a first-rate team is to offer them an environment to thrive in. I know this isn’t a new concept – you’ve probably heard it before from listicles, books, TED Talks, and leaders much smarter than me. But as a builder myself, having been in every role from an individual contributor to a leader of engineering teams, I know that my definition of “thrive” is a bit different than most.
While building Moov, I knew that I was in a unique opportunity to create the blueprint for the exact work environment I wanted as opposed to addressing it after the culture is set in stone. In order to build an environment where the most technically-competent and creative problem solvers would want to join and lead, I had to make creativity, experimentation, and failure mandatory. I had to build space for curiosity and iteration. It meant establishing a culture focused on one of our most important values: respecting the craft.
A few months ago, I had the privilege to sit down with Eiso Kant (Founder & CEO of Athenian) and Jason Warner (MD at Redpoint & Former CTO of GitHub) for an episode on their podcast Developing Leadership. We discussed building companies, attracting great software engineering talent, and increasing velocity as you scale. We discussed the process of respecting people’s craft.
But what does that mean? How do companies find individuals who treasure their craft and the craft of others? How do we approach this core value at Moov?
I’d like to go a little deeper and answer those questions today.
Building the team at Moov has helped me realize that I can’t be the best programmer. I don’t need to be. My focus is on creating the right environment that allows creatives to thrive.
Solving problems > shiny new technology
It’s 2022, and Moov is the only cloud-native acquiring payment Processor. That blows my mind. But with that statement alone, who cares? What’s behind those words?
When interviewing potential hires, I usually come across two types of engineers. The first type immediately ponders how we built our platform and what tech we’ve chosen. They’ll ask specific questions about scalability, microservices, and a whole bunch of nerdy and wonderful stuff related to our tech.
The second type takes a different approach. They want to understand why we built our platform and what value we bring to the world. They want to understand the root problem and decipher how much room there is to continue chipping away at it. Of course, they have questions about our technology choices, but for them, that’s secondary.
Being willing to ask tough questions and find better solutions is a necessary driver behind creative exploration. Team members concerned about iterating and improving real problems, even if it means they fail and have to try again during their journey, is better for the team than wanting to collect technology checkboxes or use the latest sharp tool. Deep down, engineers know that the best thing we can do as a startup is to bring value to end-users, even if that means using certain tech to get the job done.
The shortest path to bringing value to users is all that matters. Don’t wait for the shiny new tech. Deliver value, learn from users, and repeat.
The only three metrics you need
Understanding the health of your engineering org comes down to three metrics. Yes, only three. Getting caught up in the nuances of OKRs, Kanban, Sprints, and the numerous other frameworks we use is a distraction. Turning these things into religious ceremonies has very little to do with excellent engineering and building meaningful products. Yes, there is a time and place for these processes depending on the size of your organization, the problem you’re solving, and the maturity of your team. Ultimately, these are just management tools that lead to the desired results.
But process is not craft.
If you want to discover how much your engineering team respects the craft, answer these three questions:
- How fast are we shipping?
- What’s the churn on our code-base?
- How long does it take to go from pull request to prod?
Great results don’t equal great code, but poor results should be treated like a dead canary in a coal mine: time to figure out the issue. The answers here speak directly to the inner workings, beliefs, and day-to-day principles of your dev leaders. They are the ones who create the policies and define the workstreams that enable the team to deliver. You want engineers focused on excellent practices but who deeply understand the value of getting the product out the door.
Don’t take my words here as an excuse for sloppiness. Code quality matters. But there’s an art to balancing experimentation with shipping value, and understanding that perfection is unrealistic. Respecting the craft finds a magical cadence that allows room for both.
Sharing is caring
Another aspect of respecting the craft is one’s willingness to share what they’ve learned with teammates and other developers across the globe. For example, if you are deep in the trenches of using Kafka for asynchronous communication and take the time to share the different challenges you’ve overcome, you care.
Your willingness to share knowledge, teach and mentor directly correlates to the amount of respect you have for your craft. It takes guts to be vulnerable, start a discussion, and slow down to share. Being able to share and teach a peer is a forcing function to mastering the topic. This doesn’t mean every developer needs to blog. But instead, great companies should create outlets to empower their coworkers to document and share.
This mentality is the reason we started fintech_devcon. As the flagship conference for developers and builders, we wanted to create a space with no BS. Just straight talk with healthy discussions on important developer topics. No demos. No sales pitches. Just learning, sharing, and building together—the ultimate way to honor our craft.
Don’t sell features, sell confidence
As a startup, you will never have enough features. There will always be someone else who has a laundry list of stuff that you don’t. So stop trying to sell features. Customers have become numb to the idea that something is on your roadmap. And a promise of some future state will likely be broken. Things change too quickly. Demands shift. What customers really want to understand is how fast you ship.
Trust is earned by the speed of delivery. When customers see how fast you ship, they can decide, knowing that you will continuously bring value that helps them unlock new ambitions.
The dance of feature gaps is something you don’t want to be in. Engineers who respect the craft understand this at their core. They know that the thing you are building is on its own journey.
If you rush to match the feature set of your competitors, you’re telling the world that you’re building the same thing—something that already exists. But you’re not. At least that’s not the path we’re on at Moov. And our engineers didn’t join this company to build a slightly different version of what is already in the market. But don’t take my word for it, read for yourself why people join Moov.
Redefine done
The last area that underscores what I mean by respecting the craft is how you think about something being “done.” It’s easy for engineers to merge something into production and move on. It’s verified in prod, so you’re done, right? Wrong.
The best engineers I work with recognize that the new feature doesn’t exist unless it’s documented. They believe this in their heart, but they also force their teams to put it into practice. This sentiment has become a part of our culture. We don’t celebrate something as being done until all aspects are covered.
Let me explain.
Your new feature isn’t done until you tell the world about it. Consider all the activities that go along with that, and you’ll begin to understand what a proper go-to-market launch looks like.
Done means the social media is scheduled. The website is updated. Docs are published. Your Customer Success team is primed for support. Sales understand the positioning. And on and on and on.
This practice doesn’t happen overnight. We pulled it off with our announcement for Moov Drops, but we’re still figuring it out. My marketing team sometimes reminds me to quit tweeting things because the launch isn’t fully ready. There’s something beautiful in quietly orchestrating these areas behind the scenes and then revealing them to the world in a domino effect.
The foundation for shifting your definition of done requires servant leadership. The servant-leader puts the needs of others first and helps people develop and perform as highly as possible.
Engineers who respect the craft know how these pieces fit together and stay engaged with the efforts until everything is prepared — code-related or not. For example, the engineer who goes out of their way to ensure the marketing team isn’t blocked. Or the developer who offers training to the CS team because the product manager is out.
Final thought
What I outlined in this post only scratches the surface of what it means to respect the craft. We set standards that are fair but non-negotiable. We are hard on the problems but easy on the people. We’re building a culture of inclusiveness, respect, equity, and belonging that transcends any role, language, or country. At the end of the day, everyone at Moov stands unified in our shared commitment to prioritize people and our unique crafts.
