Be A Great Communicator To Progress In Engineering
Arthur T Knackerbracket has processed the following story:
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.
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.
Read more of this story at SoylentNews.