Darwinian Crucibles Part 5
Which Model?
Having thought about the options, you have to make some choices now.
Should competing teams even know about each other? If they know, this could seriously affect their motivation. Of course, storytelling could come back in play here. If people know they are part of an experiment, will they change their behaviour? Could you introduce Heisenbugs into your elaborate system of technology and psychology?
The problem is, if you chose to orchestrate from above, in a picture so big, you think you can separate teams far enough apart they won’t be aware of each other’s work, when and if people find out, some, maybe many are going to become disillusioned. Is not telling people just an excuse for reducing the risk of exposing flaws in the scheme? Could you lose hearts and minds? Maybe you could.
Personally, I believe transparency and measurement is the key. Separation only has utility in unusual scenarios. If you can setup an approach people can feel part of, and you can start to measure success then the system can develop positive feedback. The risk is, metrics lose meaning, becoming misleading proxies for what is actually going on. Jeff Bezos has an interesting take on the risk of proxies for the most valuable notion of all; what customers want. And this is where you really have to dig deep into the core of your management style and ask yourself how you want to manage people.
The objectively correct approach here (if it exists) is not relevant because it could simply be your intuitive (if there is insufficient data, or, you just function that way) choice. The risk for senior leadership is you may not get challenged on these activities that carry serious latent risk. These risks exist, occluded under the guise of trying to cleverly develop emergent behaviour.
If you sit above hundreds or thousands of people, do you believe you (or at a stretch, you and your directs) have a greater intellectual compute power than your whole team?
However, it could be a false syllogism to say more brains on any problem are always better, execution is difficult for a few, therefore more brains will solve a problem better than a few. The leadership team have experience and judgement. And, per most organisations, the top level want to give direction to a small collective, who in turn are supposed to fan out the approach to the larger organisation.
Maybe when DAOs become a practical reality, this could change. Distributed, creative, variable, unpredictable but ultimately a combined mesh of experience and wisdom that can line up without endless rounds of politics could be a very interesting new business model. A bit like consensus building with blockchain miners. Another story.
If you isolate teams, even if they know about each other, it really could blow up in your face. The team that feels they are on the losing side could lose all motivation and just leave. If you have many teams, where some are separate tasks and there are some projects that have multiple approaches, keeping the entropy down could require more energy than you can give it.
Making it Work
Photo by T.H. Chia on Unsplash
One way to setup multiple teams for one problem is to keep it simple.
Say you have 2 teams. Both are working on the same problem, but with a different focus. A hard problem may be broken down into multiple smaller hard problems. So as long as each team cracks a different hard problem and the two solutions can work together then having some swarf may be worth it.
When both teams are working on the same problem, another way to be open is gamify it. Everyone knows the goal and the winning team gets a prize. It is extremely important everyone gets recognition and there is no punitive treatment for the other team(s). Everyone competing can work. Though fatigue and burnout can result if the approach is run for too long. When applied in a timely and appropriate approach, the overall prize is friendly competition, team bonding, skill development. Some developers love a difficult challenge, “just ask me to do the impossible and I will find you a way…”
This competitive environment is a potentially a high energy melting pot. Maybe not the place for teams with middle town dreams. Such teams may be the operational bedrock of any organisation. While some other teams may hunger for the alternative, some may find it deeply uncomfortable.
In your role, it’s your judgement where to disrupt and direct novel approaches. And to be ready for fallout.
Back to metrics; is there a net gain in your true metrics? At the level of fostering healthy competition, in general, find or build teams who will love the challenge, sharpen under the stress, relish a win in the spirit of the work and not too much in crossing the finish line slightly ahead.
Incentive
How can you reward a competitive endeavour?
20% time could work. The freedom to think and work unconstrained can be very attractive to some.
Maybe funding for side projects would meet the interests of the more entrepreneurial minded.
Training is a motivator for some. The acquisition of knowledge is definitely a bed rock of all successful teams. But you can’t force it. Sending everyone on a course guarantees nothing.
Conferences are one way to achieve wide spread of new information, though, again, they have to want it. Although conferences are more likely to be virtual now.
Another approach is bringing new experts into a team. This can reduce net stress and increase a sense of inner strength.Many teams may realise their own short comings on technical topics. How many times have you heard some say words to the effect of, “well I can do it, but I am not an expert…” It is too easy to nod and trust, without understand the risk and debt you are creating. Bring in a Dev Ops guru, maybe a networking expert, maybe a mathematician. Depends on the team. Let them see you value their strengths as well as their flexibility.
Sabbaticals to study or a chance to take time with family can be motivating. Stepping back and catching up on the latest development in technology could be a highly therapeutic process.
Flexible working is more and more a staple but bring this wider. Let people work where and how they like. Let people bring their own equipment, albeit with security caveats.
Choice of developer and software tools can help a lot. Do you really need to standardise every single tool? I remember vividly thinking I needed to tow the party line on some software tool even though it eventually became clear it was inferior to the market leader. Developers hate working with sub-standard tools. In hindsight this was deeply foolish and ill considered.
Kit is key. Do you want to foist a mediocre but corporate safe choice on your team? Procurement and some IT teams are happy and nobody else is. Is that a good situation? The computer is a tool that developers use 8 hours a day minimum. Do you really think an under specified machine with maybe an over restricted build (there is security and there are hand-cuffs, be thoughtful) is not going to have an impact? Think saving a few bucks on CPU and memory is not going to impact productivity? This is what happens when pure cost-based management rules. In this area, can you find the true metrics and see the impact of your decisions? Maybe just listen to your teams on this.
Even for heavy users of Office 365, a suitable machine and build makes a lot of difference. The office experience can be highly frustrating if the environment does not perform. Basic productivity tools need to work seamlessly. Whatever they are.
Finally (for this short list) is the possibility of secondment to somewhere new and fun. Some people thrive on change and variation. Some hate it.
Corporate constraint can be a millstone. On reward, let your imagination work.
To be continued…
