jump to navigation

Technical SPOKs – Eliminate their leverage July 31, 2007

Posted by Darth Sidious in Uncategorized.

SPOKs – Single Points of Knowledge tend to occur naturally as a result of people specializing in certain aspects of a business.

This is particularly true in the areas of technology; the person who makes a certain feature of course is the automatic expert, so when enhancements to that feature are requested what’s the default choice? That person, because in this day and age with tight deadlines and the constant pressure to provide top line value to the customer, executing at maximum speed is always the emotionally desired choice.

Time goes on, and that feature or application gets more and more complex making the learning curve all the more steeper which makes it even more difficult to have others work on it due to the delay that will be incurred by the need to learn how it works.

If the application has grown to a large size it’s probably due to its importance to the business; and when that happens the application becomes a mission critical piece. It’s at this point that you’re now in trouble.

The person who created this has huge leverage over you and your business is now pegged on this one individual. Unless this person has a positive collaborative Sith attitude, over time what will happen is they’ll subconsciously start noticing that they can get away with things and management will tolerate it because they have no leverage against the individual.

So, ideally you want to prevent that from happening in the first place. On any project, you either pair engineers together, maybe not in parallel, but they cycle through each feature phase by phase.

But if you’re reading this, it’s probably because you’re already in trouble.

With technology the solution is simple, but often difficult to execute because the creator of the application will feel emotionally bound to the technology, and won’t want others to “mess” it up. It will be ownership, possessiveness, and control that will be the primary motivators behind that.

Your next move is to introduce other engineers/software developers into the mix; but don’t take away ownership from the creator, otherwise you’ll have a premature rebellion that could threaten the business.

So what you do is have the creator still be the primary person responsible and the ultimate owner, and they can review all changes to make sure it complies with whatever standards there are, or architect enhancements before handing them over to someone who’ll implement it. Or introduce the concept of maintenance programmers who don’t work on anything major, and the creator still gets to feel in control.

Lastly, it has to be documented fully. You can do this under the guise of VOX (Vader Oxley) compliance if you need to. But the mission of the secondary/maintenance engineers is to document the software itself (in-code documentation), and have the functionality documented as well

The goal here isn’t to necessarily remove control, but to eliminate the leverage of the SPOK. The SPOK very well could be a nice guy, but that doesn’t negate the fact that your business’s existence depends on a single individual. What if they quit or go on vacation? The risk is still enormous.

Convert the SPOK into a POK, and you can function on a level playing field again.
Darth Sidious



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: