The CTO Show

Okay, well, welcome back to the CTO show. Back because this is the second of this, what I hope will be a long-running show with me, John Graham-Cumming, Cloudflare's CTO.

And the purpose of this show is to talk to other CTOs with different experiences of the role and somewhat talk about how they got there and also demystify the role because I think it is misunderstood or at least understood in a limited way.

The first guest we had was Jason Warner, who's the CTO of GitHub. And today I've got someone with a totally different background and a totally different vision of the CTO role.

That's Rajiv Pant, who's currently a management consultant, but previously was the CTO of the Wall Street Journal and the New York Times.

Rajiv, welcome. Thank you, John. It's great to be here. So I, you know, I remember when we met and you were CTO of the New York Times, I came to the office in New York and I do remember walking and thinking, huh, the New York Times has a CTO.

What does that CTO do? Can you just talk a little bit about that, perhaps at the New York Times and also in media in general, what is it like to be a CTO of a company like that?

Sure. So yes, you know, as the business that the media companies have traditionally been in for hundreds of years has largely become an Internet business, the need for technology has significantly grown in these companies.

And what happens at media companies is that, you know, there's a lot of technology, including development that people on the outside don't often think about.

So for example, at the New York Times, you know, there were renowned engineers like Jeremy Ashkenaz, the inventor of CoffeeScript, Mike Bostock, the inventor of the D3 visualization framework.

And the company had open sourced a lot of software.

So, you know, people don't often think of companies like the New York Times or the Wall Street Journal or other media companies where some of the best engineers, actually once Wired Magazine wrote an article about us and said some of the best developers in the world work at the New York Times.

And, you know, it was in many ways fair to say that because we had inventors of programming languages of major frameworks in the team.

But that sometimes surprises people, you know.

But when you think about it, media has always been an area while, you know, working in media may not be, say, financially as rewarding as working for a bank or a certain, you know, Silicon Valley company with its stock going up.

You get to make an impact in the world and you get to work in some very challenging and interesting circumstances.

If you're a technologist working on a media company, you don't just work with a regular agile development process.

Sometimes you have to hit deadlines because there is no choice.

Say, for example, there are the presidential elections coming up and you need to build interactives for the website.

And you would have seen that my colleagues built at the New York Times, the interactive graphics that show you paths to victory for the election.

I remember that very, very well.

I was just thinking as you were speaking about the fact that presumably news organizations have somewhat been on the forefront of technology for a long time.

You think about the wire services and going back and back and back.

People want to get the news quickly. And so this is perhaps the latest incarnation, but having a CTO was a fascinating thing for me at least.

Yes, you know, you're right.

Actually, long before I began my professional career, media companies had been at the forefront of technology in other areas.

Nitrider, a company I worked for, had built a system that included, or it was an R&D stage system that had a tablet-like device, dealt with communications through various advanced channels.

I think there was even a satellite piece involved. This was long before my time, so I don't know all the details.

But yes, media companies did a lot of this work.

A lot of innovation came from there. And, you know, certain frameworks like the Django framework in Python that is used in a lot of places came out of a newspaper company in Kansas originally, I believe it was popular there.

So yes, a lot of these things have happened and a lot of really sharp technologists, some of the best engineers do work at media companies.

Their motivation is different because they want to make this impact and want to support journalism.

But the role of engineers, of product people, of CTOs is quite different in a media company because you have to learn to work in a company that not only has a tradition going hundreds of years, but you also have to then blend it in with modern technology companies.

So it's a bit different from say a more recently formed technology company like a Netflix or somewhere else, where it was built from the ground up with technology.

Media companies have been in some specialized areas at the forefront of technology in the past.

But as far as, you know, as web is concerned, mobile applications are concerned, that has been a newer trend.

Also, you know, certain things have been critical to news companies, like for example, using machine learning to categorize articles.

You know, we did this in the 90s when I worked at Nitrider before, you know, machine learning was an everyday term.

We ran a lot of articles through systems and trained the system, you know, both by using in-house software, but also by using systems that used to be, you know, I think autonomy eventually bought them.

There was a MetaTiger product.

There were all these products that you could train. There was a system called Netowl back in the day we used to use in the 90s that would read classified advertisements.

That's a thing that, as you know, used to exist when people looked for ads in the newspapers.

But it would read a classified ad and figure out if it said 3BDR, it actually means three bedroom.

And if there was a dollar figure in the ad, it figured out this is the rent, but it wasn't that simple.

It had to use a lot of training to get it right.

Because if there were $2 figures in the ad, one would be the discount, one would be the actual rent, but it had to figure all this out.

And you couldn't build just simple rules-based engines to parse all this text because it was meant for humans to be understood.

So the best way to parse this information and to deal with it was to use machine learning.

You know, we didn't think of it as some fancy AI thing back then.

It was just a tool we used to do the job.

Right, right. So tell me about this. I mean, I've been in technology in the sort of Silicon Valley sense for a long time.

So I sort of think I understand how someone becomes CTO of a company in Silicon Valley, but what's the route to a CTO in a media company, and in particular, your specific route?

So that's a great question, John.

I can speak a bit to my story, and I have met CTOs at media companies who come from a variety of backgrounds.

I began as a software engineer, as a programmer in the newspaper company, and I just loved programming, and I loved journalism.

My family was involved in journalism, so I loved working in the newsrooms, and over time found that I could only make so much impact.

And if I wanted to to make a bigger impact in the work and have things work even better, then I wanted to be in a role that I could have more influence.

I didn't know quite what it meant.

I didn't know what it meant to be a manager. You know, a lot of times people get into a technology management job.

Let's say you are a programmer, and you have a boss, and the boss, you know, gets promoted or leaves for another job, and the programmer becomes a manager.

But they typically don't have a playbook or a checklist for what to do.

So they look at what did their boss do before. So they look at, okay, my boss used to have a staff meeting with everybody on Monday, with all the people who reported to her.

So then they set up a staff meeting like that.

Then they find that, oh, my boss also used to have a one-on-one with each person who used to report to her.

And so, okay, now that I'm in this role, I'm going to set up a one-on-one.

But interestingly, they haven't actually looked at any research or science behind why their predecessor had a staff meeting, why their predecessor ran one-on-one meetings.

We just copied these habits from previous managers.

Because a lot of engineers and software people like me sometimes have the mindset that, okay, programming is a very systematic, scientific, methodological, methodical way of working.

But management, where we should study the science, the behavioral science, the social science behind management, people often don't.

And they just copy management practices from others and learn things either from very small samples or from anecdotal cases, or they have read books.

And the challenge with books is that a lot of management books are not necessarily written from the perspective of teaching what is actually based on evidence most effective.

Management books are often written by people.

In fact, my friend Jeff Pepper at Stanford has written a book titled Leadership BS, where he talks about this.

Management books are written basically to make the author look good and leave a legacy and write down all the great things about how they would have been a manager in an ideal world, but not in practice.

So when I had the opportunity to get into a management role, I thought about how can I apply the same skills as I applied as a developer to think about problems in a certain way to start with first principles and to think about management as a science, not just as something that I copy the habits of other people.

And especially in a media company, there wasn't a playbook for a CTO, as there may have been if you were, say, a CTO in a large technology company.

And back in those days, I guess it would have been the IBMs or the Microsofts where such roles existed.

So a lot of it was learning, interviewing, speaking with a lot of CTOs at other companies and learning how they work, what they do, and then finding what's most effective.

But I would say in media companies, a fair number of CTOs come from backgrounds like mine who were programmers, love journalism, work with newsroom folks.

There are also people who've come from other kinds of companies, though I have found some people who've done very well who come from Silicon Valley companies or other tech companies, but some have also struggled because they have found that in a media company, the role isn't the same as they were accustomed to.

Say, if you came from a certain Silicon Valley company and as a CTO, although the role varies in many companies, these days, how I think of the CTO role is really three things, product, design, and engineering.

Because a lot of what used to be the CTO role in media and other companies that included technology operations, these days, all that is handled by thanks to companies like Cloudflare or Amazon AWS.

So there aren't large departments where you'd remember the jobs like DBAs or Unix administrators.

Those aren't very common in media and other companies these days anymore.

There used to be, but nowadays, a lot of that is managed by cloud service providers.

And there are DevOps people, and often the programmers handle a lot of the scaling, security, and other such functions.

So in such an environment, the job itself is different, product design, engineering are different.

And what's also interesting is that product isn't just owned by the CTO or the chief product officer in media companies, because typically, the newsroom and the business side are separate.

And they're often organized separately.

They only come together at the publisher level. And the newsroom traditionally has been what you would call product in many companies, because they are involved in user research, in the user experience, what the product should be, what the metrics are for the product success.

So typically, what a product department is in a media company is a combination of various things.

It's a combination of working with engineers, doing program management, doing business and product, being involved in revenue, but also being a very close partner to the newsroom.

And this is something a lot of folks who come to product, come to media company product from other product companies struggle with.

It's also a challenge for CTOs and others. There was something you said right at the beginning about the sorts of people you had at the New York Times, being people who created programming languages or frameworks or stuff like that.

And that seems like a common thread to me between the CTO in the sort of company you're describing and in a Silicon Valley startup.

Often in the CTO group, you have some very high powered engineers who are maybe working on the Linux kernel, or in your case, a framework for presenting data on the web.

What is it that you think is a sort of common thread in this idea of CTO?

Is it in part the technologist or is it the product?

Take us through that because you've seen this from your consulting business as well.

Yes. So there are in these three parts, in some companies, the CTO and the CPO role is different.

So the CTO will almost exclusive, almost always in every case, run engineering.

So when they run engineering, and I mean product engineering in this case, of course, in companies like yours and Google, Microsoft, AWS, all those companies, there's a very big technology operations function too.

But in media and other companies that is over time becoming less a part of the teams.

So the reason there are these engineers and people who invent and create frameworks is because in every domain, these people need to create things that don't exist.

So for example, you mentioned data visualization, that is a major need at media companies.

They need to be able to communicate this information on a variety of platform to people where it's easily digestible and understandable.

And you've seen many such incredible visualizations at the New York Times, at the Wall Street Journal and many other companies.

These things, many of them didn't exist before.

So people had to come up with very innovative ways to do this. And that's why also in a lot of Silicon Valley companies, whether it's a medical company or a company like Cloudflare, people have to create new ways to do things.

So that's what attracts a lot of these engineers. And they love being part of an organization where they can tell their family and friends, hey, this thing, I invented it.

And that's a strong driver for people who are of a software engineering background.

So that is certainly a common thread in these companies.

Now, you've talked really about quite a lot of inward facing things the CTO does around the team, product development, all that kind of stuff.

What about the other side, which is so in some companies, CTO is also kind of an evangelist for the company or technology, particularly in Silicon Valley companies often because they want to do that sort of thing.

And obviously, in a product company, they may well be working with large customers.

To what extent in the media companies, a CTO and external facing role as well?

I would say it is an extremely important part of their role.

And one of the reasons is because for the reason you mentioned, there are people who know that media companies do very innovative things with technology and hire some of the best engineers.

But a lot of people also don't know that.

So it's important for a CTO in a media company to be out there speaking at the same conferences where, say, the CTO of GitHub or of Cloudflare or these companies are speaking and not only present their own work, but invite their colleagues, engineers from the teams, encourage them to speak.

So it is important to have that. At the New York Times, we had this Times Open blog.

And in that blog, we wrote about the technologies we were using, the decisions we were making, how we work from very deeply technical articles to technology management articles.

We wrote about a variety of topics there. And we did that partly to encourage our own team, but partly also to help attract talent.

And in a media company, I would say it's even more important.

Because if you're the CTO of Cloudflare or GitHub, it's well known that you are a highly technical company.

And for a media company to expose the world to the kind of talent and the skill sets and the needs of the technology, what they have in there, it's quite important to be to be active in those things.

Also, at times, media companies need to work closely with, sometimes negotiate with companies like Apple, Google, when things like AMP come up, or Apple News, or, say, working with Cloudflare to find a new way to publish content faster to readers.

So for all that, too, it is very important for the CTO to be able to go understand the not only of their own companies, but of other partners that they're working with, and be able to negotiate and understand and come up with solutions together.

So it is a reasonably outward-facing role, too.

Although what I've found effective is that it's important not just for the CTO to do that, but also for the engineers, the managers, the directors, the VPs, everybody in the entire technology organization.

So in some of the companies I worked at before, we all did that, because you're not just hearing from the CTO, you're also hearing from the engineers at the New York Times or at the Wall Street Journal.

Before that, when I used to work at Conde Nast, we had just acquired Reddit, which was a small startup then, and I managed a team of four or five engineers.

And of course, for 40 years, I was deeply involved in that.

But for that, one of my colleagues, who was the DevOps engineer in the Reddit team, he and I went together to present how we had moved Reddit to AWS.

So it was important for us to do that. And now, of course, Reddit is a household name, but it wasn't back then.

And it was important for us to present that, hey, this is the engineer and the head of technology for an organization representing this together.

What's interesting about that is that Reddit, at the time you're discussing, was sort of the poster child, Y Combinator company, Silicon Valley thing, right?

And then Conde Nast, this old family firm, buys it. What was that like?

What was the sort of integration effort there? Was there a big impedance mismatch?

How do you technically make that work? That was interesting. Actually, in some ways, I think I had two different jobs at Conde Nast.

So when I had joined Conde Nast to run digital technology for them, and my boss, then Sarah Chubb, who was president of digital, they had just acquired Reddit.

And she asked me to say, okay, you should manage this Reddit team, but manage it separately, not as a part of the core team that's working on all the magazine sites.

And I learned that very quickly.

One, there were these really sharp people, Steve Huffman is now the CEO of Reddit.

And I had, I would say I learned more from them.

And yes, while they reported to me on paper, really, we were all peers, these were brilliant people.

And working with them was a process of really giving them a lot of independence, autonomy, removing obstacles from their path, and not necessarily managing them in the same way I would manage a team working on a website for a for a, say, a magazine or a media company.

So that's another part of the of a CTO's job.

Usually, I've had to do that, you know, in separate jobs. But in that experience, it was I had to wear two hats differently.

And the technologies we use for it.

So for example, we never tried to standardize between the same technology being used for Reddit as we use for the rest of the of the sites who have made sense.

There were some projects where we collaborated, but we wanted to really grow it as a business.

Back then, Digg was a major competitor, they were bigger than us.

And our goal was to, you know, to surpass them and many others. So in that case, it was very important.

Over the entire four years, I managed the Reddit team, but it grew from that acquisition phase to becoming a major company.

I had to be particularly cognizant of the fact that these were really smart people, that my role was to support them, encourage them, create a culture where they would want to stay on for a while and innovate, rather than necessarily manage it as a traditional business.

Okay, so look, we're going to enter the third part of this half hour.

You're acting as a management consultant now, obviously consulting CTOs and other roles in companies, helping them out.

Given this experience, the Reddit thing is a very good example of the high velocity Silicon Valley thing, the media companies, all the changes going on.

What are the things you're saying to CTOs today about how they should think about the role and how they should organize things?

So one common trend that I'm seeing happen, and by the way, these days, since I'm doing these two things, I'm management consulting, and I'm involved in as a founding CTO in a startup, Hapio, which is a startup in the business meeting productivity space.

What I'm finding is that across both in the work in my own startup and in the management consulting world, a lot of people are creating this chief product and technology officer role or the CTO role is increasingly emerging with the CTO role.

There are many companies where it is clearly different, but I've seen in at least four or five, six different media companies where there is now just one person who's in charge for, and a while ago had started using this term PDE to refer to product design and engineering.

And at startups, it is often the case because the founding CTO is also typically the head of product.

So that's one change that, now I have not done a systematic study on this to see if this is happening across the industry or not, but in my personal experience in the companies that I'm observing, startups, as well as bigger media companies, I'm seeing that product technology and design are coming together and the CTO roles are beginning to run these functions.

Technology operations is becoming largely outsourced to companies like Cloudflare, AWS, and others where that happens.

So that's one change I'm definitely seeing happen more than I saw before, where there was a bigger, clearer wall between product and engineering.

What are the sort of mistakes you see people bicycling towards and you're telling them, wait, put the brakes on, this is an error in terms of how you're thinking about the role or how you're constructing things?

So this is a great question. Something I see a lot in companies and a common mistake I see is that CTOs will often organize their teams and prioritize their work based too much on what they believe is right for the company from the perspective just of technology itself, rather than looking at it from the perspective of a business.

And that's one reason there are many lenses through which to look at the CTO's role.

And I often say that CTO stands for culture, technology, and operations.

So I want to talk a little bit about this mistake I described that I see in a lot of places.

So what happens is particularly when a CTO comes from, say, a typical Silicon Valley company where they really own the product design engineering, in that kind of a case, they were not just a CTO, but they were also the general manager of a function.

So for example, if you work at, say, a large Silicon Valley technology company, you were a CTO for the company or for, say, a major division.

But in that case, you also own the business. So those folks, they come into, say, a media company or another company, and what they will do is that they will start the job with the mindset that they own the product.

And that is a reasonable assumption to make based on their past experience.

But what happens in a media company, for example, is that, well, there's a newsroom, there's a marketing and circulation department, there's an advertising department, and typically those are independent of, say, the product department.

So what a person needs to do in, say, a media company CTO role is to very closely partner with those people and co-define the objectives and key results for the product and technology teams in collaboration with these partners.

And that is, of course, harder than just doing it yourself within a department with the people who you directly manage.

So a lot of the CTO's job, and you talked about earlier the sort of external, I would say another internal slash external aspect of a CTO's job is to collaborate with their peers.

Something a CEO long ago when I worked at Nitro taught me was that they said, you know, if you're ever looking for somebody's reference, they want to not just ask the person above them or the people who reported into them, but they want to ask their peers how good somebody is.

And sometimes CTOs lose track of this important thing, you know, their boss loves them because in many cases, the boss doesn't fully understand product technologies work.

So they love their CTO. And the people who report into the CTO, as long as the CTO is somebody who manages a great culture, understands the engineers, advocates for their causes, they also will typically love the CTO.

But what happens is when the CTO does this at the cost of building the right relationships with their peers, the heads of marketing, the heads of, you know, you often hear about CTOs having tensions with the head of marketing, with the heads of content, with the heads of advertising, with the CFO, that leads to a lot of trouble for CTOs.

So the one advice I give to pretty much any CTO, whether it's a startup CTO I'm coaching, or through a management consulting a CTO who's working in a different business, is to always be aware because, you know, this, this mistake sometimes comes from this thinking that, hey, we don't want to be a service organization, we want to be an equal business partner.

And of course, that makes sense.

Nobody's saying that a CTO's job is to be, you know, a servant to the rest of the organization.

But depending on how you think about the word service, you know, you are in the service of the entire organization, as well as of your own team.

And that's not necessarily a bad thing.

So that is one thing I wish that more CTOs would do and think of themselves as business leaders also, not just the custodians of the technology and the product people who report into them, but also think that, hey, if this person works in the marketing team, they're also as much a part of my company as the engineer who reports into me.

Right. So we've got a couple of minutes left.

I wanted to extend on this a little bit in terms of, you know, I think sometimes people think, yeah, I should be the CTO, I want to be the CTO.

What would you say to someone like, you know, what characteristics should someone have if they are going to be a successful CTO in a company?

And in some ways, in what way should some people rule themselves out and say, actually, you would be unhappy doing this job?

Because I think that's a very important thing to be self-aware that this would not necessarily make everybody happy.

So what would you look for in someone?

What would you advise somebody? Sure. So my quick answer would be, you know, this is something I've written about in my blog, so I can share a link.

But the short answer is that you have to be really interested in culture, technology and operations and not just technology if you want to be a CTO, because if somebody is interested in just technology, they can be a great chief architect or they can be a chief, maybe technical officer who is not necessarily a manager of people.

You know, maybe that role is called CTO, but it's not CTO in the sense of an officer who's managing a department.

So they have to have a lot of interest in people, have understanding for how people do things and be ready to sometimes go with the decisions when they are made by the people who report into you, even if you want to do something differently.

So sometimes technical people, because they are really smart, they will say, oh, you know what, this is how the code should be written or this is how the framework should be built.

But if you are managing four, five, six hundred or thousands of people, you can't have everybody write code the way you want code to be written.

So you have to really understand the API of human beings, not just the API of software and the API of human beings is very different.

It's very ill-defined as well. So people who think about management as a science have an active interest in other people, love to work with stakeholders and partner up with other people.

So even if you don't necessarily understand what, say, the marketing department does or what this other department does, you have a curiosity for understanding things that you may consider unscientific.

So people who are happy in such a fuzzy world, they would make a good CTO.

All right. Well, listen, on that note of happiness with curiosity and a fuzzy world, I'm going to say thank you, Rajiv, for being on my little show here and talking about being CTO.

It's interesting to talk to somebody who's essentially been outside of Silicon Valley because I'm so steeped in Silicon Valley.

And good luck. I look forward to retweeting some of those blogs you've been talking about.

Cheers. Thanks very much. Thank you. Great to be here. My pleasure.