<x> is too important to delegate to your Chief <x> Officer
Photo credit: Shelby Murphy Figueroa via Unsplash
I started my career in the late 1980s, when the term ‘Chief Technology Officer’ was just starting to be used in companies. (It wasn’t used in the government department where I was working: that still referred to IT as ‘Automated Data Processing’. This was a place where we still had to write out our documentation by hand and send it to the typing pool to be processed,)
Since that time, I have seen the creation of many Chief <x> Officer job titles in the field of enterprise computing: alongside the Chief Information Officer and Chief Technology Officer, we have had the Chief Digital Officer, the Chief Information Security Officer, the Chief Architect and the Chief Data Officer. The latter has undergone mutation in recent years, showing up as the Chief Data and Analytics Officer (CDAO) or, now, the Chief Data and Artificial Intelligence Officer (CDAIO - a title which I can’t help singing to the tune of Old MacDonald Had a Farm - C-D-A-I-O).
While the proliferation of these job titles can seem confusing, and typing up the minutes of IT leadership team meetings can wear out the ‘C’ key on the keyboard, it is largely rational and welcome. It represents two important trends.
First, it shows that enterprise technology grows ever more complex: the field expands, fragments and splinters, and requires more specialist skills, with more focused accountabilities, to keep on top of it.
Second, it shows that enterprise technology grows ever more important. Sometimes these roles are created positively and proactively, to advance a strategic agenda: we’d better have a CDAO so that we can figure out what our customers want. Sometimes they are created defensively and reactively, to address compliance failures or weaknesses: we’d better have a CDAO so that we can fire them when we have the next data breach.
But, whatever the reason, they are created because the topic matters to the company - enough to justify a senior role with the letter ‘C’ in the title, and, most likely, regular time on the agenda of the Board.
However, there is a risk that companies take every time they create one of these roles. And it is a risk that doesn’t just manifest in the ‘C’ suite: every time an organisation creates a specialism, the rest of the organisation may stop thinking about that topic.
This is a strange and disturbing phenomenon which I have seen in real life several times.
Early in my career, people building computer systems were trained in data structures and data models. When they started thinking about a new system, they began by thinking about concepts and drawing entity relationship diagrams. As systems grew more complex, and data management technologies became more sophisticated, new roles, such as that of data modeler and database administrator began to appear. And, as soon as they did, many programmers seemed to forget everything they knew about data design - either letting their projects come to a halt while they waited for a data modeler, or, more often, lashing together a horrible design which they would find difficult to unwind later.
Later in my career (but still many years ago), the roles of solution architects and enterprise architects began to emerge, as organisations realised that it was hard to make design choices that would meet both immediate needs and long term needs, and even harder to make those choices across multiple systems simultaneously. As the role of architect was created to figure these problems out, other people in system building roles suddenly seemed to forget how to do good, balanced design - or how to move forward without someone to do that design for them.
This experience counsels caution when creating new CxO roles. If we are careless, then the new Chief <x> Officer becomes anointed as the only person qualified to think about <x> at the leadership level, and their team are the people that the organisation relies on to do <x>, while everybody else can safely ignore <x>, or, more likely, only think about <x> when formal processes force them to do so.
When we get it right, though, then the new Chief <x> Officer can become the coach and mentor for <x> for the rest of the organisation. They show why <x> is exciting, interesting and important, and why it should be part of everybody’s job. They help their boss and their team-mates think through <x> - and what the organisation’s strategy means for <x>. Such an organisation does not delegate <x> to the Chief <x> Officer: they hire the Chief <x> Officer to help them get better at <x>.
When leaders consider creating a new Chief <x> Officer role, they should ask themselves: do I want this role because I want to stop thinking about <x>? Or do I want this role because <x> is too important for me to stop thinking about it - and I need some help?
