Let's Get Scrappy

Startups -- it's time to get scrappy! But what does that mean? Well, I suppose I could call it gettin' grizzly... But that still doesn't really explain what I'm talking about. Fortunately, it does start to get you thinking and imagining where I could possibly be going with this...

In the startup space, we often encounter companies that want to embrace new technologies, methodologies, and platforms, but they have no idea just how to execute to get there. This is normally where startups start looking for their first 'DevOps' engineer. This is a great first step, and a good way to start to ensure that you can adopt the latest, greatest trends in modern technology and hybrid architectures. But is hiring a 'DevOps Engineer' enough?

Unfortunately, just hiring a 'devops engineer' is not enough. Startups should be looking for an engineer with a focus on startups. They also need to ensure that the person thinks outside the box. As a startup, you're going to need someone who can take the 'minimum' investment, and turn it into 'maximum potential'.

You are going to need to start identifying how your first devops engineer thinks, and how they are going to scale out your business. Your first devops engineer needs to be more than just an engineer. Your engineer will need to have years of experience that you can rely on, as they help you design and orchestrate an architecture that can start out small, but scale to be massive. Really, you are looking for a devops engineer with some classic architecture background from systems and networking.

I started this post by saying that a startup needs to get 'scrappy' or 'grizzly.' I chose those words for a reason -- they give you a basis and guide you through how you should start picturing yourself as a startup. You need to be in survivor mode. You have to be able to look for ways to succeed, without blowing through what funding and investment you have quickly and aggressively, ensuring that it lasts as long as possible.

One of my personal favorite things to start out with for early stage startups is the classic 'We want to be on the cloud, it's easier to justify OpEx than CapEx, and if we do it right, it's much more affordable.' This little entrance into discussion is a very fun place to start. Noone can deny that OpEx is easier to justify on your P/L sheets than CapEx. Noone can deny that the cloud can be a great way to start out, and it can be quite affordable. Unfortunately, many companies begin thinking this way, and soon find themselves spending a great deal more money than they ever intended to spend, and they have to find creative ways to reduce that cost before it becomes detrimental to the company's success.

How do you approach that type of situation, that predicament? Well, the real goal is to never reach that point in the first place. Even when building on a cloud there are many things to be aware of from the get go; policies that should be considered from day one, to reduce the overall impact of cost as the company moves forward. Are you spinning up instances only when necessary, utilizing the elasticity of the cloud to its full potential, while reducing the costly expense of 'always on' instances that are not being used? Are you ensuring that you are handling network traffic in the most efficient manner, to reduce the potential cost of data transfer?

Ok, so those are some of the fun datapoints to consider, but what about other possibilities? What if we start off with a 'small' self hosted cloud? Many of the companies I have worked with over the years have always been terrified of this, because the belief is that it is going to cost a fortune to get the hardware, and run it. That does not have to be true. It can be, but it isn't binary 'true'. In many organizations, we are already spending $3-5k on hardware every time we onboard a new engineer. We cover these costs in the laptop/workstation, the monitor(s), chair(s), i/o devices, etc. Those costs add up. Obviously, building our own cloud has to be hugely expensive, right? What if instead of buying brand new equipment, we started out with refurbished equipment, costing not much more than one or two engineer's starting hardware investment? These days, you can find great ways of implementing small clouds (sometimes even low power) for minimal cost up front.

I am not saying that starting with the cloud (aws, google, rackspace, azure), or even building your own cloud is right -- that truly depends on the situation that you, as a startup, find yourself in. But these are things to look for when you begin hiring your early stage engineers. How do they think? How do they approach problem solving? How do they plan for the future? My own personal preference is generally to start with a small self hosted cloud in a small rack (sometimes you can even use a half height 'network rack' for this).

I'll explain my reason for this in my next post, but hopefully, you can see now what I mean by 'getting scrapping'. Think outside the box -- Would you have thought about buying refurbished equipment on ebay to save on costs? There are pros and cons to this, of course, but it is an option to consider.

Hopefully, you enjoyed this little food for thought. Feel free to reach out and contact me for any questions, comments, or thoughts on any of my posts.

-Villain