Another Strategy/Tactics Post

As I look over the last 6 years as a consultant, one thing becomes very clear, technical solutions by themselves will only get you so far. As a great leader once said “Good tactics can save even the worst strategy. Bad tactics will destroy even the best strategy” (George S. Patton) this is very true for software development, but with a slight twist.  As long as you continue an effective tactical operation, the problems with the strategy may remain hidden.

From 2001-2005 I developed a mission critical system for a very large company, over the course of these years, I did what it took (including searching out Internet café’s in Key West) to keep this system operating as efficiently as possible. As an outside technical development asset, my primary mission was make sure I kept the business constituents happy, the scope of the change I could affect on the organization was limited, for long term, this change would be required to embrace and support system. As I left this engagement in early 2006, it was clear that this system was not going to be properly supported. In March of 2007 for better or worse, Software Logistics was re-engaged on this effort and will make a significant positive impact.

So how does this come back to my original quote from GSP? In this effort I worked on the “Product” and very little on the “Process”. The product succeeded at the tactical level with assistance of Internet cafés in Key West, however at the strategic level the proper systems and protocols where not being put in place.  It was clear the technical/tactical part of the solution was sound however the strategic part needed some help.   What was required for long term success on this project was a complementary skill set. Enter my business partner David E. McCracken, I’m extremely excited to work with Dave on this project going forward. There is a considerable amount of power and flexibility within the system that was developed however this power and flexibility came at a cost of an investment in understanding two domains, the first being a non-trivial understanding of the subject matter data and the second being an understanding of the architecture.  The adoption beyond the immediate team required considerable effort that in some way is mutually exclusive to the day-to-day activities.    This effort is not in creating the code, stored procedures or even the documentation around these software artifacts.  This effort is in making sure that our tactical efforts that we perform as software engineers today not only satisfy the immediate and pressing needs of the business, but also are done is such a way that they can be repeated on a consistent and predictable fashion in to support strategic goals.  In the short term tactics can make up for poor strategics, however in the long run this is not a sustainable model.  Some great gems of knowledge can be found on David's blog on some ideas on how these efforts can take place.

Bottom line is how much are you working to satisfy your business constituent's tactical and immediate needs and how many fail-safes do you have in place to ensure the long term strategic organizational goals?  Do you have the right infrastructure in place for both these equally important journeys?

-ec