Startups: Fire Your Dev Teams
Facebook should have fired their development team the minute they became successful. If you’re a startup and you just made it big you should take a long hard look at your software team and make some changes.
I’ve worked for two startups and consulted at several more. I’m not just talking about software startups, this applies to many industries—transportation, web 2.0, shopping, digital media, government—where the guys who built v1 of your web site, order tracking software, customer service tool, batch processing system, whatever, are unequivocably not the people you should rely on to take you from Startup to Enterprise.
When you’re a startup, time-to-market and user base are absolutely the most important success factors. For an aviation startup, flying your planes, selling your tickets and generating a loyal customer base are the most important things. As a computer manufacturer, you hire ex-military types to run your logistics and can custom build a PC and get it to a customer’s doorstep in four days. In general, an IT/programming competency is not required for a startup to be successful. In fact, “enterprise” engineering practices can actually slow you down. As someone who’s written software at startups I know the pressures to get the next demo ready, to release the next feature for the web site. At that stage in the life of a startup we don’t even know if the company will survive another month. Heavyweight testing, deployment and release processes just slow you down. I’d argue that most development teams actually do the right thing at this point. Get the software done, fast, and make it mostly work.
The problem I’ve found when working at startups-turned-enterprises is that the guys who built v1 of that web site are now running the IT department. The operations guy who originally managed the company’s one web site is now in charge of your entire data centre. The v1 codebase has been hacked and patched into v2 and v3, and everything is in a mess. Let’s talk about the codebase. When trying to get stuff out the door as fast as possible developers will often find out that a design decision they made is no longer appropriate. Given enough time they could fix that problem, but they don’t because the demo is happening tomorrow. And this is the right decision! But letting that patched, hacked, copy-and-pasted codebase live any longer than it takes for the company to declare itself stable is a really bad idea.
Most software developers don’t know how to engineer large enterprise systems. Most large enterprise systems are engineered badly. I know, I’ve seen a lot of them. Even with a resume with years of experience on appropriate sounding systems, most developers won’t know a well engineered app from a hole in the head. Now give these guys a couple of years hacking some code together for your startup and promote them to Chief Architect. Hire an expensive consulting company to help you build your systems better, and allow Chief Architect dude to ignore their recommendations. What?
Seriously. The minute you’re successful, plan to rewrite your software from scratch. Plan to hire enterprise quality developers. Move anyone with decent business knowledge (like Chief Architect dude) into business-related roles. They’ll be much more valuable there and cause you less problems. Hire a new development manager with proven experience engineering enterprise software. Pay them market rate +30% (you’re successful, remember?). Keep your developers but explain to them that you’re no longer a startup and they’re going to have to raise their game. At the same time you’ll be putting that old codebase in maintenance mode and starting with a clean slate. This will require planning with your business—you won’t be giving them new features for a while until you can rewrite your software. Believe me, you’ll end up with much better engineered software that can respond to change faster than your existing stuff.
Don’t believe me? As a successful startup looking to become an enterprise, try the following exercises:
- Add a column to an existing database table. Make it required. How many files did you need to alter to get that field to show up on screen? How many people were required to make the change? How did you migrate old data to the new format? How did you test the change, and are you sure you didn’t break anything else? How long did it take to deploy? What about rollback?
- Run a cut-and-paste detector on your codebase. Simian works for Java, C#, C++, Ruby, HTML and other code and is a great way to scare the crap out of your dev team (assuming you’ve admitted that duplicate code is a bad thing).
- Find out your automated test coverage percentage. If you’re not yet tracking this, now would be a good time. 80% coverage on a real world project is extremely good, most projects run much below this. If an automated test isn’t testing your code, how do you know it works?
mike on January 29th 2008 in Web 2.0
Clinton Begin responded on 29 Jan 2008 at 6:11 pm #
So true! I look forward to being “fired” as soon as we’re successful. Or more appropriately moved to the “business role” of drinking pina collada’s on a beach with a notebook computer that costs more than its worth and my own firedancers.
On Facebook in particular: It is very true that the APIs they’ve developed are horrible. I think they have taken steps to improve them though, including hiring new people. Some of the more drastic changes resently, likely did not come from the same individuals.
Great post Mike!
Clinton
Andy responded on 29 Jan 2008 at 6:56 pm #
Thank you for this post. I’ve tried to put these thoughts into words, but have always been lacking the expert touch you have given things. I work for the government and my manager happens to be the start-up guy. I love him for all of his institutional knowledge, but he is biased toward that v1 code base. It makes it difficult for me for obvious reasons. Tell my boss it needs a complete rewrite? Yes, but as softly and gracefully as possible.
Zed A. Shaw responded on 29 Jan 2008 at 10:01 pm #
Ah, perfect. This will go nicely in my collection of idiots for my next rant.
Mmmmmm, tasty stupidity.
Joel Parker Henderson responded on 29 Jan 2008 at 10:24 pm #
Smart developers can produce excellent scalability results by mixing in these kinds of concepts: data replication (master/slaves), file replication (rsync), caching (Apace, memcached), distributed computing (map+reduce), hosting services (Amazon S3, EC2), performance profiling (Eclipse & dtrace), native tuning (hire an expert to port hotspots into C), more RAM, multicore chips, and more. In my experience, these approaches are much faster, cheaper and smarter than hiring “enterprise” developers.
Premed Boya responded on 29 Jan 2008 at 11:05 pm #
I think it all depends on how good the people you start with are.
They might very well be capable of “enterprise” level engineering too.
No need for such inflammatory claims… unless ya want to be picked up by reddit of course…
jimmyD responded on 29 Jan 2008 at 11:09 pm #
“Plan to hire enterprise-quality developers”.
FAIL!
Welcome to the internet. It runs on hacker-built systems that have shown to scale beyond any enterprise-like counterparts. DNS, SMTP, HTTP – all outperformed and out-scaled their enterprise-ish counterparts.
Enterprise != quality.
My $0.02:
Hire the smartest people you can. Fire any dev, lead or manager who champions UML or who can’t code on a whiteboard.
Treat your engineering team as adults. Make sure they are aware and aligned with your biz goals. Hire & fire quickly and often.
Rinse, repeat.
Adam Ierymenko responded on 29 Jan 2008 at 11:55 pm #
I think you’re basically right here. But at the same time, this is really dangerous advice. The problem is the all-important question of when you’re stable enough to transition from gunslinger mode to enterprise mode. Call it too soon, and you have a feature freeze while you’re still climbing into the market.
If I had to err, I’d err on the side of making the transition a little late rather than a little too soon. (But not too late!)
Also: Rather than firing what are probably a fantastic bunch of code slingers, I’d move them into a kind of “skunk works” role. Have the enterprise folks take over the mature stuff, and move your gunslingers into building entirely new products– assuming you have such a roadmap on the horizon. Just like most software engineers don’t know how to engineer for enterprise, I’ve found that most enterprise engineers are rather slow and plodding and don’t know how to whip out miracles the way startup hackers do. The two are different kinds of people, and they are best at different stages of a product’s development.
Scribilus responded on 30 Jan 2008 at 12:34 am #
Good post. The prevailing wisdom is to also fire the founders of any startup that seeks to go enterprise. *In general*, people who are great at the frentic just-make-it-work mode a startup requires are horrible at the toe-the-line mode staid enterprises seem to require. However, one thing I would tend to disagree with is the need to rewrite your app. I mean, you better have some major buffers against competitors to do that. I’ve never seen a rewrite work in a heavily competitive environment.
Pavel responded on 30 Jan 2008 at 2:04 am #
I think you are confusing programming competency with enterprise “engineering” “practices”. Most enterprise software is crap because these “practices” are crap.
Jan responded on 30 Jan 2008 at 2:46 am #
Actually, you need to pretty much fire everyone except maybe the cleaning lady. Managers that are good at starting a company are usually utterly incapable running and scaling a company on the long term.
Ryan responded on 30 Jan 2008 at 9:04 am #
Oooh, fail. Try again.
Now, I’ll admit, there may be an element of truth to this, but it only applies if you’re hiring the wrong people to begin with and somehow your blind squirrel of a business manages to find a nut. If you’re hiring the right kind of developers to build a start-up around, they’re going to be the kind of developers who, while making the compromises that get the demo out the next day, give you constant push-back about the fact that you’re not letting them do things the right way. By the time they’ve helped your company become successful, you should be so deep in promises of letting them them do it the right way some day that they’re ready to walk if you don’t.
Justin responded on 30 Jan 2008 at 9:22 am #
Yeah, and then no one would be a developer for a startup.
Isn’t this what everyone criticized Jobs for at Apple?
Jamie Flournoy responded on 30 Jan 2008 at 2:30 pm #
The rewrite should be a piece of cake without the institutional knowledge in those devs’ brains, right? Just read the detailed, up-to-date spec that every startup maintains. That, together with the meticulously commented code and comprehensive automated test suite will make the transition to the new team a cinch.
And this on a blog called Agile Thinking? Nothing is less agile than firing the whole team and rewriting from scratch.
XP Principle of Small Releases:
http://www.c2.com/cgi/wiki?SmallReleases
A rewrite from scratch is the biggest release possible.
Things You Should Never Do, Part I:
http://www.joelonsoftware.com/articles/fog0000000069.html
Instead, how about this: only hire new people in engineering & ops who have enterprise experience, phase out the people who won’t adapt (possibly including the architect / team lead), and fire the deadwood who were hired in desperation back in the early days.
Paul Evans responded on 31 Jan 2008 at 11:56 am #
Wow, I’ve been subscribed to this blog for a while and this is the first thing I comment on… I wish it was more positive.
At the end of the day I believe a company is only there because of the people that make it up… on the other side of the spectrum from your experience I’ve seen a single key developer or manager leaving having a huge negative and snowballing impact.
Surely the people that helped you build a successful company are worth investing in to improve their talents? Rather then replacing them with people from the outside that come in only when the going is good?
Developing the people that started the company, and allowing them to either stay at their original post or allow them to grow in to more senior roles if they show that aptitude and want for leadership – just seems to make more sense to me.
After all it doesn’t matter how good you are at your position, there is a period of time that new hires go through where they have to familiarise themselves with the company and their position within. It just seems to be very expensive to get rid of all the people with product knowledge *and* rewrite the entire thing – which will be inherently less mature code.
Steve responded on 31 Jan 2008 at 2:15 pm #
Hmm, interesting article. I think it’s way too generalized to, but there is some truth in it.
I’m that hacker you speak of for my startup, and I actually have been planning for and looking forward to being phased out of the programming side. In fact, in everything I’ve coded from day one, I’ve included lots of comments in the sections of code that are hacked together and what the much more efficient way would be to replace it so that I don’t have to explain it to our future programmers.
But I don’t think it’s true for everyone. For the most part, I don’t think that every startup hacker is bad at enterprise software engineering, I think they probably just don’t enjoy it as much, so instead of going back to make stuff reliable, they’d rather keep themselves busy with new features. And that’s not necessarily a bad thing.
Sean Ransom responded on 06 Feb 2008 at 8:25 pm #
This seems a little backwards and shows the bias and disdain companies (and apparently people who should know better) sometimes show for the people that are responsible for bringing their most important asset to fruition.
If the right people are not in place at launch this is a MANAGEMENT problem. Maybe look there first for whom to fire first.
I worked for many years at a startup called amazon.com . A major problem there was the hiring of a well respected enterprise engineer who wrote and designed the first code at amazon.com. 10 years later it still held amazon back from making major architect changes. It was not his fault, the scale that amazon built to so quickly could not have been planned for. Huge success and the associated demands on your code base have never been solved by anyone the first time around.
Well high cost enterprise consultants will tell you otherwise but they are liars and will keep lying to you as they deplete your startup seed money.
jro responded on 07 Feb 2008 at 8:52 pm #
Are you saying the folks who are qualified to build enterprise applications the ones who have no capacity to make you succeed? That they only do well when given a running start? Wow, how beneficial (note — that’s sarcasm). Where I come from, tribal knowledge has always trumped anything marked “enterprise”. Dance with the one that brung you, I say.
But never mind that: my favorite reference is how Facebook is now “successful”. Last time I checked, they’re not making any money (just raising a lot of investment.)
But I guess, in the enterprise world, that’s what qualifies as success.
Tim Dysinger responded on 07 Feb 2008 at 11:05 pm #
I should qualify that last statement. I don’t agree with you, obviously. You shouldn’t fire the team that just got you to first base. If you hired a bunch of hacks from the get-go then it’s a management problem for sure and not the developers.
Start ups are a continual growth. That means that you fire the people that suck and hire new ones – ALL THE TIME.
There is no “Enterprise Quality” developers. There are just good ones and bad ones. You make it sound like it’s some sort of certification you can get from Sun or MSDN.
Henrik Sarvell responded on 08 Feb 2008 at 9:53 am #
Your reasoning is flawed when you assume that the people who are best for getting the biz up and running automatically can’t take it further. The only rational thing is of course to hire people that can handle all phases in the development of a company. I know for a fact that such people exist, isn’t that amazing huh?
Tobi + C# = T# » Startups: Who should you fire? responded on 12 Feb 2008 at 7:14 am #
[...] just came across a pretty funny, or sad (?) post by Mike. Startups: Fire Your Dev Teams. Yeah, that’s what I [...]
Kjetil Valstadsve responded on 17 Feb 2008 at 2:37 pm #
Hi Mike. You sure like polemics, don’t you? What you are saying is straightforward enough: It takes different kinds of programmers for different phases of a company’s life. I recognize the difference you point out, between “startup” and “enterprise” programming. However, I think you will rarely have a clean-cut situation where the whole dev team is exclusively startup-mode. In fact, if a programmer is good enough, he or she is able to run both modes quite easily. It would be really unfair to be fired just because you’ve been in the startup mode for a while. Also, it would be very wasteful, since your knowledge about the business is useful. But I guess you were polemical.
Some background: I myself have worked at a startup for a long time, and I recently got my old-timer ass moved onto the new, next-generation, full-rewrite project you are talking about. Management was certainly in “enterprise” mode – this was going to be a REAL project, mind you. Everyone was going to be writing design documents – in Word! – and no code, positively NO code, was to be keyed into anything, unless the Design Document had been approved. By a board of architects. When I was lobbying for the switch, I was informed that rogue coding was almost grounds for termination. Being an old hand, I had people working for my cause, and I got moved onto the project. (Thank you all.)
One would think this was the project you prescribe. Most of the staff were new hires. The Chief Architect was an old hand. But it wasn’t that project. Code duplication was way over twice (!) that of the “legacy” code base I had left – I ran Simian. I noticed quickly that no “utils” or “common” module was defined by the Architects, so the natural cultivation of reusable libraries had been stopped in its tracks. Test coverage was low because of a low POJO factor. SOP for creating a new module was to copy the code of similar module, then tweak it. So basically, I quit Word and rolled up some sleeves.
It took a year or two (and not so many Word documents after all), and we beat the thing into shape. It is now a distributed, dynamic module system with dependency injection. I think the moral is that programmers of all kinds, if they’re good enough, do not distinguish between the “modes” so much – they want to make something, and they recognize that the “enterprise” mode is valuable for what it’s worth – and it does have worth in the “enterprise” phase. You just need someone to champion that perspective, and a base of good programmer talent.
I am not a champion, so this particular project got on because of all the great programmers on the team. If you are reading this and recognize the project, you know I’m not complaining about anyone. It was a very educational experience. I will also point out that the original design was OK, it just didn’t actually manifest so much in the code. Or, you could say, it manifested in way too many places in the code, in the varying shapes and forms you get with reuse by code duplication.
Mike, you make a good read, and you certainly have a point. But if you really have to fire your dev team, take a long hard look at the hiring practices and middle management, because your problem is NOT just with the grunts. And if you really have to rewrite the whole thing, you are taking on a huge, HUGE cost. The last nail in your theory’s coffin? I wasn’t fired, I’m quitting!
Ronny responded on 17 Feb 2008 at 7:08 pm #
Hahaha! Although you have an occasional good point, firing the entire dev team and rewriting all the sortware are the two worst ideas you could possibly think of!
You should never hire anything but great hackers for your development team, ever! And if you mistakenly did, then fire them immediately! The black and white scenario that you propose that “all startup developers are useless at enterprise development” is as stupid as saying “all blacks are…..”, “all whites are”, or “all foreigners are….”. If you give this advice to a public company, please let me know the stock ticker so I can short it! (Thanks, Joel, for the idea: http://www.joelonsoftware.com/articles/fog0000000245.html)
Unfortunately reality is not that simple! One thing is pretty simple though: Hire only good ones, fire all bad ones. The problem is that most management are utterly incapable of seeing the difference between them. *That* is what the focus should be on! And if you’re thinking recruiters are better at it, forget it! They’re worse! You think you can see it from their CV? Hahaha, you’re funny!
By the way, what on earth is an “enterprise developer” anyway? If you refer to the ones certified by a big corporation, I’d also like the stock ticker please! You can make loads from shorting I’ve heard
Ronny responded on 17 Feb 2008 at 7:20 pm #
Forgot to comment on rewriting the whole app. Ask the Netscape team if that is a good idea!
However if you hired a bunch of monkeys in the first place and/or it stretched it too far before you allowed them to do bugfixes (features galore, no time to fix bugs or architectural flaws), so the code is in such a bloody mess that it’s beyond repair, it might be the only alternative. But in that case, I’m surprised that the company is doing good in the first place because as mentioned in earlier replies, management much be incompetent!
In any case, if you hired at least one real hacker, and [IMPORTANT] let them know your general business goal, at least the architecture should be half decent.
Michael Candelon responded on 27 Feb 2008 at 3:18 pm #
I don’t believe its helpful the group of people that got you to where you are now but all of that aside, the more I read articles geared toward me and my startup, the more I think that an attribute of a successful startup comes from making good use of the available resources specifically geared toward startups. One company, Sun Microsystems has a startup essentials program that gives startups discounts on x64 servers, free tech support and access to a 2.0 community. Not everyone has millions and that company knows it and its that outreach that I think we could use more of. http://www.sun.com/startup
Original developers and non-workaholics beware — The Puerto Rican Rails Dude responded on 08 Mar 2008 at 10:52 am #
[...] first one comes from Mike Mason, a software consultant, who advises start-ups to fire their original development team when the company has a successful launch. Of course, now that I’m part of a dev team [...]
Mike Mason » Fire your dev teams (reprise) responded on 09 Mar 2008 at 10:49 am #
[...] of course I don’t really think you can fire your entire development team and throw away your existing successful code base. Just because a blog post is spell checked and [...]
Stephan Schmidt responded on 20 Apr 2008 at 12:39 am #
Excellent post, exactly my experiences.
What commenters miss here, it’s not about hiring smart developers. Because it’s not about skills but mind sets. Startup vs. Enterprise mind sets. I’ve seen both and they differ a lot.
Peace
-stephan
mike responded on 17 Feb 2009 at 11:23 pm #
We fired a guy, he got a job at Intel the next week. Should we higher him back now?
jason responded on 20 Feb 2009 at 9:35 am #
I badly _want_ to disagree, but experience says you are mostly correct. I’ve worked on a few new enterprise products that have been amazingly successful but struggled a little after success. I wouldn’t fire the _entire_ initial dev team, but I would include the dev. manager(s), if they are also not well-rounded enough to handle the road from start-up to enterprise.
Not all, but a good number, (50-75%?), of the development and management folks that brought a product to its first release are complete software development flatfoots. They were fast because they knew _one_ way to do things and did it well. They were flatfoots because after 5 years they still only knew one way to build something, wrote horrible code with high prod support and maintenance costs, and they could not figure out how to work with a structured development process.
I am glad you mentioned this, because I had not yet realized why some of these developers or managers were ever useful. I actually appreciate them a little more, now that I see where they would excel. Maybe they weren’t morons, just better aimed for startup work. Great post, Mike!
Rachel responded on 30 May 2010 at 3:34 pm #
“The minute you’re successful, plan to rewrite your software from scratch” – I have one word in response to this misguided notion: Netscape. Old code is good code, because it’s been well-tested and debugged, and, most importantly, it’s been well received and taken up by the market place. Just ask the people at Netscape, who made a feature out of re-writing their entire code base, just when they got to a leading market position, then fell further and further behind the competition as their perpetually-delayed ‘new and improved’ browser failed to seize the moment in the way their original offering had done. Successful startups are about being new and innovative, they’re never, ever about re-inventing wheels.