Engineering Ethos

At Simon, our belief is that great engineering happens naturally when you provide a healthy environment for your team.

Our goal in writing this post is to share some of what we believe defines who we are as a company and an engineering organization.

It starts with a healthy core

To start things off, the following two lists respectively share our expectations of each employee and those of the company as a whole.

Everyone should,

• Have a connection with the product and the product team
• Have a relationship with our clients, starting with appreciating and understanding their individual needs
• Relentlessly drive for simplicity in design and implementation
• Never forget that execution is survival. If we aren’t getting things done, then we are becoming irrelevant
• Strive to be great at what they do — be inspired by your coworkers and inspire them to build something great
• Imbue a spirit of generosity — fulfill your role on the team and then some
• Treat people with respect

As a company we,

• Do not sweep failure under the rug, but address it head on with blameless postmortems
• Practice candid, respectful feedback. Whether its being delivered or received, feedback should leave egos out of the picture and focus on making Simon Data a better place
• Promote decisions based on data driven experimentation, rather than rhetoric and guesswork
• Understand that not all work happens between 9am and 5pm, but that some folks do better when they’re given trust and latitude to be productive when the time is right. For example, if someone needs to take a break to clear their head and go for a bike ride or get a beer, they’re encouraged to go do it; however when they’re in the office, they’re expected to be focused on Simon

A healthy engineering team

Within our engineering team we value,

• Balancing the desire for high resilience and quality in the code with business priorities and the TTL of the code itself. Every engineer has to accept the fact that their beautiful code may get canned if the feature for which it was built it ends up not going live or getting traction
• Iterating quickly on feature development so that we can discover blockers and risks up front, as well as decide if the feature makes sense or we need to pivot or punt on it
• Ownership by the individual writing the code to make architectural and implementation decisions
• A strong, two-way relationship between designers, product, and engineering that encourages iteration and feedback
• Staying vigilant about what is working and what isn’t. What is working today might be a total failure tomorrow. At any time, we need to be prepared to throw something away and replace it with something better (or nothing at all!)
• Quarterly, holistic retrospective review of what’s good and what needs improvements, followed up by a commitment to address any action items
• Fault tolerance on both the client and server side and relentless automation of error handling
• Tech debt and bugs as first class citizens. They are prioritized alongside product features

Is it working?

All of these principles sound great in theory, but how can we know if the team really is healthy and successful? Our conclusion: if the product continues to evolve, our clients are happy, and revenue is rising, then the engineering team is being successful. If our engineers are happy to come to work every day, engage with each other, and approve of this message, then we are staying healthy.

How about you?

We’d love to hear what you feel contributes to successful engineering teams. Send us a note at hello@simondata.com or a tweet at @simon_data.