Measure what matters

Recently a CTO I worked with started a meeting with architects:
CTO: Let's improve performance of architects team.
A team keeps silence being puzzled.
CTO: Wake up guys! Let's invent ideas how to speed up our delivery.
Architect 1: We can store diagrams in another directory.
Architect 2: We can delegate DB design to developers.
CTO: Good job, let's continue.
Me: Why do you think we need to improve performance of the team?
CTO: Because developers wait without work while architects are preparing technical proposals for them.
Me: How long does it take to create a single technical proposal on average? How long does it take for Dev team to implement a single technical proposal?
CTO: I don't know, we've never measured latency, about 10 days per each proposal (created by a single architect). Devs take about 50 days to implement a proposal.
Me: With these numbers Devs should be overloaded with a work from architects. Do we have a problem with wrong focus?
CTO: No.
Me: So why do you think architects need to improve performance then?
CTO: .....because I was said to do so.
Me: Ok. Let's imagine we implemented all improvements, how do you plan to verify the performance becomes better?
CTO: I will talk with people and ask if it's better.

I stopped participating actively in this discussion because it wasn't about improvements, it was a waste of time.
Why do I think so?
1. You cannot improve the thing you have no idea how it works now.
2. You cannot improve the thing if you don't know how to verify improvements.
3. The bottleneck in release is Dev team being overloaded by architecture proposals. Improving architects performance will make a situation worse, since it will increase Work In Progress and overload Devs even more.