Previous: Software Is Not The Product

If we stipulate that we need the following to make a good developer:

an excellent communicator	a first-principles thinker	a business and process polyglot
an iconoclastic investigator	a problem solver	an inventor
an adaptable antagonist	an inquisitive idealogue	a courageous fighter
an advocate and peer leader	tenacious	a creative problem solver
an intel collector	a time manager	platforms experience
a knowledge of data sources	skill in using logic tools	experience in development environments
exposure and comfort in systems and enterprise architecture	use and understanding of prototyping and testing frameworks	and somewhere between six and twelve computer coding languages

What else do we need?

We need a plan to take these ingredients and bake the best developer cake ever.

The picture on the side of the chocolate cake mix in the supermarket only hints at what a good baker might produce should they use the ingredients in the box (along with others not supplied). Yet, most non-technical managers act as if they could take the dry ingredients and just pour some on each plate and then act as if it’s the same as baking a cake.

Don’t be surprised when you have dinner at the manager’s house.

What’s the Plan, Then?

We stipulate that the best candidates, even the new hires, occupy those technical positions. Whether hiring senior or junior developers, two of the 12 Agile Principles come to mind:

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The best architectures, requirements, and designs emerge from self-organizing teams.

In this context, how best can we interpret and implement practices to support these two principles?

Software developers don’t think like managers. If they did, they’d know how to avoid the majority nonsense managers shovel into their personal spaces.

The phrase, “the environment and support“ rarely gets mention. Most assume this phrase means some kind of physical environment or maybe the hardware, software, or even frameworks. These are all fundamental to software development, sure. But developers need more: they need people around them they can trust, know they can build quality, and work as a single unit.

Which brings up the constantly-flogged phrase, “self-organizing teams.” Managers mis-play this phrase every time. Since managers think like managers, they interpret it like a manager would and say that we need to let the individuals pick their own titles and responsibilities from the org chart. What tosh.

Software developers don’t think like managers. If they did, they’d know how to avoid the majority nonsense managers shovel into their personal spaces. Self-organizing can only help a group of software developers if they organize around the following:

• Everyone knows everyone else’s abilities
• Everyone trusts those abilities
• Everyone constantly improves
• Everyone constantly learns to lead and learns to follow
• Everyone feels safe being protected by the others
• Everyone bears the responsibility for keeping the others safe
• Everyone watches out for the emotional stability of the others
• Everyone stays open to input from the others

This is the environment and support they need.

This is self-organizing.

And the plan must guide the entire group to a place where all have known and growing skills, have experience (or else the group commits to support where the individual may be lacking and dedicates time to grow that individual’s skills), train together in such a way that all gaps are known and training exists to fill them, and the psychological and emotional comfort of the group derives from the safety found in the group.

Next: The Plan