What do I mean by TDA?

A Technical Design Authority (TDA) is a forum where architects get together and authorise changes to the estate, typically in medium or large companies.

 

What is the positive intention of a TDA?

• Feedback – Creates a forum for people with knowledge of the tech and the estate to foresee potential problems before they occur and give the team a chance to correct early.
• Transparency – Being open about the solutions and design being created with the relevant personnel.
• Risk – Reduces risk by inspection of competent individuals.

 

Why is a TDA bad?

• The key is in the name Authority, a TDA typically revolves around approval, it blocks delivery, the flow of product into customers hands. Stops or slows the value stream.
• The word Authority is an indicator of the behaviours we see. Almost policemen like stopping teams and individuals from progressing. The attitude should be more like a traffic officer helping the teams think about their design and setting the direction or a support group where you come to discuss your challenges with people who also face them and have the ability to help you.

• Often delaying real feedback, via trial and experimentation. Delaying the team from starting. When proposing a solution we don’t really know that it will work in our context until we try, we can’t find out everything about the design up front. In a similar vain slowing innovation and learning, doesn’t allow teams to easily try out new more innovative solutions.
• Neither inclusive or empowering, the TDA’s goal isn’t to advance the technical design awareness within the teams.
• Most Architects are usually so high level they don’t understand the real problems the teams creating this solution encounter. There is usually no-one from the team who will be delivering, writing and testing the solution at the meeting.
• A TDA usually encourage lot’s of questions, debate and too much detail. Big design up front.
• The smell from a TDA is of a low trust company culture. Maybe even a lack of technical practices which enable us to fail and recover quickly. The picture below from John Cutler demonstrates the often complicated process created around within low trust environments:

 

• There are typically large documents based on templates with sections not applicable for each context offering no value wasting the time of the people in the room and the individual tasked to complete the doc for the TDA.

 

What should we do about it?

Change the focus, the conversation. Change the name.

 

Good design is continuous, one of my favourite agile manifesto principles: “Continuous attention to technical excellence and good design enhances agility.” Make it not a once

 

Doing masses of design at the start is silly, but doing nothing is also silly. Lets do something but focus on the learning gained from that design and then talk about the assumptions made by that design and test those assumptions as quickly as possible.

 

Maybe we should call it a technical design community, making it open taking away the authority and approval connotation.

 

Encourage Experimentation, test and learn. Shorten feedback Loops.