Losing Agility — A flop
My final anecdote is a company which started out agile, enjoyed massive success, but then lost its edge. The owner of the company made millions on the first, humble product offering — put together using the minimum possible of computer code. Everything about the product was highly specific to the problem being solved, with no generally reusable libraries or components developed. Large parts of it might be categorised as “scripting” rather than as an “application”.
Having enjoyed so much financial success, the owner brought in a team of competent engineers and set them to work doing “proper software engineering” to deliver the second generation of products. The vertical market was the same, ambitions were perhaps slightly higher, but mainly there was a desire to “do things right this time”. Engineers were entrusted with great freedom, provided with excellent equipment and paid well.
Business development and marketing were mostly organic due to the owner’s remarkable innate abilities to network and sell, and due to his deep understanding of the market dynamics. The owner deliberately stepped away from the technical implementation to focus on customer development, and to let “real engineers” do software development. Her focus was now on brokering deals with business partners and managing delivery deadlines.
Deadlines were set, products were “pre-sold”… and pretty much universally delivered as a half-baked mess, if at all. In a couple of years, the codebases delivered had degenerated into a mess of “reusable” libraries, ambitious but unreliable user interfaces, and business logic which was strewn across “front-end”, “back-end” and database codebases.
Soon, most of the engineering team began leaving, citing a lack of technical leadership. A skeleton staff stayed but the company’s growth remained stagnant from that point forward.
Producing a simple, focused product was something the owner was able to direct and own with success. Delegating that responsibility to others failed utterly. With her initial hands-on approach, engineering was lean and humble in its ambitions — leaving little room for misaligned technical choices. She needed the agility produced by basic, reliable engineering, but failed to derive that quality from those to whom she delegated. Eventually the company was wound down and the owner went on to other ventures.
I’m not saying that a complex SaaS can’t remain agile, but I do know that as the complexity of a service rises, the skill (wisdom?) necessary to find a steady path through the technological landscape increases exponentially. I think of this type of agility as sure-footedness.
- not likely to stumble, slip, or fall.
- proceeding surely; unerring
This is part of a series of articles on agility and software which are linked below:
