I spent last week in Malmo speaking at the øredev software developers conference. I was a bit dubious as to how relevant presentations on surviving as a change agent or diversity of thought would be to the assembled coders and programmers. Not only was I wrong about their appetite for learning how to be a more effective rebel at work but, more important, I learned a lot from them about how to manage teams in more effective ways. At the risk of embarrassing myself with my ignorance about modern approaches to software development, I can report that the developer community appears to be some distance ahead of many other work domains in rethinking how to manage teams.

Much software demands continuous updating. And old styles of project management simply can’t handle that speed of flow. Stopping work for quality control purposes is just not tenable in an era of continuous development. (And in any case, such control doesn’t actually lead to quality. Chokepoints such as software approval boards, for example, don’t actually correlate with more quality.)

Even when I was a manager of analysis at the CIA, it occurred to me that the supposed need for quality control from managers usually stalled the entire sensemaking process. This could get pretty bad when a manager “sat on the product”, taking days if not weeks to judge it worthwhile. One of my “rebel” ideas was to wonder if we could ensure quality without a linear editorial process. The software community has made much more progress than I ever did.

Instead of the linear “waterfall” process, which many organizations still employ today, the favored approach to software development is agile, which stresses simultaneous work across many streams. Work is managed more collaboratively within a team using approaches such as Kanban and Scrum. I would just reveal even more of my ignorance if I tried to explain these concepts in any depth, so check out articles such as this one. The relevance for rebels at work is that agile approaches should make it easier for team members to offer up new and different ideas. That’s certainly the hope.

Some of my favorite takeaways from the conference, in no particular order.

Striving for 100% efficiency in utilization of resources just leads to more mistakes. Several presenters made this point, which reminded me of the cult of “busyness” we find in so many organizations. Google for example, expects its staff members to meet 70% of their key objectives. Demanding much more stifles innovation and flexibility. Overcommitment to goals is not healthy.

I was introduced to Brook’s Law, which states that adding more people to a late project only makes it later. What a gem! Adding more people just creates more handoffs, more ignorance, more backbriefing, etc. So many organizations panic and make this mistake.

You can have too much micromanagement, But you can also have too much servant leadership as well. This chart from a presentation by Pete Behrens illustrates the happy medium of management styles.

The things people do in an organization tend to get mirrored in its software code. One presenter noted that he can identify healthy or sick organizations just by looking at the software code of their key processes. That was fascinating and I wondered whether in fact sort of the reverse might be true. Can you change organizational culture by adopting new software programs? I wonder.

And my favorite

The courage to not know nurtures team agility and growth. I think this also came from Pete Behrens’ presentation. When team leaders or scrum masters hesitate to answer questions, they provide others on the team the opportunity to teach. Silence can also be an important superpower for rebels at work. Ask yourself if you give your colleagues enough opportunity to contribute their ideas. Or do you always dominate the conversation with your brilliant thoughts?

Here’s a handy term to recall when you feel yourself sucking the air out of the room.

W.A.I.T: Why Am I Talking.