Hacker News new | ask | show | jobs
by johngalt 4571 days ago
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.

3 comments

I completely disagree. Traditionally, Sysadmins are what you bring in once you've grown enough that operational issues detract from development. Not only this made sysadmins feel terrible over the years having to deal with nasty production environments, but also developers were always slowed down because "Ops" were the bottleneck. And they were the bottleneck because developers didn't think like sysadmins when they started. It keeps going back and forth.

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.

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

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.
+1
> A sysadmin is the last thing you'll need while doing fast iterations on an MVP

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.

Sounds like you agree with everything I said until you edited my comment down to that sentence.

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.

On that point (needing a sys admin for say 10 hours a week), where should a currently devs only team be looking? Remote freelancer? Dev with ops / sys admin experience?
Depends on the nature of the work. Begin with the understanding that operational concerns will never be zero hours. The best freelancer in the world will need guidance from the internal staff.

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.