Fog Creek Software
Discussion Board

Best way to avoid key staff members?

I have now finished a project, and it has been
in production for a while. Would be happiness.

The thing is, I accepted 3 months employment
to finish my project, which I started as a
consultant. We were in agreement that I would
finish the design/programming part, and that
I would not maintain the system once done.

I repeatedly pointed out the need for new
staff members to come into the project to
learn the system so they would be able to
do the day to day stuff later, so that I would
not be the one sitting with all the knowledge.

This did not happen, so now I am in the
position of being the only one capable of
maintaining the system. This situation is
good only when negotiating salary. Bad for
all others.

Things that crossed my mind:

1) File for 18 weeks vaccation
2) Call in sick, and tell them "I told you so"

These 2 are ofcourse, professional suicide,
and not an option. The only thing I can come
up with is simply to refuse doing solo-projects.

What is your thoughts and experiences avoiding
this situation?

Friday, March 01, 2002

I think the best programming project I ever worked on involved about six people, writing library code.  The code was comprised of C subroutines.  Every subroutine (except for one exception, which proved the rule) was small, easy to digest, fully specified.  Therefore each routine was written by a single person.

However, from the beginning, every routine was also required to be checked by another member of the team.  Each person ended up writing N routines and checking N others.  Nobody was your sole checker; it was all spread around.  The result was that no one was the sole expert on any one bit of code.

Be careful.  It was not the checker's job to deconstruct and rewrite the original code.  In other words, control freaks were frowned upon.  There were a couple of occasions where a bad programming habit almost worked its way into the code.  Luckily, one of us was an absolute C guru, and I'd say two of us (including myself) were experienced enough at design to recognize bad decisions.

Moreover, we were all pretty friendly.  We had lunch together frequently, shared many common interests, etc.  I found out later that that makes a BIG difference.  Whenever there was a disagreement, we all knew it was legit, and not some sort of power play.

So in summary: every piece of code has both an author and a checker.  Have enough experience in the team to offset any tyros.  And have a real team, with members that enjoy one another's company.

Paul Brinkley
Friday, March 01, 2002

This rings a bell with me.  It's a prime reason I'm quit programming after 10 years:  The systems you build often have a long life and if you are the "expert" you may be married to it for a long, long time.  Even bad systems rarely go away.

Friday, March 01, 2002

I do not understand the 3 months employment you write about.  From the way you wrote it you are a fulltime employee but you write about a limited employment period.  If you are a short term employee then you are in your rights to leave and take employment elsewhere.  That you want to not be tied to this project during its entire lifetime is not suicide.

This is part of the reason I enjoy the consultant role.  I come in and design, implement and document a project for a client.  At the end I train and then usually have a single upgrade for the project for those bugs that creeped in and were not found.

I do understand that there will be pressure for you to stay and handle the day to day operations but as long as you raised flags during the process you should have a clean conscience.

Chris Woodruff
Friday, March 01, 2002

Support your development, that is your professional obligation.  If you dont want to be "stuck" doing the support for your development, then get onto another developmnent. Management will soon get someone else to take over what you have done.

There will always be times when you are the "only" person who fully understands a development. Thats the way of the world.  Try to make sure that you have a junior work with you next time, and that you never work entirely alone on a project.

Put it to management that "key person" reliance is not a good thing, and why, then over time they may "manage" things differently.

James Ladd
Sunday, March 03, 2002

If you told management they needed to have more people come learn the system, and they didn't take that advice, that's cool. You've fulfilled your professional requirement of being above board.

Now the company needs to learn the lesson, so they'll listen next time. Look for another job and then present them with: losing you or paying you a ton more.

Don't feel bad about it, the company has broken a promise to you that they made explicitly... you get to break at least one implicit promise that you didn't make; that you're THEIRS in some way, and that they don't have to behave sensibly.

Yeah, it's mean. They'll be mean to you just as soon as they can. Think of it as pro-active revenge.

Katie Lucas
Monday, March 04, 2002

You are in the IDEAL situation, not the doghouse.  ,  Now, they cant fire you.  Even a complaing loser like yourself.  Be happpy your not laid off, idiot.  Stop your whining

koo koo
Tuesday, March 05, 2002

koo koo,

Thanks for your very insightful comments. Really adds to
the value of this discussion.


Tuesday, March 05, 2002

As often as not, these things backfire. Someone comes along and says "What? That's not difficult, he obviously doesn't know what he's doing" and suddenly Management looks at you in a different light.

The truth is one of 3 things.

1. This guy is an idiot looking for a job.
2. This guy doesn't have a solid grasp of the scope
3. This guy is Linud Torvold and compared to him you *are* an idiot

So you get fired, this guy gets hired, and the first thing he does is blame you "It's because of the way my predecessor coded it that it's so screwed up, otherwise I'd do it for you right away."

Eventually someone comes along and exposes him for the idiot that he is, just like he did with you, and he gets fired and the chain continues. Being "the only one who knows" is not job security.

Mark W
Tuesday, March 05, 2002

I wonder what your version of "finished" and "maintain" is.

you say..
"The thing is, I accepted 3 months employment
to finish my project, which I started as a
consultant. We were in agreement that I would
finish the design/programming part, and that
I would not maintain the system once done."

Often I have heard programmers/designers, whatever you want ot call them say this, what they really mean is,
" I've done the easy stuff, and now that the going's gunna get tough I want out."

Dig deep, if you're any good, when you leave the customer will be happy.
Otherwise, you have failed, and are merely taking the easy way out.

Friday, March 22, 2002

*  Recent Topics

*  Fog Creek Home