Category Archives: Software Development Economics

CTO Rules for software product development teams

Software product teams that work well can be amazingly productive. The following rules have helped me grow high performance teams – most of the time they are all appropriate.

1 – Building the right thing is more important than building things well – but building things well is also important.

2 – Customers almost always ask for incremental improvements to what already exists. Your job is to figure out what will wow them – what they didn’t even know they wanted.

3 – Every team member should be able to do a reasonable demo of their product. This tends to get engineers more involved in design from the end users/business perspective.

4 – Product release cycle time <= 90 days. Faster is generally better. Software product development is an attempt to predict the future. The quicker to market, the shorter timeframe you have to predict.

4a – Products/projects going more than 1 year without a release have a dramatically higher probability of cancelation – total waste. Release often so you can learn/re-vector faster.

5 – Talent, not resources. Resources are things like servers, software, networks and money. People are different – they can figure out how to solve problems and do things better. That is talent at work. Instead of a project resource plan, build a talent plan.

6 – Every team member is treated with respect. We tend to attract folks to product development that are, shall we say, socially challenged. However, these socially challenged engineers tend to be really good at things that are difficult to get done. Keep them focused, and make them feel like valuable team members.

7 – Engineers get the best gear. Things like laptops/tablets/software/phones have become status symbols in many organizations – executives get the best gear. If you want better team productivity, then engineers get the best gear.

8 – Most decisions should be made by teams – not dictated by the CTO, except for the rare occasions when it really matters that the CTO should override the team. There are usually a number a ways to get something done. Let the teams be creative where your standards allow.

9 – Team roles are defined out of necessity, but every team member is responsible for their total product – its never not my job.

10 – Automation often improves team throughput more than adding team members. Make sure you spend enough time and money on speeding up the team.

 

 

Software Development Cost Drivers

How many times have you negotiated low hourly rates only to find that you go way over budget in a release?  What metrics do you use for development organizations?  Schedule might be a more effective metric to minimize than hourly rate.

I have had the privilege to lead teams that have been benchmarked (by outside entities) at up to seven times normal (whatever that is) productivity.  How did the auditors know?  They usually looked at the total number of components, amount of code and features developed.  And then looked at how many developers were on the team.  It was quite entertaining.  “Where is the rest of your staff?  This team could not have possibly built this – they couldn’t have work enough hours”.  But we hired top performers.  Implemented lean processes.  And made capital investments to keep teams really moving.

The range in productivity between top and low performers is often quoted at 10 to 1.  I have found that it is often much more than that – like 20 to 1 or greater.  Top performers are exceptionally good at their craft.  It’s fascinating that you don’t have to pay 10 times more.  It’s usually much less than 50 percent more.  This would be an awesome deal if….  If you could actually hire these folks and figure out how to use them effectively.

How do you know someone is a top performer?  Not necessarily because they have vast technical knowledge.  They get the right things done.  They know when they need to put in the time to get the right things done.  They also have a knack for figuring out what the right things are.  And for working well with their team.  And they seem to learn new technologies extremely fast.

The number one cost driver in most releases (or projects) is usually schedule.  You commit talent to a project or release, and most folks stay on the project for the duration.  You then have an established run rate.  And schedules usually slip.

How do you stay on schedule?   Remove obstacles that get in your team’s path.  Fund the right tools (that they pick) to get them productive.  Make sure decisions are made well in advance of when the team needs them to be made.  Absolutely minimize wait time.  No waiting for servers, software, bandwidth – invest for productivity.  I have often spent 10-20k per developer on resources to help productivity.

If you do many of the same kind of projects, or plan multiple software releases, focus even more on architecture and automation.   Measure how well you do.  With some effort you could even get to continuous development.  And dramatic waste reduction.  It may seem counter intuitive, but have your best developers build architectural components and development automation tools.  Don’t leave out testing tools.  Automated testing is super critical to accelerating software product release schedules.  Many organizations say they do automated testing, but do they ONLY do automated testing?

So…  you might be wondering if you can get away on spending money for productivity tools with cheaper talent.  They may make a difference in productivity to a point.  But productivity tools often increase complexity.  So you may need top folks to figure out how to get many of the tools to really work together.

It may be difficult to convince the compensation committee that you are paying more to reduce the cost of a release or project.  I’ll leave that one to you.