Kevin Rose: We Made Lots of Hiring Mistakes at Digg
siliconfilter.com
siliconfilter.com
On the surface it looks like a lack of strategy lead to the company hiring too many PHP developers. Of course, it could also be the developers were CHEAP and couldn't transition to another language. It could also be a lack of leadership didn't realise programmers could transition between languages or individuals were not reassigned to focus on another language so little got done.
With so little content all you have is speculation so who knows what was going on.
Bingo. It's the only logical explanation. I've yet to meet a decent PHP Developer who isn't willing or capable to turn their hand to a new technology. There must be more to it than Rose simply not exploring the idea of adding to the teams existing set of skills by letting those Dev's try new things.
We tend to severely underestimate the number of people who just want to do their job with the skills they already have with little desire to try new solutions to problems they already know how to solve. There are a surprising number of developers like this that leave the office at quitting time and not pick up a computer again until the next morning.
More often, I think companies struggle to pick up a new technology than developers. When developers pick up something new, they usually dabble and start small, but Digg wasn't in the place where it could dabble and start small. When a company needs to pick up a new technology, they aren't doing it to dabble so much as fill a solid need.
They needed expertise in other places, so they needed to hire people with those skills already rather than wait for existing devs to get them and stumble along the way.
OK - so don't hire employees, but contract with contractors. Seems a pretty simple problem, yet few companies I talk to want to go down that route.
"We're looking for someone who's in it for the long haul" or "we value loyalty" are some reasons I've heard from companies that won't consider contractors.
In some situations, that's probably fine. In many other cases - fast tech-driven startup-type stuff - contracting probably makes more sense for precisely this reason. The company's needs can change quickly, and having a lot of staff that don't know X but only Y is a competitive problem.
"But smart people can learn X too!" Well, yes, to a point, but probably not as well as the people at your competition may already know it. And who says all those smart people really want to learn X? If you're really switching from Y to X, some Y devs may resent that, because Y can handle the workload too. They may not put all the effort in to learning X, because they see it as a fad, or a dangerous pivot that is doomed to failure, etc.
"Smart people can learn new tech X too!" is condescendingly treating devs as interchangeable parts while damning with some praise ("but they're smart!")
"If your developers are either incapable of pivoting to a new language or flat out refuse to, then they are terrible developers."
You've just done 3 years of Rails development, fighting all those version bugs, pulling all the late nighters, getting every rock solid and scaling out to the moon. Yay! Launched, everything's great, and you're rocking it. Then your board of directors signs a deal with MS for Bing tie-in, and MS invests some money in your company, but you have to pivot to ASP.NET/C#. In 3 months.
Do you refuse? YOU TERRIBLE DEVELOPER!
What's that? You'd rather keep doing Rails, so much so that you'll quit your job and move somewhere else to get a chance to keep working on Rails projects? That describes most of the Rails devs I know, and I wouldn't say they're "terribly developers" at all. Well, a couple aren't great... :)
On the contrary, actually.
You want to be able to build a company engineering culture, to be able to adapt.
You want people which have a stake in the actual outcome of the company.
You don't want your programmers only be a contract away from working for your competitor.
Also: you don't want all the contracting engineering, communicating and legal overhead.
MVP+ stage requires a lot of iterative development. Ideally, you'd want to keep the people who are helping with that, because they'd know WHY things are done the way they are. They'll be aware of the failed experiments and previous iterations. You don't want future employees making the same mistakes. The goal of the MVP+ stage is to learn as much as possible about your market and product. Letting that product learning walk out because they were contractors is probably a mistake.
Building an MVP and iterating requires building to a (changing) vision. Contractors have an incentive to stick rigidly to a narrow, fixed specification. If you can build that spec and task it out then you may get good results, but just telling a contract developer your vision and sending them off to build it has a strong chance of ending in (expensive) tears.
I am a contract developer. I work with clients to elicit their requirements and have seen this first-hand - the projects that turn out best are the ones where I'm working with someone in-house who has development knowledge, even if it's just to manage and review.
----------------- You want to keep the expertise on your product IN-THE-COMPANY, not outside. ----------------- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them.
----------------- You want to be able to build a company engineering culture, to be able to adapt. ----------------- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs.
----------------- You want people which have a stake in the actual outcome of the company. ----------------- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?
----------------- You don't want your programmers only be a contract away from working for your competitor. ----------------- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too.
----------------- Also: you don't want all the contracting engineering, communicating and legal overhead. ----------------- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???
Lastly, none of what I'd initially written was posited as an "either/or". Digg's problem was they made too many hires, then were overstaffed when the nature of their problems changed. Strategic hires and contract relationships would have been much smarter, and this is something I say certainly in hindsight with Digg, but had they asked in 2007, I'd have said the same thing.
I think it was better off eaten.
"""--- You want to keep the expertise on your product IN-THE-COMPANY, not outside. --- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them."""
Then you're not doing a good job managing the company's engineering dept. Is this supposed to be an excuse for moving the experience even FURTHER away?
"""--- You want to be able to build a company engineering culture, to be able to adapt. --- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs."""
You can have both written documented processes AND employees that know them by experience, instead of just some "documents" left by some contractor that some new contractor needs to decipher.
"""--- You want people which have a stake in the actual outcome of the company. --- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?
Early engineers in a startup like Digg was have a lot of stake in their companies. Ever heard of stock options?
"""--- You don't want your programmers only be a contract away from working for your competitor. --- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too."""
There is much more friction involved if have some stake in the company, and also if they feel the "belong" in its culture. Heck, people even choose to work for companies offering less money that what competitors offer because they like their culture.
"""--- Also: you don't want all the contracting engineering, communicating and legal overhead. --- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???"""
No, the overhead of communicating with contractors is too much, the overhead of communicating with people in your company is much less. (And I can't even begin to think where you got that bizarro impression from what I wrote).
Building a startup is a time when you are finding your way and you really need people who are interested in the details of your industry. People who will look at a spec and notice things missing, or improvement to be made.
I do think that hiring contract programmers can be good and I do so myself. But I limit their involvement to smaller sub-projects that can be written to spec and easily plugged into our app. I've done that with visual components, things that require specialized knowledge of an open source framework or really complex math algorithms, etc. It has worked very well in those cases.
"Contractors" are not the be-all and end-all, but in the context of the original article - Digg hired too many people - it's an obvious no-brainer in hindsight to say some of those hires should have been contractors and the relationship revisited after 6 or 12 months.
Anybody who has written software knows that it is never really "done." And as a consultant you get forced into a mentality of meeting your spec requirement so you can get paid. To do otherwise you risk working on one project forever and never actually meeting your contractual requirements. It's just the nature of the business. If you understand this as a client then you can make it work to your advantage, but if not you can wind up with a huge mess.
No, contractors are usually not a great fit for a few reasons.
1. They're expensive. A lot of can cost a 50% to 100% premium on a salaried employee. Example most good contractors I know (solid, quality devs not rockstar architects) go for about $125 an hour in the SF Bay Area. Over 48 (assume some timeoff) weeks this is about $240,000 a year. This gets worse working startup hours where you get a cost efficiency with salaried employees when people work massive amounts of overtime. Imagine the quality of engineer you can get for $200k a year.
2. When contractors are done all the knowledge of what they've done goes out of house. Both in terms of what you lose as well as any proprietary info that can now go into competitors hands.
3. Contractors don't have to work your hours. A lot of people aren't aware of the legal differences between a contractor and a full time employee because its very vague. But you can't just say "boom" you're a contractor and expect them to show up every day like a regular employee. Some do and if they don't complain its fine, but if you piss one off they can easily get you in trouble with the IRS and your state's labor code. If you expect an employee to show up every day, at your office and work 9 to 5, and work off your product backlog then they are by law a "full time" employee. You're expected to take out payroll taxes, workmans comp etc.
No hire a few very competent people who can adjust. Where contractors have their place is on discrete pieces of work - doing your iPhone app, performance tuning your stack etc. These are great places to have contractors come in.
So since leaving digg I've heard the following phrase from many competent software dev managers - any good software engineer can learn a new language - but to Kevin - those same software engineers can't learn anything new, while he, of course, can easily learn from his mistakes.
Just to be clear - those engineers, dismissed as "PHP devs" have numerous degrees, decades of experience, and at least one published book. Kevin dropped out of a PC repair school that he likes to refer to as a "CS program."
Anyway he seems to be doing his best to expose his lack of competence.
I expect he has learnt a lot - how to sell, how to shake hands, etc.
^^ that's a key fucking learning
edit: just to be clear, I don't begrudge him anything. Kevin negotiated the best deal for himself that he could and that's what everyone should be doing. I hope the employees got taken care of as well, but it is what it is. Being an employee at a startup, and I'm on my third, is gambling.
In my time at digg, there was no retraining, nor really any feedback from management at all. As far as I could tell the leadership team spent most of their time working on Revision3.
It's not exactly a unique story, in fact it's not limited to start-ups, it's pretty endemic in the whole IT-business.
That's all kind of beside the point however. Jay Adelson was there pretty early on he should have been technically savvy enough to avoid these pitfalls.
The article is poor summary of the interview, which I saw replayed TWiTs live stream. While the quotes are accurate, the interview wasn't really about Digg
no it was not community driven, that was their mistake, that is something a user ends up figuring out and leaves
Hire inside your comparative advantage. Contract/vendor everything else.
In an engineering heavy culture, community management is sometimes incorrectly viewed as something 'anyone could do'.
I know what an accomplished developer's resume looks like and how to vet it... I have no idea how to vet a community manager effectively.
Tips/Suggestions?
NOTE: A successful community manager would have the right personality, good sense of fairness, good communication skills, etc... a handful of skills that are hard to assess quickly. That is why I ask.
I generally feel that a great community manager has a wide base of skills, is incredibly social (has a large network), knows how to deal with trolls and also has a fairly decent tech background.
The questions should be around how big of communities they have managed, what they do to grow them, how they deal with problems (big problems, like a billing fiasco) and how well they know social media.
That being said, most "social media experts" make me want to vomit a bit and if someone professes themselves as such, maybe they aren't the right person for you.
They are harder to assess, as there aren't as solid of skills. No github acct (although if they have one, thats awesome)
spoiler: It's not just because of the logo
Regardless, Digg v4 was clearly the problem. I still haven't seen him outright admit that the fact that at launch Digg v4 was basically a blowjob to Mashable, Wired, and other "content" sites and a big middle finger to the average user.
If he could honestly own up to the fact it would demonstrate a real understanding of what caused everyone to flee.
"According to Rose, “there is a temptation that you want to throw as many developers as possible at a problem.” As Digg was built on top of PHP, the company would hire too many developers that specialized in this language. Then, however, Rose noted, “you end up with lots of PHP developers, but at some point, PHP isn’t a problem anymore and you are stuck with all of those developers.” At that point, said Rose, you end up having to hire a lot of developers that can do other things and don’t know what to do with the old developers."
PHP wasn't the problem, stables full of idle, cash burning developers was the problem.
Normally it's hard to do an apples to apples comparison, but having reddit around, and running for a hell of a long time with less than half a dozen people, really allows one to actually do that comparison in a pretty solid way.
I'd even argue that even though reddit has only recently surpassed digg in terms of users and page views and all that, it far surpassed digg in terms of content quantity long before it. Yet was still managed with a micro-sized staff.
Of course v4 was a huge pile, but at about 8-10x the burn rate of reddit, you almost have to do crazy things to make it work.
It's like the Mythical Man-Month was never written.
http://allthingsd.com/20090122/digg-to-cut-10-percent-of-emp...
That's a pretty strong statement. I'm glad I don't work for you. If my employer decides to switch to Cobol and I refuse that makes me a terrible developer? What if they want to switch from an imperative language to a functional language? If I can't easily make the transition I am terrible?
What is so wrong with developers that specialize in one thing, even if it's PHP? Regardless of your opinion, there is a place for those kinds of developers. They likely won't advance as far as those with a broader skill set, but they are not terrible or useless.
This isn't the developers' fault. Rose hired a whole team of developers that were not qualified to do the required work. That's on him, and he is rightly accepting responsibility.
Of course a developer refusing to switch to Cobol or Brainfuck is completely justified.
But switching from PHP to Ruby, Node.js, Python, etc. is a completely reasonable transition to expect a competent developer to be capable of. I'm not saying you should be able to be an expert in the new language overnight, but IMHO any developer worth her salt jumps at the chance to learn a new language on the company dime.
I would agree with that sentiment. Another way to put it is I would prefer not to be on a team with a developer that wouldn't do that.
Still, I also think competence can be relative. There are lots of developers who prefer to stick with one thing. They usually cost less and are more likely to stick around long term. They can be experts in their domain (even if it is limited to 1 or 2 languages). There's something to be said about someone who is content (or ignorant) to have their career stagnate for years working with older technology and projects that keep the company running. Personally, I'm of the opinion that it's important to keep up with the times, but if you have a requirement for that sort of thing those developers can be the workhorses on projects that some other developers wouldn't touch with a ten foot pole. They can also mean certain disaster if you hire a bunch of them for your fast-moving startup.
The distinction for me is that competent is not necessarily good. For me, good is a higher bar than competent. That's why I said any good developer, any one I'd want to work with (as you say), wouldn't be a problem with switching languages.
Was PHP the only language these people knew? And they were incapable of learning anything else? I don't get it. I don't call myself a "C++ developer" even though I use C++ every day at work. I know several languages, and I am confident that if I wanted to start learning a new language tomorrow, I could get up to speed on it and its relevant libraries fairly quickly.
Were these so-called "PHP developers" completely incapable of learning Python or Ruby or some other language? I don't understand how you can be a software developer and only ever use one language in your life. But for some reason this seems to be common when I read articles about web development.
On the other hand, I would love to hear the story of why Digg failed from one of these developers.
I've always thought his blaming the digg developers was pretty classless. He was in a leadership position, he needed to lead.
(if you watched any interviews with KR, you knew this years ago)