Vision and Strategy

Creating a believable vision and strategy can be a Herculean task especially if you have not done it before.  It is an area where I personally have struggled a lot. For a long time I thought it was the sole purview of the CEO and the executive team.  Certainly for the corporate vision and strategy that is almost always true. But software engineering teams need to have a strategy too. It can often be implied, especially on a small team, but having it explicitly stated is beneficial. 

The strategy and the vision, or lack thereof, can have a huge impact on the team so it is important to get it right. It defines the approach to getting the work done; it provides the daily context for the team; and helps set the culture.  There are many ways to go wrong.  Here are a few ways that I have experienced first-hand:

• Going without – this can result in an ineffective team
• Ridiculous – you can lose the team this way
• Incomplete – you can do the wrong thing
• Inconsistent with the rest of the company – this creates conflict 
• Incomprehensible – you thrash

Hopefully by seeing some bad examples, you can avoid the same pitfalls, and set a good strategy and vision.  Because if you do it right, you can get everyone on the team motivated and going the same direction and that is a beautiful thing.

Going without

Early in my career, I thought it was all about detailed planning. Given a comprehensive plan the team would simply do what needed to get done. But that was far from the truth. On a fixed price program where we got paid on milestone deliveries, I was unable to motivate my team to complete the work. The problem was that the system that had been specified and approved as part of the contract signing process was not technically sound (i.e. it would not work). But we were contractually required to deliver what had been specified. After floundering for a while, I got some good advice; tell the team the truth. I told them my long term vision was to develop a workable system but we were going to have to do it in a roundabout way. The first step was to do the design for the system that was not going to work, to confront the clients at the design stage, prove that a subset of the requirements were incorrect, show an alternate approach, rework the contract, and then get ourselves back on the right track. There was no project plan that could communicate that. But with this knowledge the team was able to get the necessary payment milestones done without having to spend too much time on work they knew was going to be thrown out. And once that was out of the way, they started to focus on the doing the work the right way.  By setting a believable vision and approach for the engineering team, I was able to get them on track, and focus on getting the program corrected. It was simple and effective.

The ridiculous

I once had a VP of Engineering, who had come to the company from a completely different line of work and from a marketing background.  We were a systems shop where the real value was in the software we developed. We had 3 products we were barely supporting and were being asked to do a forth with no staffing increases.  The new VP spent a few weeks assessing the situation and told me that even though everyone was working hard, we needed to stop doing so much and focus on one area only to be successful. His solution was to “focus on software”. Say what? This did not provide any focus and worse than that indicated clearly that he had no understanding of what the team did.  Several people left after that announcement, me included. 

The incomplete

On another team, our VP of Engineering gave the edict that our focus was on quality first.  It made sense; since our focus in the past couple of years had been features, features, features… getting them to market as soon as humanly possible. Unfortunately, quality had suffered as a result. But his strategy for improving quality was not complete. The stated (and measured) strategy was to fix bugs quickly. Clearly fixing bugs was an important part of the problem but that was primarily a tactical effort.  There was also a need to fix our requirements definition, to attack the technical deficit we had accumulated, to rework several major subsystems, to make the system more serviceable for the support team and to improve our system testing.  We needed to build quality into the product and not simply try to fix it after it went out the door. But given what was measured (and the punishments that went along with failure to comply) the team focused on bug fixing only, and the rest of the quality initiatives suffered. The results, as far as I was concerned, were predictable and not good.  The escape rate for bugs did not change and so much effort was spent on fixing fielded bugs that feature development suffered. Eventually, after his departure, the focus was reset and the strategy for attaining better quality was expanded. 

The inconsistent

At a company with 3 development sites, the unwritten but commonly stated vision of my site’s engineering group was

• Performance is a key factor in the product’s success.
• Everyone should strive for technical excellence.

The team I worked with rallied around it and worked hard to deliver excellent code and a product that’s performance was second to none.  We argued to find get the best technical solution to a problem and we hired only the best engineers. It was great, or at least it seemed great for a short while. The problem was that the vision was not shared between all the engineering teams yet we all worked together on the same product. The other teams were focused on quick feature addition to address short term customer needs. The result was that each site was very loyal to their own team but did not like or trust the teams in the other site (my site was considered a bunch of elitists and the other sites were considered to be thoughtless hacks) and the product suffered. Without alignment, it just did not work. 

The incomprehensible

At one company we had a strategy and vision that was loved by analysts, marketing, and the execs.  We were showing market leadership by creating a new market and had a staged approach for achieving the vision. It seemed perfect.  But to the product team the vision and strategy were incomprehensible. The current product suite had only a tenuous relationship to the new market. The strategy was staged but the steps were amazingly large and literally required technological miracles for them to be completed in the required time frames (whether the strategy authors knew it or not).  So both engineering and product management struggled. Some progress was made but essentially the product road-map stayed in chaos for a couple of years. As the realization sunk in that we had not made any product or sales progress that would help forge this new market, we retrenched.  Several executives left the company and the vision and strategy were reset. 

The ideal

I don’t have a prescription for getting to the right strategy and vision for your team. But here are some rules that I follow:

1.  It needs to be the truth.
2.  It needs to be attainable but should stretch people.
3.  It needs be understandable.
4.  It needs to be consistent with the corporate vision and strategy, and with the approach of other teams. 
5.  If possible, it should inspire people.

On one team that was just starting out, we used the following template:

Vision: We are developing a world class [specific solution] for [our customers] which will provide [this specific value] at this [performance level]. 

Strategy:

Create a base product that we can put into beta test within a year of starting that

a.       Provides at least [this specific level of value from the vision]

b.      Supports this [minimum performance characteristic]

c.       Fits seamlessly within the customers operational framework

d.      Clearly shows the value to the customer

Ensure that the initial product works for the customers by

e.      Addressing all major issues noted in the beta program before the initial release

f.        Release product updates on a monthly basis that

                                                               i.      Fix customer-visible bugs

                                                             ii.      Improve the serviceability of the solution

                                                            iii.     Improve the value of the solution. The target goal for the value after 12 months of real world experience is [this amount].

Follow up with a product within the next year that

g.       Improves the performance [to this level]

h.      Works on the same equipment as the initial release with an easy upgrade path

i.        Gives the development team visibility into how to continuously improve the product

The team was motivated by this strategy and vision. They used it to make good product decisions; as it helped clarify what was important and what was nice to have. It did not replace having detailed requirements but provided context for the requirements. It worked. The initial product and dot releases exceeded management’s expectations.

  

If you were starting with a clean slate, you could just say “Do the right thing”. That might work but it would take a pretty rare (or extremely small) team to make that successful. If I could start with a clean slate and was developing a consumer software product, I might have the following vision for my engineering team.

1. Keep it simple (eliminate any unnecessary complexity in our systems and our product)
2. Add value (make sure whatever you are doing is adding value to the organization,  to the product, or to the customer) 
3.  Be collaborative (the team is more important than the individual)
4. Innovate (we win by changing the game).

Of course, we would need a strategy to support this, but you can imagine having

1. Architecture/design/code reviews that ensure we are looking at the simplest solution.
2. Regular meetings with customers to ensure that we are truly adding value.
3. Days set aside with no agenda, just an opportunity to let be people innovate.

So give it some thought. Set a vision for your team. Make sure you believe what you say and that you can defend it. And whatever you do, don’t repeat the silly mistakes that my managers or I made.