close
close
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Engineering

The DataGrail Engineering Way

Ignacio Zendejas, March 13, 2019

Hello, World!

This is yet another engineering blog (YAEB).

To kick things off and before we geek out about what we’re building, we’d like to share our engineering culture. It’ll help you understand the how and the why.

Our culture is shaped by our collective experiences. It’s a recognition that we’ll make many mistakes. We’re just doing our best to ensure those mistakes will lead to our collective success. It’s not founded on fear of failure, but in a latent fear of failing badly–with no human touch and no purpose–if we do fail at all. It’s ultimately motivated by our desire to build something truly great. And we want to do it all while having fun.

We expect it’ll evolve.

Our Culture

1. We align ourselves with company OKRs, which we help set

Focus. Focus. Focus.

2. We use scrum to deliver the most value more quickly

We often don’t know what we don’t know. We ship quickly using scrum methodologies and retrospectively learn how we can do better.

3. We’re people who happen to be engineers.

We take care of ourselves. We take care of each other. We value health and family, productivity and work — in that order. If you’re sick, stay home. Don’t get others sick. Get better soon. No BS.

If you’re burning out at DG, please let us know. If you lead teams, we’ll ensure you’re equipped with the knowledge to prevent it. Take care of your team. It’s a marathon.

4. We’re building a team, not a group of egos.

We didn’t hire people to prove they know something we don’t. We know they do–it’s why we hired them. We hire very smart people to tell us what to do, but expect they’ll work with others to be more effective.

5. We don’t hire jerks–even jerks who are geniuses.

The Shockleys of the world have a place, yes. But the “traitorous eight” proved you are often better off without them. Also, not everyone is Steve Jobs.

6. We believe in diversity and inclusion.

It is morally important. We’re building data privacy products. Privacy is experienced by everyone differently. We need to understand and represent as many people as possible.

7. We ship value, not code.

We don’t attach ourselves to code. We attach ourselves to results and to solutions. So first, we make things work. Then, we make them right–think maintainable–if they add value. And then we make things fast. Beautiful code is never the goal. But it can be the means.

And beautiful here is best understood as simple (makes the complex easy to understand), maintainable (designed to handle lots of churn), concise, and above all, easy to replace.

8. We never start with solutions. We start with problems.

Innovation is the result of applying advances in the sciences and engineering to solve many people’s problems with products they’re ideally willing to pay for. If it doesn’t add value, then there is no reason to find excuses to use the latest javascript framework, pseudo-AI, blockchain or whatever is getting funded to boost someone’s ego.

9. We never reinvent the wheel.

Our goal is to build great products. Then, to solve technical challenges that get in the way of building great products. If we can use hosted or open source solutions, use them. If they can’t scale, it’s a great problem to have. Until then, focus on making it a problem. And when we can help others avoid reinventing the wheel, we should contribute back to the communities whose shoulders we’re standing on.

10. DG engineers are not afraid to take risks and make mistakes.

We should have infrastructure and processes in place to catch mistakes before they impact our customers. If they impact our customers, we learn quickly. If we repeat our mistakes, then we’re doing something terribly wrong and the root problems need to be addressed.

To be clear: we take risks, but we are not reckless.

11. We take security very seriously.

Seriously. We have to be protective of our customers’ data–which they were entrusted with by their customers. We’re employing best practices and are always looking to improve our security.

12. We’ll never use MongoDB, PHP, and CSVs.

We generally have strong opinions loosely held, with a few notable exceptions. To understand why, see 11 above. As for CSVs… Just use TSVs if you need a simple, delimited format.

If you’re excited about what we’re working on and our culture, join us.

Photo: “Northern Lights (Iceland)” by David Phan is licensed under CC BY 2.0

Stay informed on the latest data privacy news and privacy regulations and insights with our newsletter.