Software Leaders: 4 Reasons Your Next Big, Transformative Initiative is Going to FAIL

I've spent my career in ENORMOUS software shops so have suffered through more than my fair share of failed initiatives to fix long lists of ailments, real or perceived, ranging from lack of productivity to lack of agility to lack of customer focus, to, well, there was no lack of things that were lacking. Having spent a great deal of time lately researching the transformative process of scaling Agile and even attending training on the subject (I'm now a certified SAFe Program Consultant), a rush of unpleasant memories assailed me, compelling me to take pen to paper (literally) and create a list of the biggest causes for failure of these initiatives that I've experienced.

Here are my top 4 reasons why your next big transformative initiative will in all likelihood fail (and by fail, I mean fail miserably). Being a perennial candle-lighter and an undiagnosed sufferer of Don Quixotism, I'll offer a few tips from my perspective on what you can do to begin overcoming these challenges.

1. Your organization lacks leadership
Since the dawn of civilization and probably before, we as a species have confused achieving positions of power with the ability to lead. If I ask a group of managers at most organizations how many of them are poor leaders, it is unlikely, for a variety of reasons, that many or any of them would raise their hand. In my experience, this phenomenon isn't just a product of peer pressure: most people who have the word "manager" in their title or job description believe that, after a transition period lasting between 2 minutes to 2 months, they magically become good leaders. I've got some unsettling news for all organizations: About half your managers are below average leaders. If we were to assess them based on a less relative scale, I'm sure the percentage of good leaders in most organizations would not cross 20% (and I believe I'm being generous.). When pressed for proof that they are actually good leaders, most of these folks will, at best, point to  the results they've achieved. Good for them. Mussolini made the trains run on time but, oddly, is rarely quoted in books and articles I read on good management practices.

My silver bullet for bursting managers' self-inflated bubble is to ask when the last time the people who reported to them were given an opportunity to anonymously rate their leadership ability. I've worked for organizations that regularly did 360 reviews; I've never seen any other practice that had such a profound effect on behavior. Are you providing your leaders with this critical reality check?

2. You're not prepared for the inevitable dip in forward velocity
So you read the book, took the seminar and drank deeply of the newfangled panacea's Kool-aid, convincing yourself in your boundless excitement that it is the solution to a myriad of problems. Your new framework or approach or methodology is almost certainly going to increase productivity and customer satisfaction while decreasing defects and time to market (all while finally giving you the visibility as the visionary you always knew you were). Although not too many people like to talk about it and, at best it appears in the footnotes of outrageously misrepresented and self-serving case studies, when you make big changes, you can bet there is going to be a non-trivial period of time during which all the things you're trying to fix will actually get worse! That's right, your folks'  productivity will go through the floor and their flagging morale  may drop while their cynicism, honed to razor sharpness by bearing witness to the plethora of previously failed initiatives, will spike.  Instead of lightning speed to market, your products may languish in a no-man's land of confusion and general inefficiency. It is in this valley of despair that most organizations will abandon the new approach or hobble it lethally by reverting to previous, safe practices, however suboptimal.

To avoid this type of painful, embarrassing setback, you should prepare yourself for a temporary drop in productivity and set expectations appropriately. Having a clear set of KPIs and associated decision points can also help avoid giving up too early or, even worse, too late.

3. You haven't defined the metrics by which you'll measure success (and don't have a baseline anyway)
As I mentioned in the previous section, having a clear way to measure success is critical. While this seems self-evident, many initiatives hope to improve slippery measures such as "productivity", a metric for which most organizations have no reasonable baseline nor definition. Before you launch your initiative, determine what specific impact you expect it to have, define related KPIs and make sure you can actually measure them. KPIs that have a baseline in the organization are (obviously) more valuable.

4. You think improving engineering's performance is enough
No one will argue that engineering (development) is an important part of the equation when it comes to getting great software out the door. This (and the fact that many software leaders started in development) makes this function a logical target for improvement initiatives. However, without the right processes for defining what they should build, generating demand for it and finally selling it, development and its work product are, in most cases, useless (actually, worse than useless as they consume massive amounts of resources). If you're exploring Agile, you need to think deeply about how eventually increased velocity will impact the folks up- and downstream of development. Adopting SaaS and want to deliver new features weekly? Make sure marketing, sales and support can keep up.

To avoid local optimization in the product delivery value chain, think about the end-to-end process and make sure to include the key contributors to your products' success.

Conclusion

There you go. These are the top 4 reasons behind the most spectacular "new initiative" failures I've witnessed first-hand. What are yours? Have you experienced these issues too?

For more information on my software product management consulting and training services, please visit my site: http://www.prickril.com