Decoding Your STEM Career

How to Exceed Your Expectations

Peter Devenyi

• Editorial: Business Expert Press
• Año: 2022
• ISBN:
  9781637422267
• Categoría: Business
• Categoría: Industria informatica

A must-read for STEM graduates who aspire to be the technical leaders and executives of our next generation.

This book is also for mid-level technical managers who seek to move up the corporate ladder but are not sure how to differentiate themselves from their peers. Pete Devenyi highlights ten capabilities that technology leaders must develop and nurture in order to achieve their full potential. He shares learnings and techniques through a collection of compelling, real-world stories from his own 37-year technology journey.

He discusses the importance of a never-ending commitment to technical education but recognizes that it can only propel a leader so far. It is critical to develop many additional skills as well, such as the ability to maintain composure in high-pressure situations. Technologists who commit to acquiring all the capabilities outlined in the book are far more likely to rise to senior executive levels in major corporations.

CHAPTER 1

Establish a Solid Base of Technical Skills and Never Stop Learning

Continuous learning is the minimum requirement for success in any field.

—Brian Tracy, Canadian author and motivational speaker

Whether you majored in science, technology, engineering, or math, you no doubt invested considerable time, energy, and money into your education. You probably chose a technical career path because of your aptitude for math and science and your ability to absorb complex technical concepts relatively easily.

For most of us, it is important to strengthen our skills through rich work experiences and to resist the temptation to move into management roles too quickly. It is helpful to spend time developing technical skills early as it improves our ability to learn new technologies down the road. There are many exceptions, well-publicized cases of young technology entrepreneurs who founded companies in their final year of university. Some moved on to become successful chief executive officers (CEOs) of multi-billion-dollar enterprises that they built from the ground up. I have nothing but admiration and respect for those who achieve such feats. I have also worked with outstanding technology executives who had limited technical training but were able to make up for it with their strong leadership skills and drive.

Most technology leaders, however, advance their careers through more traditional paths. They sharpen their technical skills early, and they work to improve their leadership skills over time. Many technologists are reluctant to report to leaders who lack an instinctive appreciation for underlying technological complexities. A career in technology or engineering lasts a long time, usually about 40 years. Based on my experience, the probability of advancement to senior levels increases markedly when at least 10 percent of that time is devoted to building a strong technical foundation.

My first job after graduating from university was with Geac, where I helped design and develop mainframe computer systems for libraries and banks. Peter Johnston, my boss at the time, was seven years my senior and held a role similar to mine only a few years earlier. I recall one of our conversations as if it were yesterday. I began a project to rewrite several functions of the communications operating system to improve its performance. It became sluggish due to the amount of functionality that was added to it over time. I was struggling to understand the current design, which made it difficult to determine the best way to approach the rewrite. I asked colleagues for assistance, but they were not familiar enough with the details to be of much help. I scheduled a meeting with Peter, hoping he might be able to offer me some pointers. As we dove into the details, I was struck by his level of knowledge. He was able to answer almost every technical question I threw at him. Given his other responsibilities, I was amazed that he had this level of technical depth. My level of respect for him rose to a new level. He was recognized for his broad set of leadership skills, but I realized that his technical skills were at the core of what set him apart.

Geac had a climate for cultivating this sort of talent. There was considerable social interaction, many off-site events, and an embedded culture of teamwork, but the ability to hold your own technically was an unspoken expectation. While I had minimal contact with Peter over the years, I always felt a sense of gratitude toward him for serving as my first true role model at work. He had a profound impact on the way I tried to conduct myself throughout the rest of my career.

Relatively early in my IBM tenure, while working as part of the local area network team, the ramifications of losing touch with technology were made clear to me. A member of the information technology (IT) team, who had responsibility for configuring our computers, let several of us know that he would be conducting an experiment on one of the IBM managers we knew. This particular manager had a reputation for being exceedingly nontechnical. Most of us believed the only application he ran on his computer was e-mail. In the early 1990s, 8 megabytes (MB) of memory on a personal computer was considered a lot and was only required by developers who were doing serious technical work. Apparently, this manager put considerable pressure on the IT staff, insisting that he needed 8 MB of memory to do his work as well. Weeks after his machine was initially configured, the IT team decided to remove all but 512 kilobytes of memory. They waited patiently for the manager to report an issue. He returned to his office the next morning, carried on with his work, and for the days and weeks that followed, he never complained. The experiment always stuck with me. While it was a few years before I became a manager myself, I knew this was not something I would ever let happen to me. Even if I had to work twice as hard, I committed to take pride in maintaining my technical skills.

Learn From Your Mistakes

We all make mistakes, and I made many of them during my career, but I worked hard to learn from each of them. I joined Descartes soon after the team purchased a new development environment for its next generation system, the one at the core of the company’s growth strategy. The environment was relatively unproven in the industry. It had been on the market for only a short time, but it was gaining considerable hype and press. It was marketed as a tool that would substantially reduce the time required to build scalable, fault-tolerant, enterprise-grade applications. With a background in these sorts of environments, I remember feeling uneasy about the choice, not so much because I didn’t think it was good technology, but because I knew it had no track record. I was concerned that it would take too long for our growing team to become productive with the new development model. I also believed we ran a risk of encountering a large number of previously undetected bugs.

With the hard deadlines we faced, I didn’t feel like it was the right time to be taking significant risks. Despite my concerns, I did not follow my technical instincts or ask enough questions. We faced some extremely challenging consequences as a result. Being new to the logistics industry, I decided to spend the bulk of my time familiarizing myself with the product and the requirements, and to get comfortable in my new role. I convinced myself that the development environment decision had already been made and I would just have to live with it. It turned out to be the wrong call.

It would have been a bold decision to make a change at the time, as hundreds of thousands of dollars had already been spent on associated license fees. I learned afterward that it also would have been the right thing to do. There would have been pushback from the CEO and others, but it was my call to make, as the responsibility rested squarely on my shoulders. It wasn’t enough to possess sound technical judgment if I wasn’t willing to ask the really tough questions or muster the courage to make and defend difficult decisions. I failed on the latter two accounts, and as a result, it cost the company a lot of money.

My internal reputation took a hit as well. The customers who deployed the solution were disappointed, and in early 2000, we had no choice but to migrate them to a Y2K-compliant version of our legacy product. It all had to be done on our dime. I learned how important it was to make unpopular decisions when situations called for them and to be prepared to support them with solid technical arguments and data. The pain and cost would have paled in comparison to the loss we suffered in the end. To this day, I believe it was the biggest mistake of my career.

Find Time for Technical Reading

As I began to move up the management ranks, I realized how important it was to read technical books and articles at an even more rapid pace than I did when I was a developer. The books were usually less detailed and broader in nature than the ones I read earlier in my career. I would select topics that were related to the technology my team was working on. I didn’t seek to become a world expert, nor did I have an interest in telling others how to do their work. I did, however, want to know enough to engage in meaningful technical debate and to have a high level of confidence in the technical decisions we made as a team.

I studied the leadership styles of the executives I admired most, and most had a deep understanding of the business and the technology that their teams were working on. They contributed actively to important technical decisions and were able to offer new ways to think-through solutions to the most challenging problems.

David Yach, who became the chief technology officer (CTO) of Software at RIM, was one of the most technically competent senior executives I have ever worked with. He was able to modify his depth of technical interaction with ease. He would offer employees expert database design advice one minute and simplify complex issues for nontechnical executives the next. He was an astute leader with an uncanny ability to get the most out of his teams. His technical skills were recognized and respected by all those who worked for him, and he showed considerable respect for their abilities in return. He presented himself with an air of confidence and modesty. People naturally gravitated toward him for advice and input. His humility and his ability to remain calm under pressure were major assets. His employees worked extremely hard, largely because of the strong sense of commitment they felt toward him. As a senior leader, I always tried to improve myself, and I knew the best way to do this was to model my behavior around those I respected the most.

I tried to reserve a few hours a week for technical learning, be it to read a few chapters of a book or to conduct Internet research on a topic that intrigued me. It served to increase my level of confidence, and it enabled me to engage in more meaningful conversations at work each day. When I was at BCE Emergis, we developed our application using a Java 2 Enterprise Edition (J2EE) framework. It was relatively new technology at the time, and I remember spending a lot of time reading multiple books on the topic. I wanted to be familiar enough with the technology to ensure my team did not make another big technical mistake.

In conversations with colleagues, they often made me aware of emerging technologies that I should add to my reading list. It became a never-ending cycle of learning. Over time, it allowed me to amass a significant amount of high-level knowledge across a broad range of technical topics.

I changed industries regularly during my career, from computer systems, to transportation management, to telecommunications, to warehouse automation. As time passed, I developed enough confidence in myself to make these moves without fear, recognizing that the technical underpinnings were similar. Acquiring knowledge across a variety of industries was fun, and it made work more interesting. I found that I was able to become credible in a new industry within two or three months and develop significant expertise in under a year. I would dig into the details of our internal solution, engage in conversations with experts, and read as much as I could about competitive solutions and potential disruptions. I would watch online industry videos, take copious notes, and study aspects of competitors’ solutions that were better than ours. It helped me understand the market, and it provided a baseline from which to debate the advantages and disadvantages of the products we were developing. With the knowledge to back it up, it became easier to present at conferences and to respond to questions with confidence. It made work more fulfilling, and for the most part, a whole lot more fun.

Become an Expert in Your Own Product

When I was at RIM, I made a point of participating in numerous sessions at our annual user’s conference. I usually presented an overview of our products, and I would organize meetings with our largest customers. I knew they were the best source of input, and my objective was to get as much feedback from them as I could. Armed with a relatively deep understanding of our products and at least some knowledge of competitive alternatives, I was keen to have open and constructive discussions. I would usually accept their feedback, but if I disagreed with a specific recommendation, I wouldn’t hesitate to push back with a well-founded counterargument.

In one meeting, senior representatives of several major U.S. banks banded together to jointly share their concerns with us. They felt we were not taking their input seriously and believed the BlackBerry Enterprise Server was falling behind other solutions in terms of functionality. I expected it to be a contentious discussion, so I asked several colleagues who were experts in the targeted topics to join me. The meeting did not start out well. The team from Morgan Stanley launched into a tirade about how difficult it was to set up new users with external scripts. The Goldman Sachs team complained that it was too difficult for them to integrate BlackBerry services with their internal applications. Other attendees piped in with their own complaints. As painful as the meeting was at the start, what I remember most was how we turned it around by the end. It was due to our willingness to listen, our lack of defensiveness, and our depth of understanding. We made several on-the-spot decisions to address key areas of concern, which changed the mood of the room almost immediately. In return, our customers were willing to accept several of our counterarguments.

As the meeting progressed, insults turned into good-natured jokes. An executive from Bank of America approached me after the meeting to let me know how much he appreciated my approach and my openness. He also said that given my role, he was surprised by my level of technical depth. I remember how much it meant to me to hear that. As difficult as these meetings were at times, they did wonders to strengthen our partnerships with our most important customers.

The importance of being a manager who is able to engage in deep technical discussions with customers became clear to me soon after my first management appointment. I was in the IBM booth at an industry developer’s conference to answer questions about our VisualAge for C++ development environment. One of our marketing reps walked into the booth with the CTO of a prospective customer. He asked if I could give the customer a demonstration of our recently introduced static analyzer, a new component of VisualAge that was developed by my team. It enabled developers to highlight variables and methods of an application and to instantly cycle through all associated references. It also displayed additional data that was relevant to each reference. It was a unique component at the time, intended to make developing and debugging applications easier through source code analysis alone.

I did not prepare for a demo, but I believed I knew enough to wing it. It turned out I was wrong. I tried to use the example project that was packaged with the environment, but I had not looked at it before. I launched into my demo and quickly got lost in the details. I began randomly clicking through variable and method names, causing the screen to flash faster than the eye could follow. My demo had no flow to it, and I wasn’t able to effectively convey what was happening. The CTO asked several detailed questions that I was unable to answer. He got more agitated as the demo proceeded, and I became defensive. Beads of sweat began dripping down my forehead. It was not a good look for me or the company.

When it ended, the CTO shook my hand politely and thanked me for my time, but I was keenly aware of my dismal performance. I could see it in his eyes that our marketing rep wasn’t too impressed either. In the weeks that followed, I decided to develop my own mock project to help me better understand the intricacies of the tool. I wanted to make sure I was well prepared if called upon for future demonstrations. I learned how important it was to establish an expert level of knowledge in the products my team developed. I practiced a lot and got much better at giving demos to customers and answering their detailed technical questions. It helped me contribute at a level that many other managers couldn’t, particularly those who believed product demonstrations were beyond their mandates as managers. The embarrassment I felt during my initial demo helped me understand how important it was to continue to focus on my product knowledge and my technical skills.

Understand the Underlying Architecture and Design

Before ProCure.com was acquired by BCE Emergis, the technology was used to help suppliers connect to multiple buy-side procurement networks through a single integration. Due to an industry shift, BCE Emergis became less interested in the solution soon after the acquisition closed. I was under pressure to find another use for the technology we brought into the company. Fortunately, I was invited to a meeting to review another product that was under development for Visa International at the time. The sales and engineering teams were concerned because the project was behind schedule, and they believed it would fail if we continued down the current path. Based on what I heard, I believed they were right. The application was designed for secure processing of large-value business-to-business payment transactions. They called it Visa Commerce. It had absolutely nothing to do with supplier integration into procurement networks. Nevertheless, I understood the technical design and architecture of our product in sufficient detail to recognize some similarities. I believed we could adapt it to meet the Visa Commerce requirements relatively easily. I followed up with senior members of my development team to validate my thoughts. They all agreed, and after several design sessions with the Visa team, we reached a formal agreement to move forward with the new approac...