People who put the needs of their coworkers ahead of their own, empathize and understand their customers, seek out win-win partnerships with their suppliers, and err on the side of the betterment of the group versus making their work easier, create exponential value.

Sure, people who focus on me, myself and I, can get things done, especially if they are highly skilled. But they can’t multiply that value.

Something to keep in mind when making compensation decisions.

We are efficient and have no further improvements to make.

- EQUALS -

We have no idea if we are efficient or not.

Only by continuously focussing on efficiency, constantly having improvements to make, making them, and then identifying the next improvement, could one say “we are efficient” with the added caveat “and this is what we are doing next to stay that way”.

Alarms should sound when you hear “we are efficient and have no further improvements to make”.

Iterative or rapid software development means you know exactly what you want, you have defined it extremely well, and are disciplined enough to pick from those specs what should be built in the first, small, iteration.

It doesn’t mean that you can get away with waiting to see if what you get is what you might like, or poorly describing what you want, or starting anywhere without a strategic plan for how you are going to move through the project.

Iterative or rapid software development isn’t an excuse for relaxed product ownership, on the contrary, the exact opposite is true. Things happen so fast you had better be on your game or you will quickly spiral out of control and write off your investment to date.

Every project should have a go / no go decision right at the start, that includes at the very least the following criteria:

Do it right, or don’t do it at all.

If you don’t know what you want, then don’t expect anyone else to either.

Which leads back to the first point.

Doing small software iterations, frequent releases, a little bit at a time, could go one of two ways.

Scope out too much and to keep the release on schedule skimp on the design and implementation, or even worse – quality assurance.

- or -

Scope out just the right amount and put the full press into design, implementation and quality assurance.

Both could equal a couple of weeks work, but one is a building block, and the other a throw away.

Everything you take on is forever. Regardless of whether you delegate it or not.

Therefore:

• Choose Wisely
• Simplify
• Eliminate

Such that whatever “it” is gets all of the attention “it” needs. If you can’t give that amount of focus, don’t do “it”.

Free software isn’t bad business. Losing money is bad business. If free enables you to make money through supporting services, advertising or premium upgrade sales, and it eliminates all of the complexities of your sales and marketing effort (lowers your costs!) then that sounds like great business to me.

Supporting yesterday, legacy product, does nothing for you or your client in the long run. It squanders your resource pool on the same old rather than innovation and change and it dooms your product to obsolescence in time. Not good for you or your user. Build for tomorrow.

To really innovate you need to ship software at least every couple of weeks. Get it out there, get feedback, adjust, and ship again. If you can’t ship this fast it isn’t a development problem. It is a management problem. Know exactly what you want. Pick the most important thing to do. Build it. Ship it. Stop asking for everything but the kitchen sink.

If you can’t trust your employees to work from home I think that might be the tell tale, tip of the iceberg, for much bigger problems.