In my first Star Trek post, I explored two lessons learned from Captain Kirk’s leadership skills and how we could apply them to business intelligence. Today, I’ll cover three more lessons.
Be Part of the Away Team
Captain Picard of Star Trek: The Next Generation rarely joined the away team, leaving that role to his Number One, Commander Riker. Kirk operated with far more freedom. Whenever there was an opportunity to beam down to a new planet, he was there. His leadership style demanded that he lead from the front.
I think the corollary with business intelligence work here is obvious: the success or failure of our systems depends far more on establishing correct requirements than on the actual implementation. By being part of the away team, we can be directly involved. Lack of user involvement and poor requirements gathering are generally two of the top reasons projects of any kind fail, and business intelligence is not immune to this problem.
Play Poker, not Chess
In Star Trek, there were numerous times when Captain Kirk and his crew were in a bad spot. In one episode, The Corbomite Maneuver, the Enterprise and her crew were experiencing first contact with a new alien race and it wasn’t going well. At one point, Spock had to tell Kirk that they were out of options and the alien had backed them into a corner from which there was no escape. In chess terms, checkmate. Spock, as a character, was the very embodiment of chess: cold, logical, and process driven. It was natural that he would see things this way. But Kirk was different.
Capt. Kirk: There must be SOMETHING to do. Something I’ve overlooked.
Mr. Spock: Chess: When one is outmatched the game is over. Checkmate.
Capt. Kirk: Is that your BEST recommendation?
Mr. Spock: I’m s… I regret that I can find no other logical alternative.
Capt. Kirk: Not chess, Mr. Spock. Poker!
Kirk took inspiration from the game of poker and bluffed his way out of the situation. How can this possibly apply to business intelligence? We don’t want to lie to our business partners, do we?
Perhaps we do – but in a good way.
I often come into contact with people or business processes that have been rigidly followed for many years. To the mind of the many, there’s no other way to do that particular process. In order to convince them otherwise, sometimes we have to bluff. I like to call this a demo. In order to make a difference, we have to get past that initial resistance; and sometimes a well-placed bluff demonstration helps us along that road.
Blow Up the Enterprise
Sometimes there’s no way around it. A system that’s well known, trusted, and loved just isn’t cutting it any more. The original Enterprise made it through several years of TV shows and a couple of movies before ultimately meeting her end. As much it pained Kirk to let her go, he realized that in order to move forward, the Enterprise had to be sacrificed. (I may have shed a tear or two myself.)
Legacy systems can often inspire the same attachment, but at some point we have to blow them up so we can move on. “It’s always been done that way” is a poor reason to keep a system around when there are so many new and exciting technologies that have come to market recently. Don’t be afraid to blow up the Enterprise to move forward.
But I think the overwhelming lesson to be learned from Star Trek is don’t wear a red shirt to work.
David Rathbun is a business intelligence architect for a Fortune 100 company, founder of the online community known as BOB, SAP Mentor, blogger, full-time father to two wonderful boys, husband to a wife of 25+ years, and in his spare time he likes to do photography. His last five minutes of spare time occurred approximately ten years ago. Any opinions expressed here are his own and do not reflect his employer. www.dagira.com. David’s LinkedIn Profile