CREATING A STRATEGIC PLAN
summary
Development teams all want to know what the overall plan or strategy is behind all the day-to-day work they do. Technical leaders need to define a Strategic Technical Plan that is complimentary with any corporate vision, goals and strategies and should make sure that the technical side of the company has a clear set of core values that sit behind all the actions and decisions of the team. When teams buy into the plan and its elements, they are more likely to deliver on the Product Roadmap and build products that are pleasing and useful to customers.
ISSUE
One of the most important duties a technical leader has is motivating their team to do their best. While much of this is accomplished in day-to-day tasks like stand-up meetings and one-on-ones, there needs to be something behind the day-to-day that provides a framework and aspiration for the team’s pursuit of technical excellence and innovation.
““People in any organization are always attached to the obsolete - the things that should have worked but did not, the things that once were productive and no longer are.” ”
For larger, distributed teams, a strategic plan is useful. For a smaller team, it may be that a yearly technical mission statement is more practical. Honestly, it could be that a Product Roadmap is all that’s needed to provide necessary forward direction for a smaller team that’s co-located.
CREATING A TECHNICAL STRATEGIC PLAN
Creating a strategic plan involves a number of steps—there is no consensus on what elements have to be there. I have found the following five elements to work great for creating and communicating an overall plan.
VISION
Again, a matter of opinion, but I’m not convinced the technology side needs its own vision— working from the same business vision as the rest of the company has worked best for ensuring the whole business is on board. For example here’s a business vision we took on one year:
This was a very straight-forward aspiration that actually ending up challenging us for several years. I love short vision statements that make sense to everyone—requiring no interpretation. I also love the aspiration part of this vision—we were a health industry job board, so calling out being a career resource in and of itself was a challenge to be something greater!
CORE VALUES
Over time the core values I’ve brought to technical organizations actually haven’t changed much. Sometimes I’ve modified them to point a specific team in a different direction, or sometimes the company already has core values. The team must identify with these core values—if they don’t believe or agree, then they’re pointless, right? I’ve shown six below, but it’s probably better to limit it to five or less just so there is focus.
While core values don’t apply specifically to the Objectives and Tactics defined below, they do influence how they’re carried out. Core values should be emphasized as “how” we operate as a team and business. Everything else defines the “what”.
It’s interesting to try to predict which of these value statements will be the hardest for the team to follow. In my opinion, it always seems to be hard for architects and engineers to keep things simple! There is always something cool that seems to get added or a future requirement that just has to be designed for now. There are also a lot of “lone wolfs” in software development—the collaboration piece just doesn’t make sense to them.
OBJECTIVES (OR INITIATIVES)
A strategic objective is a business need that is defined in quantifiable and measurable terms. Actionable objectives need to be bound by both a baseline and a target as well as by time. Without all of these, the strategy becomes less actionable and has a lower chance of being completed.
We usually defined our objectives on a yearly basis, going through the process of listing them all out, then having all the departments involved (e.g. sales, marketing, development) provide high level estimates around the efforts to accomplish the objective. For example, I always tried to give my estimates in days or weeks, nothing more finely-grained than that. Once the estimates were provided, the leadership team prioritized them based on overall company needs.
Below are some of my team’s objectives for 2017. These were all based on the vision stated above.
SUPPORTING OPERATIONAL TACTICS
Once objectives (Initiatives) are prioritized, operational tactics can be defined for the ones at the top of the list. User stories are then written from these tactics. We always estimated tactics in terms of number of development sprints (2 week periods) and each tactic included architecture/design time. Example tactics for the TECH DEBT objective above are shown below:
Our practice was to write separate stories for each sprint—so, essentially each of these tactics would be broken down into multiple user stories. Our development teams worked from user stories, which are elaborated and sized every two weeks.
MEASURING PROGRESS - KPIS
The final step is to track progress at the Operational Tactic level, rolling up to the Objective if possible. Since tactics have sprint level estimates, their percent complete can be tracked and reported. Each department head reported status and progress monthly as part of our normal Monthly Business Revew (MBR) process. Below is an example monthly update for the tactics shown above.
We provided explanations and corrective measure(s) for anything identified as behind or critically behind.
PRODUCT DEVELOPMENT ROADMAP
With objectives, tactics, and possibly some of the associated user stories done, a roadmap can be constructed by the Product team from all the department-level objectives and tactics. Once this roadmap was presented to and agreed upon by leadership, it was then communicated to the rest of the company.
MEASURing SUCCESS?
As mentioned at the beginning, a strategic plan can be used by leadership to help motivate a forward-thinking mindset from all departments, but especially from software development. Success is measured by buy-in, attitude, and other more tangible actions like interest in the non-technical parts of the business including financials, sales, and marketing.
Ultimately success is measured by the team hitting their deliverables at the Roadmap and Objective level, and making a noticeable difference in the product used by the end-users.
““Be strategic about productivity—do less exceptionally well, instead of doing more in an average way.” ”