At Clever, we chose early on to deliberately define the key principles we wanted our culture to reflect. These tenets are a part of day-to-day vocabulary, and we think they make us a stronger team.

About a year ago, we asked ourselves: how do these tenets apply to our engineering team? Are there aspects of software engineering where it would be useful to have more specific detail? Where it would benefit us as a team to more clearly define the principles we want to uphold as engineers? So we decided to embark on a journey to define Engineering Tenets at Clever.

The Process

We wanted to define tenets that fall somewhere in the sweet spot between describing Clever’s Engineering culture today and defining where we want Clever’s Engineering culture to go. We started with an open discussion with the full eng team, to brainstorm a list of potential tenets and values. Then, we consolidated this list into a document that each engineer could comment on, and watched to see the conversation unfold. As you might expect, with a group of ~40 engineers, there was a fair amount of disagreement and discourse on this document. It took nearly a year to get to a place where everyone could see themselves and their aspirations for Clever within those tenets. Quite a long time overall, but we think it was worth it.

The Tenets

So, what did we end up with? Six tenets. Again, we feel like they are both somewhat descriptive, showing where Clever is today, and somewhat aspirational, showing what direction we want Clever’s engineering culture to evolve towards. As we were writing them, one engineer asked “these sound great, but what are the tradeoffs of adopting these principles? Is it all good, or is there something we lose?” Everyone agreed with that point, so we documented the tradeoffs we saw. Here’s where we landed.

Code with Empathy

We develop software with our customers and our fellow engineers in mind. To gain empathy for our customers, we embed product managers within engineering teams so they may work closely together. We also encourage engineers to participate in product specifications, user testing, and school visits. We choose to write code that is readable over code that is clever or terse, to help our colleagues and future selves read and update the code. We value simplicity as a key ingredient in software architecture and implementation, as simple systems are easier to maintain, debug, and operate.

Tradeoff: we’re slower to start coding to make sure we are simplifying and meeting user needs, and we spend more time justifying tech debt paydown. We don’t do the convenient technical solution, we do what users need us to do.

Code with a Sense of Urgency

Our most precious resource is time, and the most important thing we do is solve users’ problems. So, we choose to move quickly and sequence work smartly to get solutions into users’ hands promptly. Still, we understand that having a sense of urgency doesn’t mean shipping shoddy work. We review each other’s code, write tests, and think about architecture, not because these things are “correct,” but because they help us build higher quality products more quickly, ultimately benefiting our users. We seek out opportunities to use, integrate, or borrow ideas from existing tech, e.g., open-source libraries, third-party services like AWS, Stripe, etc., since leveraging existing tech can speed up feature development and lower long-term maintenance cost.

Tradeoff: we sometimes code in an end-user-logical order rather than a developer-logical order, which can require a good bit more jumping through hoops. We feel the time pressure, which can sometimes be a bit stressful. We sometimes use suboptimal libraries because making them optimal wouldn’t be the best use of our time.

Learn and Teach, Every Day

We consider acts of learning and teaching essential parts of an engineer’s daily routine. We start with a 10-12-week onboarding period for all engineers to emphasize the importance of learning. We perform and reward spontaneous acts of teaching. We refuse to hire skilled engineers if they are arrogant. We create technical guilds in relevant areas, led by individual engineers rather than managers, for the explicit purpose of developing expertise. We work on giving each other authentic and actionable feedback, in formal and informal ways. We encourage engineers to work closely with other teams across the company to build empathy across functions and make Clever a more cohesive team.

Tradeoff: new hires can feel homeless for their first 10-12 weeks. We miss out on potentially highly skilled engineers. We spend time thinking deeply about feedback and delivering it, which takes away from coding time.

Expect and Enable Change

We believe the only constant is change. We build code for change, which means we build tests for the purpose of making future code changes easier and more robust. We build code that is modular for the sake of being easy to delete. We architect our systems as multiple small services so new approaches to engineering can be tried in incremental ways, one small service at a time. We build infrastructure to make it easier to compare new and old versions of services in production, so we can deploy changes with confidence, and we encourage deploying code changes often. Organizationally, too, we know priorities can change. We structure teams around customers, and we use transient task forces to rapidly focus a small group of people on a problem without disrupting the entire organization.

Tradeoff: we spend more time testing. We get heartbroken a bit when our code is deleted. Changes might mean manager changes, which can be disruptive, so we spend more time managing those transitions. We spend time building more infrastructure to make changes / deployment easy, rather than adding features.

Be Excellent Guardians of our Users’ Data

We are the expert guardians of our users’ data: teachers, students, school administrators, parents, etc. It is not up to our users to figure this out, it is up to us to guide them and protect them. We architect for privacy, and we design defenses in depth. We think about the data flows we enable and consider every way in which our users might be impacted. We respond to security problems rapidly and transparently. We care about far more than doing the legal thing, we care about doing the right thing.

Tradeoff: we spend a lot more time building certain features as we find the way to do right by our users. Some specific features – e.g. when allowing teachers to debug student logins – took us a long time to build, because we want to  get them right the first time when it comes to security & privacy.

Engineering is a Team Sport

We believe that engineering teams can be much more than the sum of their individual members. So we optimize for the team. We celebrate the assist more than the dunk – we celebrate accomplishments without creating a hero culture. We celebrate the engineer who takes on a less glamorous task so their peer can take on the exciting one. We celebrate the engineer who covers an incident because she is available and the on-call engineer is otherwise busy. We also celebrate teams that cover for each other so that individuals can take PTO without fear or need to stay connected. We value effective, empathetic, and candid communication. We spend time and resources building and continuously improving teams. We hold a very high bar for engineering management that enables, inspires, and supercharges teams.

Tradeoff: we might miss out on hiring a highly technically skilled engineer if we believe s/he is not a strong team player. We maintain a healthy amount of manager/engineer relationship stability through reorgs, even if a different team structure might make more sense in the abstract.

The Results

It’s great to define culture tenets, but then what happens? How do we make sure that Clever’s engineering culture does in fact evolve towards these tenets?

For a while, we just let the tenets simmer to see how they naturally embedded within our culture. While our practices didn’t stray from the tenets, they also didn’t really move closer towards them, and team members started to forget that we even had tenets at all. So we decided to reinvigorate the tenets at our last engineering offsite by having engineers recognize each other for as exemplars of the engineering tenets. We took nominations and created appreciation cards thanking each engineer on the team for the tenet they most exemplified. We initially feared this would be a bit too over-the-top, maybe artificial. In fact, the team enjoyed the exercise so much, it was everyone’s favorite part of the offsite (not counting dinner).  We are now looking at how to achieve this kind of recognition more regularly, and how to embed daily reminders of the engineering tenets in our workflow.

It’s easy to talk about “having a good culture.” It’s much harder to define what “good” means, and even harder still to set up engineering workflows that continually move a team closer to that definition of “good.” That said, we’ve found it to be quite meaningful to every engineer at Clever to invest the time to do this well, and we’ll continue to celebrate our engineers as often as we can, because little compares to working with a team that shares your values and works to improve itself every day.

Interested in joining us? Check out our jobs page for current openings.