Manage your people

Whereas I don’t have the experience to write about it, I’d like to show some lecture notes and summaries about leading in high-tech.

Science, technology and tools often hide the most important fact: your people are your capital! The better your people the better your products. Of course you can hire highly trained people, but it’s your obligation to give them space and opportunity to evolve.

Your employees are highly motivated and highly trained after their schooling, but all to often the get demotivated far too fast. Why? One thing I’ve blogged about earlier is to tell them how to do their task instead the goal. This leads to an interest conflict, the requirements may conflict with the employees liability. Simply put: I can’t be responsible for things I was forced to do.

Software Engineering is somehow special in some cases:

  • Ideas are the driving force
  • The outcome is often unsure
  • Research leads to knowledge gain; Development to products; these two often get mixed up and lead to nowhere
  • Progress is hard to measure (90% syndrome)
  • Unsafe starting-point (changing requirements; incomplete foundation)
  • High complexity of modern software products

To support the worker, you must make sure

  • to give them enough freedom to think
  • to enable quiet and uninterrupted working
  • to enable communication between the people
  • to supply the needed tools
  • not to condemn errors – these are necessary within a creative environment

Important points to keep:

  • bad ideas lead to bad products (often the first idea won’t be the best)
  • the best idea won’t lead to success if the routine work fails
  • methods enable creative thinking (they free you from thinking about routine tasks)
  • processes make projects faster! If a process slows you down (long-term), it’s the wrong one.
  • your people want to be proud of their work, make sure they can.

Managers are hired to amplify the productivity of all people around them.
— Scott Berkun; The Art of Project Management

Growth

I’ve seen companies which try hard to grow1. I often can’t see the point in getting more people to work for them. Investing in the current people pays much more, I think. If you take the span of bad people to very good people which can be ten times more productive2, wouldn’t it be worth to invest five times more money and time into these people than hiring more and more? Every single person increases the communication effort and slows the whole organization down. Whereas a slim, highly productive team increases the quality and lowers communication effort.

More productive?

There are many factors which influence the productivity of people in software development.

  • Speed (Function Points per Week)
  • Defect rate (bugs per Function Point)
  • Communication effort (knows how to use Google and Books)
  • Cost (Cost per Function Point)
  • many many more…

Lets compare two groups of developers, one slightly better than the other5.

Developer FPs/Week Bugs/Fp Euro/Week Euro/FP Additional communication-effort
A 100 0.01 1200 12 0.05
B 66 0.02 800 12 0.10

So, developer A is clearly more productive than developer B, but costs more.

Imagine a project with 1,000 Function Points. It has to be code complete in five weeks.

Group of A-Developers

1,000 Function Points in five weeks are 200 Function Points per week. Our team has to consist of three A-developers. Ideally, three developers produce 300 Function Points, but we have to consider the communication effort: (3 × 100) x (0.953) = max. 257 Function Points. Cost: 18,000 Euro with a combined defect rate of 0.02973.

Group of B-Developers

This group has to consist of six developers. (6 × 66) x (0.96) = max 210 Function Points. Cost: 24,000 Euro with a combined defect rate of 0.114.

Summary

As you can see, a few developers which are slightly better than another group can easily outperform a double sized team:

Team Number of developers max. FPs Cost Defect rate Communication effort
A 3 257 18,000 0.0297 0.1426
B 6 210 24,000 0.114 0.4686

You could easily pay the A-Developers the double amount of the B-Developers and you would still produce a better4 product in the same time with the same expenses! Additionally the A-team still has more capacity left for changing requirements or unforeseen problems.

Again, wouldn’t it be far better to support and develop your current staff than simply adding more people?

1 In terms of “hiring people”.

2 The numbers came from two different sources. The first one is senior Siemens manager, and the second one is Paul Graham.

3 One minus the probability of no error: 1 – 0.993

4 More features or superior usability and less defects.

5 Never trust a statistic you didn’t fake yourself.

Adding manpower to a late software project makes it later.
— Fred Brooks

The First Idea

I don’t like first ideas. Most people working with me may have painfully experienced that1.

I really think that idea generation is vital in our business. We can’t afford (anymore) to take the first idea and start working. Knowing the alternatives is much too important. All too often I see people thinking of a problem and the first idea that seems to make sense is it. These (non)efforts result in changing directions in the middle of the development, or in starting over. Both very expensive experiences.

Sometimes the fist glance (see Blink2) is very important and a very powerful tool. But in this case, with systems more complex than most other products in the world, that won’t work.

I really enjoyed Scott Berkuns “The Art of Project Management3”. Especially because he dedicated some pages on that problem. When we start to think about a problem we should explore the problem space as far as possible4. Know what’s allowed to do and think of as much possible solution within these boundaries as possible. At some point the solution space stops expanding and collapses. This is partly because some solutions are not feasible, and partly because the solutions overlap. At the end you should have a few very distinct solution-proposals. Now it’s time to analyze those. Do they really solve your problem? Is this what the users want? Is it feasible? How much does it cost?

At the end of this process you should have one solution which is very likely significantly different from the first idea. And you have a high chance that you’ve chosen one of the best solutions possible.

Bad ideas simply lead to bad products, but also good ideas lead to bad products if the rest fails. Nevertheless, many of the failing projects4 have problems with their foundation (requirements and ideas) than with the implementation (design and code). Unfortunately changing the foundation gets very expensive the further the project develops.

1 On the other hand, my blog-articles are rarely more than a blink of an early idea.

2 Blink by Malcolm Gladwell

3 The Art of Project Management by Scott Berkun

4 You have to know when to stop.

5 Number vary, but standish offered these: 31% are cancelled before completion, and 22% slip their schedules. Most of them had problems with their foundations.

I don’t stop searching for a needle in the haystack, even if I’ve already found one.
— Thomas EdisonThe scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.
— Nikola Tesla