A guide to how we work at Gruntwork

We started Gruntwork in 2016 with two goals: (1) make it 10x easier to understand, build, and deploy software and (2) build a company where we can work on interesting projects, with interesting people, while leading interesting lives. This blog post is primarily going to focus on how we’re trying to accomplish #2 and build a startup that is distributed, self-funded, family-friendly, and profitable.

This blog post serves two purposes. First, the company is starting to grow quickly, so we’ve created this blog post as a guide for job candidates and new hires. Second, we’re not the first people to build a company, so in the interest of learning, forcing ourselves to improve, and being transparent, we’re publishing this as a public blog post. We’d love to hear your thoughts, advice, and feedback and we’ll try to keep this post up to date as we grow and learn.

Here’s what we’ll cover:

Why Gruntwork exists

Our mission at Gruntwork is to make it 10x easier to understand, build, and deploy software. We believe that software is one of the most important technologies in human history, right up there with fire, the wheel, and writing. But we also believe that, as it is today, software is far too hard to create. Only a tiny fraction of humanity—people with abnormally high pain tolerance we call “programmers”—can create software at all, and, to be honest, no one is particularly good at it.

There are many reasons why software is hard to create, and at Gruntwork, we’re starting by focusing on just one: the difficulty of DevOps. That is, we’re building products that simplify all the steps that come after you’ve written some code, including how you deploy, test, monitor, scale, and secure that code.

Our goal is to make world-class infrastructure and DevOps practices accessible to everyone, and not just the small, elite group of companies that can afford a huge team of infrastructure engineers and SREs. When writing became accessible to all of humanity, rather than just a tiny “priest” class, it had a profound effect on the world; we believe something similar will happen when it’s an order of magnitude easier to build, run, and maintain software.

What we do at Gruntwork

As of 2018, the main products we’re building are:

How customers find us

We don’t pay for advertising or sponsorships or other traditional marketing; most developers are blind to ads and all promotional materials anyway. Instead, just about all of our customers find us through our published content. This includes our blog posts (you’re reading one now!), books, talks, training, and open source. In other words, our main marketing tool is to teach DevOps.

This is a virtuous cycle. We share what we’ve learned with the world, which makes it easier for developers to build software. Some of these developers realize our products can make their lives even easier, and they become customers. As we work with these new customers, we learn even more, and when we share those new learnings with the world, the whole cycle starts over again.

How we bootstrapped the company

When we started Gruntwork, we did not raise money from investors. For most investors, the nature of their business requires them to seek out 10–100x returns, and the only way to make that happen is to chase hyper-growth and big “exit events” (IPOs, acquisitions) above all else. At Gruntwork, a big exit isn’t our primary goal; if it happens, great, but that’s not why we get up in the morning.

We get up in the morning because we care about our work and we genuinely want to make software easier to create. But we also care about life outside of work. We want to be able to travel and spend time with family. We want to work reasonable hours and take vacations. It’s not impossible to accomplish all of this if you raise money, but it tends to be much harder. Perhaps we’ll raise money in the future—if we can find investors who have similar values—but so far, we have done no fundraising and have taken on no debt.

Despite this, the company has been profitable and we’ve been able to pay competitive salaries from day one. How’s that possible? Well, every single thing we’ve built at Gruntwork has been paid for by a customer that wanted that thing—and we got them to sign the check before we built it.

Initially, this meant we were effectively doing consulting. When we worked with our first customer, we were a team of two developers who were good at DevOps, and offered to help that customer build their infrastructure for a reasonable hourly fee. Here’s the key: we signed a contract that let us keep the IP for the code we wrote! Customers were OK with this arrangement because (a) we gave them a license to use and modify that code for almost any purpose, (b) the infrastructure code we were building was completely generic and keeping it proprietary did not provide the customer with any competitive advantage, and (c) in exchange for the IP ownership, we also offered to maintain, update, and support that infrastructure code on an ongoing basis.

When we went to our second customer, we repeated the same process, except this time, we were able to start with a small amount of code from the previous project, so it was an even better deal. With our third customer, we reused the code from the previous two. And so on, until today, where that code has been assembled into the battle-tested IaC Library and Reference Architecture that we sell as products.

Update, October 4, 2018: Gruntwork is now not only profitable, but we’ve hit $1 million in recurring revenue!

Update, March 29, 2021: We’ve now reached $4.5 million in recurring revenue!

That means that every piece of code we developed was something a customer (a) desperately needed and (b) was willing to pay for. It turns out if you can find one such customer—what Steve Blank calls an “earlyvangelist”—there are likely many others who want the same thing. As a result, we have a strong product-market fit. We’ve been lucky enough to work with some of the biggest brands in the world, as well as many small and medium businesses, because fundamentally, just about all of them need the same basic infrastructure.

How we hire

We’re trying to build a diverse team that is welcoming and safe for people of all backgrounds, cultures, genders, and ethnicities. We don’t use puzzles and brainteasers in our interviews, as they are a complete waste of time that do little more than make the interviewer feel smart. We don’t do whiteboard coding interviews, as they test the wrong skills and discriminate against many developers, and often become little more than a hazing ritual. And we don’t do salary negotiations, as they lead to gender discrimination.

Our approach is a little different:

Finding candidates:**** Either you find us (e.g., through our hiring blog post or careers page) or we find you (e.g., through your blog posts, talks, open source work, or a personal connection). We’ll go through your background and make sure you meet our basic criteria:

Meet the team: Next, we set up video calls with a few team members. These chats are to help us understand what you’re looking for and to help you understand what we’re looking for. Tiny, bootstrapped, distributed startups in the DevOps space are not for everyone, so we spend a lot of time trying to understand what you’ve worked on in the past, what you want to work on in the future, and sharing as much as we can about the type of work we do at Gruntwork.

Trial project: If the chats all go well and everyone wants to move forward, the next step is a trial project. Instead of you spending a day doing whiteboard coding at a company’s office, we ask that you take the exact same day and work on a real project for us out of the comfort of your own home (or coffee shop or library or wherever you prefer working). We might have you fix a bug in one of our open source projects, add a new feature to an existing module in our IaC Library, or even build an entirely new module that a customer requested. We’ll introduce the project to you at the start of the day, chat with you via Slack and email throughout the day, and then review your work at the end of the day.

In other words, it’s basically a regular work day—which is exactly the point! Our goal is to give you as accurate of a glimpse as possible at what it would be like to join Gruntwork. By the end of the day, you should have a good idea of the type of projects we work on and what it’s like to work with us, and we should have a good idea of what you’re capable of and what it’s like to work with you.

Offer: If the trial project goes well and everyone wants to move forward, we’ll make an offer. See the next two sections for how we do compensation and benefits.

Compensation: At Gruntwork, we strive to be transparent and to treat everyone equally. Inspired by companies such as Buffer and Quip, we determine salary, equity, and bonuses using formulas. We don’t share the exact numbers publicly, but everyone within the company knows what everyone else is making, which we believe helps ensure fairness and avoid bias and discrimination.

The formulas currently work as follows:

Benefits:

How we ramp up new-hires

When you first start at Gruntwork, we will a assign a mentor to you. Your mentor is responsible for making you successful and productive at Gruntwork. They are also responsible for helping you figure out your goals and doing 1-on-1s.

Goals and 1-on-1s

Your mentor will set up a weekly 1-on-1 meeting with you via video chat:

Becoming a full member of the team

Your first few weeks at Gruntwork will consist of working with your mentor to pick out gradually bigger and bigger projects. The first project might be a simple bug fix. The next one may be adding a new feature to an existing module. The next project after that could be to build a new module from scratch. The goal is for you to get a basic familiarity with all of Gruntwork’s products and to learn any new technologies you need to along the way (e.g., Terraform, AWS, Go, etc).

At the end of the ramp-up process, you’re a full member of the team. Each team member, whether junior or senior, becomes an owner of one or more projects that we have going on (more on that below). Of course, all work is peer reviewed, so while you’ll be the primary person driving your projects forward, you’re never working alone and always have access to guidance and help. Every time you complete a project, a new feature, or even a bug fix, add it to our latest newsletter so we can notify customers about it. If it’s a major new feature, consider announcing it more widely by writing a new blog post on the Gruntwork Blog.

How we work

Gruntwork is a fully distributed company spread across 3 continents. Being distributed has many advantages:

But there are also drawbacks to being a distributed company:

How we’re trying to make it work

To help mitigate some of the drawbacks of remote work, and to best take advantages of the strengths, here’s how we operate:

The tools we use

We use a number of different tools and services to get our jobs done. Here are few of the most important ones:

Let’s go do some gruntwork!

We hope you found this guide helpful. If there is anything missing or you have questions, please let us know! Our goal is to make this blog post a living document that we keep updated as the company grows and changes.

If you’re interested in working with us, send an email to careers@gruntwork.io.