AN UNEXPECTED NO
It was 9.45 am, and Matt, the CTO of a large investment bank, decided to have a quick break before the next meeting. “What was that?” he wondered. “Oh yes, the monthly prospect initiatives proposal.”
His teams joined the call, and Matt asked Julie, his head of staff, to go through the schedule. There was just one proposal to discuss. It was about a new ITOPS automation capability, submitted by the SRE team.
Patrick, the head of the team, went through the presentation, and he was brilliant. He was prepared, perfect to emphasize the benefits and the absolute robust return of the investment.
When Patrick reached the end of his slides, Matt stepped in, saying: “Than you, Patrick. I truly appreciate your team’s great work in assembling this proposal, and it is evident to me it is valuable for the Company. Well done.” He then took a pause and added: “But this time, you get a no; I’m sorry.” He said goodbye to everybody and left the meeting.
Matt in the afternoon called his report to explain his decision: “This is the third project on new capabilities you submit, and you did great so far. But how far have they gone? What is their real adoption among IT teams? We’re spending our Company money badly if we don’t get our planned ROI. So please, I’d like to see your plans about it before moving on the next new thing.”
Patrick finally got it. He grabbed his team and worked on the plan, which he submitted two weeks later to Matt. This time he got a big “yes”!
SPREADING VERSUS BUILDING
Buiding new things is always interesting fot tech teams. You experiment, find value for you Company, build capabilities on top of existing ones in a path of progessive maturity.
But it isn’t totally true if you’re not caring enough about your existing capabilities.
In my experience, valuable technical leadership practices are:
- View capabilities as “products”
- Adoption must be supported by defining new or shaping existing processes, and you should take initiative even if you’re not their owner
- Influence your context to get them widely adopted and ask for honest feedbacks while pushing to get it done
- Measure with KPIs their adoption level, main gaps and understand reasons (for instance tech features, processes gaps, training needs, documentation)
- Manage their lifecycle: what should be discontinued and when? Or improved and when?
- Work with your team to make this approach become part of your culture and values.