Category Archives: Management & motivation

A faster horse? When not to listen to your customers

Last Wed I had the privilege of giving a talk at IBM to about 250 software professional. The topic was fostering innovation.  If there is a mantra of the modern corporate workplace it’s probably “Listen to your customers”.  We’ve all seen how companies falter when they try to dictate to their markets rather than listen to them.  However, I truly believe that listening to customers is a cataclysmic error.  By cataclysmic I mean an error so profound it can put you out of business.  Ok, I’m being provocative, to get your attention.  More truthfully, there are times you really need to pay attention to what your customers ar telling you (failure to do so may put you out of business), and there are times when you shouldn’t (because doing so may put you out of business).

Here’s why. Markets are all about supply and demand. They demand products and services to solve their needs.  When people need food they create demand for groceries. When companies need data management they create a need for database software.  Companies need to listen to their customers to understand those needs, so we can supply solutions they’ll be interested in consuming.  The problem, and it’s a serious one, comes when we extend that listening solutions.  The market provides demand, it is not designed to provide innovation. That’s our job as engineering companies.  When we listen to our customers’ ideas about how their problem should be solved it often cripples our potential for dreaming up a more creative and potentially superior solution.  Henry Ford was the founder of the Ford Motor Company and the father of the modern assembly line and industrial automation. He famously said “If I’d have listened to my customers, I’d have given them a faster horse!”.  Apple co-founder Steve Jobs once made a similar point, saying:   “A lot of times, people don’t know what they want until you show it to them.” 

After my IBM talk someone asked me if I really meant we shouldn’t listen to customer ideas about how to solve their problems. Of course it’s always worth listening, and sometimes what customer think they want really is the ideal solution.  But if you stop at listening, and never get to dreaming, you’ll deprive yourself of all the real moments of innovation that can help change the world and drive successful new business.  Although there are exceptions, as a rule if you are only building and doing what the market suggests you do, you’re going to be a follower, not an innovator.

So, my advice is this: Listen to your customers o and requirements. Do that with a passion.  When it comes to finding solutions, consider their input as just that – input.


Why software project management is like painting a Rebrandt (or, knowing when done is done)

Rembrandt Harmenszoon van Rijn (July 15, 1606 – October 4, 1669) was a Dutch painter.   When you see his paintings you can’t help but be amazed by their detail and lifelike nature.  The problem with paintings, especially the ones that are based on classical realism, is that there’s always one more stroke of the brush you can add. The painter is never finished. So too with software. There’s always one more test case to try, one more error scenario to trap, and one more use case to cover.   That’s why, left to their own devices, software projects never end.

Does everyone have a clear understanding, and does everyone have the same understanding of “done”? Ask around in your team  – I absolutely guarantee that in most organizations people do not!  

RED FLAG WARNING: Software developers love to say things are “basically done”.  The problem with “basically done” is that it usually translates to 90% ‘functionally’ done, but the last 10% of the work could take more than 50% of the time. As they say, the devil is in the details and the details are always in the final 10%.

Because there’s no such things as exhaustive development (and in particular, testing with full branch and code path coverage) one of the most important steps a software project manager can take in driving a high-efficiency team is to make sure that everyone in the organization understands the definition of “done” for the pieces they are working on. When is the code done? When is testing done?  It’s not as easy as it sounds, but it’s an effort well worthwhile. 

More on secrets of software project management in Chapter 15 of Making it Big in Software: Get the job. Work the org. Become great.

ITWorld’s interview with author Sam Lightstone.

Columnist and author James E. Gaskin interviews Sam Lightstone for ITWorld.

“Career advice: Making your mark in software programming”

Alone in a crowded room (and other email addiction problems)

Avoid the urge to do email during meetings. Laptops and BlackBerries have made it possible to do email almost anywhere and anytime. While it may seem like an efficient use of time, doing email (obviously) distracts you from what brought you into the room in the first place: the meeting! All too often, hard-working people schedule meetings to present important updates or proposals, or to review and discuss key issues, while the audience is clearly heads down in their laptops doing email. The speaker is literally alone in a crowded room. 
Not only is this extremely rude, but from a business process model, if you consistently do email during meetings, you will effectively not be present in most of the meetings you attend. As a senior person in an organization (or one aspiring to be), your attention at meetings is, believe it or not, frequently required.  


The optics on this kind of behavior are also pretty bad. To build an image of yourself as a person who is informed, engaged, and engaging, keep yourself focused on the meeting, not on the email.   

Avoiding software project overruns: watch the ratio!

In Making it Big in Software I discuss 11 reason why software projects run late (see Chapter 13).  In this post I’ll mention just one – my favorite. It’ my favorite because it’s ubiquitous, subtle and is fundamentally about programmer psychology. 
Software developers are notoriously poor judges on how long things will take.  Fred Brooks  (author of the Mythical Man Month) found that the following rule of thumb allocates time for software development with reasonable accuracy: 1/3 specification and design, 1/6 programming, 1/4 function and integration testing, and 1/4 system test. Over the past 30 years those ratios have held true (of course, they vary from project to project). Over the past ~15 years, the more mature teams in our industry have finally come to terms with the reality that testing is half the effort of a software development cycle, and that’s probably the biggest reason project success rates have been improving. Testing, in this context is the entire test cycle, which includes both the effort to plan  and execute the tests, as well as the effort to fix the problems it surfaces. We still have major problems on the front end, and these are the areas that most significantly damage individual careers.  Why is that happening? 


For a wide range of emotional reasons, software developers refuse to believe that coding represents only 1/6 of the software development cycle. They refuse to believe this because software programming is fun, and it’s what  they want to spend their time on. It’s just too depressing to believe that the very thing they jump out of bed excited to do, the very thing they planned to spend their professional careers on, represents so little of what they will actually be doing. 
Programmers like to believe that programming is relatively hard (which it is) and that other tasks, such as testing and writing, are comparatively easy (highly questionable). So when you ask developers how long a piece of work will take, they are thinking predominantly about the coding effort. However, what the project manager was usually asking for was an estimate for the total effort, including specification, design, and testing – or at least all the work up until testing. One tactic to avoid these issues is to only let programmers estimate what they are good at estimating: the coding effort. The ratios are well-known and hold true across a wide range of projects. If you can get a reasonable estimate on the coding effort from the engineering team, you can extrapolate easily to determine the time for design, specification and testing.  The coding estimates are usually the most accurate sizing a programmer will produce:    
   Design and spec = 2 x coding estimate   
   Function and integration test = 1.5 x coding estimate 
   System test = 1.5 x coding estimate     
 These guidelines are simplistic, and, of course, well-known exceptions exist. Features that add performance value (speed) but otherwise leave externals unchanged require performance quality assurance but functionally may require little testing beyond regression testing (to ensure that what used to work still works). Dependencies between features under development always add delays as teams spend more time collaborating to understand a broader set of requirements. Although I don’t recommend applying these guidelines naïvely to all projects, they make a good starting point for most. Then you can revise the estimates for the outliers as a (sometimes major) refinement.      

Whether you let the programmer estimate some,most or all of the required work, its worthwhile to sanity check the estimates they provide to make sure they’re in the ballpark of reasonable. If testing is less than 25% or design and specification are less than 15% it should raise a large red flag for you.    

Chapter 13 of Making it Big in Software: Get the job. Work the org. Become great. has the full story, along with the other 10 causes for software development overruns and how to handle them.  

What really motivates workers? Don’t believe the Harvard Business Review

After a recent talk on “Making it Big in software”, one of the attendees sent me a link to an article by the Harvard Business Review about breakthrough ideas for 2010. The top idea was an article by Amabile and Kramer about what really motivates workers. Their thesis was that people are motivated by “progress” more than “incentives”.  To support their claim they studied the correlation between “good days at work” and “progress”, showing, not surprisingly,that the two are indeed highly correlated. (Here’s the article: Here’s a direct quote:
“A close analysis of nearly 12,000 diary entries, together with the writers’ daily ratings of their motivation and emotions, shows that making progress in one’s work—even incremental progress—is more frequently associated with positive emotions and high motivation than any other workday event.”

A similar presentation by Daniel Pink goes further to suggest that rewards and incentives actually inhibit productivity.

What Pink, Amabile and Kramer are suggesting is that incentives in the traditional sense (financial rewards, public recognition, etc) are not only secondary they are actually counter productive. That is to say, these kinds of “incentives” have a negative effect and that what really gets a team excited and driven is a feeling of progress.

There’s no question that people are happy when they make progress. But is it fair to say that happiness and positive feelings are really the same as successfully motivating a team towards a goal? I’m sure they are important, desperately important. But a happy day at work isnt;t the same as a motivated goal driven day.

In fact the key effect of incentives is not to motivate people, and I agree with Pink, Amabile and Kramer in that (to work harder and hopefully receive the reward) but rather to provide clarity to employees on what an organization really values. In short, you get what you reward: not predominantly because you have motivated employees with the potential of reward (that helps, but only slightly), but overwhelmingly because the rewards remove ambiguity.

If you tell your staff that eating ice cream is unhealthy for them, but give out free ice cream at lunch every day will the consumption of ice cream increase or decrease? There’s no question consumption will rise. That’s because although you’ve really sent a mixed message (one that encourages eating ice cream and another that discourages it) the message to eat ice cream was more compelling – because that’s where you invested cold hard cash. The message that ice cream was unhealthy was jus a message, while the free ice cream was something more – it was an incentive.  This is a powerful idea in Making it Big in Software – incentives clarify intentions. They identify for people what an organization really values. In so doing, within the morass of mixed corporate messages, incentives filter the chaff from the wheat.

Pink, Amabile and Kramer are probably bang-on that progress is a dominant factor in job satisfaction. But to really keep a team passionate and focussed you need more than a satisfied team, you also need a team that’s completely focussed on its goals. Clarity of purpose. That’s where good ol’ fashioned incentives can work wonders.