Ingredients to Successful Teams – Planning February 8, 2008Posted by Darth Sidious in Uncategorized.
add a comment
Successful teams allocate quite a bit time to planning. They plot out in as much detail how they plan for something going down; they factor in what the potential risks are and how those risks will be mitigated.
They plan out all kinds of potential scenarios, whether they’ll happen or not, so that in case it does happen – they have the plan ready to go, all the thinking has already been done up front, everyone knows what to do… and it’s just execution at that point.
For example a Network team may plan out all possible risks – denial of service attacks, virus outbreaks, etc… and have all the plans ready if they do happen. They also make plans to prevent it from happening in the first place – but if it doesn’t happen, no one is panicking, they know what the game plan is.
We have our fleets of Storm Troopers practice our plans. Whether it’s an attack from the Jedi, or Ewoks whipping rocks at them… they’ve been ingrained with all the standard plans for all these things so when it does happen, all they do is execute (and we mean execute literally).
Listen. If you’re prepared to the best of your ability – whether you win or lose, doesn’t matter, because you’ve prepared to the best of your ability. The BEST of your ability, meaning there’s nothing more you could possibly have done, so the result (bad or good) is going to be what it’s going to be (of course, you should always be in a state of learning and improvement so that your best is always increasing).
Luck is being prepared for an opportunity…
Technical SPOKs – Eliminate their leverage July 31, 2007Posted by Darth Sidious in Uncategorized.
add a comment
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.