Stratagical

I invented a new word today: “Stratagical” – a synthesis of “Strategically tactical, practical and agile.” This sounds terribly pointy-haired boss-like, but whatever, I don’t care, because I’m excited that I’m able to hoist myself to a place where I am able to help make tactical decisions but keep a focus on the strategic goals of a project.  In many ways, in my previous software developer role, I could become consumed with the architecture of a solution and its enormous volume of details to the exclusion of practicality and making tactical choices when necessary.  One transformative step on the road to Stratagical decision making was the day I realized I needed to do a huge batch process completely in memory for speed.  This decision eventually paid off quite well.  I am learning that many tactical decisions can be strategically advantageous if done correctly.

I consider this type of decision making process to be a key to agile management of an agile software development and technical operations group, and it must be founded in practicality. The strategic part comes in by ensuring that the software and systems we are designing meet the long-term needs of the institution, that we not shut the door to future needs, that we ensure good data to start with. The practical part comes when you understand that a new system will not be immediately used by the entire population of the institution, and can be phased in over time. The agile part comes in by focusing on improving the baseline of the system at each customer integration opportunity.

Step 1: Design the system to be flexible in the future
Step 2: Get good enough data into the system to start with one or two customers
Step 3: Validate the data with those customers
Step 4: Fix discovered data issues
Step 5: Repeat steps 2-4 with a new customer or customers

If you do this right, things seem to start nearly magically falling into place, and you start knocking out large chunks of alignment and execution, like scoring 5 lines at a time in “Tetris.”