What's a CTO to do? (part 2)

It has been a while since I posted about some of the disciplines that a CTO in a software start-up needs to consider. For the record, I broke these down into:

1. Strategy
2. Product
3. Architecture
4. Infrastructure
5. Process
6. People
7. Program

Some of these are self-explanatory, whilst others require a bit more depth. As a summary, here's what I think are some of the really important questions in each of these disciplines. When reading this, consider the role of a CTO in a software start-up, I am not so concerned about big enterprise CTO roles, but more of the kinds of innovative, product-oriented businesses that build and deliver software, either shrink wrapped, or as a service over the Internet.

1. Strategy
What is the business strategy? What is the technology strategy? Is the technology strategy succinct enough to capture the attention of partners and investors and satisfy the requirements of technical due diligence? Does the technology strategy align with the business strategy? Who owns the technology strategy?

2. Product
Is there a product mindset? Is there product management mindset? Does technology follow product, or vice versa? Is there an overarching product strategy for the complete suite of products? Is there a product roadmap? Does the roadmap have clean and achievable timeframes for delivery? Are there separate release cycles for core infrastructure and customer-specific projects?

3. Architecture
What is the software architecture? Does it align with the product architecture? Do all members of the technology team understand it? Is the architecture managed? Is there a plan for allowing the architecture to change over time?

4. Infrastructure
What is the state of the engineering infrastructure? Is day-to-day developer productivity appropriate? What is the nature of the configuration management, version control and build environment? Is there room for improvement? Does the engineering infrastructure support the product strategy?

5. Process
How does the team work? What formal and informal processes are in place to assist?

6. People
Are the right people in the right roles? Is there separation between the software infrastructure team and customer-specific project teams? Is there a plan for succession in key roles?

7. Program
Is there a comprehensive program of work designed to deliver the product strategy? Does the program have clear milestones? Is the level of agility appropriate for the nature of the task, the nature of customer-specific projects and the maturity of the organisation?

As I said in a previous post, I consider the customer to be important enough to have its own category over and above these 7 disciplines (perhaps I will add it in as Discipline Zero in a future iteration of this framework). I have found that just having a simple framework like this is a good start, particularly during the discovery phase of a consulting engagement where you are trying to find out how a start-up or software development house operates.

My personal favourite from this list -- and the one where I think Australian software companies really lag behind our North American and European counterparts -- is product. I have come across very few companies that really embrace the idea of product management. In fact, one company I worked for spent a long time disavowing the entire notion of product management, insisting instead that they "had a framework, not a product", leaving no wonder why it took them so long to make their first sale. Alternatively, some companies end up so customer and project focussed, that they never have time to even notice that doing enterprise project work is a completely different exercise to product development, requiring a profoundly different outlook, and different set of skills.

I genuinely believe that things do not have to be like this! So, in an upcoming post, I'll take a stab at a really, really, simple software product management process, and attempt to situate product management as one of the core disciplines that a software start-up CTO should be across.

M@