OT: Don't be indispensable

[David W. Fenton]

In the US, the shenanigans around the AIG bailout are very much in
the forefront of many people's minds. If you want a slap-in-the-face
overview of what that's about, I highly recommend this extremely
entertaining article:

http://www.rollingstone.com/politics/story/26793903/the_big_takeover/

I'm posting here in the newsgroup because I can't help but conclude
that any business owner viewing this whole situation, where we see
employment contracts written in such a way as to guarantee
compensation (heads I win, tails you lose) as with the AIG retention
bonus contracts, would conclude that they really need to FIRE every
INDISPENSABLE employee.

Now, why is that relevant to Access programmers?

Because many of us, whether freelancers, or employed within larger
organizations, have basically gotten ourselves into situations where
we are indispensible.

My clients would have a *very* difficult time replacing me.

And that realization scares me -- in this economic environment,
engaging in a trust relationship with an "indespensible" contractor
means you have no idea how much exposure to risk you've exposed your
company to. My clients are small businesses and that makes this
exposure substantially more significant -- do they have to trust me
or am I interchangeable with other Access developers?

If a client is asking that question (and in the present environment,
I think any intelligent business owner *should* be asking), I think
that we need to work to make sure the answer to the question is one
that works in favor of the ourselves *and* the client. I think we
need to make ourselves *less* crucial to our clients' business needs
as individuals. We need to work to make sure that we understand that
they need to be able to operate without us, that the solutions we
provide are industry-standard, and not specifically tweaked in a way
that works only with their particular environment (and with the
special knowledge of their particular developer).

Now, in general, I try to work that way already. I think it's a
valuable service that I offer if I'm not indispensible -- they can
hand off my projects to someone else if I get hit by a bus. And in
proposing a project, I've always sold Access applications as
something that there are a lot of people who can pick up if I'm out
of the picture.

But am I conveying that to my long-term clients? Do they know that
I've engineered their projects to be as transparent as possible to a
new developer? Do they know that I'm thinking about their best
interests when I make my recommendations on how to move forward with
their project?

I'm not sure.

But I'm definitely thinking about it a lot more these last few
weeks.

If I were a business owner, I think I'd fire everyone who was
indispensible.

And I think that would be a very good business move.

 

[tina]

i'd say that having person-dependent processes is very common in businesses
of all sizes. too many daily tasks - many of which are taken for granted -
are handled by a single person who "knows how to do it"; and there is no
documented work instruction, and no trained back-up personnel to step in
when that person is gone for a day, or forever. this is a recipe for
disasters both small and large.

management often overlooks many of these processes because they aren't
perceived as mission-critical; but the work that falls through the cracks,
or is mishandled, means wasted time and resources, and therefore money, in
recovery - and so impacts profitability and the company's competitive
position.

i've always built Access applications as a "side line" to whatever job i was
primarily hired for - i've never been employed as a developer per se - and i
think that's the situation of many folks who post here asking for help. but
once we take on the task of building an application for our employers, it's
still our job to look at as much of the big picture as is reasonable (and
usually that's more than management thinks is necessary); to make the
database expandable, and maintainable by a user rather than a developer; to
build it for "the process" rather than for the person(s) currently handling
the process; and to write a work instruction that documents the process
rather than just directions on how to use the application itself to perform
isolated tasks.

tina