Agile of the Avengers - The myth of flat hierarchies and T-shaped engineers
The world is changing fast and so is the world of Agile. The Agile I had experienced when I worked as programmer at my last IT firm was more about project management and successful completion of a release through the phases of development and testing to delivery and support. There was a healthy collaboration between team members of a project that worked really well but command chain was still there. Developers and Testers still had to report to their Project Manager (PM). The PMs further reported to their seniors in the firm until the chain ended at VP (Operations). Our client was a company located abroad and the stakeholders communicated through emails and Skype.
To the best of my knowledge, that firm still works in a similar way and perhaps so do many other Indian IT services companies. However, the modernists of the West seem to prefer a new Agile model these days, one that entirely eliminates the command chain. Yes, I'm talking about flat hierarchy organizations. In theory, this model aims at keeping few or no levels of middle management but in practice, the enthusiasts are wildly celebrating on twitter about the fact that they've eliminated the command chain entirely and that employees in their firms have no titles at all!
There are all kinds of "Agile Consultants" too who are making these wild claims citing companies like Spotify and Toyota who they claim work on this new flat hierarchy model. The problem with this model is that it assumes the existence of T-shaped person who is skilled in both technical and managerial crafts.
I don't know how successful this model has been so far but reducing all the complexities and intricacies of project management into this one T-shaped skill doesn't seem like a good idea. This arrangement assumes an Avenger kind of hero who not only has expertise in his own skills (like inventing robots or breaking large cement blocks!) but also has the effective and mature skill to communicate and coordinate with other Avengers in the team, this naturally eliminates the need for a coordinator or leader entirely.
But from what I remember, even Avengers ceded the leadership control briefly to Captain America in the first Avengers film! Its impossible to work without a leader for longer duration of time and especially at scale. In practice, most engineers are never T-shaped. Yes, you can build a sophisticated think-tank composed of creamiest of MIT/IIT/Harvard graduates who can all be T-shaped individuals but the average engineer doesn't work like that.
T-Shaped simply means "Jack of all and Master of one" because there is one main skill like programming or testing plus a broad array of incompetence in multiple other skills like coordination, communication, human resources, project management, etc. That sounds great in theory but in practice, everyone knows how difficult it is for a coder to wear the hat of a project manager or for a domain expert to wear the hat of a tester. They might pretend to get "interested" about the other person's craft but there are limitations to how well they can perform, skills aren't really exchangeable or fungible in that way.
The keywords here are complexity and scale. In a small project at a small startup, the team members can perhaps get away without a coordinator though there could be tricky situations there too. For example, what happens when two members run into a conflict? Coder-A wants to have his way of a short and high-performance recursive function but Coder-B has come up with a more lengthy but readable approach. Now, who will resolve this conflict and who's version will be merged in the app's code-base? Similarly, a tester may run into a conflict with designer regarding what to put in a test case. The client doesn't care with either approach and is fine with whatever, so we've again run into a conflict. There could be 100s of scenarios like these which require centralized coordination even in a small project, I can go on and on.
The T-shaped myth also assumes that most engineers have leadership skill intrinsic in them but that's simply not true. Most engineers simply don't care about what's going on in the rest of the project, they are typically sitting at their desks buried in their own "muse", be it about coding or testing or design. Engineers being engineers, they are more likely to grab a popcorn and watch the show rather than jump into a running conflict and try to resolve it! Bystander effect is most commonly found in techies.
But when you bring complexity and scale into the picture, things get really out of hands and T-shaped just turns out to be a pipe dream. Most Indian IT Services firms are large scale in nature, they hire thousands of engineers who work in all kinds of projects across multiple locations. Its impossible to miraculously turn such large numbers into T-Shaped individuals, they simply aren't trained to think in that manner. People often dislike and complain about the bureaucracy in these companies but its there for a reason. As the complexity increases, you must manage costs of running the project, negotiate quotations and release dates with the client, track milestones and deliveries, negotiate appraisals and salaries with team members, manage their leaves, etc. which is a job in itself, however bureaucratic and thankless it may be. And this is a specialized project management job that requires an expert, not something you can just delegate away to a T-shaped person.
However excited the world of Agile consultants may be about this flat-hierarchy, it just seems like a pipe dream to me given the current situation and conditions. Were you able to successfully implement a flat-hierarchy system in your organization? Do let me know in comments.
To the best of my knowledge, that firm still works in a similar way and perhaps so do many other Indian IT services companies. However, the modernists of the West seem to prefer a new Agile model these days, one that entirely eliminates the command chain. Yes, I'm talking about flat hierarchy organizations. In theory, this model aims at keeping few or no levels of middle management but in practice, the enthusiasts are wildly celebrating on twitter about the fact that they've eliminated the command chain entirely and that employees in their firms have no titles at all!
There are all kinds of "Agile Consultants" too who are making these wild claims citing companies like Spotify and Toyota who they claim work on this new flat hierarchy model. The problem with this model is that it assumes the existence of T-shaped person who is skilled in both technical and managerial crafts.
I don't know how successful this model has been so far but reducing all the complexities and intricacies of project management into this one T-shaped skill doesn't seem like a good idea. This arrangement assumes an Avenger kind of hero who not only has expertise in his own skills (like inventing robots or breaking large cement blocks!) but also has the effective and mature skill to communicate and coordinate with other Avengers in the team, this naturally eliminates the need for a coordinator or leader entirely.
T-Shaped simply means "Jack of all and Master of one" because there is one main skill like programming or testing plus a broad array of incompetence in multiple other skills like coordination, communication, human resources, project management, etc. That sounds great in theory but in practice, everyone knows how difficult it is for a coder to wear the hat of a project manager or for a domain expert to wear the hat of a tester. They might pretend to get "interested" about the other person's craft but there are limitations to how well they can perform, skills aren't really exchangeable or fungible in that way.
The keywords here are complexity and scale. In a small project at a small startup, the team members can perhaps get away without a coordinator though there could be tricky situations there too. For example, what happens when two members run into a conflict? Coder-A wants to have his way of a short and high-performance recursive function but Coder-B has come up with a more lengthy but readable approach. Now, who will resolve this conflict and who's version will be merged in the app's code-base? Similarly, a tester may run into a conflict with designer regarding what to put in a test case. The client doesn't care with either approach and is fine with whatever, so we've again run into a conflict. There could be 100s of scenarios like these which require centralized coordination even in a small project, I can go on and on.
The T-shaped myth also assumes that most engineers have leadership skill intrinsic in them but that's simply not true. Most engineers simply don't care about what's going on in the rest of the project, they are typically sitting at their desks buried in their own "muse", be it about coding or testing or design. Engineers being engineers, they are more likely to grab a popcorn and watch the show rather than jump into a running conflict and try to resolve it! Bystander effect is most commonly found in techies.
But when you bring complexity and scale into the picture, things get really out of hands and T-shaped just turns out to be a pipe dream. Most Indian IT Services firms are large scale in nature, they hire thousands of engineers who work in all kinds of projects across multiple locations. Its impossible to miraculously turn such large numbers into T-Shaped individuals, they simply aren't trained to think in that manner. People often dislike and complain about the bureaucracy in these companies but its there for a reason. As the complexity increases, you must manage costs of running the project, negotiate quotations and release dates with the client, track milestones and deliveries, negotiate appraisals and salaries with team members, manage their leaves, etc. which is a job in itself, however bureaucratic and thankless it may be. And this is a specialized project management job that requires an expert, not something you can just delegate away to a T-shaped person.
However excited the world of Agile consultants may be about this flat-hierarchy, it just seems like a pipe dream to me given the current situation and conditions. Were you able to successfully implement a flat-hierarchy system in your organization? Do let me know in comments.
Comments
Post a Comment