I had a small epiphany about the organization structure at my place of work (big financial institution). Many of the managers are non-technical (no surprise there) and have a technical “lieutenant” that they depend on for technical matters. They routinely pass all the significant technical concerns to this single trusted lieutenant.
Arguably this is just practical delegation, or a natural result of the two “tracks” of promotion (technical and management). Regardless, it’s funny (both “ha ha” and weird) now that I see it that way. Being technical, the lieutenants often don’t share the same viewpoint (having been shaped by personal experiences and plain bias). Yet the lieutenants have their respective captain’s ear, and indirectly shape debate at a higher level.
Even when instructed to collaborate, lieutenants may not come to meaningful agreement/compromise. There’s no responsibility to a common superior, so it can easily become a form of “he said, she said”. In theory, there is a common superior if you follow the organization tree high enough, but even in that case, the dilution effect of the true and complete intent from “flowing” through even two different people is significant.
To put it a different way, it seems that every non-technical manager recognizes their deficiency and picks up the best techie they can find to use as their tech “shield/sword/hammer”. Yet the efficacy of these techies collaborating is greatly reduced compared to a typical tech team because their responsibility to each other is so indirect and dilute.
It seems like it’d be better that as managers have their own tree, the techies should have their own as well. Then at least you’d have the people who would naturally need to deal with each other more often (business to business, management to management, tech to tech) closely aligned in interest. An analogy would be like painting: your basic resources (colours) are pooled homogeneously first; after you determine your needs, you take what you need and put it into a palette for mixing. The current system feels more like having been dealt random colours on various palettes, leaving you holding too many palettes to manage at once.
Hmm… come to think of it, that’s exactly what Microsoft does with their system of three. A Program Manager, a Developer, and a Test resource to work on a feature, yet each reports to their own hierarchy. I guess other people have grasped this idea better than I have (given my disjointed explanation). Too bad I’ve yet to find literature that encapsulates this eloquently.
