Windows 11’s next update will introduce support for Calendar Agendas in the Notification Center. It’s one of the Windows 10 features that disappeared after the release of Windows 11 in 2021. While the Outlook-based Agenda view is coming back, it’s going to be a WebView2 component, which means it’s yet another web crapper that calls Edge resources.
Microsoft is still testing Agenda view in Windows 11 preview builds, so it does not work for me correctly, but apparently, it attempts to load the Outlook meeting details inside a WebView2 shell. For example, when I turned on the half-baked Agenda view and opened the Notification Center, I noticed a sharp spike in “WebView2” processes.
I also made a video that shows how the “Windows Shell Experience Host” process in the Task Manager immediately jumps from an idle state to using over 6-20% of the CPU. And when you expand the “Windows Shell Experience Host” process, you’ll notice that there are loads of WebView2 processes.
The emoji representing “Calendar” and the font also make it quite obvious that it’s a WebView2 component.
Inside this host, we can clearly see items named “GPU Process,” “Renderer,” and “Utility.” These are standard components of Microsoft Edge WebView2 used to draw the interface.
When the Notification Center is clicked, these processes instantly wake up, causing the memory usage of the main host to jump significantly from around 1MB to over 130 MB as it renders the Agenda view.
But when you close the Notification Center, Windows attempts to save resources and power by putting the components back to sleep. For example, Windows Latest noticed that “GPU Process” and “Utility” items immediately switch to the “Suspended” state. This means Windows has “frozen” these web components, so they stop using the CPU or RAM.
In other words, WebView2 is only loaded and triggered when you open the Notification Center and enable Agenda view. But as soon as you close it, RAM usage drops to almost zero.
Nobody likes WebView2 for a lot of reasons, but mostly it’s because web apps do not feel native on Windows 11, especially WebView2 and Electron. React is still far better, especially on mobile, because it renders native UI components (TextView on Android) rather than rendering web inside a shell.
Calendar Agenda view in Windows 11 is going to be as good as the Windows 10 version
The agenda view in Windows 11 is a bit similar to how things worked in Windows 10. It’s still a clean UI and shows a chronological list of your scheduled meetings. However, the only catch is that you’ll find AI-related features. For example, if you click one of the agendas, you should be able to access ‘Microsoft 365 Copilot.’
Microsoft officials previously confirmed that MS365 Copilot will be integrated into the Calendar Agenda view in the Notification Center, but it’ll be an optional addition, as you can always choose to ignore it. Also, another notable change is that you can directly join meetings in Teams from the Agenda view.
I don’t think a regular user would care as long as the Agenda view works as intended, and I think it does. It does not use a lot of resources (100MB RAM is not huge).
Electron and WebView2-powered Windows 11 apps are eating gigabytes of RAM at a time when RAM is getting expensive. Microsoft will hopefully find a way to optimize WebView2 in the Notification Center, but is it really that difficult to build native components for something as important as Notification Center?
You can finally remove “AI Actions” from File Explorer’s right-click menu, as Microsoft has caved in to the demands to make this feature completely optional in Windows 11. Until now, “AI Actions” appeared in the context menu even when the feature itself was turned off. However, that’s no longer the case.
AI Actions is one of those “AI” features that add little or no value. I am not saying it because I am an ‘anti-AI person.’ I am not. In fact, I regularly use Claude Code for my workflow, as it adds value. However, AI Actions is really a bloat, and it’s not useful like most of Microsoft’s AI ideas on Windows.
If you have not tried it, here’s how it works. When you select an image, right-click, the context menu populates with several options under “AI Actions” that let you blur an image, remove objects from the image, perform a visual search with Bing, and remove the background from the selected image.
That sounds like a neat idea at first glance, as you might think context menu takes care of the “AI processing,” and you don’t have to open apps like Photos or Paint, right? WRONG! This “AI Action” menu just redirects you to one of the apps, such as Photos or Paint, depending on the option you choose.
You can always click “Edit in Paint” or select “Photos” and easily perform the four tasks it has listed. Why do we need a separate option, “AI Actions,” that just lists a couple of first-party apps with AI features? Also, we already have ‘Ask Copilot” in the context menu, which can be used to call these apps using Copilot Actions (an upcoming feature).
In its current state, AI Actions is not worth populating the already bloated context menu, and you’ll be able to remove the option in the next update. To remove “AI Actions,” just open Settings > Apps > Actions, and uncheck all options, such as Paint, Photos, Teams, Microsoft 365 Copilot, etc.
Right now, if you uncheck these options, AI Actions still shows in the menu, but the nest-menu (the second menu inside it) is empty, so it just eats up space. This is now being fixed.
“If there are no available or enabled AI Actions, this section will no longer show in the context menu,” Microsoft noted in the release notes of Windows 11 Build 26220.7344, rolling out to testers at the moment.
AI Actions is now hidden
Microsoft says it’ll reduce clutter in the context menu, as making the “AI Actions” option is just the start
New Windows 11 right-click context menu in File Explorer takes just half the vertical screen space (after the update)
Microsoft is moving options like “Compress to… and “Copy as path” to a new sub-menu called “Manage file.” It also has options like TAR, RAR, ZIP, etc. The result is surprisingly good, as the clutter has been reduced and the context menu looks smaller than before.
Microsoft has also consolidated OneDrive-related options inside just “OneDrive. This means options like “Always Keep on this Device” and “Free Up Space” now appear inside the OneDrive option.
I’d call these baby steps, but I am glad Microsoft is trying to make the context menu less cluttered in Windows 11, especially the ability to hide “AI Actions.” However, the right-click menu’s happy ending is a far-fetched dream unless Microsoft adds a feature that allows us to customize the options that appear in the menu. What do you think?
Isolation is something I've been thinking about lately. Although I have an abundant professional network and support probably 100+ engineers, PMs, and others, at times I do experience a sense of isolation in my role. I'm not sure if it's the holidays, or because now that I'm 50, I'm apparently at the bottom of the "U-shaped happiness curve," but I'm trying to understand how to navigate a world where my relationships with colleagues are increasingly transactional (purely information-based) and lack more social aspects. There are several reasons for isolation, and good reason to believe that AI will only increase our isolation.
I’ve heard “program” used to mean everything from a team to a project plan to a portfolio to lines of code. At some point, someone has to stop and say: you keep using that word—I don’t think it means what you think it means.
A shared Taxonomy and Lexicon essential for focus and execution. Without one, organizations descend into semantic chaos. Few places create more confusion than the “P” words: Pfunction, Program, Project, Product, and their associated management functions.
Every company eventually trips over these. People use them interchangeably, often without realizing it. “Program” means one thing to engineering, another to marketing, and something else entirely to finance. The result is fuzzy ownership, blurred priorities, and circular conversations.
As I described in How We Scaled Alexa: One Problem, One Leader, scaling complex work requires single-threaded clarity. You can’t have one leader accountable for “the product” if half the org defines “product” as an app and the other half thinks it’s a platform. Leaders must explicitly define the boundaries: who owns what, what success means, and how each piece fits into the larger system.
This post defines the “P” words as I use them and explains how aligning on them creates clarity, focus, and scale.
Pfunction
A Pfunction (that’s a joke to make the “P” theme work) is what a person contributes to the company. Every employee provides one or more functions.
A CEO’s pfunctions might include executive leadership, fundraising, and investor relations. A software engineer’s pfunctions might include design, implementation, and testing. Pfunctions are not roles or titles; they describe what the role delivers.
Ok, I’ll stop using pfunction now and just use function. You get the point.
When an organization is small, people wear multiple functional hats. As it scales, clarity about each function’s purpose becomes the scaffolding for specialization. Confusion about functions is often the first crack in the foundation of focus.
Program
A Program is a long-term (measured in years) human effort to deliver customer value in a well-defined scenario area.
Programs are the durable units of investment; they are what the company will care about indefinitely. A great program has a clear vision, a defined customer set, and measurable outcomes that endure over time.
Programs are usually led by a Single-Threaded Leader (STL) who is fully accountable for the program’s success. The STL owns both strategy and execution, bringing together all pfunctions (engineering, design, marketing, operations) behind one clear goal. STLs of Programs are strong in all four of the CBTO perspectives.
Examples from my time at Control4: Smart home customers will always care about lighting, so we had a Lighting Program that built all of our connected lighting products. Jeff, a kick-ass, traditionally trained Product Manager, was the STL for Lighting (a vertical). People living in smart homes will always care about how scenarios that combine smart home verticals (Lighting, Whole Home Audio, Security, etc…) come together in a unified way, so we also had a horizontal Program for Home UI. Joel’s team built the Control4 mobile app and the experience on touch screens. He was a very technical engineering manager type. 1
Programs produce Products over time. Each Product emerges through one or more Projects. Or, as I like to say, “Programs poop out Products, using Projects.”
Project
If Programs define the long-term why, Projects deliver the short-term what.
A Project is a short-term human effort to fix a problem or deliver something specific by a certain date. Projects are measured in days, weeks, months, or sometimes years. When a project is complete, the people involved move on to something else.
Projects are how organizations make progress in the short term. They are temporal, discrete, and measurable. A project without a defined end state isn’t a project; it’s a program pretending to be one.
Projects work best when their goals ladder up cleanly to a Program’s long-term outcomes.
A Project can also have an STL. The best ones do. The STL of a Project has full ownership of getting the thing done on time, on spec, and aligned with the broader program. Generally, STLs of Projects are super strong on Technical execution and appropriately strong in the other CBTO perspectives.
Product
A Product is a cohesive bundle of functionality that customers experience as a whole.
Products are what customers see, touch, and pay attention to (and often pay for). They can be physical, digital, or experiential. They can be literal boxed products or software as a service. Products deliver the promise of a Program.
Programs evolve through a series of Projects that create and improve Products. Over time, a strong Program poops out new Products: each one a milestone in the Program’s lifecycle of customer value.
When we scaled Alexa, teams had wildly different ideas of what “the product” was. Some thought it was the Echo device, others thought it was the Alexa voice service, and others still said it was the developer platform. Clarity only came when we defined “product” in customer-centric terms: the thing customers experience and value.
Products are the bridge between customer value and company execution. Misdefining them breaks that bridge.
For early-stage companies the Product and Program are usually one and the same. If the startup is successful with the first product, then the Program becomes distinct. The danger comes when growth blurs this line, turning a scrappy Product into a sprawling Program without reassigning ownership.
The Heart of the Confusion: Program vs. Product Management
Microsoft and Intuit2 in the 1980s and 1990s, invented a discipline called Program Management.3 A Program Manager’s job was to be the single threaded leader for a product area: define what should be built, why, and ensure it got built the right way.
“A Program Manager is the advocate for end-users and customers” who bridges engineering and usability while driving execution.” — Steven Sinofsky
That model worked brilliantly. It fused customer obsession, technical depth, and operational rigor into one role. It forced alignment between strategy and execution.
But when Microsoft alumni scattered across the industry, the terminology mutated. Other companies borrowed the idea but changed the labels. The same role that Microsoft called Program Management eventually became known everywhere else as Product Management.4
The result: decades of linguistic confusion. Today, Product Managers rarely “manage products.” Program Managers rarely “manage programs.” And Project Managers often do a bit of both.
There should be a single function that defines what to build and ensures it gets built the right way. That function bridges strategy and execution. I wish the world still called that Program Management because that’s what it really is. But since most of the industry uses Product Management for this function, I use that term to stay consistent.
Function Taxonomy
Project Management
Project Management is the function responsible for ensuring a specific body of work is completed according to plan. Unlike Program Management and Product Management, there’s little confusion around the terminology: Project Managers manage Projects.
The skills required for Project Management are the fundamental blocking and tackling required to drive the mechanics of execution: schedules, dependencies, risks, and reporting. Somone skilled at Project Management is able to keep lists of details organized, up-to-date, and accurate. They master tools like Google Sheets, Jira, and Microsoft Project. They are good at herding cats.
Project Management is tactical by definition (recall from above, a Project is an effort literally bounded by time) and essential. The best project managers anticipate failure modes, surface tradeoffs early, and enforce accountability with discipline and humor.
Program Management (PgM)
Program Management is a supporting function that provides systems, tools, and mechanisms for consistency, coordination, and delivery at scale. Dedicated Program Management resources are not needed when the scale is small (startups, early-stage Programs). Dedicated PgMs are valuable when an organization has scaled to dozens of Programs with interdependencies and a need for cross-Program consistency.
At Amazon, there’s a function called Technical Program Management (TPM). These folks are very technical, really good at influencing others, and excellent at holding teams accountable to dates. They provide the most value when they manage complex arcs of dependencies across organizations.
At the scale most startups operate at, and when something new is hatched within a larger organization, dedicated Program Manager resources are a bad idea and a sign that the Program’s STL is not the right person for the role. Put another way, adding a PgM to an early-stage effort both robs the STL of ownership and just adds another chef to the kitchen.
Product Management (PM)
Product Management owns both the “what” and the “how.” The Product Manager leads the PROGRAM. He or she is the STL for the area of functionality that customers will care about over the long haul. I use PM as the acronym for Product Management.
The best Product Managers are really good at Project Management (being the “a-hole with a clipboard”). If they’re not, they’re really good at hiring or delegating to someone who is. Likewise, they’re really good at Program Management (driving consistency and coordination).
One does not have to hold the title of Product Management to provide the function of Product Management. I’ve delivered amazing, magical, customer value via a Software Development Manager who acted as his own PM. A recent thread on X, by Nikia Bier, is a great example:
How to Reconcile Internal and Industry Terms
I obviously have strong opinions, strongly held on these terms. Maybe you agree with my definitions. Regardless, the real point I’m trying to make is:
Most people are confused and unclear on these terms and it’s very common within teams for there to be disconnects and misalignment. As a leader it’s your job to recognize this and be intentional about fixing it. Stop the semantic sword fights; define your ‘P’ words, arm your STLs, and watch execution accelerate.
Here’s how:
Define Internally First Decide what each “P” term means inside your company. Write it down. Review it regularly. Teach it to every new hire.
Map to Industry Terms Recognize where your definitions differ from common usage. Create a simple mapping document so you can explain your language to external partners and candidates.
Be Consistent Across Mechanisms Use your taxonomy consistently in planning, budgeting, reviews, and reporting. If your systems use “project” differently, adapt them or clearly translate.
Keep the STL Principle Front and Center Every Program and every Project should have one clearly defined leader who is responsible for the outcome. One problem; one leader.
When these definitions are explicit and mapped to reality, your organization gains coherence. People stop fighting over things that don’t matter and get to the crux of debate faster.
If your team struggles with blurred ownership or mixed terminology around programs, projects, and products, I’ve helped many leaders build taxonomies that scale. You can grab time with me during my office hours to talk.
In my post on Anti-Silo Mechanisms, I described a similar setup we used for Alexa Smart Home. ︎
A short and small one, but one that is very useful for quick proof of concepts and/orhackatons - and Snap likes to organize those at the moment. If you are working with multiple people at a such high paced short interations project, scene stucture tends to change a lot, breaking references to objects in the scene, and sending your project into havoc at every commit or pull - not to mention your nerves and the team spirit. There are, however, in the Spectacles Interaction Kit, a few functions that allow you to quickly find objects in the scene from code by name or type rather than referencing by @input fields, and obtains references that way:
findSceneObjectByName
findComponentInChildren
findAllComponentsInChildren
findScriptComponentInChildren
findAllScriptComponentsInChildren
findComponentInParents
findAllComponentsInParents
findScriptComponentInParents
findComponentInSelfOrParents
findAllScriptComponentsInSelfOrParents
If you are coming from Unity, you might easily fall into the trap (as I did) of seeing not differences between Component and ScriptComponent, use findComponentInChildren or findAllComponentsInChildren, notice that that won’t even compile because it wants a “keyof ComponentNameMap” in stead of a type - and waste a lot of time on that. So if you want to find ScriptComponent/behaviours that you have placed in the scene and your team mate has moved it somewhere, you should rather use the *findScriptComponent* methods than the *findComponent* methods.
However, with the exception of findSceneObjectByName, these only work if you provide a top SceneComponent. So if your lovely team mates have created multiple root scene objects, good luck finding your scripts.
So I created this very little helper function that does that for you:
import{findAllScriptComponentsInChildren}from"SpectaclesInteractionKit.lspkg/Utils/SceneObjectUtils";import{DEFAULT_MAX_CHILD_SEARCH_LEVELS}from"SpectaclesInteractionKit.lspkg/Utils/SceneObjectUtils";exportfunctionfindAllScriptComponentsInScene<TextendsScriptComponent>(scriptClass:new(...args:any[])=>T,maxDepth:number=DEFAULT_MAX_CHILD_SEARCH_LEVELS):T[]|null{constfoundComponents:T[]=[];constrootCount=global.scene.getRootObjectsCount();try{for(leti=0;i<rootCount;i++){constso=global.scene.getRootObject(i);constcomponents=findAllScriptComponentsInChildren<T>(so,scriptClass,maxDepth);if(components&&components.length>0){foundComponents.push(...components);}}returnfoundComponents.length>0?foundComponents:null;}catch(error){print("Error while searching for components in scene: "+error);returnnull;}}
I created a little demo project that demonstrates this. For this I made a trivial TestTarget ScriptComponent that I sprinkled through the scene:
@componentexportclassTestTargetextendsBaseScriptComponent{publicgetInfo():string{return"I am a TestTarget component on "+this.getSceneObject().name+"!";}}
And an equally trivial TestFinder ScriptComponent that finds them:
Result in the Lens Studio Logger panel shows it actually works:
A word of warning: this is highly inefficient as you are bascially traversing the whole scene to find script components. This can be useful at startup, for connecting the dots initially, especially in the circumstances I described. But do not use this very often, like from an Update loop, because especially in a large scene it can be very resource intensive and slow.
Log in
︎
