Fog Creek Software
Discussion Board




Product or skill based organisation?

I have been studying the different ways to organise the software development. Is there any other way to do things besides these two? And why would you prefer one or another?

First way is to have resource pools. A company would have several teams which all have special skills. Like one team would be a database team, another is for documentation and third one knows everything about network protocols. Every project borrows its resources from these resource pools for a certain time period. Of course the different projects might need same resources during the same time, but then someone have to make priorisation decisions between projects.

On the other hand we have product based development organisations. Developers are bound to their own software and nothing else. There might be few experts on very special topics that are needed on every project a company is running. Every project has their own coders, testing team and documentation people. People work in different way in every project althought the products might share pieces of code.

I would prefer the first way of doing things. First, there is advantage of really knowing the skills of the people. With several isolated projects going on, you might end up recruiting new people with special skills, without knowing that there already exists such a resource, but in different project. Second, your people will learn to think better since they work with different products. Third, the good practises learned within one project will be transferred to other projects as well.

What are your opinions?

Otto W.
Thursday, November 08, 2001

So you create an expert (or team of experts) on passive FTP ;-), an expert on GUI layout, an expert on databases, an expert on error checking, etc...

What happens if a problem requires a "think outside the box" solution. Haven't you just assembled a bunch of people and assigned them a very narrow track to think down.  Aren't you training them to think "inside the box" all the time?

Won't these people get bored with always coding the same widgets all the time? Will they really get different experiences (or feel like they are getting different experiences) by working on different projects, if all they do is drop in, code the same ol' widget into it, and then move on to do the same widget in another project. What happens when your expert gets bored with 18 months of doing the same widget 2000 times, and leaves?

I can see why this would look attractive at the start, but I can see lots of pitfalls, most of them on the human side of the equation.

Robert Moir
Thursday, November 08, 2001

I've been toying with this idea for a while now.  I actually like the resource pool idea -- if only because I work in a project-organized company and annoyed by certain drawbacks in that model.  Where I work, each person in a group seems to have a certain specialty or field of expertise anyways, and if the project is rather light on needing their expertise, they go idle and have nothing to do.  Furthermore, most of the communication is within the project group and there is little cross-talk between the groups, resulting in a slow transfer of skills and techniques among engineers who work with the same set of technologies.

I'd say boredom is equally likely in either scenario ... working with one technology for one year is probably no better or worse than working on one product for one year.  The main downfall with the resource pool model as I see it is that although each one of the pieces may be great code, no one person has buy-in or responsibility to make the combined effort a usable product.  A potentially workable solution is to adopt a hybrid organization, a portion of the company being project-focussed, the rest being technology-focussed, and rotate people in and out so as to reduce boredom and improve cross-training.

Alyosha`
Thursday, November 08, 2001

If you only hire people who are smart and can get the job done then you don't need to pigeon-hole them. They're flexible and can think laterally and be creative without having to be a square peg in a square hole all the time.

John C
Thursday, November 08, 2001

I agree with Robert.  I am of the strong opinion that an employer has an obligation to their employees to keep them engaged.  To "stick" someone with only database programming or only UI programming is detrimental to their career and the company.  Lets face it, 90% (ok...made up percentage) of all employees are getting trained for their next job.  And I think this applies to all careers not just technology.  So if you keep training your employees, keep moving them around so they get their hands on everything, they stay longer because they are always learning and engaged (i.e. happy).  So if I interviewed somewhere and was told I was going to be in the middleware resource pool, I'd hit the street.

Just my $0.02

Justin Rudd
Friday, November 09, 2001

Here's a random thought from someone who doesn't have much real perspective, but I think it could be an interesting approach. What about the hybrid, like someone mentioned? You could have resource pools, of which everyone is a member and may be called on for components of other projects, and then you must have some organization.... i suspect the higher level (i.e. architechural/designing) people should be assigned permanantly to a project, so someone knows the project. That way, you have people moving around doing work they can do well for every project.



Also, what about allowing for volunteers? Given 20 geeks, I bet you can find a fair interest in a diverse set of topics. I mean, once you have enough basics hammered out, why can't someone who may not be an expert but have some knowledge volunteer to research it? Assuming you don't have someone who knows it, but then again, if you have someone who knows it, then much of the problem can probably be solved with a little code reuse, no?



Just my thoughts on an environment I'd like to work in: One that allows freedom to try new things, but at the same time leveraging each employees strengths. Of course, trying onew things should be one of those strengths.

Mike Swieton
Friday, November 09, 2001

Having a resource pool seems to make sense on the surface but...
I'm considered the Perl expert where I work.  I've done lots of Perl programming and pulled lots of rabbits out of my hat.  People come to me for help and I gladly give it.  I have at times though gotten very frustrated by people who don't take the time to work the problem on their own before coming to see me.  "I don't have time to learn this.  Paul can teach/do it for me."  This is coming from people who have been programming Perl for 1-3 years who really should have progressed beyond the basics.  At some point, a developer needs to teach themselves and grow.
I'm not saying that every developer needs to become an expert in all areas.  That's not possible anymore.  They just have to become proficient in those areas that are important to them and their company.

Paul

Paul Leclerc
Monday, November 12, 2001

So main reason against resource pools is the thought they would lock up people just doing the same thing over and over again.

I do not see it as a problem, since I don't see the resource pools as some bad thing that prevents people of doing meaningful things or locks them up doing same things over and over again.

Paul had a problem where everyone knows he can do some Perl. Other people are also capable of do things with Perl, but not as well as Paul. What if they had a group of Perl maniacs? Paul shares his knowledge with a small group of people who then are capable of doing the same things. And Paul can learn things from them. After a while there are several people who are ready for some serious coding.

You also have to understand that resource pools must not be obstacles if you want to learn new things. People can switch from pool to pool. Some people gain knowledge about a specific projects and may eventually become product architects. Also project managers may be taken from pools.

Robert wrote: "Aren't you training them to think "inside the box" all the time?". I think I do not train them to think "inside the box" since they will work with several different products (since usually the companies tend to have more than one product). If they are smart, they code something for one product, learn, and do the thing better for the new version or different product.

Alyosha` was worried about combined effort. That is the reason why we have product architects, project managers, product managers, etc. They give personnel a target where the projct is aiming.

I think I still prefer resource pools.

Otto W.
Wednesday, November 14, 2001

There is a tendency, and its been around since the year dot, for employers to specialise people.  They distrust people with multiple skills and wide experience they think they will be difficult to manage or to keep.

Well perhaps they are right in that belief, it probably is harder to keep interested someone that has a range of abilities in a lot of areas.  But the gains in having such people are immense.

The resource pools you're talking about migrated into external consultancies (you can imagine a big arrow over my head now if you wish), or contract labour.  Skills that can be hired and dropped as needed.

Companies then pay a premium (or did until recently) for that flexibility and they lose out on not having that resource to hand until someone entirely dissassociated with the process can make a decision about hiring.

It would take a very large organisation indeed to maintain internal resource pools.

Simon Lucy
Friday, November 16, 2001

<Robert wrote: "Aren't you training them to think "inside the box" all the time?". I think I do not train them to think "inside the box" since they will work with several different products (since usually the companies tend to have more than one product). If they are smart, they code something for one product, learn, and do the thing better for the new version or different product.>

While I agree, on reflection, with the comments about a hybrid of the two extremes that everyone is making. I want to come back to this comment by Otto.

Otto, you say with your idea your 'subject area expert' people are working with different products/projects, and are therefore learning, but after so many iterations of refining a library I am responsible for to fit new projects I am not learning new things by adding it to new projects.

There must come a time where someone is more or less just cutting and pasting the same old code from a libary of code snippets into different projects, and theres nothing else to do except link it up to the project, test, debug, and scoot. People will be learning less and less, and starting to get bored, as they get nearer to this point.

Robert Moir
Friday, November 16, 2001

I think Simon is on the right track by comparing Resource Pools to contractors.  Instead of the contractors being hired from an outside company, they are merely borrowed from an outside department.

You therefore have all of the related negatives associated with skill for hire.  There is no true sense of a team unified to accomplish a specific goal.  There is no ownership of
work and accountability of results.  Task switching, etc.

There are some great articles on this site that go over these ideas in more detail.

Scot Martin
Tuesday, November 27, 2001

*  Recent Topics

*  Fog Creek Home