Monarch’s Engineering Values

These Engineering values are what we use internally at Monarch. They are evolving, but we wanted to share them publicly.

There are many ways to build an amazing engineering culture, and we’re just starting to hone in on exactly what ours is. So we ask for your investment, participation, and feedback in co-creating the culture here at Monarch.

• We believe in collaboration. “Don’t go down the rabbit hole alone” has been an unofficial mantra on the team for a few years now. It’s easy to get stuck in a loop, miss important insights, and create single points of failure when working alone. Get feedback early. Bring others along for the ride and intentionally partner with them on delivering great engineering work. Be or find a thought partner, especially if the work is complex or you feel stuck or uncertain.
• We default to trust. Having the confidence that any task that needs to be completed will be done with the same high quality, no matter who on the team does it, is a key component to high-performing teams. We also believe curiosity is a great way to push each other and shine a light on details our teammates may not have considered. We challenge each other’s thinking to get to the best outcomes, but we trust that we will get to the best outcomes.
  • Some relevant readings
    • “Work” with people you believe in—believe in people you “work” with
    • The Simplest Way to Build Trust
• We hate (bad) surprises. Deadlines shift, scope creeps, and environment factors will always change out from under us. These things, often, we can’t control. But what we can do is raise the flag as soon as possible to make sure the rest of the team isn’t also caught off guard.
  • Some relevant readings
    • The Principle of Least Surprises and Stakeholder Management
• We own our work. We believe people are happiest and do their best work when given as much ownership as possible without creating silos or gatekeeping. With autonomy also comes responsibility. We empower each other to make decisions, but also expect each other to own the consequences of those decisions.
  • Some relevant readings
    • Engineering Project DRI (+ Secondaries) [redacted internal link]
    • You Don’t Have to Manage, But You Still Have to Lead
    • Things To Do Before and After You Write Code
• We leave room for inspiration. While things like having a two-week sprint cycle or maintaining an ownership tables are important to keep us on track, we believe our team’s talent shouldn’t be restricted by process or boundaries. Human beings don’t always work on a regular cadence. If, on occasion, inspiration for something impactful strikes, we do our best to create room for it. When a talented, driven person is inspired, it’s often best to get out of their way (we only hire talented, driven people).
• We are intentional about the tradeoffs we make. We’re thoughtful about the trade-offs we make, and are deliberate about decisively choosing the path forward. In the sciences, the phrase “there is no free lunch” has a habit of coming up again and again — speed of delivery often comes at the cost of quality. Working iteratively can get you stuck in local maxima. There is no universally “correct” place to fall on this spectrum, only the most appropriate for the present situation and constraints. We think (often collaboratively) before we act/build/decide. Writing is a great way to force yourself to think (and to solicit input from others).
  • Some relevant readings Write a Design Doc—Even if No One Else Will Read It
• We don’t like complexity, but it doesn’t scare us. We think simple things are better. They are easier to use, understand, maintain, and talk about. That said, hard and meaningful problems tend to be, well, complex. We aren’t scared to tackle complex problems, but when we do, we try to reduce that complexity. We decompose problems into simpler ones, we surface and reduce dependencies, we sequence simpler work first to help us learn and de-risk, and we work in small, fast feedback loops.