Fog Creek Software
Discussion Board




Integration and The Spectacular Failure

Here's an edit of something that Brad Wilson wrote in response to a previous post:

==========

A small company acquired a bunch of funding, and thus, a bunch of engineers in a very short amount of time.  It ended up with 4 or 5 of really high quality engineers, and 35 or so people who didn't have the requisite skill level to do the work.

Aside from being just plainly not skilled enough to do the job, those 35 people stopped the 4 or 5 skilled people from being productive, because of the required process that had to be put in place to stop the 35 from destroying the product.  What little that did get done was of such terrible quality that it was virtually impossible to get running.

==========

Okay, everyone, pretend that you were one of the 35 people.  How could you successfully integrate yourself with the 4 or 5 skilled people?  How have you seen unskilled people successfully integrate themselves into a small, highly skilled group?


Brad, could you tell us what "required process" was put in place in this instance?  I think that that would be an enlightening perspective.

Brent P. Newhall
Wednesday, May 28, 2003

Some people would suggest the sort of elitist route. Don't let the 35 into the equation no matter how much money you make. Keep hiring clusters of 5s. Let them go after their own business. Share what you can between the clusters. Help each other a bit. But never have enough infrastructure to need management or sales. You have to be a self-starter, but this is one of the alternatives Philip Greenspun wrote about back when he had ArsDigita to run.

Li-fan Chen
Wednesday, May 28, 2003

how fuct up do you have to be to hire 30 or so people that don't fit in with your company?

Sounds like the board needs to step in or the owner needs to have a long hard chat with himself.

Tell the employees that it's time to sink or swim.  Give them measurable objectives to meet. 

victim, jr.
Wednesday, May 28, 2003

I've been one of the 35 and it would have been better
if they hadn't hired me.

valraven
Wednesday, May 28, 2003

If the job requires a certain minimum level of engineering expertise, the company was wasting everyone's time by hiring unqualified people.

But given that there was no choice but to hire "warm bodies", one can assume in any group there will be about 20% who are fast learners and who can step up to skill levels that might be minimally acceptable in a rather short time. That is, to do non-engineering functions (because not everything we do requires an engineering degree) but still go over and above the low level work they currently are qualified for.

So after a few months you have allowed another 14 to develop and you've added to the 4 or 5 "good" workers who can do real productive work. Now it becomes possible to parcel out some of the dog work to the unqualified people and make the productive ones more so. But you are still saddled with a large number maybe 40-50% of useless appendages and it calls for a round of layoffs and rehiring with new and clearer job requirements.

All that being said though, the 4 or 5 "good" definition also smacks of a bit of elitism. Who was it that decided on the mix of skills to hire in the first place and who is it that decided that only 4 or 5 were actually "good" ones? The company would have to be incredibly inept at absolutely everything it does from planning to hiring to managing people in order to end up with 80% dregs and 20% good.

old_timer
Wednesday, May 28, 2003

The required process was a home-grown documentation heavy process that was designed to attempt to help ensure the components were designed well. It more or less failed, of course, because the design was never really translated into reasonable implementation because the skill level wasn't there in the majority of the workers.

This, of course, ties all the top senior people up into not much more than supervisory roles.

~~~

"Some people would suggest the sort of elitist route. Don't let the 35 into the equation no matter how much money you make."

Indeed, that's exactly what I intend to do with hiring now.

~~~

"how fuct up do you have to be to hire 30 or so people that don't fit in with your company?"

That's what happens when you take "big money" VCs into the organization (at least, before the bubble). Nobody wanted to invest small money for small gains, they all wanted the grand slam. It was much easier to raise $50m than $500k.

The problem is, that to get $50m, you end up having to sell your soul. You make ridiculous promises that everybody knows you can't meet, and then have to staff as though you had a prayer of doing it. Since you clearly can't grow an engineering organization intelligently by 5 or 6x in 6 months, you end up hiring people that you shouldn't. For what it's worth, a lot of us were overruled when we said "no hire".

~~~

"All that being said though, the 4 or 5 "good" definition also smacks of a bit of elitism. Who was it that decided on the mix of skills to hire in the first place and who is it that decided that only 4 or 5 were actually "good" ones?"

The skills we asked for were irrelevant, because almost nobody we interviewed had them (we needed experts in C++, with heavy emphasis on COM & ATL). Despite "no hire", they were hired anyway. We tried to train them (no real training budget, so we did it in house), but mostly failed.

There is two questions of good, here: (1) were the people good software engineers in general, and (2) were they good enough to do the obviously difficult work that we had to do. My judgment of "good" is a personal judgment, based on my experiences and the performance I saw.

You can call that elitist if you want; I'm not bothered with the labels people choose to use. I'd much rather be a highly successful elitist than a miserable failure inclusionist. *shrug*

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, May 28, 2003

ouch.  hope the managers got fired.  sounds like there's more than one level of incompetence here.

victim, jr.
Wednesday, May 28, 2003

Excellent discussion so far, though so far, nobody's answered my question:  What would you do if you were one of the 35?

Brent P. Newhall
Wednesday, May 28, 2003

jeez.  I work for a mildly successful .COM, and we got a little crazy when the money came in too.  Joel's 100% right about growing a company:  http://www.joelonsoftware.com/articles/fog0000000056.html

Now you have to worry about alienating the people that ARE good.  Hope it all works out, remember you are going to have a powerful and maybe devastating effect on REAL LIVE people. 

victim, jr.
Wednesday, May 28, 2003

I've always been in the top 20%, so I can't say for sure.  I guess it depends on the company.  If I suddenly found myself working with a bunch of ex Microsoft Research people, I'd probably volunteer to be moved to a testing or documentation or sysadmin role.

victim, jr.
Wednesday, May 28, 2003

The problem you describe is fairly common, although not to such disastrous extent. The key is to find a way to get you good people in the best possible way.

Has anyone tried what my friend calls "Editor" relationship where the 5 skilled people would spend a lot of their time reviewing the code written by the other 30 to make improvement suggestions and prevent serious errors from getting in? This is somewhat similar to the way linux is developed where Linus has the final say over what gets into the release. Of course this means that the skilled develpers get little direct engineering work done. Instead, you leverage them across larger group and improve the not-so-good people to the point where they can be independently productive. On the other hand, if each skilled person is responsible for reviewing work of 2-3 less skilled developers then they can contribute more directly and not get disgruntled.

Do you think such approach would work?

igor
Wednesday, May 28, 2003

The second sentence should read:

The key is to find a way to USE your good people in the best possible way

igor
Wednesday, May 28, 2003

that's probably a good idea.  there must be SOME endearing qualities to these people, somehow they could contribute.  that's the management challenge.  based on past performance though, it doesn't look good.

victim, jr.
Wednesday, May 28, 2003

If I was one of the 35, I probably wouldn't be aware of that fact.  So the question is moot.

x
Wednesday, May 28, 2003

> the 5 skilled people would spend a lot of their time reviewing the code written by the other 30 ..

Why should you make the good engineers waste their time on this drivel?

echidna
Wednesday, May 28, 2003

The Adm. Rickover <sp?> solution...  He sugested that two-thirds of the general staff of the Pentagon send memos to each other and allow the one third that was willing and able to work to get something done. 

Seriously the 30 - 35 warm bodies should not have been hired they would have been better off hiring 10 experts from other companies with the same money.  Or slowly growing the company over a several year period,  hiring only people with something of the correct skill set.

A Software Build Guy
Wednesday, May 28, 2003

if I was one of the 35 I would spend my day cruising the internet boards and commenting on how everyone in this industry doesn't know what there doing.

J.
Thursday, May 29, 2003

Well, how else do people integrate themselves into a group where they're less skilled?  That sounds similar to the definition of "learning."

You have two strategies.  If it's a sinking ship, you spend your time learning resume fodder.  If it's unclear, learn things oriented to the job, until it's clear the ship will sink.  Make sure to notice little clues about the boat's floatation.

anonymous
Thursday, May 29, 2003

Regarding the idea that the skilled 5 should mentor and review the unskilled 35... I don't think this would work.

First, there's no guarantee the skilled five would be excellent mentors. Training and development are two skills that don't necessarily overlap.

Second, that's a lot of people to mentor. They would spend all their time supervising instead of coding. Quickly, this group is likely to get fed up which is not a good idea, as suggested earlier.

Finally, you'll end up with a group of 40 people working at an fairly slow pace. You should use the 5 people at what their good at, because you're not getting your money's worth otherwise.

The problem is hiring 35 people and thinking you can get away with it in the first place. If you want hire cheap programmers and bring them up to speed, you have to do it slowly. You just can't multiply the team N-fold and expect it to work.

I'm sure a lot of people have seen in this kind of thing play out in the boom years we've been through, and we're still fixing the coding legacies that were the result.

Joel Goodwin
Thursday, May 29, 2003

*  Recent Topics

*  Fog Creek Home