The Tactics of Making a Strategy

As a team leader or manager, people will look to you to describe the direction the team is heading in the future - the strategy.  Here is a surprising definition from www.dictionary.com that makes me wonder how similar managing a group of engineers is to leading a war.  Some days, I can definitely see the relation, but most of the time, I can't. 

In military usage, a distinction is made between strategy and tactics. Strategy is the utilization, during both peace and war, of all of a nation's forces, through large-scale, long-range planning and development, to ensure security or victory. Tactics deals with the use and deployment of troops in actual combat.

The similarity is that strategy in engineering teams is the "large-scale long-range planning" (or in my terms, broad-scoped, long-term plan) to ensure success of the team (or "victory").  When you are being tactical, you are thinking about the current day-to-day events or tasks.  That's what the engineers do - they are tactical.  The managers need to think strategically.  So how does one create a strategy?

Over the last few months, that has been my main task in my current role as a Test Manager at Microsoft.  I had to create a Test Strategy for my team to help them realize how to move in the right direction and to help the other leaders in my team join in to this movement with clarity and passion.  Here are the steps I took: 

1. Noticing the issues:  About 6 months ago I started recording the issues I saw within the team and with interactions outside of the team.  Since I've managed many different teams, I could make comparisons and see where improvements could be made.
2. Creating themes and sub-themes:  I took this list of issues and put them into categories or themes to help organize my thoughts.  I have themes like QA Excellence, Technical Competence, and Team Dynamics.  The sub-themes are limited to 3 focus areas inside each theme.  For QA Excellence, I use Engineering Practices, Standing Firm on Quality, and Defect Management.  All items that support better QA Excellence.  For Technical Competence, the focus areas are Automation Standards, Skill Development, and Metrics Reporting.  For Team Dynamics, there are Hiring/Staffing/Retaining, Roles & Responsibilities, and Cross-Group Communications as sub-themes.  And then I have a miscellaneous bucket for items like Lab Management, Performance Testing, etc.
3. Writing Descriptive Statements: For each focus area or sub-theme, I placed items from my initial list of issues.  My leads and I wordsmithed these so that they describe the goal and what I wanted the team to accomplish.  It is very difficult to avoid writing "how" statements, but a strategy should not describe how something gets done, but only what needs to get done.  The how is the implementation details that need to be figured out next.  For example, instead of saying "Increase business process knowledge through customer visits and understanding customer scenarios", you can leave off the how part of "through customer visits and understanding customer scenarios".  In this case, it was decided that even the statement "Increase business process knowledge" was too specific and that there is more that the team needs to improve in this space.  So the statement got changed to "Improve customer/partner relationships".  This opens up the door for much more thinking as to how to make this happen.
4. Timing: After having the strategy spelled out, it needs to turn into more of a roadmap and placed on a timeline.  There is no way my team could do everything in the strategy all at once.  And if a strategy is supposed to be long-term, then I wouldn't expect things to get done immediately.  But unlike a product strategy that can list features or capabilities on a roadmap with clear start and end dates, a team strategy roadmap needs to be thought of a bit differently.  I have 4 teams in my org and one may be further along in automation standards and another in defect management.  So when placing items on a timeline, the start/end dates won't be appropriate for everyone in the team.  So instead, I changed the definition of "completion" within the roadmap.  The timing of items getting started is somewhat irrelevant.  People are going to have to work backwards from the completion timeframe to estimate when to start and that could be different for each of my teams, especially since each item is getting done to varying degrees by different people in my team.  So I defined completion as the time when everyone in the team is following that strategy item and they consider it the natural way they do work.  When that is accomplished, that strategy item is completed.   I then placed the items in three time frames: 0-6 months, 6-12 months, and 12+ months.  This gives me a strategy for at least the next 2 years and of course, I can revisit it and change direction as needed.  In addition, I added a Current State section to give a baseline on what we currently do so the positive change by following the strategy can be more easily understood.
5. Get it review:  A strategy can change the way a team works.  It's important to review your strategy with the right people and to be open to change it.  When reviewing, I list out my asks or important points for others to take away from it.  Since much of the work QA does has dependencies on other disciplines in the project team, they have to understand what is required of them for QA to reach their goals.  And maybe your strategy will drive more strategic thinking in other parts of the group where it doesn't yet exist.

After it gets reviewed, the process is mostly done.  Parts of the strategy continue to get over-communicated to the team until I start hearing the team repeating them back to me in normal conversation (that's the start of "the natural way they do work" that I stated earlier).  And I revisit and refresh the strategy regularly.

I hope this helps you in creating a strategy of your own for your team.  Without one, how do your team members know what direction the team is headed?