Comments on: How Are You Staffing Your Startup?

By: Grant Austin

Grant Austin — Sat, 17 Jan 2009 21:09:19 +0000

I used to work at a small software development company. One of my friends and coworkers there was a really amazing sysadmin. He was always working hard so he could get into development, even though he was way more valuable to the company in his current capacity. I think his reasons basically boiled down to two things: Most people see system administration as lower prestige than software development and, at small companies anyway, system administrators get paid significantly less than developers.

By: Nes

Nes — Tue, 16 Dec 2008 19:25:34 +0000

The barrier between systems/database and developers happens in big companies often because the systems people have to handle stable production environments whereas developers are pushing the envelope in new projects and the production people are not willing to be more agile and flexible to try new things. There are usually checks and balances in place to avoid screwups in productive environments (for example multiple signoffs) that slow down development.

By: m0j0

m0j0 — Tue, 16 Dec 2008 13:57:25 +0000

In a small company or department, I think skill diversity is a requirement, and I think these environments run more smoothly when there is skill diversity, precisely because there is some overlap in the skill sets of the staff there, which makes a lot of things easier both from a technical and managerial perspective. I believe I do point out that things will work in this mode… to a point. And I begin to define where that point occurs.

I suppose I should note again that the environment I’m speaking to here is the recent startup environment. In my experience in dealing with relatively recent startups, the ones I’ve seen do well are thinking about systems-related issues up front, and have a systems person on staff (who probably also does a bit of coding or, in my case, database work). The ones who are floundering seem to be unaware that there are systems issues to address, or that there’s planning that can be done and precautions that can be taken in their code to insure that the application will easily scale when systems scaling maneuvers are performed later.

Skill diversity only goes so far. The idea that a developer who has “seen a system or two” has the experience to foresee, plan for, and conquer even relatively short term (in web 2.0 time) scaling issues is almost certainly hubris. Perhaps not coincidentally, it’s also right in line with a lot of things I’ve heard people at startups say. I’ve mostly kept my mouth shut about it rather than confront people with big degrees and even bigger egos. But now, when I go to sites where there’s still the (completely stupid) ‘stealth-mode’ splash page up, months after their planned date for going live, I begin to think perhaps my own theory that skill diversity doesn’t get you all the way there, and systems people really can improve the outlook for a startup weren’t just selfishly-motivated wishings.

I can’t remember if it was someone from flickr or livejournal who once said in a talk that, if they could do it all over again, they’d put more thought into the systems end of things. I would imagine that, somewhere, someone from twitter is uttering something similar right about now.

By: Arjen Lentz

Arjen Lentz — Tue, 16 Dec 2008 13:02:41 +0000

In a small company, skill diversity is a great asset.
In an organic-growth company, one could even say it’s a necessity.
There are some downsides to skill diversity, but as long as you’re aware of it, I think it can work out fine.
As the company grows, specialisation is something that tends to naturally happen; managing that in a smart way can again make things work better.

By: Manuel Padilha

Manuel Padilha — Tue, 16 Dec 2008 10:45:08 +0000

I worked for 3 years as a sysadmin, regularly meeting developers “on opposite sides of a deployment or application support problem”. It wasn’t pretty.

For the past year an a half I’ve joined a development team as a developer. It sure opened up my horizons. But I can say the opposite is also true, having me on board said team managed to tackle things like multi-plataform support, multi-threading, caching and network performance optimization, which would otherwise remain unexplored areas.

Excellent post by the way.