SmoothSpan Blog

I love that line from Paul Graham’s post about what went wrong with Yahoo:

In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

That observation is so true, as is this one:

Theirs was not to reason why; theirs was to build what product managers spec’d.

That’s in reference to Yahoo’s totally Product Managment-driven decision process.  It has seemed to me at times like Microsoft errs dangerously on this side too.  Product Managers are essential, and can be great, but if you place in a role where their job is to hand down stone tablets for the developers to slavishly implement, it doesn’t work.  It is not empowering to the developers who have tons of great ideas, insights, and vision themselves.  But ultimately, it’s just not a good idea to have guys in Ivory Towers thinking great thoughts they have no responsibility or accountability to deliver on.  It’s certainly not much of a team effort when things work that way.  I see great Product Managers as being the ultimate Customer Advocates.  Who else can say that they spend 100% of their time understanding the company’s customers and translating that into product requirements?  The trick is to balance those requirements against other sources of requirements, for example the need to innovate and differentiate, which far more often comes with vision rather than customer feedback.  It takes both as even the brilliant Steve Jobs discovers when his visions get too much at odds with what customers want.

The final great point from the post for me was:

In the software business, you can’t afford not to have a hacker-centric culture.  So which companies need to have a hacker-centric culture? Which companies are “in the software business” in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

Hacker culture often seems kind of irresponsible. That’s why people proposing to destroy it use phrases like “adult supervision.” That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.

Yes indeed, there are worse things than seeming irresponsible.  Though I think the appearance of irresponsibility is only an appearance and comes from suits not being able to understand the hackers.

So let’s say you’re running a company that has Bad Programmers.  Are you really doomed? 

It’s an interesting problem to think about fixing it.  How did you get there to start with?  Here are some thoughts:

–  Like Yahoo, you had a culture that didn’t value Technology.  Great programmers can smell that a mile away and will general avoid it.  I have seen cases where most of a company didn’t value the developers much, but there was an elite core group where great developers could flourish.  It’s often hard for overly sales-driven cultures to value developers as much as they should.  As one friend put it, sales-driven cultures see the Customer as God and Sales as the Church.  There were certainly elements of this at work for Yahoo.

–  You outsourced or isolated your Developers.  This is not a guarantee you have Bad Programmers, but it is a virtual guarantee they’re not really plugged into your corporate culture the way they should be.  Developers can smell this too.  Sometimes they like being off by themselves, but its too easy for it to turn into a Stone Tablet scenario at which point they’re unhappy.  The opposite extreme is the Dev Group that has no customer contact and is just implementing whatever they feel like.  Also bad!

–  The fish rotted from the head.  Bad Leadership is a problem for Developers.  They have little patience for a lot of politics or a weak leader that’s easily snowed.  Dilbert is not a recipe for a great Hacker Culture.

–  Lazy hiring.  You started out with some great developers, but you did a poor job hiring and building an organization.

–  Lousy process.  Smart people abound, but the processes in use are not productive, or worse are destructive.  This is usually a function of poor change control.  If left to fester, you can get spaghetti code from the brightest of teams.

So back to the question of fixing it, and while we’re at it, let’s also look at avoiding it in the first place.  Consider these proactive steps:

–  Make sure your corporate culture values what Developers do.  They don’t call them Software Companies for nothing.  They’re not Sales Companies, Marketing Companies, or Finance Companies.  Make sure you act like it, while also recognizing the huge value these other groups bring. 

–  Keep the Developers well plugged into your corporate culture.  If they’re remote, work overtime looking for ways to make sure they’re still plugged in.  Rotate them through corporate.  Send the right people out to the remote locations frequently.  Never let it turn into a case of micromanagement from afar (Stone Tablets) or no management at all.  Make sure there is strong leadership in the remote locations and make sure the leaders there most of all are plugged back into corporate.  Let me tell you, this will be a lot of work.  You outsourced and offshored to save money.  Welcome to the first of many hidden costs that will make it seem less attractive, though not fatally so.

–  Get great Engineering Leadership.  You need leaders who are inspired, visionary, extroverted, technical, and downright fun to hang around.  They need to be great not just with the developers, but with their peers in the other functional areas.  The leadership, more than anything, has to move the cultural values both ways across the blood brain barrier that often separates Developers from the rest of the culture.  They’d better speak both languages (Geek and Business) to do that well.

–  Realize that Hiring is critical from day one, and it never stops.  I could write many posts on hiring, but I will leave it to one simple observation.   99% of the time people seem to regard hiring as a temporary distraction from what’s really important, such as delivering a product.  But hiring the wrong people will cause you to deal with more kinds of Hell for longer than any architectural mistake you can possibly make.

–  Keep tuning the process.   Start out with the obvious Best Practices, but don’t rest on your laurels from there.  Development organizations have two responsibilities: delivering Great Products and building a superior Software Factory.  They spend most of their time focused on the Products, but like Hiring, the Software Factory is not to be overlooked.  Any given product release is just a battle in the war.  If your Software Factory releases faster than the competition, if it builds better product every cycle, and if it does this more cheaply than the competition, it’s a huge advantage.

One last piece of advice.  If you already have a lot of Bad Programmers runnning around, find a way to isolate them.  Don’t just beg Good Programmers to come in and drop them piecemeal into a pit of Bad Programmers.  They won’t be effective and they won’t hang around.  Start out making sure you have great leadership, and build new groups with Good Programmers.  Preferably do this product by product, and through acquisition of Teams that are known good entities who know how to work together to accomplish great thinks.  Don’t hire Good Programmers and term them into Bad Programmers inadvertently, or drive them away altogether.