when relevant content is
added and updated.
For years we have been told that tomorrow’s CIO role will not be able to be just a technologist; the role will also require business skills. Of course, most of those articles were written by journalists, executives, and others who were less technical — “people people.”
In other words, tomorrow’s CIO will be more like the authors of the articles.
I always found it odd that the rhetoric continued, even when Larry Page and Sergey Brin turned out to do just fine at Google, or when companies like MySpace and Yahoo were destroyed by “business people.”
Most of the literature focuses on how people need to have business and communications skills to be successful in those roles. Today I would like to suggest something a little different – that system forces tend to pick people with those attributes, regardless of whether or not those things make them successful. In particular, the CTO’s role, which was designed to be technical from the beginning, ends up tugging any CTO to turn into a businessperson.
That might be good. It might be bad. I suspect, at the very least, it is what it is.
Let’s talk about why.
System Forces at Work
Ten years ago I worked with a company doing a massive systems upgrade. The hardware and database teams were quickly documenting how they built the dev and test environments while running cutover scripts and ‘testing’ what would run on the final cutover day. Time grew tight. In one meeting, the lead DBA asked the Windows team lead to add him as a user. The team lead insisted on a ticket. The DBA scribbled all the details on a stickynote, and the team lead said “no, it needs to be on a ticket.” So, even though they were right there, and the actual work would take about a minute, the DBA had to go into the workflow tracking system, fill out a request, and, since it was a priority three (not production), wait up to a week for a response. After the meeting, he ranted to me for several minutes about how terrible the service was to require a ticket – clearly he was venting some emotional baggage.
A year goes by. I am promoted to project management and the DBA team is transferred over to technical services. I ask the same DBA if he can do a simple operation for me that would take about a minute.
You guessed it. He insists I file a ticket.
Most of the time, when we encounter what we think of as bad service, it’s not the people — it is the system.
Now let’s talk about the office of the CTO.
The CTO’s First Year
Most companies select a CTO who is a senior technical person, ideally one who has mastered a particular process; they might have owned an entire system. The CTO, role, however, has to own the entire technical staff for the company. That looks more like system integration – the glue – than a mastery of the individual pieces. The company already knows how to run system A and system B; the CTO will struggle with how to get those two to fit together, plus how to get data out of A and B and either to a business partner or into another system. With those sorts of problems, it’s no wonder the past few decades have been full of Enterprise Architecture Integration (EAI), Enterprise Resource Planning (ERP), Service Oriented Architecture (SOA), and, of course the Enterprise Service Bus (ESB).
All those three letter acronyms are sold by vendors. When the vendors come in, they have charts, graphs, webinars, and demonstrations. Instead of doing the technical work, the CTO is in meetings all day, both with superiors and with vendors.
The CTO wakes up one morning and the company has changed version control systems and platforms. He knows the platforms name and can tell you exactly why the company chose xmlvm — it can cross-compile java applications to both iOS and Android – but he couldn’t code in it. For that matter, he didn’t code in it when he selected the tool, so he doesn’t know how to use it as a client. If we are lucky, the CTO has good people he can call for advice, to do the research on these things. Unlucky, the vendors rule the show, or, worse, the company just keeps cranking out tools using the Visual Basic that the CTO used when he wrote the site the first time.
In any case except the last, the CTO has turned into someone who goes to meetings all day. There’s a name for that after a few years: A Business Person.
And we, the technical staff, want him to go to those most of those meetings. If the CTO took the five hundred or so hours a year to stay technical, then he would lose the political game, because he wasn’t in the room when things mattered.
From technical person to business-person CTO in two years. That is the pattern.
The Good News
The story above, like that of Ebenezer Scrooge in a Christmas Carol, is only a shadow of what might be – not what has to be. The forces of mediocrity will pull a rudderless ship their way–but a good leader can steer. Jim Goodnight, CEO of the SAS Institute, kept chief programmer in his title for the first thirty years of the company’s existence, up and past the point where it was making billions of dollars per year in sales. The trick is to define the role carefully, align it with the needs of the business, and be very explicit.
Instead of reacting, leaders can be prime movers defining the role for what it will be.
Getting the vision is one thing. Communicating it again and again to a wider audience prevents all kinds of problems. That’s a marketing plan, and it’s something I recommend to anyone working in an environment with any ambiguity about role.
How to build a marketing plan for a role, and what that might look like, is a bit beyond the scope of this article. For now, have you seen these sorts of role expectation mismatches – and what did you do about it?