It was one of my favorite rooms ever. The sound was that of whirring floppy drives – and it had that delicious, though faint smell of 1980’s electronics. The room was clean, and probably fairly recently carpeted and painted. And entering it felt like entering a spaceship and departing on a journey to exciting and unknown places. It was the computer room at the youth center on the Army base in Berlin, Germany. The room was empty in the center with computers on the walls so that you were seated facing the walls.

Maria ran the computer room – she introduced us to all the unique and exciting experiences held just beneath the keyboard of the Apple ][. Things that you might not discover – like the fact that there were multiple versions of the BASIC programming language floating around. Or the power of the GOTO keyword.

It was around this time that I reached the pinnacle of my programming career. I made the machine print “Kyle is Cool” over, and over, and over, and over again.

So.

Epic.

“Making the machine do something” is really the fun of it. And the more complex and interesting, the more fun the experience is.

Though we all realize at some point that there’s a level of complication and sophistication, no matter how clever we are as individuals, where working as an individual maxes out and working with a team begins to appeal.

And this is where Systems Thinking becomes IMMEDIATELY valuable. We may not realize we are doing it at first, and there is an infinite world of connections and systems to explore and to manipulate to help create better software. But one way or another, thinking of the people building the software and the way they’re arranged and working together is a powerful tool, even if the primary system you are passionate about is the one turning ones and zeroes into useful behaviors.

The Downside

Over the years I’ve seen examples of the human system not working to its own advantage – but one case stands out to me. And the thing that should be noted about this is how far out of the immediate day-to-day situation the system extends. So pay particular attention to that as we dive in…

I was on a small team of developers – there were four or five of us delivering software together. We weren’t an ideal team but we generally worked well toward common goals.

At the highest levels of the organization – probably four to five management levels above my teammates and I – a decision was made to use a performance management system that included the usual unfortunate cliches. Most importantly it included a feature that was regularly trumpeted during “town halls” and other communications – pay for performance. “He (or she) with the best list of accomplishments in the previous year, gets the most money”.

The effect was powerful..and not in a good way.

Team members began making decisions that buoyed the initiatives that they most wanted on their list of accomplishments. At the team, day-to-day level. Instead of working to arrive at common goals and then pushing toward them together, the environment became immediately individualistic.

This is one of the most common ways that corporate environments can ruin software delivery. And I have discussed it in depth, from a philosophical perspective in https://softwareforprofit.com/2019/09/12/killing-software-development-capacity-part-1-the-performance-review/.

But more importantly, the take-away from this practical situation is how broad the “System” is that you participate in. And how easy it is to maul a software team with the axe of good intentions.

The Upside

To use Systems Thinking to your advantage you have to realize several basic truths. The first of these is that there are truths. There is an underlying reality in the way that humans work together and think together. And that reality is expressed in fairly predictable ways in software development

The second, though, is that when it comes to actually creating software, it’s almost impossible to predict. And because of this…

The third thing is that the primary principle to build into a software team is distributed authority. Make the teams small and skilled and let them make their own choices about how to deliver. Because there will always necessarily be too much information to funnel through any information bottlenecks (see “Managers” – also see: https://softwareforprofit.com/2019/10/05/what-are-managers-good-for-anyway-the-role-of-leadership-in-software-development/)

And the final thing is realizing that skilled means skill with the computer system and skill with the people system. People that can make the computer do something are a dime a dozen. People that can work with other people to make a computer do something – those are the gems. Build a team of gems and ensure that the loosest possible guardrails are in place.

And then just sit back and watch the magic happen…