Originally posted at mcod3.wordpress.com
I have worked at several companies now that have a ‘technical authority’, but to this day I have never seen their purpose.
What is a Technical Authority?
A technical authority is a group of senior and lead developers (usually those the management like, rather than actual competence or knowledge) whose purpose is to oversee all technical decisions made by the developers.
Great idea, surely?
I agree that ensuring the company follows a standard line is a good idea. A decision check can quickly highlight if a similar problem has been previously encountered and therefore if it’s already been solved. No point reinventing the wheel.
I agree some oversight across the development field of multiple projects is a good idea. It allows knowledge sharing and again…no point reinventing the wheel.
So what is your darn problem?
Well simply put the Technical Authority is a redundant entity that actually slows progress and makes developers feel undervalued.
Management already have an oversight of all projects
Each project usually has its own technical lead…are they not trusted to make the decision. After all if every project were the same developers would be a redundant job title and adequate library gatherer would be the industry bread and butter.
The Technical Authority meet infrequently (somewhere between once a week and once a month) so awaiting their decision stops progress, especially if it’s a topic requiring further discussion and so spanning multiple meetings.
Whilst it is believed developers are extremely intervert they do actually communicate, and on technical matters become extravert.
A proposal or other documentation usually needs preparing for the authority to scrutinise and ponder. Along with the obligatory ‘please add to agenda’ email.
Not all technical leads are part of the authority…so who is actually leading?
But the big one
It’s often said that the purpose of the technical authority is to ensure that the latest technical approach is in use.
So the company is essentially saying they only trust a select few to keep up with current industry standards, trends and thoughts. Only the technical authority know if it’s appropriate to use approach A for problem Q that they’re only seeing from a brief description and possibly quick overview from the tech lead.
They’re saying the tech lead isn’t leading anything other than discussion with the authority. They’re saying the developer is just a keyboard cruncher.
The reality
The developer knows exactly what they are doing. The development function is a community, it helps each other, it takes the piss out of each other, it shares information and insights, it discusses the latest moves in the industry, it learns as one.
A technical lead will sign off on well thought out and reasoned approach immediately and not bother the authority with it at all. If it’s an approach that seems sane but gives the lead that niggling feeling then it might be mentioned at the next authority meeting, and then only if that particular lead is part of the authority.
Problems will be anticipated by a decent developer long before encountered, so will have been researched and probably prototyped (most likely in the developers own time) for a while before the problem occurs, by which time the developer is pretty confident with their approach, why break that trail of thought waiting for the authority to research it all over again.
The technical authority are still human, they haven’t encountered every problem before. They are not an all knowing being with an immediate answer
Top comments (2)
Take away the "(usually those the management like, rather than actual competence or knowledge)" part and the structure makes good sense to me.
Who else would ensure developers are making stuff in a way that caters to the business case? I mean it's not feasible to include all developers in every business decision and related meeting?
I've tried not having teck' leads, and the anarchy was really hard to deal with.
I would make a feature, and include a cool tool, so would my mate, and all of the sudden we had an application soup that was impossible to maintain.
Also, the bigger the team the worse the soup... :I