Brinkmanship part 2

In part 1, I explained that brinkmanship is the craft of putting yourself (or your team) on-the-brink-of-disaster.  Some people seem to love to dabble in brinkmanship.

Here is my “top 10 list” of favorite (as-in: must avoid) examples of brinkmanship within the programming/IT world:

  1. Making backups but never testing them, until you desperately need to use one
  2. Not checking-in your source code, often enough (anything longer than “weekly”)
  3. Deploying hot-fixes (ie. Moving untested code from dev, to prod) more often than “almost never”
  4. Not preparing a test plan, so, when you deliver your code, you just have to count on the testers (or developers) to think of everything
  5. Not having a plan before you undertake any point of a project
  6. Delivering requirements after the programmers have begun programming (or for Agile: changing requirements during a sprint, instead of putting them in the next sprint)
  7. Acting like there is an emergency, more often than “almost never”
  8. Not monitoring production systems, not keeping logs or not monitoring your logs
  9. Constantly trying to reduce timelines and maximize efficiency of staff, or generally over-working your staff
  10. Not purchasing the software/tools/utilities/equipment/licenses that you require to run things/systems properly

There are a few more things which are not specifically part of brinkmanship, they are common ingredients that contribute to brinkmanship.  Without them, you probably would not be able to experience brinkmanship, in the first place:

  • Not planning ahead
  • Not learning from your mistakes
  • Placing blame instead of taking responsibility
  • Accumulating technical debt

Some of these don’t seem like a big deal, and honestly, they don’t have to be.  There are some companies who are very chilled-out and just go-with-the-flow. They are keeping it loose and free.  In that case, it is fine to expect everyone else to wing it too.  Under circumstances like that, I suppose you can’t have brinkmanship.  You are probably expecting stuff to break and be down occasionally.  When it happens, it is not a surprise, and nobody freaks-out over it.

However, if you are pushing an aggressive timeline, things are going to seem much more serious.  Mistakes, flaws and outages are going to interfere with your timeline.  It sometimes breeds more corner cutting and panicked choices.  Under those conditions, you better put a lot of effort into being organized and methodical.  In fact, if you aren’t doing much to organize your projects, or plan ahead, then you are engaging in brinkmanship.

I know some people live for the excitement that comes from brinkmanship.  The cowboy life is the life for them.  Unfortunately, not many people share the same appreciation for this kind of thrill.  In fact, it is common for non-thrill-seekers to seem irritated and maybe even counter-motivated, when they are told to clean up a mess right now, when they didn’t make or cause the mess, and maybe they even “told-you-so”.  This is not an un-natural response.  You will not be successful at brow-beating it out of those people (the non-cowboys).

Brinkmanship, it is not for everyone.  It is a dangerous way of life and there are more-sound ways of operating.  If you must hand out grenades to everyone, do not keep the pins for yourself.  “All-hands on-deck” will rapidly become un-achievable.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Horror Stories, Lessons Learned, Professionalism. Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s