🎹 Music for this post: https://www.youtube.com/watch?v=yARVs1ZNLjU.
When you identify a leader, how do you invest in his or her growth?
My father was an electrical engineer of the highest order. A master bridge player and a director of electrical engineering at Hazeltine Corporation — one of the most significant electrical engineering companies in American history — he was a smart man who worked in the smartest of company. Dad’s colleagues over the years included not just Professor Alan Hazeltine himself, but Harold Wheeler of Wheeler Laboratories; Page Burr, co-founder of Burr-Brown, and who was my father’s classmate at Cornell; Bernie Loughlin, who co-invented color television; and Henry Bachman, who served as IEEE President and became an IEEE fellow. There were many others. I don’t usually do this, but I encourage you to view the links to these individuals before you proceed, as they will paint a vivid picture of the fortunate magnificence of my father’s cohort.
What follows is not a hackneyed story about how my father was a great leader (although he was). It is a story about how the engineers of my father’s generation invented the idea of software, carving out the path to a new form of leadership. It is also the story of how he catapulted me along for the ride — with a swift kick in the pants.
Dad spent nearly 50 years at Hazeltine. My brothers and I all worked there at some point in our lives as well. My eldest brother Paul notably worked there for over 30 years in manufacturing, including time spent as part of the team that created the world’s very first multi-layered PC boards. Hazeltine was a major force in the formative years of the electrical engineering industry.
I grew up in a fairly traditional household, where we shared stories over supper, every day. The children would discuss their schooldays, Mom would talk about what happened around the house and the news of the day, and Dad would share the latest goings on at Hazeltine. These would often include (generalized) stories about how the military changed requirements for the projects his teams were working on, how frustrating those changes were, and how this all threatened the due dates that they faced.
Above all else, these were stories about human beings and their struggles with change. I wish that I could recall many of them in great detail so that I could share them; I cannot. But they had a huge impact on our family’s understanding of the world Dad worked within.
Less than a year and a half before he died at age 93, I was lucky enough to record Dad (during a car ride) recounting the following funny and fascinating story about the search for an aneroid barometer that was suited to solve a voltage issue his engineering team had at high altitudes within an Identification Friend or Foe (IFF) system for a Northrop aircraft.
Have a listen:
Dad told these sorts of stories every night when we were growing up. Without really appreciating it at the time, I was deeply conditioned by the lessons and experiences of my father and his distinguished colleagues as related through these suppertime stories, right alongside their journeys to define the modern disciplines of their craft. It is all hard to believe in retrospect, but I had a first-hand seat to this era of engineering history, which became, no doubt, a significant component of my own education, outside of any classroom.
One of these old stories is easy for me to vividly recollect, no doubt because it was the seed that grew into my life’s professional focus. During one summer evening in the late 1970s, Dad introduced our family to the word “software.” While I can’t recall all of the details, one thing I do recall is him sharing how it allowed his engineers to make changes to things they made without having to redesign hardware. The fact that the very idea of software came about to mitigate the issues that electrical engineers of Dad’s generation faced is a lost story, yet it is critical to remember if we wish to understand the opportunities it represents. Electrical engineers designed hardware that could be programmed, elegantly enabling them to honor the human need for change while reducing their natural, personal frustrations when faced with that need.
The world would do well to remember that software is all about encouraging — rather than resisting — change. Many people wish to treat software as something to finish. Haven’t we all heard people ask, “When will we be done with this software so we can move on?” How do you feel when you hear that? I enjoy tossing back this pithy response, which was borne of my suppertime story experiences:
If we want something that doesn’t change, we should just build hardware.
When I was a young teenager in the early 1980s, I spent countless — undoubtedly thousands — of hours programming the 8-bit computers of the era, starting with the Commodore VIC-20 and moving on to the Commodore 64. One might describe me as addicted to programming, to the extent that Dad occasionally switched off the circuit breaker to my room so that I would better attend to my assigned chores and homework. During high school, I told him that I was eager to study computer science in college (software engineering degrees were more than a decade away at the time, and the term itself was probably not in common use, either.) His response to this was not what I expected.
“You don’t need a computer science degree to be a computer programmer,” he shared, with a brusque certainty. Dad was typically more demanding than I — or any young teenager — could bear. He would quickly and easily find the flaws in any system, argument, or idea that I might have. He went on:
“I will be paying for your education, and will not pay for you to do that. What you need in order to program computers is a background in liberal arts, because that experience will best equip you how to learn on your own on an ongoing basis, as computer languages, and the problems they are used for, change.”
That hit me like a ton of bricks, in the sense that I had no choice, unless I could find the money to pay for college myself. But it was also fair and gentle, in the sense that it was broad, with no specific direction other than to study liberal arts. I happened to be interested in studying journalism and publishing, and I was good in English class, so this all wasn’t as horrible as it could have been. But it was certainly not what my other teenage programming friends were doing, and at the time it was hard to believe he was right.
You might recall this quote:
“When I was a boy of fourteen, my father was so ignorant, I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished at how much he had learned in seven years.”
—Not Mark Twain
I followed Dad’s orders.
The undergraduate program that I joined in 1986 at SUNY-Binghamton was focused on rhetorical theory, which, if you have read many of these pages before, you will understand as the ancient and philosophical study of persuasion and communication. Lucky for me, Dad didn’t mind if I took a computer science program or two, which I did to my personal delight, serving to fulfill some of my science obligations. (We learned Pascal back then.) But rhetorical theory became my academic passion. It was the driving force behind my appreciation and understanding of empathy and trust. If you want to know more, I recommend you read Aristotle’s Rhetoric.
When I graduated from college, I landed a job as a software developer for a publishing company, oddly satisfying my broad desire to work for a publishing company while simultaneously satisfying my desire to program all day.
I never left the software industry after that.
In my career’s first 15 years, software development projects were universally managed using traditional, deadline-driven waterfall methodologies, just like the very projects my dad managed in his career. In the mid 2000s, however, Scrum entered into my life — and the lives of many others. What occurred to me in the process of learning Scrum was that managing software development with Gannt charts and up-front planning was completely at odds with what software was supposed be. It felt remarkably more compatible with what Dad had shared at the dinner table over thirty years prior. With Scrum, we could finally develop software in a manner that embraced the sort of change that only software could deftly provide.
Software’s very nature doesn’t merely involve uncertainty. It invites it. It is its raison d’ĂŞtre. Software is utterly pointless when there is certainty (I will repeat: otherwise, we should just build hardware.) What are we really achieving when we practice Scrum? We are offering a framework for human beings to help them manage the invited change and uncertainty, by taking one step at a time.
And, as the saying goes, herein lies the crux of the matter.
One of the best books I have ever read on the notion of leadership is Building The Bridge As You Walk On It: A Guide for Leading Change, by Robert E. Quinn. In it, he describes two different states that we might wake up to every day:
- The Normal State, where we seek comfort and predictability (when we wake up and wish for a day without drama or surprises, and a pleasant evening to follow). We stick to the reactive, and not the proactive. As Quinn puts it: “To remain in the normal state, refusing to change while the universe changes around us, is ultimately to choose slow death.”
- The Fundamental State of Leadership, where we face the need to change with the world around us, eschewing our natural desire for the comfort of the normal state. To quote Quinn once more, “In the fundamental state of leadership, we become less comfort-centered and more purpose-centered. We stop asking, What do I want? Since what we want is to be comfortable, this question keeps us in the reactive state. Instead we ask, What result do I want to create?”
The difference between supervision, management, and leadership might best be described as follows:
- Supervision is the practice of overseeing people to ensure they’re doing their assigned tasks.
- Management is the practice of nurturing someone’s career so that they can achieve what they aim to.
- Leadership is the practice of taking people on a journey to an unknown place while managing their natural anxieties about this journey.
This is why good executives are fond of pointing out that everybody in an organization is capable of being a leader, no matter where they fall in the corporate hierarchy. Leaders drive change, and bring tools to the table to facilitate that change.
By definition, software engineers bring tools to the table to facilitate change — whether employing Scrum or not. Scrum just happens to make the journey easier for everyone involved. Don’t leaders worthy of the label seek to do these things at every turn? When software engineers use frameworks like Scrum to assist them in their efforts to drive change, they are living the very highest form of leadership.
What are the consequences of this assertion?
For starters, we should make every attempt to recognize that software engineers are key leaders for the organizations they serve. To be clear: they are not future leaders; they are current leaders.
As a consequence of that, I believe that software engineers are worthy of being provided the very finest we can give them in leadership skills and training…the very same skills we afford our best executives. We should do everything we can to groom their skills in:
- Interpersonal communication
- Group dynamics
- Conflict resolution techniques
- Emotional intelligence (EQ)
Yet, I can’t think of too many organizations today that see how these are essential offerings for their software engineers, except perhaps as remedial activities once in a while. That approach is a mistake. Everyone worthy of being called leader needs regular nourishment in these skills, software engineers in particular.
At RIT’s Golisano College of Computing and Information Sciences, where I serve as Adjunct Faculty, we differentiate software engineering from computer science this way: computer science is the art of understanding the detailed underlying architecture of a computer so that you can design better ones; software engineering is the art of applying these computers to solve human problems. Department founding chair Mike Lutz is who we thank for this approach; he inspired RIT to offer the very first undergraduate software engineering program in the nation back in 1996.
In that sense, a good software engineering curriculum places significant emphasis on requirements elicitation, communication, human factors, and group dynamics. Over my decades managing software engineers, it has become apparent to me that the connection to the human condition doesn’t end with the education provided by the software engineering degree. The degree itself is the foundation of a long arc of a leadership journey. Corporations who employ these engineers play a key role in this journey.
Dad’s opinion about the computer science programs of the 1980s was prescient. I think he would have liked Mike Lutz.
I would be remiss if I didn’t offer that the generalized practice of IT is also, at its most vital human points, a form of leadership in the very same vein. While generalized IT folks don’t generally develop custom software, they certainly select and configure off-the-shelf software solutions that enable change. These IT professionals — including the business analysts and project managers who serve both IT teams and software engineers — should be afforded the same sort of nourishing training that software engineers deserve.
At this point, you might wonder: what about those ISTJ and INTJ stereotypes? The propellerheads? Can they really be leaders in the way we traditionally envision that label? My answer? It’s too late! You have no choice; they are already leaders. As my own coach, Dr. Jim Kestenbaum, has taught me, there is good news here. While we are born with our personalities and our IQs — and there is little we can do to change them — we have the ability to increase our skills in the four areas I listed above, EQ included. The investment will be worth it, if you choose to make it. But the first step is to realize that if you have software engineers in your organization, you have leaders — vital ones — who require care and feeding. To miss this is to shoot your proverbial corporate self in the foot.
What are you going to do about that?
If you liked this piece, please read the followup.
Discuss this specific post on Twitter or LinkedIn.
![[Logo]](https://theprogressivecio.com/wp-content/uploads/2020/07/ProgCIO-1024x1024.png)