Technical architecture teams are much maligned so lets not start this by going over the ivory tower nonsense.
Lets talk about Technical Architecture as an organisational entity that manages strategy and culture.
Technical strategy is the bigger picture play. The why in what gets built:
- Is it economic to build this?
- Should be looking at a Saas solution to achieve this rather than building in-house?
- Does this align to our overall organisation goals?
- Will this scale and do we need to make any changes elsewhere to accommodate this?
Setting a cultural strategy is often forgotten about, particularly in top down organisations. It forms part of the how:
- What questions are we giving to delivery to answer?
- How do we define a successful outcome?
- How do we make sure that developers have enough freedom to own the solution?
As Peter Drucker says:
Culture eats strategy for breakfast!
Strategy is important but the culture and the impact technical architecture teams have on this, have the biggest impact on delivery...
There is a slight caveat to this I'd like to add. Not all organisations can support a culture with fully autonomous delivery teams.
As Hersey and Blanchard's theory identifies four different levels of maturity, including:
M1: Group members lack the knowledge, skills, and willingness to complete the task.
M2: Group members are willing and enthusiastic, but lack the ability.
M3: Group members have the skills and capability to complete the task, but are unwilling to take responsibility.
M4: Group members are highly skilled and willing to complete the task.
If your development capability isn't in M3/M4 group, technical architecture must resort to traditional roles. I do hope you don't work for one of those organisations or worse still, if your technical architecture team falls into M1/M2!
