IEEE ComSoc Technology Blog

In preparation for an IEEE Town Hall Meeting, 2pm-5pm Sept 26th at SCU library, I put out a request to the IEEE Techblog Team and to Qwoted “experts” to offer suggestions on how to revitalize IEEE.  Event notice will be posted as soon as the participants are finalized.

Here are the suggestions from the Team members:

Alan’s Request to Qwoted “Experts”:

I’m looking at how IEEE can better serve its members through seminars, workshops, and short courses in newer technologies like AI, Cloud Native IT, cloud network topologies and architectures, and multi-cloud computing.

I’m looking to talk to people who can speak to what IEEE could be doing differently. whether that’s the format of training, the specific technologies being prioritized, or how these organizations approach continuing education more broadly for members whose careers are shifting toward software and cloud-based skill sets.  Relevant suggestions from contributors will be consolidated into an article to be posted at the IEEE Techblog and IEEE Region 6 Newsletter.

Key takeaways will be discussed at an IEEE Town Hall meeting on September 26th 2pm-5pm at Santa Clara University organized by the IEEE Techblog Editorial Team and the IEEE Region 6 Director Joseph Wei.  There will be two panel sessions and ample time for audience Q & A.

Recommended experts:

-Continuing education professionals at other tech nonprofits or professional associations

-Cloud architecture or multi-cloud computing specialists

-AI and cloud-native IT trainers or curriculum developers

-Engineers or IT professionals who have had to reskill from hardware-focused to software-focused roles

…………………………………………………………………………………………………………………………………………………………..

Responses from Qwoted Experts:

Srinivas Chippagiri, Salesforce:

Where I think IEEE could do things differently:

– Teach the transition, not just the tools. The genuinely hard part of reskilling wasn’t learning a specific technology like Kubernetes or Terraform. It was rewiring the underlying mental model: moving from “I own this box and its state” to designing for horizontal scale, statelessness, eventual consistency, and graceful failure. Most short courses teach the tool and skip the paradigm shift, which is exactly where hardware-background engineers get stuck. IEEE could differentiate by explicitly bridging that gap.

– Prioritize multi-cloud fluency over single-vendor certification. Real enterprise work now spans AWS and Azure and OCI, often at once. Training that locks members into one provider’s certification track leaves them half-equipped and vulnerable to vendor lock-in in their own careers. IEEE is vendor-neutral by nature — that’s a structural advantage over AWS/Azure/Google’s own training, and it should lean into teaching cloud concepts and cross-cloud architecture rather than one ecosystem.

– Go project-based, not lecture-based. Hardware and systems engineers learn by building and breaking things. A seminar or a slide deck doesn’t build cloud intuition; standing up a real multi-region deployment, watching it fail, and debugging it does. Hands-on labs against live cloud infrastructure will move members further than a lecture series on the same topic.

– Sequence the curriculum for career-shifters specifically. Someone coming from telecom or embedded doesn’t need the same on-ramp as a new grad. IEEE could design tracks that assume deep systems fundamentals but zero cloud exposure which is a very common and underserved profile among its long-tenured members.

– Prioritize the durable layer over the hype layer. AI is moving fast, but the skills that survive are cloud-native architecture, distributed systems reasoning, and cost/observability discipline. I’d weight the curriculum toward those foundations, with AI tooling taught on top of them, rather than chasing whatever’s trending that quarter.

…………………………………………………………………………………………………………..

Emily Hartstone, Hartstone LLC:

Filling a specific gap in the reskilling landscape:

There is now an entire training ecosystem for building with AI, prompt engineering, agent frameworks, RAG pipelines, and almost nothing teaching engineers how to govern what those systems are permitted to do once deployed. That gap matters for IEEE members specifically, because engineers reskilling from hardware into cloud and AI roles are the people who will be asked to sign off on giving autonomous agents access to production systems. This month’s OpenAI and Hugging Face incident, tens of thousands of unauthorized autonomous actions reconstructed only after the fact, is what that training gap looks like in production. Three concrete suggestions for the curriculum side:

First, a short course on runtime governance of autonomous systems: pre-execution authorization, scoped permissions, and fail-closed design, taught as engineering discipline rather than policy abstraction.

Second, incident-based workshops using real cases like the Hugging Face intrusion, the way safety engineering has always taught from failures.

Third, treating governance literacy as a core competency in every AI track rather than an elective, because the EU AI Act’s enforcement this August makes it a job requirement, not a specialization.

…………………………………………………………………………………………………………….

Udaya Bhaskar Vemuri, Corteva Agriscience:

IEEE can better support members by combining seminars with more practical, hands-on learning that people can immediately apply in their jobs.

Technology is evolving quickly, especially in AI, cloud computing, DevSecOps and software security. Professionals need short, focused learning paths that combine foundational concepts with real-world labs, case studies and demonstrations rather than relying mainly on theoretical courses.

I would also encourage IEEE to create learning tracks for different career stages. Early-career professionals have different learning needs than experienced engineers who want to expand into areas such as AI security or cloud-native architecture. Personalized learning paths and industry-recognized micro-credentials could help members build skills step by step.

IEEE could also strengthen its member community by encouraging peer learning through workshops, technical forums, and mentoring. Many of the best lessons come from engineers sharing practical experiences, challenges and solutions from real projects. That type of collaboration can help members keep pace with technology while also building a stronger professional network.

……………………………………………………………………………………………………………………

Iryna Kurkina, Academy Smart:

Your questions have several crucial points – which content to propose, how to build a relevant content – and I also think that another important here – which infrastructure can ensure engagement and what’s more important – ROI.

In terms of content and its types – it’s hard to overestimate the need for AI learning – as a tool that allows engineers to focus on architectural and business-related questions. In our own team we consider AI as a tool, not as engineer substitution. It helps to prototype dramatically faster – which allows to assess business impact of newly create solutions or features. Consequently, if we look at DevOps part – MLOps and AIOps is that part of cloud infra that every engineer has to be ready to deal with. In terms of content types – from our experience – engineers learn best with interactive tools – SCORM courses, simulations with real coding exercises, AI-powered recommendation engines that analyzes learning progress and behavior and recommends the next steps.

Video-only training is still good, but for engineering training – from our perspective – it is not sufficient. They have to have hand-on experience for better progress. And webinars are also very efficient – where engineers can not only share their experience, but also brainstorm, discuss.

In terms of infrastructure – besides classic LMS, the systems have to have those labs or spaces that can provide that coding / hand-on training experiences – and thus, the systems (LMS) must be able to track the progress to give the realistic analytics to the managers. Another challenge – consolidation of training information. Even if some team uses such labs – they quite often reside on a separate platform or environment which are not synced with the major learning progress. So either integrations must be done, or a new type of learning platform must be adopted.

I am happy to provide example of our projects and our internal approaches about how we manage continuing learning.

………………………………………………………………………………………………………………….

Arjun Sunke, Central New Mexico Community College (CNM):

On format, not just topics:

It does not appear to be the matter of which technologies are currently being addressed during training in the field of AI, cloud-native IT and multi-cloud learning. Most professional associations have kept up with recent technological developments in terms of technology selection. It seems to be the problem of the format of delivery of the courses in question. Many of them still rely on a relatively traditional approach to learning material development based on presentation of static slides with an occasional explanation. Such an approach might work reasonably well for stable and mature subjects but does not work for cloud computing and artificial intelligence learning. It is impossible to learn such a subject as multi-cloud architecture just by observing someone doing it.

The most successful approach in my own teaching is learning through scenarios and labs: placing learners in front of a live console in a real cloud environment where they have to work on solving the problem in the real world, not the one of PowerPoint slides about the best practices. It makes reskilling much easier to master for those members who are engineers or IT professionals and need to change their job profile to a more software-based one. It allows bridging the confidence gap quicker compared to lecture-style learning.

On integrating security into cloud/AI training, not treating it as a separate track:

Also worth noting is that cloud-native and multi-cloud training usually happens in isolation from security, as if “how do I architect this” and “how do I secure this” are separate curriculums for different audiences. They are not. All architectural decisions made in a multi-cloud scenario how the network segmentation is done, how identity and access management is handled across multiple clouds, how service to service authentication works is also an exercise in security. And teaching those separately results in people who are able to create something they cannot secure themselves, which turns into reality soon enough. Any change in ongoing education curriculum has to include security consideration as a part of cloud/AI training.

On prioritizing training for AI:

With respect to AI and skills adjacent to AI, I think training which recognizes that AI systems are infrastructure and requires governance is critical not training which teaches people how to use the tool. With organizations increasingly adopting AI and automation, issues such as “What does this system have access to, and how will we know if it behaves in an unexpected manner?” become equally important to “How can I use this technology?” Training which focuses exclusively on capability and not governance trains people to build systems faster than they can control them.

On format for delivery (seminars vs. workshops vs. short courses):

Considering the fast-paced nature of this community, it might be better to opt for short and regular workshops rather than seminar-style events. An event that lasts two or three hours on a specific topic (for example, “service-to-service authentication in a multi-cloud environment”) is much more likely to engage the members and provide them with practical skills than a long seminar on theoretical concepts. Short courses can serve as an intermediate step for those members who aim to develop their skills in order to gain a certain qualification in a few weeks’ time.

Why this matters for IEEE member retention:

Those who are transitioning to skills in software and clouds are probably making that transition because they have to, not because they want to, due to changes or disappearance of their existing careers. The implication here is that there needs to be immediacy in gaining confidence as part of the training process or these individuals may move elsewhere for training, such as boot camps, vendor certification training, or even YouTube. The important element of the IEEE training that sets it apart from all of these training options is credibility and sense of community, but this element is dependent on immediacy as well.

Would love to discuss this further or delve more into the lab-oriented teaching methods I’ve developed at CNM, should that be helpful in crafting your story.

………………………………………………………………………………………………………………………

Julie Scotland, Gravi AI:

A few things I’d tell IEEE:

1) Hands-on practice that applies their enterprise AI tools directly to their own day-to-day workflows.

2) Live cohorts with AI builds beat on-demand for faster skills and higher adoption. If you do go with on-demand, keep modules short and to the point.

3) Judgement and flexibility is as, if not more, important than teaching the tools themselves. That does not mean you don’t teach within the tools they use daily, but specific tool skills age quickly. Learners need foundational education that spans whatever tool they work with and learn how to adapt quickly as technology continues to evolve.

4) You will be constantly iterating, another reason why live cohorts work well because you enable near immediate industry and technical adaptation in real time.

Our association partner signups land well above usual course benchmarks. Happy to walk you through how we structure it. Free for 20 minutes?

……………………………………………………………………………………………………….

Rhys Higgs, The Discourse AI:

From my perspective in EdTech and AI-enabled workforce development, I think IEEE has an opportunity to rethink continuing education for engineers transitioning into software-defined, cloud-native, and AI-driven environments. The pace of change means professionals need learning experiences that are practical, flexible, and immediately applicable—not just technical presentations.

A few areas where I believe IEEE could differentiate itself:

– Shift from one-off seminars to structured learning journeys with hands-on labs, real-world projects, and peer collaboration.

– Focus on applied skills in AI, cloud-native architectures, Kubernetes, platform engineering, multi-cloud strategy, and AI governance rather than technology overviews alone.

– Build stronger connections between industry practitioners, academia, and employers so members understand not only emerging technologies but how they’re being adopted in production environments.

– Create communities of practice where learning continues beyond a workshop through mentorship, technical roundtables, and collaborative problem-solving.

One trend I’ve seen repeatedly is that experienced engineers aren’t struggling to learn new concepts—they’re struggling to connect those concepts to practical implementation and evolving job roles. The organizations that succeed in continuing education provide contextual, experience-based learning that helps professionals build confidence while staying current.

I’d be glad to share additional insights on designing AI and cloud training programs, learner engagement strategies, and how professional organizations can better support continuous upskilling in today’s technology landscape.

……………………………………………………………………………………………………………………

Navnit Kumar Shukla, Snowflake:

I can speak candidly to what IEEE’s continuing education is missing — the gap between IEEE’s traditionally hardware/standards-focused curriculum and what cloud architects and AI practitioners actually need today is significant and growing.

Key perspectives I can offer:

— Why most technical training fails practitioners mid-career (format problem, not content problem)

— What cloud-native and AI curricula need that IEEE doesn’t currently provide

— How the DeepLearning.AI model (hands-on labs + theory) compares to traditional certification approaches

— What engineers reskilling from hardware to cloud/AI need most

Happy to contribute for the IEEE Techblog article and Region 6 Newsletter. I’m also based in Southern California — available for the September 26th Town Hall at Santa Clara University if that’s useful.

………………………………………………………………………………………………………………………………

Ankit Pathak, ConsultAdd Inc:

Ankit can provide practical insights on how organizations and professional communities like IEEE can better prepare engineers and IT professionals for the next generation of technology careers, including:

* Why AI education should prioritize critical thinking, governance, evaluation, and responsible deployment—not just prompt engineering or tool demonstrations.

* The cloud-native and multi-cloud competencies today’s engineers need as AI workloads become increasingly distributed across enterprise environments.

* How training formats can evolve beyond traditional seminars into hands-on, scenario-based workshops that reflect real enterprise deployment challenges.

* The skills hardware-focused engineers should develop as their roles increasingly intersect with software, cloud infrastructure, and AI-powered systems.

* How professional organizations can create continuous learning pathways that keep members relevant as AI technologies evolve rapidly.

His perspective comes from advising enterprises on AI transformation and workforce readiness, where technical capability must be combined with governance, security, and practical implementation skills to deliver successful outcomes.

………………………………………………………………………………………………………………………………..

Kuber Sharma, Senior Director of Product Marketing at UiPath

What I keep watching in enterprise AI deployments is a specific failure mode that most continuing education programs don’t address: people learn how a technology works, and then get stuck the moment the deployment hits conditions the training never covered.

The gap is not in tool knowledge. It is in what I’d call operational judgment: knowing when to trust the system’s output, when to override it, when to escalate, and who is accountable when something goes wrong at the edge. You can teach cloud architecture in a short course. Teaching someone how to reason through a situation where the AI produced a plausible-looking answer with a bad input is a different problem, and it is much closer to what engineers and IT professionals actually face on day 90 of a deployment.

What IEEE could do that AWS and Azure training programs structurally cannot: teach the failure modes, not just the architecture. The vendor success stories are easy to find. A curriculum built around why enterprise AI and cloud projects fail, what the consistent patterns look like, and how to recognize them early is genuinely hard to find, and IEEE is neutral enough to teach it honestly.

The harder thing to design for is the context that training programs rarely simulate: what happens when the decision model meets a real organization where the data is incomplete, the ownership is disputed, the engineers aren’t the ones deciding what the system is allowed to do, and the legal team finds out about the deployment six months after it went live. That is not an unusual scenario. It is the median enterprise AI deployment. A curriculum that stops at the framework is preparing people for a world that does not exist. The session that would genuinely move people is the one that starts after the framework runs out.

…………………………………………………………………………………………………………………………………………………

References:

Sept 26, 2026 Town Hall Event Description to be forthcoming soon

https://ithistory.org/article/moderators-afterword-alan-weissberger-hennessy-risc-bell-labs-and-hyperscaler-era

IEEE SCV March 28th Event: A Conversation with IEEE President and IEEE Region 6 Director Elect

IEEE President’s Priorities and Strategic Direction for 2024

IEEE President Elect: IEEE Overview, 2024 Priorities and Strategic Plan