A few weeks ago I found myself getting overly excited. Gruntwork had been growing at a steady clip each month, and at our last in-person meet up in March we came up with our vision for the next month, the next year, and the next 5 years. I don’t remember my exact inner monologue, but it was something along the lines of:

“If we can achieve our vision, we’ll make such a huge impact! It will be awesome!"

But then I couldn’t sleep that night. Not because I was seized with any brilliant vision or insight, but just because I was still emotionally charged. The feeling continued into the next day, when we got a customer inquiry to build a module that would help us make our product more competitive but not in a major way. Still, I found myself strongly advocating to the team that we pursue it. I communicated something along the lines of:

“If we can add this new module, it will make our offering even more complete!"

Read More...

This is a post about striking the right balance between values and business needs.

A few weeks ago, I helped finalize the parental leave policy at Gruntwork and an interesting philosophical discussion came up: How many resources is the company willing to allocate to creating a humane parental leave policy?

Some larger companies like Netflix offer full pay for 1 year when your kid is born. As a parent, that kind of benefit is…amazing. If I were an employee of Netflix, I would revel in the idea that Netflix cares about me and my family, not just the next release milestone. It would make me feel a deeper emotional connecton to the company.

But Gruntwork is just 12 people total with 9 engineers, and while we’ve been profitable from Day 1 and growing fast, if one engineer were to leave for a year, that would reduce our engineering output by, on average, 11% while still having to carry that perons’s salary. Can you imagine what kind of impact an 11% engineering output reduction would have on NetFlix? Let’s say NetFlix has 2,000 engineers. That’d be 220 engineers gone for a year…while on full payroll!

The reality is that, as much as I personally want to support a year-long parental leave policy, the company simply can’t afford it right now. Or to be more accurate, if we chose to support a 1-year parental leave policy, we would have to increase our cash reserves to a point that would significantly slow down hiring and other initiatives requiring working capital.

Ultimately, having any parental leave policy at all is “inconvenient” for the company in the sense that it reduces your ability to pump out new features and bug fixes and/or puts additional load on the rest of the team. So…should we just have no parental leave policy at all?

Read More...

In November 2014, I started helping software teams ramp up on Amazon Web Services and DevOps. This was gratifying work because a few years prior, I was involved in a project that did a terrible job of DevOps and suffered greatly for it. Now I was helping other teams avoid that same fate.

And what an adventure it turned out to be! I got the chance to work with Intel, Infusionsoft, 3-person startups, a well-funded Spotify competitor and so many other interesting companies doing interesting things. I called the consulting practice Phoenix DevOps because, well, I live in Phoenix, Arizona, and it turns out the concept of immutability (sometimes known as “Phoenix Servers”) is a central tenet of DevOps.

Along the way, I wrote A Comprehensive Guide to Building Scalable Web Apps on AWS, Part 1, and gave lots of DevOps presentations at various meetups and conferences.

During that time I also discovered the outstanding Blog of Yevgeniy Brikman (“Jim”). Jim mentioned one day he was looking for DevOps people and I loved his work, so I messaged him: “Hey, I do DevOps for lots of teams and have no time right now but let’s talk!”

It turned out Jim was doing consulting very similar to what I was doing through his own consulting practice, Atomic Squirrel. And after many conversations and trial projects, we decided we really liked working with each other.

As we compared all our experiences, we realized we’d basically been doing the same thing for every client. Setup a best-practices VPC, automate deployment, setup monitoring/metrics, get ramped up on AWS, etc.

Doing consulting on an hourly basis was one paradigm for helping clients solve these problems, but what if we could solve the problems really well one time and then consult with clients merely to help them adopt what was already built? That would mean we could significantly lower the cost and time needed to get your DevOps on.

Well, that’s what we’ve decided to do! And so today, it is my pleasure to announce that I am officially winding down Phoenix DevOps and joining with Yevgeniy Brikman in a new company we call Gruntwork.

Why call it Gruntwork? Because that’s what this work is for almost every software team. Whatever app you want to build, the infrastructure stands between your vision and your app; almost no one gets excited about automating their infrastructure. Not to mention that it’s hard to find DevOps engineers, they’re often expensive, and they hold all the keys to your kingdom. And when they leave, then what?

So Gruntwork is here to do your grunt work for you, and because of the way we’ve set things up, and the thousands of hours of collective experience we have, we can help you achieve a result that’s more effective and less expensive than the most amazing DevOps person you could hire.

One other aspect of Gruntwork that’s important to Jim and me is that Gruntwork has to be able to completely disappear and you should still be ok to run your infrastructure. Would I base my important project’s entire infrastructure on a new company that was just started by a couple of guys? Only if I had complete control of the source code and could run it without them.

So, unlike most businesses which strive to build lock-in to your product, we are actively striving to build “not lock-in”. It’s actually kind of hard to do sometimes, but it means that customers can choose to come back to us not because the cost of switching is so painful but because we continue to actively provide them value.

There’s more to share in the Gruntwork story, but I think that’s enough for now and we’ll announce more when we’re ready. In the meantime, I am thrilled to be working with Jim, who’s been a fantastic business partner so far, and I am thrilled to embark on this new adventure!

Thanks for reading. Now time to get some Gruntwork done…

I’ve been helping software teams accelerate and succeed with DevOps and Amazon Web Services for a few months now (See Phoenix DevOps), and one of the more rewarding parts of the job is getting to observe how multiple different companies operate.

I’ve seen high-performing teams in companies that are about to IPO, software teams in Fortune 100 companies, startups of about 10 engineers, and software-based companies of no engineers at all! It’s been incredibly enlightening for me to learn about how people organize themselves to get sh*t done.

Read More...

Recently I celebrated my 10th year at Omedix, the company I started when I was 24 years old. At 34, it is a little hard to imagine I’ve done anything for 10 years!

The milestone has made me reflect on some of the early decisions I made when I first got started. There were many really good decisions, but there were plenty of bad ones, too. And of course when you’re in your early 20’s you have that perfect combination of extreme confidence and supreme ignorance. Sometimes that can be a good thing, and sometimes it can be as bad as it sounds.

Read More...

I had a very powerful business experience about 4 years ago that taught me a lesson that I didn’t fully understand until recently.

I was the sole owner of a company that received a Letter of Intent from a publicly traded company to be acquired for around $1 million, all before I was even 30 years old. Sure sounds sexy, right? Well, the catch was that we were not profitable at that time and of course the time between receiving a Letter of Intent and actually signing all the contracts, getting a check in the bank, and considering the acquisition a done deal can be anywhere from a few weeks to over a year.

So we waited. Doing our best to not be too unprofitable and not incur too many legal expenses, but thrilled at the prospect of an acquisition that would instantly remove all the stress. I remember every day trying to act to the outside world like things were fine, but inside I felt incredibly stressed. Each day was a new opportunity to obsess just a little bit more about when the acquisition would finally close.

And then finally it did. Except that it didn’t go through, it fell through.

Read More...

I keep noticing a recurring theme in my hobbies and in business: cut out the noise and focus only on the essential.

It seems so simple, but the fascinating thing about life is that the things and people we encounter so rarely do cut through the noise. Instead it seems like most endeavors of consequence are messy, complicated and hard, and it’s not always clear why.

When you approach almost everything with the mentality of “how do I cut out the noise?” life becomes a very magical experience where a little effort in the right place can yield big results.

I think can think of at least 3 areas of my own life where cutting out the noise yielded big results.

Read More...

I recently read Pitch Anything by Mr. Oren Klaff and one of the coolest concepts in the book was the idea of “frames.”

A frame is basically the set of beliefs, contexts, and assumptions that implicitly sit behind everything you communicate. The author argues that when two people meet, their frames eventually “clash” and that only one frame can win out. This concept was also discussed in The Game by Neil Strauss, but it was presented there in the context of attracting girls, not clients.

Anyway, after I finished reading Pitch Anything, I have been blessed with a special insight into how I and others think, and to the social dynamics underlying most business transactions.

Take sales, for example. When I first started out doing sales, my mentality was always about understanding what the client was saying as precisely as possible and, to the greatest extent possible, providing him with exactly what he requested. But it turns out that’s not the best way to do business. Often times, I’ve found, people respect when you challenge them because they see it as an opportunity for growth. I realized one day that with myself, when someone challenges me head-on, I find them really interesting and then start engaging about why they disagree.

Read More...

Thrashing n. To expend a disproportionately high amount of energy relative to the quality of output you receive

When I was younger and looked at successful companies, I simply could not for the life of me understand how they ever went from NOTHING to what they were today. The modern equivalent would be like asking “How did Jamba Juice launch hundreds of stores across the country? How did that start?” It made sense to me that if you raised a massive amount of money and then immediately bought all the capital equipment and hired all the people you needed then you’d at least be capable of serving all the customers, and that the massive revenue from the customers would balance out your massive expenses…but how did it all come to be from NOTHING? It seemed like magic to me.

And from this line of thought I embarked on what I believe is the fundamental fallacy of entrepreneurial thinking: asking the question “what does a company need to do to succeed?”

Read More...

“We are hugely in favor of the technical founder. We will generally focus on companies started by strong technologists who know exactly what they want to build and how they are going to build it.” – Marc Andreessen

I’ve always prided myself on being a “technical founder.” Basically, it means that if I were hired as a dedicated software engineer I could make a pretty meaningful contribution to a software product, but that my primary role is to guide the growth of the company as CEO. I used to think that being a technical founder was an absolute advantage over non-technical founders since not only could I do the business thing, but I could really understand at a deep technical level how viable something is, and I also know what’s possible, which enables me to come up with product ideas and visions that non-technical founders might not be able to.

But life has this funny thing where our biggest strength can also be our biggest weakness. The trick is being honest with yourself about what they are.

Read More...