cogitatio

So, your software company has been in business for a few years, you have a relatively reliable revenue stream, and you can bring in new clients with relative ease.  Your software platform is stable enough that you can implement client projects relatively rapidly, but as technology changes and evolves, and as the business needs change, of course it leaves a few things to be desired.  Over enough time, it leaves quite a lot to be desired and may be on the verge of being unsustainable.  And here is where the conflict arises.  Sales is constantly selling new revenue generating projects that require development resources to implement.  Software engineering resources tell you that there simply isn’t enough time in the day to intelligently grow the software platform while at the same time managing the implementation of revenue generating projects that sales has sold.  So what do you do?

An intelligent manager will try to figure out if there is any way to either carve off some segment of development resources to work on maintaining and enhancing the software platform, or hiring in new resources to dedicate solely to the software platform itself.  But this is where the conflict arises.  Engineering resources dedicated solely to the software platform are by nature, NOT dedicated to directly implementing revenue generating client projects.  A short sighted executive sees such costs associated to maintaining and enhancing the software platform as merely a cost center – money spent with no direct tie to incoming revenue.  For the short sighted executive, this remains true whether you work with existing development resources or hire new development resources.  If you use existing development resources, meaningful work is hard to accomplish without some meaningful amount of time dedicated to it.  Software engineers generally require some good head space to wrap their brain around the problem and then dive in.  While it is possible to define tight enough sets of deliverables that quality software can be parceled out into nice discrete periods of time, without the buy in from sales and the executives that during this time, the development resources on this project will not be working on revenue generating projects, you have a recipe for failure.  This is even more true if you hire in dedicated resources to work on the software platform (The short sighted executive asks – “How can I justify their salaries based on THIS set of revenue projects?”).

There are really a few different parts to the solution to this issue.  Firstly, the executives need to understand that the software platform is the business.  If it rots on the vine, then the business rots too.  Secondly, instead of looking at the costs associated with building out and maintaining the software platform as a “cost center” there needs to be a paradigm shift – the executives need to look at the software platform as a pool of features, things that the business needs to make the sale and deliver for their clients.  Lastly, the business needs to allow the engineering resources to do their job and there needs to be an institutionalized notion of space.  If features required for the “Sale du Jour” are looked at as “features in the pool”, and engineering resources have the space to work on the pool of features rather than willy nilly on this client project or that, the world can be very different.  If these things happen, the software platform becomes a revenue engine, development resources can be used most efficiently, and everyone’s happy.  Then again, its a rare small company that can make the paradigm shift from “cost center” to “revenue engine” if this wasn’t an institutionalized notion at the outset.