Introducing Gruntwork

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…

A Common Pattern in Successful Companies

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.

One of the other cool things about my line of work is that it’s right when companies are about to scale to the next level that they call me. So, for the most part, the companies I interact with, are successful startups on the verge of fast growth.

Now here’s the interesting pattern I see. I have yet to work with a single software team that doesn’t suffer some level of “embarrassment” about the state of their codebase, the “amateur” methods they used to get the job done, the duct tape they used here, or the total-makeshift-not-scalable solution they used there. It’s a really…unexpected combination: a business whose growth rate and product-market fit looks awesome, and whose product is filled with shortcomings.

Continue reading

Doing Business in The Right Order

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.

Continue reading

Your New Normal and the Futility of Stress

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.

Continue reading

Cutting Out the Noise

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.

Continue reading

The Power of Frames

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.

Continue reading

The Fundamental Entrepreneurship Challenge

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?”

What’s wrong with that rather innocent question? Well, it’s missing a critical component that ultimately matters more than anything else.

Time.

If I were speaking to my self from 10 years ago today I would make a very important point of clarifying that the real question is not how can you grow a company to be successful. The real question is, how can you learn to be successful in the shortest possible time?

A college professor once told me: “Given enough time, every single one of you could completely master the subject I’m about to teach.  But the problem is you don’t have enough time and neither do I.  So you’re going to have to figure it out in one semester while you take all your other classes, too.”  What a perfect example of the same phenomenon.  When you go to school, the question isn’t “what can I do, no matter the cost, to get the highest possible grade in this one class”, the question is “how can I get the best grades in all my classes this semester while still having lots of time for fun?”.

I would say for myself that I have experienced more personal and business growth in the last 12 months than in the prior 3 years combined.  One of the fundamental differences?  I’ve started imposing more constraints on myself than just “learning how to be successful.”  I think about how I spend my time on each of my days.  If I feel like I’m thrashing a little bit (see definition at the beginning of the article), then I know something’s wrong and I invest some time to assess what’s going on.

I think one of the main differences for myself is that in the past year I’ve been fortunate enough to find some amazing mentors.  These are people whose accomplishments I am blown away by, who I have a great personal relationship with, and who are willing to give me input on ambiguous issues that come up.  After enough conversations, you basically start to pick up the same patterns of learning and the lessons that they accumulated over a lifetime.  Mentorship, I’ve come to realize, is literally the primary mechanism through which society evolves itself.

I mean, think about it.  If you didn’t know how to write but you knew how to speak, how ridiculously hard would it be to invent this concept of an alphabet, which combines different “letters” together to form “words” which are expressed in “sentences” which are organized in “paragraphs” and annotated by “punctuation.”  Writing is such a basic thing and yet figuring out writing from scratch would take probably a millennium.  But learning writing?  Well, a few years in school.

That’s how it feels since I’ve been fortunate enough to find mentors.  The “learning on my own” process is shortcut by about 99%.

When I think about how much thrashing I’ve done at different periods in my business career, it just makes me sad.  As Mark Cuban says, you can make as many mistakes as you want in business as long as you don’t make a really big one.  So, yeah, I avoided a really big mistake, but I think about how much time I spent on some things that one great conversation with the right person could have saved me from.  I mean, really, think about it.  The idea that a single 1-hour conversation could save you months of work?

And that’s really what it comes down to in the end.  The enemy of entrepreneurial success is not failure.  The real enemy of entrepreneurial success is thrashing.  What would you rather be?  Moderately successful at age 30 where you have another 70 years to apply the lessons you have learned, spend money, earn money, love, live life, grow, etc.  Or ultra-successful at age 80 where you’ve spent the bulk of your life learning how to actually figure out how to be ultra-successful.

Life, of course, rarely presents such black & white choices and the greater point here is really about how given enough time, sure, just about anyone could learn to be as successful as they wanted, but that time is precious, and scarce, and should be spent thoughtfully and purposefully.  A day spent making awesome progress on something you care about is infinitely more satisfying than a day spent thrashing.

 

The Technical Founder: Strengths and Weaknesses

“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.

On the positive side, being technical is wonderfully empowering. When I talk with our development team, we review details down to the database diagrams and how that will ultimately affect the product vision. I know with confidence at a deep technical level how powerful our software is and how that power can be leveraged in the future. I can formulate ideas for products based on knowledge of our database schemas, recognize problems that have high value to a client and are technically less challenging, or have an appreciation for those problems — like online registration, for example — that are actually quite complex and require considerable thinking.

I realize I love technology so much that these conversations are pure joy for me.

On the negative side, though, loving technology so much means you think in terms of technology. During engineering or product development meetings that works great. But when it comes time to put on the CEO hat, a mindshift is required. Because in CEO mode, those technical details are not empowering. In fact, they’re the opposite, they just get in the way.

Earlier today I had the opportunity to speak with an accomplished healthcare IT entrepreneur who could probably reasonably consider himself technical as well (MIT graduate). As I reflected on our conversation, I realized that there were moments in our conversation where he asked me questions that had a business — not technical — spirit behind them, yet I answered as if I were an engineering consultant, not a CEO.

The problem? My technical mind interprets his question first and foremost on a literal level and launches into a literal response! And sure enough that’s exactly my comfort zone! Comprehensive, technical responses.

But the funny thing is when I’m surrounded by businesspeople who only want to speak in high-level terms and I absorb their high-level mindsets for a small amount of time, I find I quickly adapt to the high-level thinking. Questions asked with a business spirit are answered in a business spirit, even if they have a technical element to them.

And this is the domain of the CEO. You step outside of the trees and speak only in terms of forests. You use the background technical information as minimally as possible, calling on it only when the situation makes a special request for it. You transfrom from being precise and comprehensive — a critical trait when designing software — to being loose and general.

Sometime this year it finally dawned on me why the CEO has to speak and think in these terms: because no one else cares about your details. They only listen to what your “proposition” is and then make a decision about whether you appear legit or not. The details simply aren’t important.

And sure enough we see this phenomenon in other spheres of life, too. I was SHOCKED to discover that one of the worst ways to sell software is to show it. Instead, the more you talk about it and the less you show it, the more inclined people are to buy it. Why? Because most people don’t care about details.

To summarize the conclusions in this post:

  • Being a technical founder is awesome
  • But watch out for situations where it gets in the way

Lead Like the Great Conductors

This is a beautiful exposition (and metaphor) on the role of a leader. I’ve often wondered if it’s better to set forth clear guidelines so that everyone knows exactly what to do, or better to provide people a framework within which to “tell their own story” (to use the words of Mr. Talgam in the video below).

Ultimately, I’ve found that different people respond to different styles. But if there is a “default style,” I believe the conductor who empowers the musicians to perform the music in their own style while providing subtle yet meaningful guidance on context, feeling, and intent produces the most beautiful music.

Zappos Offers New Hires $3,000 to Quit After 4 Weeks

This article was posted two years ago, but it’s still a pretty cool concept.  Basically, Zappos (the online shoe site that Amazon recently bought) will train new hires for 4 weeks, and then offers them $3,000 to quit.  Check it out for yourself:

http://www.businessweek.com/smallbiz/content/sep2008/sb20080916_288698.htm

I feel these kinds of counterintuitive moves have a deeper wisdom in them.  Conventional wisdom says “why would ever induce someone who we just spent 4 weeks training to quit?”  A more zen approach says “we only want to work with people who really want to work with us, and we believe if they take ‘the offer’ we all saved ourselves the heartache of what would have been inevitable.”

The offer above isn’t perfect and does have its drawbacks, but it’s certainly a concept worth pondering.