Systems Approach From 2014 to 2020 I had a title of CTO at VMware, first for the networking business and then for the Asia Pacific region as a Field CTO.
While CTO officially stands for Chief Technology Officer, the standard jokes are that it’s either Chief Talking Officer or Chief Travel Officer. I embraced all of those roles, especially the travel part when my territory covered India, New Zealand, China and everything in between. And while I definitely relished having a job that required me to keep developing my expertise in a wide range of technical fields, I also really enjoyed the chance to keep working on my communications skills, whether that was through talking or writing.
In my last year at VMware (when travel was curtailed due to COVID) I put a lot of energy into developing (online) presentations, including one on the art of giving presentations. You can find that talk on Peertube – it is in PechaKucha format, which means 20 slides, 20 seconds per slide, which I find a great source of creative inspiration. You can probably watch it in less time than it takes to read this article.
The longer I worked in technology, the more I came to believe that communications, both oral and written, can be a key differentiator in a technical career. Probably the first time I realized this was when writing my PhD thesis. Engineers as a group are notoriously averse to writing, but I came to see the satisfaction to be had in clearly communicating your ideas on paper. For one thing, by the time I was in the last year of my program, I was pretty happy to be producing something as tangible as a thesis. I had written a lot less software in my course than I’d expected, a result of Edinburgh Computer Science being more of a theory place than one encouraging system building from its students. So watching my ideas grow on the page into something the size of a book was oddly satisfying.
Engineers as a group are notoriously averse to writing
I think the reason I was not as averse to writing as many engineers had a lot to do with the way I was educated in Australia. High school English was a “must-pass” subject if you wanted to go on to university, and I found it much more challenging than my maths and science classes. Not wanting to take chances, I worked disproportionately hard on English in my last year of high school, surprising both myself and my teachers with the highest grade of my life in the final exam that mattered most.
Somewhat to my chagrin, the undergraduate engineering degree in those days did not allow any courses to be taken outside of the Engineering department, but there was a mandated “English for Engineers” course, taught by one of the engineering lecturers. (I think the course had a different official name, something like “Engineering Communications”.) I can only remember two things about that course: one is that we read “Voss” by Nobel-prize-winner Patrick White, which was challenging but enjoyable. So they weren’t treating us as complete dummies. And the second was that we had to make a formal presentation in front of the class, which I found both stressful and educational. (My high school debating experience helped a bit here.) While I might have enjoyed an actual English Literature class more, this one was much better than the course name implied.
I continued to make the occasional presentations through my PhD program and into my early career, but a pivotal experience was watching David Clark speak twice at SIGCOMM 1990, at which he won the SIGCOMM award and also presented the paper, “Architectural considerations for a new generation of protocols.” His presentation of the latter was so engaging that I remember thinking “that is how you get people to listen to your ideas.” (That paper’s ideas continue to influence my thinking today.) As a young researcher at Bellcore at the time, I was surrounded by people who had creative ideas, but I had never seen someone get the audience excited about their work the way Clark had done. I resolved to get better at making technical presentations.
At the same time, I was working on my “accidental smartNIC” project as part of the Aurora gigabit testbed. There came a point where I realized that the system was complex enough that I needed to write some sort of design document–hardly a revolutionary idea in industry, but somewhat uncommon in the research group that I worked in. My first audience for this document was me, because I realized I couldn’t keep all the details in my head any more. Later on it would enable me to involve others in the project both as subsystem designers and programmers of the system.
Documentation critical
When I left the research world for a development team at Cisco, I quickly noticed that there was a massive repository of system design documents. There were the formal ones such as product requirements documents (PRDs) and system functional specifications, but also less formal documents, such as Yakov Rekhter’s famous two-page description of Tag Switching that laid the foundation for MPLS. While Cisco was a place that put a lot of emphasis on building hardware and writing the software to run on it, documenting ideas and architectures was critical to getting big things like MPLS to happen.
Coincidentally, the first book that Larry and I wrote together, Computer Networks: A Systems Approach, was completed on the day that I decided to leave Bellcore for Cisco. I realized that completing the book – which was not part of my job description at Bellcore – was the most satisfying thing I had done in years, so maybe it was time for a new job.
By this time I was also active in the IETF, and the development of Tag Switching and MPLS led to my taking a more active role there. There are pretty much two ways to have an impact at the IETF: Write documents, and speak about your work. Of course, the IETF also depends on “running code” to back up those documents and talks – a definite benefit of working at a big place like Cisco was the resources that could be applied to writing code if the company decided to get behind an idea, as it did with MPLS.
All of these experiences led me to appreciate the value of both written and spoken communication, and I continued to work on developing these skills. Taking a couple of public speaking classes early on had a huge positive impact – although I still talk too fast when I get excited about my topic. (I’ve learned skills to manage that, but sometimes forget them in the excitement.)
Learning to be a good communicator can itself be a great way to build your technical skills
In my CTO roles I had plenty of opportunities to advise engineers on how to progress their careers, and I always found myself coming back to emphasize the value of communication skills. Of course you need technical skills as well, but I view these as table stakes, whereas it is the great communicators who rise above the pack. And communication skills are eminently trainable. All the great public speakers I know put huge amounts of time into preparing and practicing their talks. They might look effortless on stage, but that is because of all the effort that went in ahead of time.
Finally, learning to be a good communicator can itself be a great way to build your technical skills. In my last year at VMware, I started to get really interested in quantum computing, which was a challenge for me – it’s full of mathematics and outside my core expertise. But the more I learned the more excited I got, so I decided to present on quantum computing at our Asia-Pacific technical team conference. My goal was both to become knowledgeable enough to avoid embarrassing myself, and to show by example how much fun it can be to expand your horizons.
A version of the talk is here and some lessons from it are here. If you can learn a topic well enough to explain it to your audience, you are going to have a deeper understanding than if you just keep that knowledge to yourself. And if you can communicate your ideas–and your excitement about them–to people around you, you’ll greatly increase the chance of those ideas having an impact. ®
