Tech Lead - I do not think it means what you think it means.

    A bit of wisdom from Inigo Montoya for the title of this post. And a bit more wisdom from the Agile Manifesto to ease us into things; "The best architectures, requirements, and designs emerge from self-organizing teams." The line in the title is borrowed from The Princess Bride circa1987, and the Agile Manifesto from 2001, which at the time of this writing, is nearly a decade and a half past.
    A part of much more recent internet history is an article published by InfoQ on my 40th birthday that brilliantly details the concepts of self organizing teams and the broader topic of self-organizing systems. The same article also notes that we basically have no idea yet how to make and support these self-organizing teams. One has to wonder how, given the proliferation of Agile both as a software approach and marketing buzzword, we still haven't figured out this silly self-organizing team thing.

    Welcome to the enterprise software terrordome. Organizations with long standing cultures built on hierarchy at all levels aren't about to just let teams of professionals run rampant. As they've "gone Agile" these companies lost the managerial relationship with developers once held by a proper manager hovering over a row of cubicles. A manager who had paid her dues and was properly institutionalized. What to do? They can't leave real, direct managers in place, because that's not Agile. But they darn sure can't let developers run themselves either. Imagine the chaos that would ensue if a bunch of math, science, and engineering minded individuals were allowed to sort things out themselves. I shudder at the thought of the efficiency and common sense that would linger like a dark cloud over the whole situation.
    Alas, the modern Tech Lead role was born. If there cannot be a manager then there must be some acceptable proxy who can keep an eye on things. To loosely employ Anais Nin, they needed a spy in the house of software. Having served in the Tech Lead role on many teams for many years, what I can honestly offer is that a Tech Lead is the more modern, more technically qualified, incarnation of a manager. Somewhere around the third time I fell for the "50% time coding and 50% time performing other duties" farce, I got the point.
    The existence of these Tech Leads is an organizational crutch. One of many clear signs that we have not yet realized the vision laid out before us in 2001. You see, teams know quite well how to interface with each other and who the experts are on the team. Developers learn quickly who has answers and who they are actually following, generally based on a belief that those surreptitious leaders are technically capable and will provide a fruitful path. It is the broader organization that does not know how to interface with teams, and therefore installs a Tech Lead rather than learning how to work in this way.
    There are some unpleasant side effects that occur as a result. Problems that should be owned by all team members become Tech Lead problems. Decisions that should be whole team decisions become Tech Lead decisions. Evaluation of team members inevitably get proxied through the Tech Lead instead of being managed by the team themselves. The wisdom of crowds is lost. The virtuously lazy nature of humanity kicks in and the whole notion of a team working as equals toward a goal goes right out the window. I could go on...
    I say a good Tech Lead, a really truly good Tech Lead, who is focused advancing our profession and doing what is right, is trying to figure out how to eliminate the need for their role. It would be easy to say this is the responsibility of the companies we serve, but it won't get us the outcome we desire. It's on us, Tech Leads, to teach the people around us how not to need us. Then we'll have really done something.