Category Archives: Improving Success in Software

Process, Methodology, Transparency and other ideas to help your company and teams guarantee success in your software product or project.

The Top 5 Rookie Mistakes in Software – #2 Sustaining Innovation





Espionage and Sabotage

A toxic environment can kill innovation

Your innovators are your lifeline to success. Without a critical mass of imaginative people who are willing to take chances and throw their neck on the line for a fresh idea, you’ll be doomed to mediocrity. The unfortunate organizational culture that emerges in most corporations, however, is one that plays a harsh game of whack-a-mole with the few willing to stick their heads up to pursue new sustaining innovations. Why is this?

Here’s an interesting and hilarious Ted Talk video by Ken Robinson about killing creativity. Robinson does an excellent job of highlighting the backwards approach we have towards people for taking chances; for willing to be wrong. “If you’re not prepared to be wrong,” he says, “you’ll never come up with anything original.” But being wrong in the corporate environment – as it is in politics – exposes people in a negative light. It invites criticism and is met with disappointment. It’s remarkably easy to spin it as unsuccessful, you’ve failed.

In the world of software, having an edge in innovative products and innovative design is particularly important. The blinding speed that new technology hits the market puts heavy demands on differentiating yourself from the competition. Google, Apple and Research in Motion all know this (Here are the Top 50 most innovative companies according to Business Week). Check out this statement, which is part of Google’s employee agreement, “Thinking beyond the norm is expected, no matter what position you happen to hold…Innovation is our bloodline.” Even players like Google, however, will struggle with maintaining an innovative edge. It appears to be an unfortunate but consistent pattern as organizations become successful and continue to grow.  This pattern shows as an Innovation Curve where, during the new or start-up phase of a company (or departments within a company), there is a keen, passionate environment that allows and encourages innovation to thrive. As the company becomes successful, however, the innovation dies off; the innovators are pushed out and the organization becomes stale. According to a recent Research-Technology article on Sustaining Innovation, “As firms grow, they tend to exhibit common behaviors that prevent them from being adaptive to new environments, thereby limiting their ability to sustain their innovation drive”.

The innovation curve is a bit like this: innovation curve

Over time, rigid processes, resistance to change and complex power structures cause innovation to just drop off.

This curve is particularly noticeable when you work in the technology business – which is a domain that tends to attract innovative types. It’s a unique discipline where the scientist, inventor and artist – when all blended nicely into the same human package – can actually succeed in the corporate world. Success over the long term, however, means a tendency to regularly switch jobs as a result of this curve. They either get pushed out or slip away on account of boredom or frustration.  The long and short of it is: To drive out your best people, just let it get political.

Spot an Innovator

What do they look like? They’re often the ones who are quietly offering clever, game-changing solutions that come out of nowhere but blind you with simplicity and clarity. Not always the Howard Roark Geniusstereotype, of course, The Innovator can be bold and outspoken, and absolutely resolute in a vision.  They can be annoying and persistent and uncompromising and … shockingly unaware of the optics of a situation. Whatever the look they assume, one thing is certain: the innovator is a threat to The Ambitious and to The Contented.

Bluffing Your Way Into Management

The hierarchy of the typical corporation is a breeding ground for The Ambitious. The existence of an org-chart alone makes for a convenient physical reminder to many motivated individuals about goals. It is often the thing that drives them most. Having ambition, by the way, doesn’t necessarily make you one of The Ambitious, by my little definition. Those I’m calling The Ambitious are the ones who are born gifted with a political savvy about working the system. Rather than pursuing success through doing good work and bringing value, these are the calculated planners that pursue success through whatever means possible.

This includes the removal of barriers like innovative people. And the innovators are typically a very easy target because they’re so bluntly unaware of politics. Being keenly aware of the power of perception and making strategic alignments, a character assassination is a pretty routine task for The Ambitious. In the Sustaining Innovation article mentioned above, not much is made of this darker side of organizational culture – but the truth is, we all see it. It’s the active and transparent sabotage of individuals or teams to eliminate a threat.  Robert Sutton gets it. His blunt and charasmatic message bypasses all the niceties and tells it like it is. To learn more about Sutton’s offering, have a look at this rather good commentary on the civilized workplace and how not to be that guy. For an additional inspired read, check out Snakes In Suites by Babiak and Hare. 


Change Bad, Risk Bad

Process is an excellent strategy for removing innovators.  Lots of Process. As an organization experiences success The Contented will introduce greater Process and Meetings, and questions, and presentations to defend positions, and extensive documentation, and costShoot Foot justifications and detailed planning. Not to mention Committees and Steering Teams and Global Synergy Initiatives. This is all great stuff for driving the innovator absolutely nuts. A general resistance to change and risk, where everything is comfortable and familiar is also an ideal state to achieve where innovators will simply disappear. In other words, when the environment gets too bogged down with manoeverings, detractors and pointless meetings, the innovator will just get bored and leave. Of course, effective processes and process management are important, critical even; however they should match the environment and bring value.

Again, from Sustaining Innovation, “First, as firms mature they tend to become too comfortable doing what they normally do; this comfort leads to myopia and also discourages risk-taking outside their comfort zone. Second, core values and the structures in place become rigid over time, thereby encouraging only a narrow focus on operations and mission. This results in incremental innovations compatible with existing structures. Third, firms lose the drive that got them where they are; that is, they lose the creative energies, the openness to risk-taking and experiments that allowed them to carve a niche and disrupt the incumbents when they first entered the market.”

As Usual, It Comes Down to Leadership

When the Big Three auto CEOs flew private jets to ask for taxpayer money, in November, 2008; I remember thinking to myself, These guys are really out of touch. As shocking as it was, it’s representative of how common it is for leaders in established organizations to get thoroughly disconnected from what’s going on down on Earth.  Strong and engaged leadership and leadership strategies are critical to enable a competitive level of innovation. Deliberate actions and reinforced values have to exist to eliminate the exploits of The Ambitious and the conflicts waged by The Contented.

Leaders and managers at all levels of an organization must be tought to underline the importance of remaining an innovator.  Innovate or Die. Isn’t that the expression? Management is the most succeptable to becoming lazy and Contented and guilty of no strategies around sustaining their innovation edge. The stagnation of innovation is a symptom that has roots at all levels, especially right at the top.


Chris Ronak


Nothing to see here, move along

NerdPassionsA few months ago I had lunch with a friend who wanted to pick my brain about some frustrations she was having with her company’s software development department.  Her company produces specialized machinery for something (actually, I forget what they do), but they also build and sell software products.  In her role, she leads up a marketing team in charge of commercialization, PR and marketing of their software.

She started the lunch in a quite civil mood – the food was great, the restaurant was awesome – but once she started talking about their software guys, she got a bit edgy.  “I don’t know what they’re doing.” She said, clearly agitated.  “We’re supposed to release this new version in 3 weeks, and I’ve never even seen it.  I don’t know what new features are actually going into it, and they won’t tell me.”

“Every Time I go to meet with them to get more information, they treat me like I’m an intruder – like I’m some annoying idiot from Marketing invading their turf.  All I get is hand-waving and the big brush-off: ‘Nothing to see here pretty lady…’ blah blah blah.”

“I don’t get it.  How am I supposed to do my job? We’re supposed to go live in 3 weeks and they won’t even show me!”

My immediate reactions while she was telling me this story were a bit like this:  I wanted to go strangle that software team.   It was clear that they were badly organized, lacked leadership, they’ll no doubt miss their release target, it will ship with a reduced set of features, and the quality will be poor.  I got especially annoyed when she went on to tell me that they were “Agile”.  Her comment was, “I know you do Agile too, but I don’t think it works.”  That was the clincher.


Agile is all about transparency, it’s about delivering continuous working software, it’s about inviting all stakeholders in to participate in the development of a product.  Like anything, there are a lot of pretenders out there using a popular concept to hide their own inability.

So, if you were in my shoes, in that situation, sitting across from her, what would you say she should do?

Should she escalate the issue to higher-ups?

Should she continue to badger them till she got answers?

Maybe she should just know-her place.   Bow down to the divine miracle-makers in software.  Wait patiently until they’ve completed the magic-of-software-development before asking more tedious marketing questions.

What would you say? (see poll below)

Ultimately, there are so many things wrong with this situation; I struggle to know where to begin.  So, I’ll make a quick list of the obvious problems that this represents before diving into any detail:

  1. There’s a clear misaligned idea of product ‘ownership’.  While the product should be owned by the business as a whole, the development team appears to view their role as somehow ‘more entitled’
  2. There is a dangerous breakdown in Transparency and Communication
  3. The software team doesn’t know how to ‘ship’ software

A misaligned idea of product ‘ownership’

Clearly many software teams are compelled to believe that what they do – their role in their organization – is to ‘write software’.  Which, in some respects, has some functional truth to it; but the greater truth to what technology professionals do is, “Build Market-Driven Products”.

So, okay, maybe that statement makes you want to roll your eyes to the sky … but at the end of the day, we all work for a company that is in the business of doing business.  Making money.  Whether you’re building commercial or internal software, your company is investing in your time because they believe that it will help them make money.  It’s pretty rare that someone will pay you to play with technology.  The fact is, they’re paying you to do whatever you can to produce a product that has the maximum market potential and ROI so that they can make money.

The long and short of all that is: the technology team doesn’t ‘own’ the product and they have no right to throw up barriers around that product when other stakeholders with equal ownership need to participate in the product’s success.  The product is owned by the business, and the software group’s contribution to that should be a business-driven contribution. NOT a technology-driven contribution.

A Breakdown in Transparency

Software developers have a strong desire to hide in a dark corner and fidget away at their work – their creation – for as long as they can get away with.  The goal is to reappear, unveil the masterpiece with a “Ta Da!” and crowds will applaud the genius, the angels will sing and he will have saved the day.

This is likely the most dangerous thing in the world of software.nothing to see here

Ensuring that your team is fully transparent from all aspects of communication, visibility and availability of working product is absolutely fundamental to a successful software project. If you’re getting pushed off with the “Move along, nothing to see here…” attitude from the dev shop, it’s a clear sign that things are not well in that department.

Learn to ShipSoftware

I just had a chat with my friend, and as it turns out, 4 months later, they still haven’t shipped that release.  And it’s still not clear to her, or anyone else outside the technology department, what will be released or when.

Writing the code is only one aspect of creating a commercial product that you deliver to happy customers (internal or commercial).  The act of shipping that software product is craft that requires practice, experience and a lot of planning.  It’s tricky to ship.  No question.  So, to manage the risk and pitfalls that exist around getting your product to market, best practices tell us to ship all the time.  Ship your software as often as you can. Even if it’s only to internal stakeholders – your BA, Product Manager, trusted clients, etc.  Ship.

If you are on the outside looking in; and your dev group can’t prove that they can ship the software asset you’re investing in long before the release date – this is another sign that things are not well in that department.

Chris Ronak

When your project fails, it IS your problem

As Technology Professionals, we have an obligation…

It’s pretty common for software projects to fail.  According to the Standish Group’s 2009 CHAOS report, only 32% of software projects succeeded over the past year. Not exactly a banner year to be sure; but even in a good year, it’s rare to hit more than 40% success. Whatever the reasons and wherever the fault may lie, these are disturbing numbers that I think we, as technology professionals, need to take ownership of and do our part to correct. (For a little background reading, have a look at this excellent IEEE paper about software failures).

It’s easy for a member of a software project team – especially developers – to up and bail out of a ‘disaster’ project situation and simply move on to another project.  There are plenty of opportunities out there for skilled technical people, so it doesn’t take much to just throw your hands up in the air and abandon the disaster for a more appealing career move.  It’s equally easy to ride-out the disaster and just show-up for work, and tune out the world around you.

The thinking, of course, is that it’s someone else’s fault, someone else’s problem and someone else’s financial catastrophe to sort out.  After all, you’re just a small player in a big machine.  It was probably a lack of requirements, poor leadership, lack of focus, too many changes, management issues, etc etc. that caused the failure, right? So, why should you take on any responsibility?

The trouble with that type of thinking is, Those People left to pick up the pieces of a software failure are left with a bitterly sour taste about the risk associated with investing in software.  They have to stand in front of investors, customers, regulatory bodies and other stakeholders to explain the multi-million dollar failure.  And you know what?  They are not happy with the 32% success rate in software projects.  It’s both expensive and it looks bad on their career.

And with all these software failures on the books, They may decide that, when faced with the prospect of investing in software products & projects – and technology in general – it is far too risky and their money is better invested elsewhere.  We really need to improve things.

So, without descending into a blame and fault discussion, let’s be honest about the burden of responsibility of software project success and failure.  While it’s true that the causes are rooted in many influences and situations in an organization, my goal in this discussion is to zero in on what we, as technology professionals, HAVE TO DO to avoid and repair the ongoing brutal legacy of software project failures.


On the positive side, I truly believe that we’re getting better at building software. This is echoed in historical CHAOS reports from the Standish group, but it’s also something that’s evident in the many improvements and maturity in the world of software development: better tools, improved standards, and the emergence and more widespread adoption of Agile and accompanied development processes that reduce risk.

Part of the challenge is that there really aren’t any established standards in this industry.  Adopting standards is optional.  There are obviously scores of strategies to improve quality and the ability to reliably hit release targets, but it’s typically at the discretion of the development team and mostly overlooked … which is largely why we’re at a 32% success rate.

So, to start with: whether you’re a manager, developer, product owner or business person, here’s a bare-minimum list of what your software development team should be doing to improve your ability to build and ship quality software:

  1. Continuous build on an independent build machine.  Check out Continuous Integration for more.
  2. Improve team communication through daily Stand-ups or Scrums
  3. Integrate QA into your development team and development cycle
  4. Keep your software in a continuous working state. Only the code that’s checked-in should be considered as valid working code.
  5. Ship your software product often – like every week. Even if it’s just to internal stakeholders.
  6. Divide the release cycle into manageable chunks (sprints, iterations)
  7. Remove barriers between the technology teams and the rest of the company or to customers. Invite users/stakeholders to regularly see your working software in progress
  8. Adopt best practices around: peer reviews, QA, exception handling, coding standards.

Each of these simple process improvements vastly reduce risk and increase the chances for success.  These examples are only a scratching of the types of methodology/process upgrading that teams should be adopting, but I believe if ‘most’ teams were to do only those things, the number would dramatically move from less than 40% to well over 50% success.  Still not great – and I’ll address some more deep reaching improvement concepts in upcoming discussions – but if more teams and technology professionals were to adopt a sense of ownership in improving the global perspective of software project reliability, we can avoid a most certain backlash in the availability of technology investment dollars.

Chris Ronak