Careers
How We Engineer
The experience of working at a startup is both exhilarating and uniquely challenging. Nothing compares to the camaraderie that develops from tackling an ambitious problem together and driving the company to new milestones of achievement. The startup experience also presents unique challenges for engineers. The future of the product is evolving so the product roadmap is necessarily provisional. The speed of learning from customers is rapid and tests our ability to keep pace.
As a result, we’re continuously managing the tension between building for the long and short term. Build beyond the horizon of the product roadmap and we invest precious time and focus on things that our future learnings may invalidate. Build only the things where we have certainty and we zigzag into a local optimum that’s painful to maintain. There’s no “right” way to address these challenges. At Enigma, we’ve evolved a handful of principles and practices to help us strike this critical balance consistently. If these principles resonate with you, you’ll probably feel right at home building with us.
Setting clear goals is empowering.
We set quarterly OKRs at the company level (the fewer the better) so that everyone understands what we’re trying to achieve. Everyone has input into these goals and we review progress towards them every Monday morning at our weekly company stand up. We select goals that the company feels are both ambitious and attainable.
There can only be one first priority.
This maxim seems obvious. Yet nothing is more empowering for individuals and teams than knowing what’s most important to focus on. Occasionally we find ourselves making decisions that implicitly violate this maxim. We’re continually reminding ourselves that doing one thing well is our best chance at both achieving our goals and keeping our sanity.
We can’t see the future, so act accordingly.
Much as we might wish it were otherwise, no one at the company is clairvoyant. But it’s empowering to clearly distinguish between what we know and where we’re ignorant. Knowing where we’re ignorant informs the conversations we need to have with customers and the technical research we need to perform. As engineers, this allows us to build software that takes advantage of what we know while being tolerant of several possible outcomes depending on what we learn.
Over-engineering vs under-engineering is a false choice.
Even for relatively small features we prefer to sketch out the full system rather than hack together a solution with high costs of ownership. Sketching out the system is a fun exercise, exposes hidden questions and assumptions and builds alignment between teams. When we build, we build the minimum feature as cleanly and simply as possible. Having the shared vision of the more complete system acts as an invisible hand that steers our immediate efforts in the direction of what we build later.
Invest in our ability to focus.
While we can’t perfectly see the ROI of each project we take on, we can tell when we’re doing low value work: repeatedly running a series of commands that can be automated, regularly debugging an unreliable component in a system or even hunting down the same information multiple times. We put a high value on removing sand from the gears. Not only do these investments save us time, they reduce our cognitive overhead and allow us to see true problems more clearly.
Failure is a learning opportunity.
Solving ambitious problems means that even highly motivated, capable, well-led and collaborative teams can fail to achieve a goal. The best aspects of our culture come out when things don’t go well. We’re curious to understand the underlying reasons why we failed and take for granted that everyone did the best they could. As a result, we come out of retros with a shared understanding and actions for what we can do better the next time.