Your First Hire Should be a Sysadmin(engineering.crowdtilt.com) |
Your First Hire Should be a Sysadmin(engineering.crowdtilt.com) |
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.
I hope the audience is smart and intuitive enough to understand that if none of the co-founders is a coder, then obviously your first hire can't be a sys-admin. With that assumption, having a sysadmin early on will only improve the productivity of the development team as is the case at Crowdtilt.
I guess the better word than Sysadmin is DevOps. Because what the author did at Crowdtilt wasn't just deploying and maintaining servers, but actually impacting and streamlining the development process.
edit: the title mis-match was by a mod
I'm not sure I agree with this. Someone needs to be working on your CM scripts and debugging production issues... and if it's not a SA, it's you or your developers. If you really want to iterate as quickly as possible, you need your developers focused on developing, not system administration.
If there's honestly 40 hours a week of ops issues during the first hire/MVP/market fitting phase. One of two things is happening:
1. Your startup is so wildly successful out of the gate that operations/infrastructure needs to grow exponentially.
2. Your startup has produced something that is complete garbage.
Neither situation is likely, but I'll let you guess which scenario is more common.
A much more realistic scenario is that ops work starts off as 5hours/week and grows to 10, 20, 30, 40 etc.. over a couple years without anyone noticing. By that time you've got a team of 4-6 devs and operations issues have become an annoying interruption to all of them. This is where bad IT decisions happen.
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.
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.
Especially when services like heroku and take alot of the heavy lifting of the start ups hands, initially anyway.
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.
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.
For example, good product, code is done, bad design => hire designer.
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.
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.
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.
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.
If you've already got something in place and operating at <10 hours a week, I'd keep it in house with whatever dev has more ops experience. Or whichever one drew the short straw after no one admits to having ops experience. You could hand it off to your newer hires to gain an understanding of what you do. The key is to define who responds to what.
Keep an engineer on retainer that you can call in to handle one-off builds and emergencies. Big changes/deployments where you can't afford to gain experience the hard way.