2026-08-24 22:00:01
The AI boom has disrupted the way engineers work, introducing new tools to learn, raising expectations for what teams can achieve in a workday, and making it harder to get hired in the first place. This makes it difficult to advise students on which specific coding languages or technical skills they should learn. So amidst the uncertainty, advice for young professionals often turns to a common refrain: Be adaptable. But what does adaptability look like in practice?
Engineers often operate on the cutting edge of technology, so dealing with change is a normal part of the job, says Samantha Brunhaver, an associate professor of engineering at Arizona State University, in Tempe. Yet university curricula and training in the workplace often don’t prepare students for this.
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it,” says Brunhaver, who received a National Science Foundation award in 2020 to study how to foster greater workplace adaptability among young engineers. For this ongoing project, she has interviewed engineering managers, early career employees, and undergraduates about their experiences.
Part of the problem, she says, is that every employer has its own idea of what to be adaptable means. Generally, Brunhaver defines adaptability as “the ability to recognize that a change or uncertainty is occurring, and then respond effectively to that change.” But the skill is context-dependent. In software engineering, that might mean responding to turnover in the tools you use on a daily basis, while aerospace or biomedical engineers may need to keep track of changing procedures and regulations. “Managers are all saying adaptability is important,” Brunhaver says, “but defining it in different ways.”
At the same time, engineers are all contending with changes beyond these industry-specific expectations. Jobs in the technology, media, and telecom sectors are experiencing the fastest pace of skill turnover, according to a June 2026 report on the effects of AI from the professional services network PwC. And the World Economic Forum’s most recent Future of Jobs Report, published in 2025, found that employers across all sectors expect 39 percent of workers’ core skills to change by 2030. This uncertainty can be uncomfortable. But with the right mind-set and support from leadership, adaptability can help keep you afloat.
The AI transition is a big shift—but not an unprecedented one, says Jenna Butler, a research scientist at Microsoft who studies developer well-being and productivity.
During this type of paradigm shift, there is often a “chaos period” when a new normal is being established, Butler says. In AI’s case, it challenges the understanding of what a computer can do. “I think we’re still in this in-between, difficult period that we’ve seen before, but [it] is maybe moving faster than it has historically.” Software engineers—in one of the fields most affected by AI—are now facing a significant increase in code review. “If you ask 20 developers, you get 23 different ways of working with it. Everyone is trying to sort it out,” says Butler, who describes this period as “the uncomfortable middle.”
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it.”– Samantha Brunhaver, Arizona State University
Brunhaver says one way educators can help prepare students before they enter the workforce is by offering a diversity of real-world experiences, such as internships, team-based projects, community service, and leadership roles. Each of these teach students to adapt to different challenges, easing their transition from school to work.
It’s also important to encourage reflection, Brunhaver adds, noting that metacognition helps individuals use the skill more effectively. “In order to adapt, you have to think that you have agency and the ability to get through a situation.” Ultimately, it comes down to three steps: Perceive a need to adapt, evaluate your options, and act.
For those already in the workforce, that action may mean taking the time to learn new tools and ways of working. Software engineering, for instance, may soon rely more on prompting models and managing agents than coding line by line. “I think people who went into software because they like solving problems are going to have a lot of fun, and people who just enjoy the art of writing code are not,” Butler says.
Although the tools engineers use on a daily basis are evolving, the core responsibilities of the job are more stable than they may seem, says Andy Hunt, a software developer who coauthored The Pragmatic Programmer (Addison-Wesley Professional) in 1999. The book outlines practical coding principles, and has been taught in many computer science classrooms. When Hunt was working on the 20th anniversary edition of the book, he was surprised by how much of the advice still applies. And now, seven years later, he maintains that belief.
“The fundamental part of the job is problem solving and communication, and that’s always going to be there,” he says.
Hunt emphasizes the importance of developing systems thinking over particular tools. To him, identifying as a Java programmer, for instance, is “like a carpenter saying, ‘I’m a hammer user,’ or ‘I specialize in cordless drills.’ ”
He acknowledges that today’s hiring process, in which companies often filter résumés for certain languages or years of experience, makes it harder to embrace a more expansive way of relating to your job. Employers, he says, should recognize that “the tech’s not the hard part, and it never has been. Understanding information theory, understanding systems thinking, understanding what constraints you’re up to—that’s still the hard part.”
With this type of misalignment between employers and employees, AI is also intensifying an old source of tension: How can engineers slow down enough to adapt and learn new tools when the pressure to become more productive keeps mounting?
Young engineers need to embrace change. However, educators and employers also play a role in building a successful workforce. From the educator’s perspective, Brunhaver says “we need to be more explicit about what [adaptability] means and why it’s important.” Managers, meanwhile, should invest in their employees’ professional development.
Microsoft research scientist Butler often encourages leadership to set aside intentional time for continuous learning for their engineers—even just an hour a week—without any expectation that they will produce code or progress in their daily work. “I realize that’s difficult,” says Butler. “I would encourage people to do it on their own, but I would really encourage organizations and leaders to do it, because you’re not going to get this sudden change in your people if they don’t have time and space to learn how to work differently.”
This also means providing enough instruction, Butler adds. When developers aren’t given enough guidance on adopting something new, while being pressured to increase productivity, they risk doubling down on the tools they already know and burning out.
“I do imagine the next number of years could be challenging,” Butler says. Engineers will have to adapt to find their place in an evolving workforce—but they also have a say in shaping that future.
“Being adaptable sort of implies that you’re going to change based on what’s happening around you, and I would really like people to realize the change that’s happening is somewhat up to us,” she says. All individuals have a choice in how they use AI, for instance, and which models they use. “We need to be adaptable and go with the flow to a degree, but we also need to be directing that flow. The future with AI is absolutely not predetermined.”
This article appears in the September 2026 print issue as “The Adaptable Engineer.”
2026-08-24 19:37:02
This article is brought to you by Emerson.
I’ve spent much of my career as an engineer, including years in the semiconductor industry. And one lesson has stayed with me through every major technology shift: innovation always creates new complexity.
In semiconductors, we have seen that repeatedly. Every generation has delivered breakthroughs in performance and capability, but each step forward made it harder to understand system behavior. What used to be easy to validate on the component level with a test bench now needs a much wider view.
“The future of engineering will be defined by who can verify, understand, and improve complex systems fast enough to safely keep innovation moving forward,” says Ritu Favre, President of Emerson’s Test & Measurement business group.Emerson
Chiplet-based designs are a prime example. A chiplet from one supplier, an interposer from another, and a packaging process from a third may all perform perfectly on their own. Yet there is a chance for unexpected behavior when you put them together in a system. More and more often, the hardest engineering challenges are not in the individual components themselves. The problems are found when we start to combine components and have them interact with each other.
These challenges extend far beyond semiconductors. Products are becoming more software-defined and dependent on interactions across different technologies and environments. Think about the interactions needed for a modern car using adaptive cruise control on a bumpy road in a rainstorm. Or a passenger jet adjusting wing flaps and engine speeds in turbulent weather to maintain safety and stability. Both the car and the jet are being guided by complex computer systems with thousands of sensors leading to thousands of interactions every second. And in many cases, there are multiple computer systems working together. We are building systems of remarkable capability but understanding how they will act under real-world conditions is getting harder.
That is why I believe we are entering a new era of test. The defining challenge of modern engineering is no longer simply what we can design and build. It is what we can confidently verify.
In this new era, test can’t be an afterthought. For decades, test was treated as the final checkpoint before release. Design teams developed a product, test teams validated performance, and organizations looked for a final pass/fail to determine whether they were ready to move forward. That model worked fine when systems were more self-contained and predictable. Today, that approach can lead to more risk.
I believe we are entering a new era of test. The defining challenge of modern engineering is no longer simply what we can design and build. It is what we can confidently verify.
Many of the delays and fire drills we face come from issues that were not visible early enough. Problems discovered late in development are more difficult to diagnose, more expensive to fix, and more likely to get you off schedule. The solution is not more testing at the end. The solution is to make test and verification part of the engineering workflow from the start.
When validation is integrated throughout development, teams catch problems early when change is easier. Test also stops being a barrier to release. Instead, it becomes a source of insight, helping us understand how systems behave as they become more connected.
When confidently verifying technology becomes the key challenge, the tools we choose take on a different level of importance. The tools have a direct impact on how quickly we can diagnose a problem and keep moving forward. In an environment where technology changes rapidly, disconnected tools get in the way of progress. Modern test strategy requires linking information across design, validation, and production, turning measurement data into decisions made quickly enough to keep pace with innovation.
This reminds me of when EDA was first introduced. Before it came along, engineers spent much of their time hand-drawing circuit layouts and placing transistors. EDA eliminated that tedious work by letting teams describe complex behavior in high-level code. It enabled them to focus on overall architecture instead.
A connected test platform does a similar thing for validation. Because a platform can adapt and scale alongside technology, it cuts down on maintenance and downtime, keeping teams from having to rebuild their workflows from scratch as requirements change.
Today, AI is rapidly entering the engineering toolkit to accelerate design and analysis. But in test and measurement, AI cannot reach its potential in isolation.
An AI model is only as effective as the data feeding it. Without context, even the smartest algorithm will struggle to tell the difference between normal hardware variance and a critical failure. A connected platform supplies the structured, traceable data stream AI requires to deliver real insight.
AI can correlate complex multi-system interactions, flag unexpected behavior, and direct an engineer’s attention right at the root cause.
When measurement data flows seamlessly across the workstream, AI moves from being a standalone tool to an active layer of intelligence. It can correlate complex multi-system interactions, flag unexpected behavior, and direct an engineer’s attention right at the root cause.
Every technology shift that accelerates how fast we create new designs also increases the complexity we must verify. AI can help teams keep pace with that complexity. Not by replacing human judgment, but by giving engineers the context we need to act with confidence.
Ultimately, the goal of modern platforms and AI-enabled workflows is to help technical teams spend more time building new things and solving hard problems. Most of us didn’t choose this profession to spend our time searching for data or dealing with last minute surprises. We want to innovate and integrating test directly into development provides a better view of system behavior, allowing teams to focus on that innovation rather than managing complexity.
The future of engineering will not be defined by who can build the most advanced product or technology. It will be defined by who can verify, understand, and improve complex systems fast enough to safely keep innovation moving forward.
That is the new era of test. As the pace of innovation accelerates, every breakthrough creates new paths to failure, and test is how engineers find those failures before the real world does. In an increasingly complex world, that capability is becoming as important as innovation itself.
Innovation has always required great engineering. And now, more than ever, it also requires confidence. Confidence that comes from knowing that we are not only building what is possible, but we are also building technology that people can trust.
2026-08-23 21:00:01
How do I touch you
across the ocean,
across cold depths
where light travels through glass.
Not copper—fibers. Optical.
Through liquid glass, through flickering light
that carries you in fragments. Light broken into pulses.
You say: it’s easier this way. What are we missing like this? You smile.
Safe distance.
I say: network.
Signals slide beneath the sea, through cables thinner than trust, faster than touch,
slower than longing.
We stand alone, together. Synchronous, yet apart. Icons replace skin, latency replaces breath.
This distance protects us. Silence that feels intentional.
Everything is under control as long as nothing truly hurts.
And we choose it
because it shields us
from what we might become if we actually met.
You are my counterpoint. My response.
My reflection
at a safe distance.
Beneath the ocean, nodes remember paths.
Packets shake hands without bodies.
If we get lost,
we resend everything, with error,
with noise,
with hope.
2026-08-22 02:00:01
Balaji Ingole rarely saw televisions while growing up in Udgir, India. No one in the small Maharashtra village had computers or phones. Only one household owned a television, and neighbors often gathered there to watch shows together.
Ingole never even saw a computer growing up. It wasn’t until he reached middle school that he encountered a computer lab, an experience he says changed his life. Almost immediately, he says, the machine felt like a window into a different scale of possibility for him.
Employer
Amla Commerce in Milwaukee
Title
Project manager
Member grade
Senior member
Alma maters
COEP Technological University and Welingkar Institute of Management, both in India
“I was very studious and not very social, always reading or solving problems in a math textbook,” he says. “At the computer lab, I began learning the C programming language—which was like discovering a whole new world. I was fascinated that you could create something with just a few lines of code.”
His early interest grew into a self-directed education. Outside of Ingole’s formal classwork, he taught himself to build database-backed applications, wire up hardware, write software, and trace error logs.
Today the IEEE senior member similarly splits his time. During the week, he’s a project manager in Milwaukee at B2B e-commerce company Amla, leading AI-driven digital transformation initiatives to help the company’s clients boost their sales. On weekends, he leads a similarly demanding life as an independent researcher. His current projects include developing AI-enabled health care diagnostic tools and assistive technologies to support people with physical disabilities.
“I believe in ‘learn by doing,’” he says. “I really like to test my knowledge and prototype ideas to find out if they truly work.”
Ingole’s tendency to go beyond his coursework continued after he graduated high school in 2004. As a mechanical engineering undergraduate at The College of Engineering, Pune (now COEP Technological University), in India, he participated in several extracurricular activities. One was interviewing entrepreneurs and writing about them for The COEP College Magazine. The experience helped him gain confidence, he says, giving him the push he needed to pursue interviews for the publication with two Indian entrepreneurs he admired: N.R. Narayana Murthy, cofounder of IT giant Infosys; and his wife, philanthropist Sudha Murty. The Murtys cofounded the Infosys Foundation, a nonprofit that runs educational, health care, women’s empowerment, and sustainability programs in underserved areas of India.
“Every week I would fax them: ‘Please give me an interview time,’” Ingole says. Eventually, Sudha Murty’s office offered him a phone interview, but he requested to meet her in person at Infosys’s Bengaluru offices. She agreed, but the offices were 940 kilometers from Pune, and he didn’t have the money to travel or stay overnight in a hotel.
Ingole and a classmate borrowed money from friends and traveled through the night on multiple buses and trains to get to Bengaluru. They freshened up in a public bathroom before heading to the Infosys campus to meet Murty.
Impressed by their persistence, she surprised them by also arranging a brief chat with Narayana Murthy.
“Narayana Murthy handwrote a personal message to the engineering students of [my college]—which we proudly published in our college magazine,” Ingole says. “In his note, Murthy shared that we are at an extraordinary moment in India’s history and that the future looks even brighter. His words encouraged us to work hard and make the most of this time.
“I still have that note,” Ingole says. “They are billionaires, and I was just a regular student. The fact that they took the time to do this really motivated me.”
During the final semester of his engineering studies, Ingole joined the Tata Research Design and Development Center in Pune for a six-month internship. After earning his bachelor’s degree in mechanical engineering in 2008, he became a graduate engineering trainee at Honeywell Automation in Pune.
He left the company in 2009, and during the next 13 years, he held different software engineering and project management positions at IT companies across India.
He earned a master’s degree in business administration from the Welingkar Institute of Management, Mumbai, in 2017.
In 2022 he accepted a project-manager role at Mars IT Solutions in Madison, Wisc. The following year, he left to join Gainwell Technologies, also in Madison, as a senior project manager. At Gainwell, he managed projects for the core IT systems multiple U.S. state health departments use to administer Medicaid benefits, manage provider enrollment, and verify member eligibility. The experience managing projects that directly enabled patients’ access to health care gave Ingole a special appreciation for and interest in this area, he says.
“Health care data is not like other data,” he says. “The stakes are high, compliance requirements are different, and the margin for error is effectively zero.”
Ingole says he enjoyed the rigor of data governance combined with the potential to positively impact lives, and that also applies to his current work at Amla.
Ingole joined Amla in July 2025. He helps manufacturers and B2B customers modernize their e-commerce operations. He also builds AI tools for them and for his internal team.
For Amla’s customers, he’s developing AI-enabled chatbots that help manufacturers set up and manage large product catalogs in e‑commerce platforms. Such product setup traditionally has been a manual, tedious, error-prone process: Companies upload thousands of products, adjust item names, enter prices, update images, and more.
“Product setup has been one of the most painful processes in e-commerce, and it can take [our] customers two to three months to complete,” Ingole says. “We’re creating an AI agent that will guide them, step-by-step, to get everything set up in two weeks.”
Ingole relies on AI agents for some of his own tasks at Amla. Project managers historically have spent 10 to 12 hours each week assembling and sending status reports to stakeholders. Ingole built an AI agent to handle much of the work.
“It runs every Monday morning and reads through my emails to extract highlights, risks, timelines, and upcoming releases, then sends me a written status report,” Ingole says. The process might sound simple, but the agent’s workflow involves at least a dozen steps including defining parameters, managing temporary files, and integrating with existing tools.
With the information-gathering work handled, it frees up Ingole and his colleagues to spend more time on deeper-thinking work, he says.
For nearly a decade, Ingole has spent some of his free time conducting independent research projects in data analytics and AI-enabled applications in health care. He has written more than 40 peer-reviewed papers, which are in the IEEE Xplore Digital Library. He has been granted six patents in the United Kingdom and India. In the U.K., he is a registered coinventor of an AI-powered, cloud-connected wearable device for health monitoring and an AI-based breast cancer detection tool.
Ingole’s patent for the breast cancer detector, he says, reflects his belief that when engineers apply data and AI correctly, they can help doctors diagnose patients more quickly and accurately.
That, he says, is both a power and a responsibility.
He is part of a team helping patients who are paralyzed and nonverbal control items in their environment. His goal, he says, is to develop a brain-computer interface to let patients turn on a fan, switch off a television, and complete similar tasks.
Publishing research requires both academic rigor and peer scrutiny, and Ingole says the function has been critical to improving as both a project manager and a researcher-inventor.
“Lots of research ideas never make it to paper,” he notes. “But when you write for journals or conferences, you’re bombarded with questions from Ph.D.s and experienced researchers. This forces me to refine my methodology, and to combine use cases and technical architecture in a way that stands up to expert review.”
Ingole joined IEEE in 2022, and he says the affiliation has become central to both his research and his professional identity.
“I use the Member Directory often and contact engineers through my IEEE email address, which gives me credibility because they know it’s a genuine research connection,” he says.
The organization has given him a platform to contribute to the research space beyond his own papers, he says. He has served as a conference session chair, keynote speaker, technical program committee member, and peer research reviewer for various conferences and events. His IEEE membership, he says, has opened doors to other communities, helping support his entry into the British Computer Society, which has stringent acceptance criteria.
Those opportunities have helped him build a global network of collaborators with whom to discuss upcoming research, seek advice, and share data, he says.
“IEEE is important for me to continue as an independent researcher,” he says. “It lets me contribute to the community, and I get a lot in return.”
2026-08-21 22:32:37
About this Webinar
Turn Yield Excursions into Faster, More Confident Root Cause Analysis
When a yield issue emerges, the answer rarely lives in a single system. Critical clues are spread across metrology data, tool traces, chemical analysis, and facilities systems, while growing data volumes make traditional dashboards slow, fragmented, and difficult to act on.
What You’ll Learn:
Discover how a purpose-built semiconductor analytics platform can help engineers connect insights across domains without moving data. See how Agentic AI, semiconductor-specific visualizations, and push-down compute enable faster investigation of yield excursions and process issues, even across billions of data points. In the session, a live demonstration shows how to conduct a multi-domain root cause investigation using Spotfire® Industry Pro.
Key Takeaways:
Who Should Attend:
Yield, Process, and Integration Engineers; Fab and Manufacturing Operations Managers; Quality and Reliability Engineers; and Data & Analytics leaders supporting wafer fabs, foundries, OSATs, and IDMs who need to identify issues faster while maintaining confidence in decision-making.
Save Your Spot!
Join this webinar to learn how leading semiconductor teams are accelerating root cause investigations, scaling analytics across massive datasets, and transforming disconnected data into actionable manufacturing intelligence. Reserve your seat today.
2026-08-20 02:00:02
This article is part of our exclusive career advice series in partnership with the IEEE Technology and Engineering Management Society.
Imagine this: You have a strong idea for a new product for your company. Your coworkers encourage you to move forward because they believe it could be the organization’s next big success. The idea clearly falls outside your department’s responsibilities, however, and you have no role in the product line.
What should you do? Sit and wait for “the right group” to pick it up, or push the idea forward without knowing how or what it might mean for your current position?
Such situations occur frequently. Many end up as missed opportunities, even though they could have significantly advanced the company’s technological or market position.
Some organizations actively support such initiatives, allocating specific periods during the workday for employees to focus on developing their own ideas.
Companies known for that include Google and 3M. They allow employees to pursue projects with a portion of their time, such as one day per week. Research that I conducted indicates it pays off for employee performance.
At some companies, managers know such projects exist, but they deliberately turn a blind eye, allowing them to continue.
Some employees persist through bootlegging or skunkworks projects.
Bootlegging projects have not been approved by a manager or funded by the company.
Skunkworks projects involve a small team within the company that has been given authority and funding to secretly research and develop potentially groundbreaking innovations during their off-hours. The term comes from Lockheed’s Skunk Works division, set up in 1943 in a rented circus tent to build the P-80 fighter jet in secret. It took just 143 days.
The 3M Post-it Note came out of the company’s “15 percent culture,” described as a permitted bootlegging policy. It gives employees paid time off to pursue their own ideas.
The company traces the philosophy to its longtime president and later chairman William L. McKnight. Company scientist Arthur Fry used the policy in 1974 to turn a colleague’s dormant adhesive into the first Post-it prototypes, after his own bookmarks kept falling out of his hymnal.
There are several examples of high-visibility skunkworks projects. At Apple, Steve Jobs pulled roughly 20 people—pirates, as he called them—out of the company to build the original Macintosh computer in a building nicknamed Texaco Towers. In Walter Isaacson’s biography Steve Jobs, he frames the idea as modeled on the skunkworks approach.
Google’s Gmail system is frequently—and incorrectly—cited as a product of the company’s “20% time” policy. In a 2014 interview with Time magazine, the system’s creator, Paul Buchheit, said Gmail was in fact an official assignment. What the Gmail incubation did share with classic skunkworks projects was secrecy: For much of its three years in development, it was kept hidden from most people inside the company.
If you want to drive change in your organization, build a promoter triad around your idea.
At Alphabet, Google X—now known simply as X—operated as a secretive “moonshot” lab, kept hidden from most Google employees, according to a 2011 article in The New York Times. Google’s self-driving car project graduated from X to become Waymo, and Google Glass was likewise incubated there. The X team is now developing the second edition of Glass Enterprise, a successor aimed at industrial rather than consumer use.
Amazon runs a comparable model through Lab126, which, according to an article in Fast Company, evolved from a small skunkworks Amazon subsidiary into a hardware maker with nearly 3,000 employees. Lab126 delivered the Kindle in 2007 and the Echo in 2015.
Then there are so-called submarine projects, which employees work on without permission and despite explicit disapproval. They can lead to disciplinary action and termination.
Innovation management theory offers a more structured and robust approach. It argues that successful organizational change requires support at several levels, according to “Teamwork for Innovation: The ‘Troika’ of Promoters,” published in R&D Management. The promoter theory, developed around 25 years ago, consistently shows that change projects are far more likely to succeed when they are supported on multiple organizational levels. A good idea alone is not enough; you need a network of technology, process, and power promoters to turn a concept into a fully implemented, scalable solution.
First, you need a technology promoter: the person who has the idea, such as a new product, and possesses technical expertise and specific knowledge about the field or industry. Art Fry at 3M would be such an individual.
How can you put that into practice as an individual? Start by clearly formulating your idea into a concise concept paper or one-page summary including benefits, technical feasibility, and potential business impact.
Identify potential technology promoters (experts who can validate and refine your idea), and approach them early to strengthen the technical foundation.
In parallel, map the relevant stakeholders and decision-makers, and identify process promoters who understand how decisions are made in your company. They could be colleagues in innovation, R&D, or business development who understand your idea and how it can benefit the company.
The second is a process promoter: someone who might not know all the technical details but understands the organization’s formal and informal networks and knows how to navigate its processes, committees, and decision-making paths. This person can ensure the idea reaches the right stakeholders at the right time.
In the 3M case, it would be a person from the organizational management department, often called an innovation manager. The key role here is to connect inventors such as Fry with people from other departments needed for further project development, such as manufacturing, quality control, and sales.
Lastly, there’s the power promoter: a person in a leadership position who might not know the technical details but can allocate resources, eliminate obstacles, and maneuver through the company’s political dynamics. This individual has hierarchical power and acts as a sponsor of the idea or project. In the case of Fry, the person could be, say, the chief technology officer, but it also could be a middle manager who has the power for an individual field of action.
The three-level promoter structure applies regardless of whether the change concerns a new product, new service, or internal process innovation.
Engage potential power promoters by presenting a low-risk, small-scale pilot and a clear value proposition. Leaders are more likely to support ideas that are well prepared, vetted for potential risks, and backed by a small coalition.
In short, don’t work in isolation. Systematically build alliances across expertise, networks, and hierarchical levels to create lasting change. If you want to drive change in your organization, build a promoter triad around your idea.
The tech experts and leadership promoters are easier to identify. Process promoters are often found in corporate innovation management, R&D management, or strategy functions, but they also can emerge in line units with strong internal networks.
Innovation management, as the promoter model describes it, looks nothing like the management structure most engineers are trained to expect. Traditional technical management runs on a single reporting line. With the promoter model, influence is spread across three people—technology, process, and power promoters—who may be in different departments, at different levels of seniority, and who might never share a reporting line.
What holds the trio together isn’t a formal structure; it’s the idea itself, for as long as it takes to move the idea forward.
That makes innovation management closer to networked, matrix-style leadership than to the pyramid most engineers picture when they hear the word management. It’s worth understanding both models before you decide which kind of impact you’re actually optimizing for.
The Institute has covered the tension from the individual’s side in “Tips for How to Think Like an Entrepreneur,” “Management Versus Technical Track,” both published in partnership with the IEEE Technology and Engineering Management Society, and “What to Consider Before You Accept a Management Role” from the IEEE Spectrum Career Alert newsletter. All are worth a look if you’re weighing a formal management track against staying close to the technology itself.
Remember: You don’t have to build your promoter network alone or only inside your own company. IEEE societies, sections and chapters, and technical committees, as well as the networking platform IEEE Collabratec, function as a ready-made cross-company network. They are practical places to find technology promoters with deep expertise in a field you don’t fully own yet, or to meet process and power promoters at other organizations who have built a promoter coalition around a similar idea.
For more tips on how to advance your career, check out our Career Advice for Engineers, From Engineers collection.