To progress as an engineer career-wise, become a great communicator
(2025/05/18)
- Reference: 1747570209
- News link: https://www.theregister.co.uk/2025/05/18/communications_for_engineers/
- Source link:
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 [1]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.
[2]
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 [3]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.
[4]
[5]
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 [6]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 [7]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.
[8]Tech jobs are now white-collar trades that need apprentices, not a career crawl
[9]Tech hiring stalls as AI hype, layoffs, tariffs, economic uncertainty, more collide
[10]Engineers are troublesome 'expert loners', says prof
[11]Engineers on the brink of extinction threaten entire tech ecosystems
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 “ [12]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.
[13]
A version of the talk is [14]here and some lessons from it are [15]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. ®
Larry Peterson and Bruce Davie are the authors behind [16]Computer Networks: A Systems Approach and the related [17]Systems Approach series of books. All their content is open source and available for free on [18]GitHub . You can find them on [19]Mastodon , their newsletter [20]right here , and past The Register columns [21]here .
Get our [22]Tech Resources
[1] https://peertube.roundpond.net/w/167u3mtfG225FfzaxbtznE
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.nobelprize.org/prizes/literature/1973/white/biographical/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://dl.acm.org/doi/10.1145/99517.99553
[7] https://www.theregister.com/2022/03/02/mpls_history/
[8] https://www.theregister.com/2025/02/27/tech_career_paths_apprenticeships_needed/
[9] https://www.theregister.com/2025/04/09/it_hiring_slows/
[10] https://www.theregister.com/2009/06/09/engineers_aggro_loners/
[11] https://www.theregister.com/2022/07/18/electrical_engineers_extinction/
[12] https://www.ietf.org/runningcode/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://youtu.be/PkuDIV2L-Lo
[15] https://www.theregister.com/2022/07/21/quantum_computing/
[16] https://book.systemsapproach.org/
[17] https://www.systemsapproach.org/
[18] https://github.com/SystemsApproach
[19] https://discuss.systems/@SystemsAppr
[20] https://systemsapproach.org/newsletter/
[21] https://www.theregister.com/Tag/Systems%20Approach
[22] https://whitepapers.theregister.com/
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 [1]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.
[2]
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 [3]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.
[4]
[5]
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 [6]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 [7]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.
[8]Tech jobs are now white-collar trades that need apprentices, not a career crawl
[9]Tech hiring stalls as AI hype, layoffs, tariffs, economic uncertainty, more collide
[10]Engineers are troublesome 'expert loners', says prof
[11]Engineers on the brink of extinction threaten entire tech ecosystems
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 “ [12]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.
[13]
A version of the talk is [14]here and some lessons from it are [15]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. ®
Larry Peterson and Bruce Davie are the authors behind [16]Computer Networks: A Systems Approach and the related [17]Systems Approach series of books. All their content is open source and available for free on [18]GitHub . You can find them on [19]Mastodon , their newsletter [20]right here , and past The Register columns [21]here .
Get our [22]Tech Resources
[1] https://peertube.roundpond.net/w/167u3mtfG225FfzaxbtznE
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.nobelprize.org/prizes/literature/1973/white/biographical/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://dl.acm.org/doi/10.1145/99517.99553
[7] https://www.theregister.com/2022/03/02/mpls_history/
[8] https://www.theregister.com/2025/02/27/tech_career_paths_apprenticeships_needed/
[9] https://www.theregister.com/2025/04/09/it_hiring_slows/
[10] https://www.theregister.com/2009/06/09/engineers_aggro_loners/
[11] https://www.theregister.com/2022/07/18/electrical_engineers_extinction/
[12] https://www.ietf.org/runningcode/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/cxo&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aCoEGh3ezlDjyunEIgihcAAAAAw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://youtu.be/PkuDIV2L-Lo
[15] https://www.theregister.com/2022/07/21/quantum_computing/
[16] https://book.systemsapproach.org/
[17] https://www.systemsapproach.org/
[18] https://github.com/SystemsApproach
[19] https://discuss.systems/@SystemsAppr
[20] https://systemsapproach.org/newsletter/
[21] https://www.theregister.com/Tag/Systems%20Approach
[22] https://whitepapers.theregister.com/
Not the case elsewhere? US?
" 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 "
Is it possible to become a graduate engineer without a passing grade in English (or the National language) in your high school matriculation years?
I remember in my time the local Uni (not Melbourne) had just recently dropped a "foreign" language requirement (typically French, German or Latin, Greek) for admission to Arts or Sciences but English was mandatory.
The final two years of high school English was a major subject covering broadly the language (grammar & basic linguistics) and literature (prose, poetry, speech & drama) from Chaucer to contemporary works with a large reading list and copious assignments.
Unfortunately in the many decades since I suspect the subject has been split into a mandatory veggie English subject and various, some basket weaving, electives as has been pretty much the case with mathematics and the sciences.
I remember it as the most challenging by far of my subjects and in hindsight was the most University like of those subject in requiring a lot of research and reading on your own initiative.
Sadly many contemporary University courses have leaned in the other direction mostly for purely commercial reasons leaving capable and talented students unchallenged and frequently frustrated.
Recent graduates are possibly better oral communicators but tend to fare poorly in written communication sometimes to the point of borderline illiteracy which is worrying if maintaining documentation is part of the role.
If candidates were required to compose with pen and paper (A4) only, a one page essay on a given but straightforward topic, I believe that would filter 95% of applicants out of the hiring process in most cases.