

Your First Hire Should be a Sysadmin - knighthacker
http://engineering.crowdtilt.com/your-first-hire-sysadmin/

======
johngalt
Sysadmins are what you bring in once you've grown enough that operational
issues detract from development rather than add to it. A sysadmin should
absolutely not be your first hire. At most a consult with an engineer in the
early days to get you started. This would help if your coders are used to
handing off deployment to someone else. Bluntly, if you completely lack ops
knowledge, buy an hour block from an ops specialist that can get you over the
rough patches.

My concern with a sysadmin first is that you'll want your early development
very tight with your production systems. A sysadmin is the last thing you'll
need while doing fast iterations on an MVP. In the early days your need for
feedback is high and your operational issues are low. After some significant
growth your ops needs will be high, and the feedback value of those issues
will become lower (more repetitive less new information). This is where you
bring in a sysadmin to manage/automate the repetitive and filter some of the
ops issues into actionable information for the development team.

Edit: Ops guy for over a decade btw.

~~~
mago0
Author here. Admittedly, the title is a bit strong (though mismatch in titles
was by a mod) but I was hired simultaneously with our lead dev and focused on
ops/automation, as well as, product development in the early days. More
accurately, my point is that it's extremely important to have _someone_
focusing on these issues from day one.

edit: the title mis-match was by a mod

~~~
johngalt
The article makes more sense from that perspective. The idea that ops needs
should be planned and responsibilities designated makes sense. Otherwise it's
easy to end up with fragile systems that are no one person's responsibility.

~~~
knighthacker
+1

------
wpeterson
I could not disagree with this more.

Focus on building your business and your product, not devops infrastructure.
Unless your business is devops infrastructure.

Your initial technology stack should allow you to deploy code seemlessly from
day 1. This is why Heroku is a great start for early startups, despite the
drawbacks.

~~~
nasalgoat
Having spent nearly a decade of my two decade career cleaning up totally
broken developer-architected systems that were so poorly coded for performance
that they could barely handle 10 concurrent users, I have to strongly
disagree.

It's getting better, but most developers still focus on making it work _right
now_ over making it work _right_. They don't think about caching, or query
optimization, or debug logging, or stateless scenarios for portability and
clustering.

These are all things that need to be thought about _before_ you start.

That said, a generic sysadmin won't be the kind of architect that is _best_ ,
but they'll be thinking about more of that stuff than the devs, plus he can
implement and manage your infrastructure. Seems like a win to me.

------
knodi
No, a full-time sysadmin is dumb idea for first hire. Your first deployment is
not going to be complex and there will be a lot of moving parts. If you dev
team can't understand deployment I'm not sure what your expecting your first
hire sysadmin to do.

Especially when services like heroku and take alot of the heavy lifting of the
start ups hands, initially anyway.

------
j_baker
I don't think you should hire a sysadmin until you have a larger set of
developers. Still, I think there's a good point here: you should think about
deployment early on. Having things automated will allow your early team to
spend more time writing features and less time fighting fires and hacking
production configurations.

------
herge
We are a small 5 programmer company, and we implemented a couple of ansible
scripts to deploy our applications a 2-3 month project.

For us, at least, a full-time sysadmin is overkill, and I would expect any
decent programmer to be able to implement this himself as part of his basic
skill set, or to be able to learn it quickly.

------
falcolas
I imagine it depends on your focus. Want to pay someone else to do your
sysadmin for you and take advantage of the economies of scale - use a PaaS
provider and makes plans for when you outgrow it.

Want your developers spending time debugging CM scripts and install quirks?
"Full stack" developers it is.

Want developers developing, and your application doesn't fit into a PaaS
architecture? You absolutely need to hire a sysadmin.

------
kurtle
Your first hire should be the person who fills in the missing gaps in your
product.

For example, good product, code is done, bad design => hire designer.

~~~
throughnothing
yes!

------
charlesju
I'm also going to have to disagree with this one. There are plenty of
frameworks (Ruby on Rails) and companies (Engine Yard, Heroku) that take care
of these issues for you on a time-share basis (ie. 20 companies use them, they
hire 5 sysadmins). I would say if you're not spending 7 figures on server
costs a year you absolutely do not need a personal sysadmin.

~~~
druiid
Disagree with the seven figures number. Six figures, sure. Seven is just
silly. You can have a lot of gear or servers for mid/low six figures.

------
jameszhang
I really disagree with this. For your first hire, a full time sysadmin who
cannot work on developing the product itself is just as useless as hiring a
developer who cannot ship the code.

I think what this article is trying to get at is that your fire hire should be
a full-stack engineer who can also play the DevOps role when needed.

~~~
throughnothing
I think saying a sysadmin 'cannot work on developing the product itself', is
silly. I think it's a given that anyone joining at such an early stage of a
company is going to be developing the product. You will definitely need a
sysadmin that can develop the product and move fast. Your architecture is part
of the product, and the sysadmin should help with the design and
implementation of the architecture, as well as possibly parts of the codebase
going onto that architecture.

------
CreakyParrot
Why was the title changed from "Should" to "Could"?

While I don't agree with the author's argument, he's at least making a
specific point.

"Could", on the other hand, reduces it to being meaningless. Your First Hire
_Could_ Be a Weirkeeper. Or a milliner. Or a janitor. Or, you know,
_anything_.

~~~
knighthacker
The post was changed by a moderator. Our blog post title is what we stand by

~~~
CreakyParrot
Sorry if I wasn't clear; that's what I assumed happened.

Which seems an awfully silly thing for a moderator to do since it effectively
guts the premise of the article. Glad to see it's been changed back.

------
goggles99
> _Your First Hire Should be a Sysadmin_ (an imperative and definitive
> statement)

Written by a Sysadmin....

He goes on to say how he built infrastructure and how it benefited the company
but... He was far from the first hire at Crowdtilt - which invalidates the
whole premise. why compromise the whole integrity of the article with a false
premise and untrue suggestion.

~~~
mago0
The title is strong, yes (on purpose). I'm not certain how you came to the
conclusion that I was far from the first hire at Crowdtilt. Your statement is
simply false.

