How we built a distributed, self-funded, family-friendly, profitable startup

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
• What we do at Gruntwork
• How customers find us
• How we bootstrapped the company
• How we hire
• How we ramp up new-hires
• How we work

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:

• Infrastructure as Code Library: A collection of over 250,000 lines o reusable, battle-tested, production-ready infrastructure code written in Terraform, Go, Python, and Bash. Instead of reinventing the wheel and building all of your infrastructure from scratch, you can build on top of a mature Infrastructure as Code (IaC) Library, which has been built by a team of DevOps experts, and proven in production with hundreds of customers.
• Reference Architecture: An opinionated, end-to-end tech stack built on top of the IaC Library. Instead of spending months assembling everything from scratch, we can deploy the Reference Architecture into your AWS account in about one day and give you 100% of the code, which includes just about everything a typical company needs: server clusters, load balancers, databases, caches, network topology, monitoring, alerting, CI/CD, secrets management, VPN, and more.
• Gruntwork Houston: Houston is Mission Control for your entire infrastructure. On the surface, it’s a simple web interface that your Dev team can use to deploy and manage infrastructure. Under the hood, the web interface and how it manages infrastructure are completely defined and controlled by your Ops team using infrastructure as code. It’s the best of both worlds: your Dev team gets an easy-to-use, self-service experience, while your Ops team still has all the power and control they need to ensure reliability, security, and compliance.
• Support: We provide commercial support, updates, and maintenance for the IaC Library and Reference Architecture.
• Training: We offer recorded and live training across a variety of DevOps topics, including Terraform, Docker, Packer, AWS, and security.

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:

• You know how to write code (“dev”).
• You have experience running production software (“operations”).
• You want to create software to transform DevOps.

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:

• Salary: The inputs to this formula are your title and level. The base salaries for each title and level come from salary data for a US city, plus a fixed multiplier for the entire company (the idea is that this multiplier will go up for everyone as Gruntwork becomes more successful), so everyone with a given title makes the same salary, regardless of where you are in the world.
• Equity: The inputs to this formula are your seniority level and employee number. Earlier employees take on more risk, so they get more equity in return. Also, we have a progressive equity program in place, which means if we have a large “exit event” (i.e., an acquisition or IPO) some day, the earnings will be distributed more fairly throughout the entire company, rather than being hoarded entirely by the founders.
• Bonuses: The inputs to this formula are how the company is doing financially and your personal performance.

Benefits:

• Insurance: We offer health, dental, and vision insurance for every employee.
• Equipment: When you join, we reimburse the purchase of a new computer. If you wish to work at a co-working space, we will reimburse a desk as well.
• Time off: We have a minimum vacation policy (inspired by TravisCI), requiring that all employees take at least 4 weeks off a year. Simply plug the vacation time into your calendar, send the team a notification, and we will plan the work around your schedule, rather than the other way around.
• Company outings: We fly out all employees to fun locations 3–4 times per year to work in person. We pay for the flight, lodging, meals, and fun outings. More on that below.

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:

• In the first meeting with your mentor, and at least once per year after that, you will define your goals for the year and get them down in writing in a shared Google Doc. These goals typically include new things you want to learn (e.g., “I want to be proficient with Go by March” or “I will develop my speaking skills by giving 3 conference talks this year”) as well as projects you want to complete (e.g., “I will create modules for deploying and managing Kubernetes on Azure in Q3”).
• In all subsequent meetings, you’ll spend half of the meeting chatting about anything on your mind, and the mentor will spend the other half of the meeting chatting about what’s on their mind. You’ll also review how you’re doing against your goals. You and your mentor should both take notes in the shared Google Doc.
• At the end of the year, the performance review consists of going through the notes in the shared Google Doc and seeing how you did against your goals. Hopefully, you’ve been doing this every week anyway, so there won’t be any surprises, and the notes in the Google Doc will ensure we don’t forget about all the things you’ve worked on throughout the year.

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:

• You can work wherever you want: at home, from a coffee shop, a library, a co-working space, an airplane, a boat, or pretty much anywhere else with an Internet connection.
• You can work whenever you want: other than ~2 live meetings per week, your hours are completely up to you. This allows you to plan your work around your life rather than the other way around.
• In fact, your entire lifestyle is up to you, whether you want to be at home with your kids, or bounce around the world like a digital nomad, or anything in between. For example, since founding the company, I’ve traveled to Italy, Ireland, England, Czech Republic, Austria, France, Latvia, and all over the US, worked the weirdo hours I’ve always wanted (I am not a morning person), and sold an awful lot of software while wearing my PJs.
• We can hire the best people from anywhere in the world, rather than hiring just the candidates who happen to be within a few miles of some office.
• You can avoid most distractions. We do almost all of our work asynchronously, so there are almost no interruptions from other coworkers or the noise of an open office. This is an ideal environment for work that requires prolonged periods of deep concentration, such as writing code.

But there are also drawbacks to being a distributed company:

• While remote work avoids distractions, it also slows down the feedback loop. Instead of a 30 second chat, you may have to wait hours for an email or chat response.
• It also makes it harder to have serendipitous discussions. Many important ideas are born during an unplanned hallway chat or a lunch time discussion. These sorts of discussions are more rare with distributed companies.
• It’s harder for the team to bond. With a distributed company, you have far fewer opportunities to have random off-topic conversations, share meals, and celebrate with parties and get-togethers. In fact, some people find remote work to be lonely and isolating.
• Remote work requires everyone on the team to be driven, highly organized, and great at time management. With no one nearby to put pressure on you, some people struggle to stay motivated. This can be especially problematic for junior employees who are just getting started in the industry.

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:

• Weekly strategy meeting: Every Monday, we have a meeting with the whole team via video chat to plan out that week’s work.
• Weekly status updates: Every Friday, we have a meeting with the whole team via video chat to talk about how the week went, do quick demos and code walkthroughs of what we got done, and see how we did against the plan from Monday.
• Weekly 1-on-1: Once per week, each employee has a 1-on-1 with their mentor, as discussed above.
• Daily standup: Once per day, each member of the team gets an automated message from Basecamp Check-ins asking them (1) what they worked on yesterday, (2) what they are working on today, and (3) if they hit any blockers. Your responses are visible to the whole team. Doing “standups” in this asynchronous, written manner has revealed some interesting insights: since all the check-in responses are visible in a single place, it’s easy to look at one day to see what you had planned and to look at the next to see what you actually got done. If the two frequently don’t match up, it’s a sign that something is going wrong (e.g., too many unplanned interruptions), and we need to fix our process.
• Quarterly team outings: Three or four times per year, we fly out the entire team to a fun location to spend several days working in person, and several days having fun. Previous trips included Iceland, Paris, Dublin, Phoenix, Boston, and Austin. We use these trips to do long-term strategic thinking, coming up with plans for the next quarter or two and goals for the next year or two. We also use these trips as a way for everyone to bond, for example, by wandering around the Louvre or going for a hike in Sedona.
• Co-working: For employees that find working at home too isolating, we reimburse a desk at a co-working space. This allows you to work in a normal office, maintain separation between your home and your work, and meet people from other companies. We’ve even scored customers from these interactions!
• No-meeting days: Everyone on the team blocks out their calendars for Tuesdays and Thursdays so no meetings can be scheduled. We use these days to get long periods of uninterrupted time for “focus work,” such as coding. Avoiding context switching not only makes CPUs more efficient, but people too!
• Notes: We take copious notes about every single meeting and discussion in Google Docs, Basecamp, GitHub issues, etc (more on the tools we use below). We are inspired by GitHub’s rules of communication, defaulting to asynchronous, written communication when possible.

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:

• We use G Suite for email, docs, and calendars.
• We use calendly for scheduling meetings without any back-and-forth or “are you available on Tuesday at 4pm or Friday at 5pm…” nonsense.
• We track all tasks in Basecamp.
• We do real-time chats via Slack. To avoid Slack being too big of a distraction, we recommend turning off all notifications, except direct messages and mentions, and only using those if a discussion is timely.
• We do all video chats via Zoom.
• All of our code lives in GitHub. All code changes must be submitted as a pull request and code reviewed. All code must include documentation and we strongly recommend following Readme Driven Development practices to get early feedback.
• All code must include tests, which we run after every commit in CircleCI. Thorough automated tests are what have allowed our tiny company to build and maintain a huge library of infrastructure code that’s used in production by dozens of customers.
• We provide support to customers through shared Slack channels, the support@gruntwork.io email address, which we manage via ZenDesk, and the Gruntwork Community Forum, which is powered by Discourse. We have a support rotation where each employee takes the lead on support questions for one week. Note that our contracts explicitly say we do NOT provide emergency or off-hours support, so we only provide support during normal work hours!
• We manage payroll and benefits through JustWorks for US employees and Globalization Partners for all other countries.
• We track all deals in our sales pipeline in PipeDrive.
• We track all financials in Quickbooks. We share all our numbers with everyone in the company.

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.