I am a jack-of-all-trades. Admittedly — and proudly — I realize that a lifelong series of trial and error, crash courses, evening reading and incurable curiosity have resulted in this ability to do many things — especially things involving some manual work. I feel self-satisfaction to think about all the situations that could arise in which I would know what to do, and how to do it. I can help someone fix a kitchen sink on a Sunday afternoon. I can drive a snowmobile, sail a catamaran, or connect a portable gasoline generator to your house. My varied skill-set affords me a serene feeling of power over the random hazards of life. That, and it’s also lots of fun to do different things.
There is currently an interesting trend in many organizations to favour highly autonomous teams. The rational is quite simple: autonomy often translates to an accrued operational leeway that offers a better breeding ground for innovation. By not being weighed down by other teams, there’s a hope that the group will perform better and yield more innovative ideas. There is also the expectation that the team, using an Agile™ method, will produce tangible implementations much faster if it can be left alone. The justification is founded in the belief that small teams perform better. Makes sense: the smaller the team, the easier the communication, and we all know that ineffective communication is a major source of inefficiency — in IT as well as in any other field. And if you want your team to be autonomous and composed of as few individuals as possible, then there is a very good chance that you need multi-skilled resources.
Jacks-Of-All-Trades and Interchangeable Roles
You need jacks-of-all-trades or else either the number of individuals will increase or you will need to interact with other teams that have some of the required skills to get the job done. As a result, you will not be as autonomous as you’d like.
But there is more: the sole presence of multi-skilled individuals is not enough to keep your team small and efficient in yielding visible results at an acceptable pace. You must have an operating rule that all individuals are interchangeable in their roles. If Judy —a highly skilled business analyst— is not available in the next two days to work on sketching the revamped process flow, then Imad —a less skilled business analyst, but a highly motivated jack-of-all-trades nevertheless— needs to take that ball and run with it. You need multi-skilled resources and interchangeable roles. That’s all pretty basic and understandable, and your organization might already have these types of teams in action.
For a small and autonomous team to keep its low size and independence upon others, it needs to be made of jacks-of-all-trades and roles must be interchangeable, or else it will either grow in size or depend on outsiders.
Conflicts of Roles in Small Autonomous Teams
Before you declare victory or you rush into hiring a bunch of graduates with a major in all-trades resourcefulness and let them loose on a green field of innovation turf, read what follows so that you also put into place the proper boundaries. If you want to ensure maximum levels of quality and sustainability of what comes out of small, autonomous, multi-skilled teams, you need to ensure that there are no conflicting roles put on the shoulders of the individuals that need to juggle them.
Conflicts of role occur when the same person needs to do work that should normally be assigned to different persons. The most obvious —and, in corporate IT, the most abused — combination of conflicting roles, is creating something and quality controlling that same thing. This can be said of any field, really — not just IT. Industrial production process designers have understood for centuries now that he who quality checks should never be the one that is being checked. Easily solved, might you think. You just need to have Judy check Imad’s work in two days when she’s available, and the issue is solved! Maybe —but there’s a catch.
No Accountability and No Independence
Proper quality control requires at least one of these two conditions: (a) the person being checked and the controller must be both accountable for the level of quality of the work, or else (b) the person doing the quality control must be able to perform the reviews independently. If Imad and Judy are both part of a team that is measured on the speed at which it delivers innovative solutions that work, then there is a good chance that quality is reduced to having a solution that works, period. Other quality criteria are undoubtedly agreed upon virtues that no-one is against, but are not as important as speed. As described in another article, in IT more than any other field, a working solution might be ‘under-the-hood’ a chaotic technical collage, hardly holding itself with haywire and duct tape— but it can still work.
These situations often occur when IT staff are put under pressure and are forced to cut corners. As such, speed of delivery becomes in direct competition with quality when assigning the person hours required to deliver excellence. If the small, autonomous, multi-skilled team’s ultimate success criterion is speed, then Judy’s check on Imad’s work is jeopardized if the quality of his work has no impact on speed. In this case, because Judy and Imad are both part of a group that must deliver with speed, then none of them is really accountable for any other quality criterion than simply have that thing work. As long as it doesn’t impede delivery pace, any other quality criterion is just an agreeable and desirable virtue, but nothing more. Judy is not totally independent in her quality control role and worse, there is no accountability regarding quality.
When a small and autonomous team’s main objective is to deliver fast, any quality item that has no immediate impact on speed of delivery becomes secondary, and no-one is accountable for it.
And it doesn’t stop there: considering that quality control takes time, the actual chore of checking for quality comes in direct conflict with speed, since valuable time from multi-skilled people will be needed to ensure quality compliance. After two days, when she becomes available, Judy could check on Imad’s work, yes, but she could also start to work on the next iteration, thus helping the team run faster. If no-one is accountable for quality, Judy’s oversight will soon be forgotten. Quality is continuously jeopardized, and in your autonomous teams there is a fertile soil for the systematic creation of lower quality work.
There’s No Magic Solution: Make Them Accountable or Use Outsiders
So, what precautions must be taken to ensure maximum levels of quality in multi-skilled, autonomous teams? The answer is obvious: either (1) the whole team must be clearly held accountable for all aspects of the work —including quality— or (2) potentially conflicting role assignments have to be given to individuals who are independent; that is accountable and measured on the work they do, not for the team’s performance.
If you go with the first option, beware of not getting trapped into conflicting accountabilities again, and read this article to understand how quality can be challenged by how it is measured. To achieve independence (second option), you will require having team members report to some other cross-functional team, or allow an infringement to your hopes of total autonomy by relying on outsiders. Although multi-skilled and autonomous teams are an enticing perspective for jacks-of-all-trades, the agility they bring to the team should not be embraced at the expense of the quality of the assets you harvest from them.
Lower Quality at Scale
If you want to understand how and why unwanted behaviors such as those depicted above are not only affecting small autonomous teams, but are also transforming the whole of corporate IT into a mass complexity-generating machine that slows down business, read this mind-changing book. It will help you understand why lower quality work products are bound to be created, not only in small, autonomous and innovation-centric teams, but almost everywhere in your IT function.