U.S. technology stocks plunged for a second consecutive day on Friday as investors grew increasingly concerned about the enormous cost of artificial intelligence development and whether those investments will pay off. The Nasdaq fell more than 3.5%, while Intel shares dropped as much as 30%, Reddit fell 26%, and Alphabet extended its losses after shedding more than $500 billion in market value Thursday. The BBC notes that Meta, Alphabet, Oracle, Amazon, and Microsoft have collectively committed to spending $800.6 billion on AI in 2026. From the report: Chris Low, from investment management firm FHN Financial, said the bulk of what was happening in the stock market was in reaction to some of the biggest tech players such as Amazon and Google. He told Reuters the companies were "showing some pretty significant growing pains as they aggressively pursue the AI build-out." "The thinking is that these signs suggest that the entire sector is going to slow down."
Kathleen Brookes, research director at trading firm XTB, said there have been many ups and downs in AI trade in recent months. "Investors have turned ruthless, punishing any signs of disappointment in [third quarter] earnings," she said. "The AI trade has had a good run in recent years, but now investors want payback, and companies like Alphabet and Intel are in the crosshairs." [...] Brookes noted that November is typically a strong month for stocks. "If we see AI stocks continue to struggle in the coming days, it could suggest the AI trade is past its peak, and investors will be looking for a new theme to drive markets," she said.
This event summary was created by Claude with light editing by Tim O’Reilly, based on a transcript of the event.
On October 15, 2026, Tim O’Reilly hosted Andrew Odewahn, CTO of O’Reilly Media, for an hour-long episode of Live with Tim O’Reilly, the interview series streamed live on the O’Reilly learning platform. Andrew has been at O’Reilly for many years, starting as an author, then building tools for the company’s platform, then eventually as CTO and head of engineering. Over the past year, his team has been building what the company calls Expert Intelligence, a suite of tools that connects an AI agent to an organization’s own systems, gives it a skill file describing how to reason about what it finds there, and grounds its analysis in the practitioner frameworks of the O’Reilly library. Andrew described the work in a recent Radar piece, “Building Organizational Intelligence.”
Tim and Andrew’s interview was organized around a presentation in two parts, the first on the research agent and the second on the system Andrew’s team built for reviewing what it produces, with discussion in between and audience questions throughout.
Tim framed the conversation by asking a question he said Andrew’s work helps to answer: Most of the AI story is about efficiency, doing the same work faster. What does it look like for an organization to get smarter?
Building the research agent
Andrew’s research agent emerged from a personal need rather than a strategy. He wanted to know the status of a project, for example, how long a migration from RabbitMQ to Pub/Sub would take. This is the kind of question every engineer dreads but every engineering leader has to answer. He also had a broader concern. A single person being good at AI isn’t the same as an organization being good at it.
He built his agent in four steps. He mapped the organization’s information systems as a hierarchy, connected them via MCP, wrote a skill telling the agent how to use them, and finally added the Expert Intelligence layer.
The map of the sources of truth in the engineering organization’s workflows was what made the rest work. Andrew put them in order and explained to the model how they relate: Strategic goals and feature priorities live in Productboard. Those become epics, sprints, and stories in Jira. Stories become code in GitHub. A service catalog describes the roughly 300 services that make up the O’Reilly platform and who owns them, and observability tools show how those services perform against their SLOs. The skill also had to encode local quirks. Some teams mark an epic as finished with an end date, while others consider it done when every ticket is closed. Andrew also told the agent it was a research agent, not a coding agent, and that its job was to write reports.
Connecting everything through MCP was, in his words, “the most completely tedious step of the whole process.” Productboard had no MCP server at the time, so he wrote a wrapper. Later, when Tim asked how another company could repeat the work with a different set of tools, Andrew suggested starting from the vendor list. Export it from your procurement system, ask the model what products those vendors make and which would hold information relevant to the questions you care about, and have it put them in order. O’Reilly product managers are now turning this process into a skill for the forthcoming Expert Intelligence Skills Hub.
One audience member asked whether MCP was really the right tool for internal knowledge, compared with semantic search. As Andrew pointed out, sometimes anything is better than nothing. Ultimately, what you want is to give the model the ability to search across your systems.
From a hiring case to a toil audit
The center of the presentation was a before-and-after comparison of the particular use case that Andrew had previously written up in his “Building Organizational Intelligence” article. An engineering manager asked Andrew to hire another engineer, and Andrew had his reporting and analysis agent make the hiring case. The first report covered the five-person team that manages content and metadata, the 10 tier-A services it owns along with its B and C services, the status of the Pub/Sub migration (64% complete), and the full backlog. It concluded that the team had a capacity problem and should probably hire. Andrew called it useful and very detailed. . .“maybe overly detailed.”
He then connected the agent to Expert Intelligence, asked it to act like a consultant, and ran the analysis again. The new report came to a very different conclusion. It opened by saying that the team’s operational overhead problem was “structural, not a staffing deficiency.” When it consulted Expert Intelligence, the agent brought in the concept of toil from Google’s Site Reliability Workbook. Toil is the manual, repetitive, automatable operational work that scales linearly with a service. The reporting and analysis agent used this notion to separate the team’s backlog into toil and the work people actually wanted to be doing. It recommended a structured toil audit before the next planning cycle, an explicit toil-reduction target, and treating runbook ownership as a first-class engineering artifact. Andrew said the team followed the recommendations and closed a substantial part of a backlog that had been sitting on everyone as a cognitive burden.
The report went on to cite Jim Highsmith, a signer of the Agile Manifesto and author of Wild West to Agile, to argue that the team’s technical debt was compounding. Andrew explained how that differed from the usual management advice:
A lot of the time when you read these high-concept frameworks, they’re like eating your broccoli. I should really be doing that. But what made this really interesting is that it pulled out a specific project we had, the Django upgrade, and put it within the context of this broader framework. It wasn’t just, “here’s an abstract principle you ought to be applying.” It’s “here’s your backlog, and here’s a specific example.”
A second analysis looked at services that crossed team boundaries. Drawing on microservices experts and Kent Beck’s work on coupling (see Tidy First?), it diagnosed the video metadata service as a complicated-subsystem problem rather than a boundary problem. In this version, Andrew had the agent pull out quotations, attribute them, and link to the source text. The resulting analysis was remarkably effective. The company has since retired a couple of systems. “I don’t need LLMs adding code,” Andrew argued. “I want them reducing it.”
Andrew said the part that surprised him most was the reaction from colleagues. His earlier reports were data dumps. Readers couldn’t tell where any given claim came from, and as a result they were much less actionable. When the analysis cited experts that engineers knew from their own work, the documents became, as he put it, “much more approachable, much more human,” and people engaged with them far more deeply.
Tim’s response: Invoking the experts
Tim broke in to put the demonstration in context. He contrasted it with the view that models are now smart enough that you can simply tell them to do something and let them rip, an approach we hear a lot about from vibe coders and those arguing for “dark factories.” Tim argued instead for a return to expertise.
He cited a post published that day by Felix Rieseberg of Anthropic, “How to Be More Ambitious: A Tutorial for Humans with Models,” which describes four kinds of ambition when working with models: speed, altitude, depth, and range. Most discussion of AI’s economic value is about speed, getting the same work done in less time. In Tim’s reading, Andrew had gained altitude (thinking about the outcome rather than the tasks) and depth (approaching the problem the way a field-leading expert would) simply by invoking the experts.
Tim then offered a metaphor he has been developing for a while, of AI programming as a kind of magic spellcasting. In the Marvel comic books and movies, Doctor Strange opens his spells by invoking some source, with words like “by the power of the dread Dormammu” or “by the hoary hosts of Hoggoth.” Andrew, he said, was doing the same thing, saying in effect, “By the power of Kent Beck, I want you to think differently about this problem.” Even where Andrew didn’t name an expert, as with the SRE workbook, simply pointing the model at the expertise embodied in the O’Reilly publishing canon raised the bar for what the agent produced.
Tim described this as using human expertise as a focusing mechanism, and connected it to his argument that LLMs are better understood as a medium we create with than as independent intelligences. He also pushed back on the idea, often drawn from “The Bitter Lesson,” that models will simply get better and human expertise will stop mattering. Andrew, he said, had found a particular way that it matters.
Andrew took up the metaphor. His own first prompt, he said, had been “Be snobby. Go find these great resources and look at them.” He wants to hand the model canonical works in a field, like Designing Data-Intensive Applications, and tell it “these are the ways I want you to think about it,” rather than accept whatever the model comes up with first. He compared it to business school, where much of what you learn is a set of frameworks for organizing facts.
What models do without direction
Tim argued that models don’t do their best work unprompted. Watch their chain of thought when they search for information, he said, and you may see them settle on some random file from the internet rather than canonical sources. Even with a frontier model like Fable, his own experience has been one of false starts and errors, a model brute-forcing its way to a solution rather than necessarily knowing how to approach it.
Andrew had a story from a few days earlier. He asked his agent to review incentive plans for the engineering and product teams.
The data that came back was, “according to the company Robusto (which I’m sure is a great company), this is the framework, and you should really be doing what they’re doing.” I’m like, “What is Robusto, and why am I seeing this?” And I realized, oh, I’m not connected to the VPN. So I hooked it up, and suddenly it was, “According to Harvard Business Review, these are the different ways you should be designing these incentive programs.” This was a very powerful model. But it keyed off the first thing it found and said, “This is the way I’m going to think about the problem.”
Tim raised an economic dimension. He pointed to instructions in Anthropic’s Claude system prompt that limit how much the model may quote from any source, and read them as a sign that AI companies want to avoid paying for content. The result, he argued, is that models can’t draw on the best material available to them specifically enough and too often fall back on generalities. He called this an early form of enshittification in AI.
O’Reilly takes the opposite position. Andrew explained that the company applies the royalty model it already uses for O’Reilly Answers. Material returned through the Expert MCP server can be cited, and authors are paid royalties on it, so that expert content has a market and earns a return.
In response to an audience question, Tim and Andrew noted that Expert Intelligence is in prerelease with a group of founding partners while O’Reilly works out its economics. Interested organizations can request access through the product page.
Putting the discussion where the AI can see it
The second part of Andrew’s presentation dealt with what happens after the agent writes a report. Decisions need consensus, and with AI-generated analysis people need to check that the model hasn’t keyed off something unimportant, out-of-date, or misinterpreted. “The AI can identify all the trade-offs,” he said, “but people still need to make the decisions that matter.”
His team first circulated reports as Google Docs, but they ran into two problems. The most interesting part of a document under review is usually the comment thread, and because at this time, O’Reilly company policy doesn’t allow MCP connections to Google Docs, the agent couldn’t see it. And when Andrew asked the model to fold the discussion back into the document, pasting the result wiped out the comments.
Doug Hogan, an O’Reilly engineering director, built an alternative on top of Git and GitHub that Andrew called SuperAnswers. (Andrew joked that this was why he isn’t allowed to name things.) Documents live in a Git repository, discussion lives in GitHub Discussions, and every change is versioned. Andrew can ask his agent what the consensus is on a project, have it incorporate comments into a new draft without losing history, and later reconstruct when a decision was made and what people knew at the time. The same record lets him generate the derivative documents a decision requires, such as scope statements for engineering, product, and design teams, or a meeting agenda. A graph view clusters the topics people are discussing and flags decisions that are still open.
Tim summarized the whole system as a research assistant connected to the organization’s sources of truth, a layer of outside expertise to put its findings in context, and a shared, versioned discussion that becomes an evolving store of organizational knowledge, which makes the AI a more useful coworker. Andrew agreed and said he would like to open-source SuperAnswers, which he described as a thin layer on top of Git.
Andrew also pointed out that the fragmentation he was addressing isn’t limited to engineering. Sales teams have their information spread across systems like Salesforce, 6sense, and Gainsight, and every function has the same need to pull those threads together. Tim added that tool access is uneven across the industry and always has been. Claude produces better PowerPoint than Google Slides, Gemini the reverse, and organizations have to capture that kind of knowledge about their own toolsets.
Questions from the audience
An audience member named Thomas worried that workers now talk to AI rather than to each other, and that work disappears into “that AI hole.” Andrew said his preference for keeping everything in Git is partly an answer to that, since it gives both humans and AI a central place to find and reconstruct past work. But his larger interest is in humans talking to humans in a way that AI supports. He described a category of questions he never used to ask:
I knew, if I ask this question, somebody’s got to go off for two weeks and compile all this stuff from all these different systems. Now I can gather it in a few minutes. Maybe some of this is throwaway, but it’s not bad if it’s cheap.
In response to that “throwaway” comment, one audience member wrote in the chat: “This is not throwaway work, Andrew. It is a product lead that changes the value proposition in a positive direction. Shit hot, bro.” Tim couldn’t help but read that one aloud!
Asked by Tim what he got wrong, Andrew conceded that he didn’t think early enough about how people would review and respond to AI-generated documents. People don’t want an AI-generated data dump to wade through, and they extend AI no benefit of the doubt. If an AI-written report gets one small fact wrong about Kubernetes operators, a reader is likely to dismiss the whole document. AI tools have to be understood as marshaling and presenting evidence, not making decisions. “These need to support your analytical capacity, not replace it.”
Tim connected that answer to concerns about deskilling. He described a fine-tuning project he attempted with Fable to train a small model to write more like him. He wanted to understand each stage rather than letting the model run, but it never explained them, and the training run failed. In part this was because the model asked him to provide samples of his writing, but it didn’t give him enough grounding on what a really good training dataset would look like, so the samples weren’t targeted enough. They were too long, and when Fable chose the short fragments it actually needed, it didn’t do an ideal job.
When Tim tried the same project with O’Reilly Tutor, a tool still in development, it sent him to read an O’Reilly resource on what a good training set looks like, and he realized where he went wrong. Tim compared the kind of deskilling that can happen when people just turn the work over to AI to people who can no longer read a map, or who call a plumber for a simple fix they could do themselves in 30 seconds if they only knew a bit more about how things work. He argued that everyone has an obligation to keep learning alongside the tools they use.
An audience member named David, a laid-off engineer looking to reskill, made a similar point. We used to know things, then we searched, and now we skip the search and just ask for the answer. He asked how to build real depth. Andrew suggested picking a project and working through every aspect of it, asking AI to act as a tutor (he’s relearning calculus that way) and keeping a book open alongside, or taking advantage of instructor-led live events on fast-moving topics.
The conversation ended with the difference between an AI system that simply makes an organization faster and one that makes it better at deciding what to do. In Andrew’s account, getting better at deciding what work needs doing depends on three things the models don’t supply on their own: a map of where the organization’s knowledge lives, a body of expertise that people trust, and a place where the humans can argue with what the AI produced.
You can watch full episodes of Live with Tim O’Reilly, including this one, on theO’Reilly learning platform,YouTube, or wherever you get your podcasts.
Working on a remote machine should feel just like working on a local project: open it, start coding, and pick up where you left off. In 2026.3, JetBrains IDEs move closer to that goal. You can now start and manage remote sessions directly inside the IDE, connect over SSH using native OpenSSH, and begin working on a remote project while the full remote IDE is still being prepared.
Remote development sessions are now part of your IDE
You no longer need to open JetBrains Gateway or use the Toolbox App as a separate starting point for remote development. From the Home screen, your recent remote projects now appear alongside your local ones – marked with a “terminal” icon so they are easy to spot.
First-time connections to a remote host can be initiated from the top menu, under File | Connect to Remote, or from the Home screen. The Connect to Remote option in the Projects widget starts a simple two-step dialog:
After connecting to a remote host, you can either open a specific project residing on a remote machine or launch the IDE right away.
If this is your first time connecting, the remote backend will be installed automatically, or updated to a new version if needed.
You will be guided through this setup, getting you into your code faster than before. While the existing remote backend model remains unchanged, the entire connection and session management experience now lives inside the IDE.
The new in-IDE workflow also includes a few practical path-handling features: paths beginning with ~ are now correctly interpreted as remote home directories in both the full connection flow and Light Mode. Together, these updates make it easier to select project directories using familiar syntax without accidentally resolving paths against your local machine.
Note: This initial implementation focuses on SSH connections to supported remote environments.
Our goal was simple: make your IDE the single place where you start, manage, reconnect, and return to remote projects – no additional tools or applications required. Your daily remote development workflow is now available in one click: Just open your remote project from the Recent Projects list, and you are good to go.
Connect with the SSH setup you already use
SSH is fundamental to many JetBrains IDE workflows, including remote development, terminal access, and remote host integrations. In v2026.3, JetBrains IDEs introduce native OpenSSH support as an option for SSH connections.
This update eliminates the need to rely exclusively on a custom JetBrains SSH implementation. Instead, you can take advantage of the compatibility, ecosystem, and maintenance of OpenSSH. Building on a broadly adopted and actively maintained ecosystem means we no longer need to independently implement, patch, and track every single SSH compatibility and security concern within the IDE.
Additionally, the new in-IDE Remote Development picker brings together connections from your recent history, Toolbox, OpenSSH, and IDE settings, making it easier to reuse existing SSH setups and connect quickly.
Native OpenSSH support extends the range of authentication mechanisms and SSH features available to JetBrains IDE users. As this integration matures, OpenSSH will become the default SSH implementation in upcoming releases.
Start working while the remote IDE gets ready
Starting a remote project usually involves a waiting period while the remote IDE is downloaded, installed, and launched. In v2026.3, we are cutting down this downtime: When you connect to a remote project using the new in-IDE flow, the IDE immediately launches an embedded client and starts the session in Light Mode while the remote IDE is downloading, installing, and launching.
Light Mode gives you instant access to the project and provides the essential tools you need right away. You can explore the remote project, open and edit files, use the terminal, and search through files and their content. The IDE remains responsive from the moment the connection is established, giving you useful access to your workspace.
Light Mode intentionally focuses on the basics. Once the remote IDE is ready, your IDE will transition seamlessly from Light Mode to Smart Mode. All work started in Light Mode will be preserved. You can continue working without closing the project, repeating actions, or restarting your workflow manually.
In this release, Light Mode is supported exclusively on Linux remote hosts in GoLand, IntelliJ IDEA, PhpStorm, PyCharm, RubyMine, RustRover, and WebStorm. CLion and Rider are not yet supported.
Preview service deployment operations with azd deploy --preview before making changes.
Deploy container images to Azure Container Apps express environments with the existing containerapp host.
Remove stored environment values with the beta azd env unset command.
Generate pipelines that install extensions required by extension-defined infrastructure providers.
Build extensions with stable deployment-preview, usage telemetry, and current Azure principal contracts.
New features
Deployment previews and Container Apps express
To inspect deployment operations without deploying, run:
azd deploy --preview
Preview deployment operations for App Service, Container Apps, Functions, Static Web Apps, Azure Kubernetes Service, and AI endpoints. Results describe the resolved Azure target, with structured target and host details available in JavaScript Object Notation (JSON) output. [#10204]
Deploy images to Azure Container Apps express environments using host: containerapp. azd detects the environment’s express mode and updates the image without setting a custom revision suffix or traffic weights. Use the image-based deployment strategy; express doesn’t support multiple revisions or traffic splitting. [#10223]
Environment management and pipelines
Remove one or more exact, case-sensitive stored environment keys with the beta azd env unset command. It asks for confirmation, protects AZURE_ENV_NAME, and leaves other environments and process variables unchanged. Non-interactive removal requires --force. [#10362]
Use extension-defined infrastructure providers with azd pipeline config. Generated GitHub Actions and Azure Pipelines definitions install the required extensions. [#9878]
For example, to remove two stored values from your development environment:
azd env unset OLD_API_URL OLD_FEATURE_FLAG --environment dev
Extension APIs and command behavior
Extensions add commands and integrate with azd project and deployment workflows. This month’s updates give extension authors stable contracts and more control over command output.
Build read-only service-target deployment previews with the extension software development kit (SDK). The contracts and SDK application programming interfaces (APIs) graduate to stable v1 in 1.37.0, while existing beta routes and source remain compatible. Contributed by @Siglud for the initial SDK support. [#10055][#10628]
Use stable v1 APIs for extension usage telemetry and current Azure principal lookup. Existing beta routes remain available. [#10439]
Discover project-service save capabilities and confirm completed service additions with typed acknowledgments through preview APIs. [#10334]
Return structured informational and warning messages from extension service predeploy and postdeploy handlers. azd deploy and azd up include these messages in terminal and JSON results, including failed deployments. This API remains beta-only. [#9950]
Contribute follow-up guidance to successful core command completion messages through a preview API. Guidance appears after handlers finish and doesn’t change JSON output. [#9794]
Mark individual extension commands with launch.noAzdEnvironment to skip loading the selected azd environment and resolving its Key Vault references. Inherited process variables and explicit environment API calls remain unchanged. [#10479]
Breaking changes
Environment and state Go API migration: Exported environment and state path APIs now return errors. Update custom implementations and mocks, check and propagate errors before using returned paths, and pass an *azdcontext.AzdContext to state.NewStateCacheManager instead of an environment-directory string. Construct the context from the project directory, not its .azure directory. These changes make path-validation failures explicit. See the environment-state API migration guide for the affected signatures.
Bugs fixed
Extension installation and execution
Restore the previously installed extension’s files and metadata when an upgrade fails or is cancelled. [#10315]
Propagate Ctrl+C cancellation across extension processes, remote procedure calls, and extension-started workflows. Report cancellations and timeouts distinctly instead of as generic failures. [#10353]
Return an error when a non-interactive extension install can’t apply an explicit version pin without confirmation, and keep file-based extension sources available after changing working directories. [#10181]
Improve selected-file validation in the Foundry SDK. [#10181]
Preserve parent and sibling registrations when creating nested dependency injection scopes, and respect the selected output format in extension installation diagnostics. [#10254]
Preserve process exit codes for directly invoked extension commands. [#10282]
Avoid repeating unchanged progress lines during extension installs and updates when output isn’t a terminal. [#10280]
Open the correct documentation for extension namespace --docs requests. [#10304]
Resolve extension command metadata, canonical paths, and flags correctly when commands use parent or child aliases and global flags. [#10479]
Keep extension selection prompts on stderr so terminal output doesn’t mix into JSON results. [#10479]
Project configuration and environments
Preserve unrelated azure.yaml settings during extension service edits, including empty mappings, large integers, and environment templates. [#10479]
Restore in-memory project configuration when an extension service addition fails. [#10334]
Restore environment access after project initialization when an earlier lookup found no project. [#10294]
Complete environment configuration updates reliably and fix a race in task-list rendering. [#10191]
Clear stale in-memory authentication entries during re-login cache cleanup. [#10317]
Deployment and developer workflows
Make provisioning warnings clearer about which scope permissions were checked. Critical warnings default to No and require explicit confirmation; --no-prompt or unanswered critical confirmations return an error. Cancellation skips post-provision hooks without hiding failures in parallel layers. Contributed by @hyoshis. [#10396]
Validate unresolved or empty environment variables embedded in Deployment Stacks deny-list values before sending the configuration to Azure when the deployment.stacks alpha feature is enabled. Contributed by @saikeerthan-14. [#10516]
Show deployment timeouts clearly instead of displaying them as skipped steps or obscuring them with underlying errors. [#10157]
Handle cancelled deployment progress updates and closed progress channels without hanging or stopping unexpectedly. [#10304]
Accept inline shell expressions with operators, assignments, or expansions without spaces in azd exec --shell, and stop mistaking inline commands with path arguments for missing script files. Contributed by @jongio. [#10376][#10375]
Retain file changes and remove stale entries during file-watch registration and shutdown. [#10300]
Stop showing a question-mark hint when prompt hint keys are disabled. [#10445]
Other changes
Update Go dependencies across core and first-party extensions, including gRPC v1.84.0 and OpenTelemetry v1.47.0. [#10572]
Update the bundled GitHub CLI to v2.102.0. [#10456]
Update Microsoft Authentication Library for Go to v1.10.1. [#10251]
Azure Developer CLI reference (October 27)—Updated command reference includes azd deploy --preview, extension management options, and a clarification that non-interactive azd env unset removal requires --force.
New templates
Community-authored templates help you get started faster, solve real-world scenarios, and showcase best practices for deploying solutions with Azure Developer CLI.
LangChain AG-UI Chat with Angular, Hono, and LangGraph on Azure Container Apps by Jay Chase: A streaming AI chat application with generative UI tool components, connecting an Angular (@copilotkit/angular) frontend to a LangGraph Server via the AG-UI protocol and @ag-ui/langgraph on a Hono API. Demonstrates a fully self-hosted deployment on Azure Container Apps using official AG-UI and CopilotKit packages.
The Azure Developer CLI template gallery continues to grow with contributions from the community. Thank you!
New to azd?
If you’re new to the Azure Developer CLI, azd is an open-source command-line tool that helps you get your application from your local development environment to Azure faster. It provides developer-friendly commands that map to key stages in your workflow, whether you’re working in the terminal, your editor, or continuous integration and delivery.
In this episode, Andy talks with John R. Miles, host of the Passion Struck podcast and author of The Mattering Effect: Creating a Life of Meaning and Worth. John is a Naval Academy graduate, former Navy officer, and longtime Fortune 50 executive who built what looked like a very successful life, until his young son asked him, "Dad, how come you never laugh anymore?"
John and Andy explore the difference between belonging and mattering, and how leaders can spot team members who quietly feel interchangeable. You'll hear what the Surfside building collapse teaches us about warning signs on teams that are still delivering, why recognition for accomplishments doesn't always land, and how to uncover the hidden rules that run our lives, like the belief that we have to earn rest. They also discuss how to build a sense of mattering sturdy enough to survive AI, and what John would tell a younger version of himself as a dad.
If you're looking for a deeply human conversation about meaning, worth, and the people side of leading, this episode is for you!
Sound Bites
"We see the resume, and oftentimes we don't see the person that ended up becoming the resume."
"The most important thing she taught me was that I could either continue to be a victim or I could choose the opposite."
"One of the tragedies of life is we often wait until someone is gone before we tell them how much they've shaped us."
"The people who notice the drift the most, if you have them, are your kids."
"When you hear those things, that's not a belonging problem, that's a mattering problem."
"The leader's job isn't just to include people. It's to help people understand the unique difference that they make."
"Buildings don't collapse overnight. Neither do teams. Neither do families. Neither do relationships."
"They stop bringing the ideas. They stop challenging the decisions. They stop disagreeing, and all of a sudden you end up with groupthink."
"Recognition often celebrates what you've accomplished. Mattering, on the other hand, recognizes who you are on that journey."
"That's not how life works. The deck's never gonna clear."
"I try to think about what deserves my attention today because it matters, not because it's urgent."
"If your worth comes from being useful, then artificial intelligence is terrifying. But if your worth comes from being human, AI can't replace that."
"People matter because they're people, not because they're productive."
"Your children don't need a perfect mother or father. They need a present one."
Chapters
00:00 Introduction
01:58 Start of Interview
02:10 The Speech Therapist Who Made John Feel Like He Mattered
05:22 Telling People How They Shaped Us Before It's Too Late
07:48 When Usefulness Is Undeniable and Humanity Is Optional
11:32 When Others See the Cost Before We Do
14:41 The Difference Between Belonging and Mattering
17:01 Resources, Quiet Meetings, and Feeling Interchangeable
Episode 134 with Scott Mautz. It goes way back in the podcast archives, and many of the ideas from that conversation are still relevant today.
Episode 31 with Adam Grant, his first-ever podcast interview, where we talk about what it means to lead with meaning.
Episode 385 with Vanessa Patrick about her book The Power of Saying No, packed with ideas for when you need to draw the line.
Chat with PMeLa
You can chat directly with PMeLa, the podcast's AI persona, to get episode recommendations and answers to your project management and leadership questions. Visit PeopleAndProjectsPodcast.com/PMeLa to chat with her.
Join Us for LEAD52
I know you want to be a more confident leader–that's why you listen to this podcast. LEAD52 is a global community of people like you who are committed to transforming their ability to lead and deliver. It's 52 weeks of leadership learning, delivered right to your inbox, taking less than 5 minutes a week. And it's all for free. Learn more and sign up at GetLEAD52.com. Thanks!
Thank you for joining me for this episode of The People and Projects Podcast!
The Mentorship Maximizer Matrix: How to Score Every Mentor on Fit and Commitment, and the Move to Make Next
Lisa landed a conversation with a VP four levels above her.
She came back celebrating. I asked, “What’s your follow-up plan?”
Silence.
She was about to let the best career opening she’d had in years end as a great chat. And she’s not alone. Plenty of engineering leaders have a mentor. Far fewer are actually getting mentored. They meet for coffee once a quarter, and nothing changes.
It’s not your mentor’s fault. Mentorship is mentee-led, and the difference is what you do next.
Most engineers treat a mentor the way a free solo climber treats the guy at the base of the wall. Ask for a few tips, say thanks, then turn around and climb alone. Great mentorship is climbing with a partner who knows the route and brings the rope.
In this episode I walk through the three monster mistakes mentees make, then draw the Mentorship Maximizer Matrix: score every mentor on fit and commitment, find which of four boxes they’re in, and make that box’s move. That’s how Lisa went from a hallway conversation to a VP mentor, and how a mentor named Josh became the sponsor behind one of my biggest promotions.
Your mentor can hand you the rope. Only you can clip in.
You don’t have world-class mentors, either none at all or one HR assigned you who’s following someone else’s formula. You don’t meet, or you meet once a year over coffee instead of at the gemba, where your mentor can see the real work. And you don’t ask for what you actually want, so you end up treating your mentor like a curated version of Google.
You’re Not Alex Honnold
Free soloing El Capitan is one of the greatest athletic feats of all time, and it’s how most engineers run their careers: a few climbing tips at the base of the wall, then up the rock face alone. There’s one Alex Honnold. The rest of us climb further, waste less energy and survive the slips when we’re roped to a partner who knows the route.
The Mentorship Maximizer Matrix: Fit × Commit
Fit is whether a mentor has the results, skills and experience you want, and shares your values. Judge it against your vision, not their job title. Commit is how much they’re actually investing in you right now. Once-a-year coffee is low commit, however senior they are.
Four Boxes, Four Moves
Bad fit, low commit: move on. Thank them and close it out, the way I opted out of an HR-matched mentorship early in my career. Bad fit, high commit: dig for gold. When my mentor Steve ran out of promotion advice, we switched to what Steve was a guru at: personal investing. Perfect fit, low commit: ask for more. That’s where Lisa was, and one courageous ask changed it. And if your mentor says they only meet quarterly, respect the boundary and invite them to more anyway. Let them say no. Don’t say no on their behalf. Perfect fit, high commit: make them proud. The most generous thing you can give a mentor is applied advice, and a report back on what it did.
How a Mentor Becomes a Sponsor
Josh and I worked together for years. I kept asking for more, kept digging for gold, and kept making him proud. When a Whirlpool reorg created a key moment, Josh became the sponsor who helped me land a huge promotion at a young age. The top-right box is where you want every mentor’s name to end up, because it’s where sponsors come from.
Your Move This Week
Take the names of your mentors, not theoretical ones, and plot each one on the matrix. Then make the move for each box this week. If your matrix is empty, it’s time to go fishing, and the Life Raft episode is the place to start.
About Zach White
Zach White is the founder of Oasis of Courage and the host of The Happy Engineer podcast, now in its second season with more than 200 episodes published.
He holds mechanical engineering degrees from Purdue and the University of Michigan and spent his corporate career as an engineering leader at Whirlpool before leaving in 2019 to coach full time. Since then he has coached more than 300 engineering leaders at over 200 companies — big tech to rust belt, and everything in between.
His flagship program, the Lifestyle Engineering Blueprint™, is a 12-week coaching program that helps engineering managers and directors get promoted without handing over their nights and weekends to do it. He also runs an invite-only Mastermind for Blueprint graduates and hosts OACO Live.
He built all of it around one belief: you shouldn’t have to sacrifice your life to reach your potential at work.
Links & Resources
Free download — The Mentorship Ask Scripts Know your move but not what to say? The exact words for every ask, from the first message to a stranger to asking a mentor to become your sponsor. → https://toolkit.oasisofcourage.com/mentorship-scripts
Please note the full transcript is 90-95% accuracy. Reference the podcast audio to confirm exact quotations.
Having a mentor doesn’t mean you’re actually getting mentored. I’ve coached over 300 engineering leaders, and I’ve seen one courageous ask turn a conference handshake into a director opportunity.
I’ve also seen leaders meet their mentors for coffee year after year after year without moving forward. And the difference? It’s what the mentee There’s 3 monster mistakes that can keep you on the wrong side of that equation.
Let’s see if you’re making one and then get clear on the action that you need to take to maximize the value of mentorship for your engineering career.
Expand to Read Full Transcript
And by the way, if you’ve been meeting with your mentor for months, maybe even years, and you’re still having those same career conversations, something needs to change. And sometimes the hardest part is just knowing how to ask for what you need, what to say when asking a new leader to be your mentor. That’s why I’ve created a free set of mentorship scripts. These are for engineers who want to be intentional about career growth and just feel stuck on knowing what to say. You’ll have the language that you can adapt to approach the right person and explain the kind of guidance that you need and that you’re looking for. Grab those scripts for free in the description, in the show notes right now, and let’s get cracking on these 3 monster mistakes. The first mistake is the most obvious one. And unfortunately, out of the 300+ leaders who I’ve coached from IC to VP across the board, it’s the most common. It’s that you don’t have world-class mentors. You just don’t have them. And there’s 2 sides to this mistake. One is having no mentors, period. The second is that they’re really not world-class. You have someone who was assigned to you by HR, perhaps you joined one of the corporate matching mentorship programs. And frankly, that person is not supporting the success that you desire. They’re not actively creating new results for you because they’re just following the formula that was laid out by someone else. And yes, they’re generous and they want to give back, they do. Uh, have a desire to see you succeed, but they may not be the actual person who you need in your corner. So whether it’s you have zero people in your life raft as a mentor supporting you, or the people who you have frankly are just riding along in that boat instead of actively rowing in support of your success, if you do not have a tribe of world-class mentors in your corner, that is a monster Mistake for you as an engineering leader, no matter what level you are at. If you’re a junior individual contributor all the way to director and VP, we all need those mentors. Mistake number 2 is that you have the mentor and you don’t actually meet. This is amazing how often I’ll say, hey, do you have a mentor? And the engineer will say back to me, yes, I do. And I’ll say, well, how often do you connect? And it’ll be twice a year, maybe once a quarter, or, oh, I don’t remember the last time that I met with my mentor. It’s like, well, that’s, that’s not a mentor. Once a year doesn’t move the needle. All right. Yes, it’s good to stay in touch with past mentors who may be able to come back and support you in a key moment, but you need cadence. All right, you need cadence and you need an environment when you meet that allows the right conversation to happen. What cadence is right will depend on what you’re seeking to accomplish. And in just a moment, I’ll share with you the importance of how those things fit together. But on the environment piece, I think it’s a huge mistake that most mentorship meetings are coffee chats or going out to lunch. Sometimes the most valuable thing you can do is bring your mentor into your work environment. Go to the Gemba, go look at the work itself and get their insights, their coaching, their mentorship, their advice right there in the thing that matters most. Mistake 1 is you don’t have the mentors. Mistake 2 is you don’t meet with the mentors you have in the right cadence and in the right way. And mistake 3? You’re there with a great world-class mentor. You’re meeting in the right environment, but you don’t have the courage to ask for what you really want. Mistake 3, you don’t ask for what you want and what you need. This is another monster mistake that mentees make all the time. You get this close to something that could have radically shifted the trajectory of your career, And you didn’t have the courage to ask for it. Or worse, you don’t know what you need to ask for in the first place. Huge, huge miss, huge bummer. It’s almost like people treat their mentors like a curated version of Google. They just ask questions and get information back, and they settle for this transactional relationship with a mentor to get information from them. That frankly you could have gotten 90% of from ChatGPT or Claude, and you’re not digging into the right topics in the right way, and you’re not asking for the support that you really need. 3 monster mistakes. You don’t have world-class mentors. You don’t meet with your world-class mentors in the right cadence and in the right way. And you don’t ask your mentors for what you really need. Want and need. I’m curious, which of those 3 best describes you? Is it 1, 2, 3, or all of the above? What is the challenge that you’ve faced with mentors in your career? And if you wanna go deeper on this, I’ve got an entire podcast episode where I take 20 minutes and unpack these 3 really deeply. If you feel stuck and trapped on these, if you’re in the audio podcast, it’s episode 175, and here on YouTube, Uh, we’ll get that linked up in the description if you want to watch that next and go deeper, but we need to make sure we’re not making these mistakes so we can move on to actually maximizing the mentors that we have. So let me show you the Mentorship Maximizer Matrix. This is a really simple and powerful tool for how you can take the mentors in your life and turn them into leaders who are supporting your success. But I need to remind you first, You’re not Alex Honnold. If you don’t know who Alex Honnold is, he’s a free solo rock climber, and he did an incredible special by that name, Free Solo, showing how he climbed El Capitan with no rope. It is absolutely ridiculous. I would encourage you to go check that out. It’s one of the greatest athletic feats of all time, and it’s the way most engineers want to run Their career. They think that they’re Alex. They meet a mentor at the base of the wall and they ask their mentor for some climbing tips. And they say, hey, how did you do that section up there when you climbed this really hard mountain? And then they say thank you to their mentor and they turn around and they walk to the wall and they free solo the rock face. That’s the way that engineering leaders, whether you’re a manager, director, I see it all the time. They go to their mentor to ask for climbing advice, and then they go climb on their own. Great mentorship is not like that. Great mentorship is climbing with an experienced partner who knows the route, knows where to place the anchors, and can hand you the rope to clip into. Okay? You’re gonna climb further. It’s gonna take less energy. It’s way safer. So when you slip, you don’t fall to the bottom because the truth is you’re not Alex Honnold. You’re not the one in a million engineer. You’re not that person. Maybe you think you are, and if you are, awesome. But the truth is there’s one Alex Honnold and there’s all the rest of us, and there’s no point climbing that face alone in your career. So let’s get into the mentorship. Maximizer matrix. There are 2 dimensions, and I want you to grab your notebook and draw along because you need to be marking where your current mentors are at on this matrix. The first dimension, let’s talk about this x-axis. It’s fit. It is fit. You can have a mentor who is frankly a bad fit. You and that person don’t get along. You and that person are not Really able to support each other. They cannot help you with the things that you want. And on the other end would be someone who’s a perfect fit. That’s the ideal. That’s what we want. This leader has the results that you want to accomplish. Remember, that’s the key distinction of a world-class mentor is that they have actually achieved the results that you want. So bad fit to perfect fit is really obvious in finding a great mentor. But the vertical axis on this matrix is their level of commitment to you. If you have a mentor who is low commit, that’s a problem. They’re not investing into you. And on the other end is somebody who is highly committed to your success. Highly committed. This is the problem with a lot of mentorship relationships is that you’ve got somebody who could help you a lot, but they’re not committed to helping you. And as a mentee, we just sit back and say, well, there’s nothing I can do about that because they’re the mentor and I’m the mentee. What am I supposed to do, Zach? Well, that is not true. That is not true at all. Let’s talk about what action you need to take based on where your current mentors map into this Matrix. First one, let’s talk about low commit, bad fit. It’s pretty obvious if you’re in this quadrant, if the name of your mentor lands in this quadrant, that you’ve got a problem. All right. This person is really not able to support your success, and they’re really not that invested into your success anyway. So why would we continue to use our time and energy here? The answer is simple. The action to take is move on. Move on. Have the courage to tell that mentor, thank you for the support that you’ve given me. It has been extremely helpful. I appreciate you. And I think our mentorship relationship has run its course. For me, I had this experience early in my career when I joined one of those HR mentor matching programs. I filled out a few questions. Let’s be honest, it was not Match.com. I don’t know how they were pairing people up, but somehow I ended up getting matched with a mentor who will remain nameless for the sake of protecting their reputation here. And at the end of the day, I felt there was very little this person had to offer me. Their career path had been very different than the direction I wanted to go. They did not have tremendous success or results to speak of in their own career. And the other people I was asking were like, hey, Probably wouldn’t spend too much time around that person. That’s not someone you want to hitch your wagon to. So I went through the minimum required sessions as part of that HR program, and when it came time to either continue or opt out, I said thank you and opted out. If you’re in a similar situation, just have the courage to say no, to let them know that that’s the end of the relationship, and move on. Now the next two. Quadrants are a bit trickier because you’re halfway to what you want. You may have a mentor who’s really committed. They’re willing to invest in you, but they’re not a great fit. The conversations, maybe they’re not clicking. You just don’t vibe with that person. Maybe the results that they’ve had in their career are not aligned with the direction that you want to go. So it’s not really that great. Maybe you’re on the deep technical side and they’re more on the product side and it’s not working, or the opposite. You want to move more towards the commercial and business end of the engineering career ladder, and they’re more interested in keeping you in deep technical work. Whatever the reason is, it’s a bad fit. Or the opposite, you may have someone who’s a perfect fit, but man, you just can’t get their time. You can’t get their focus and their energy. That person is unavailable, or at least so far has not been open to committing to you. When you’re in one of these 2 quadrants, it can be tough to know what to do because you don’t want to let that relationship go. Let’s start with the high commit, bad fit. I think this one is actually the more common situation that I see. When you’re in this quadrant, the action that you need to take is to dig for gold. Dig for gold. What I mean is to explore other ways that this committed mentor can help you. I remember a mentor named Steve who supported me at Whirlpool Corporation, and after I’d gotten a couple of promotions, Steve didn’t have much more to offer me around the idea of career development. We were actually peers on the org chart by this time, so asking him for continued advice on how to get promoted to a level he’d never reached didn’t make sense, but— Steve was committed. He really enjoyed and supported me in a great way. So I started digging for gold. What else is Steve great at? And it turns out he was a guru when it came to personal investing, understanding Whirlpool’s 401 plan, you know, personal investing and just financial strategies and financial intelligence in general. So we shifted our mentorship away from getting promoted and into me learning from him about investing strategies. If you have somebody with great experience who you connect with in some ways, but it’s just not quite a fit for your goals and what you want right now, go dig for gold. Maybe that person can help you in another way. What about low-commit, perfect fit? This is that VP, this is that director, this is that person at another company who’s a thought leader. You’ve seen them on LinkedIn. Who oh, they’re they’re the perfect person. They’re the person who you want to be when you grow up. They’re the person who has all the success, all the reputation that you want to emulate. It’s a perfect fit. But even getting in the same room as that person can be tough. Maybe they don’t even know your name yet. Well, here’s what needs to happen: the action for you to take when you’re here. It’s one of. Courage. You must have the courage to ask for more. Remember the leader I mentioned, Lisa, from the intro of this conversation today? She was invited to go along and represent a project that she was working on at a major engineering conference. The VP of product was also at the conference. This was a female engineering leader who’d made it to the vice president level, and Lisa really wanted that opportunity to have a conversation with the VP, and she got it at that conference. And Lisa was in my coaching program and she came back and was celebrating the win. She said, ha, you’re not gonna believe this. I got to go to the event and While I was there, got to have a conversation with the vice president and was celebrating that win. And so I asked as her coach, I said, amazing, what’s your follow-up plan? A few seconds of silence, no response. Lisa hadn’t even considered the possibility that a follow-up might be available, right? This was totally out of her league. This is a person who was at the time, I think, 4 levels above her. in the org chart, right? There’s no way this VP would want to mentor Lisa, right? Well, how do we know if we don’t have the courage to ask? So I said to Lisa, hey, do you want this person to be your mentor if you could? And Lisa was like, of course. I mean, that would be amazing. This is a perfect fit. This person’s career path is almost exactly the path that I would love to follow. I said, okay, it’s time to make that courageous Ask. Now’s the perfect time. You have the relationship, you just met face-to-face and had this conversation. Go ask for more. Lisa did. The VP was ecstatic to serve as her mentor, and now Lisa is in line for a director opportunity. The same could happen for you if you have the courage to do it. Dig for gold. Ask for more. If you’re currently in one of these 2 quadrants, that is your objective to push you into the place that we all want to be, the top right, where you have that perfect fit and a high commit. So what do you do in that situation? So let’s jump back out to our matrix. And by the way, if you’re thinking, I have the courage to make that ask, I just don’t know what to say, remember to grab the scripts. That are totally free there in the show description. So you can get past that hurdle of knowing what to say and just get on with the actions. But when you’re in this 4th and best quadrant, perfect fit, high commit, you’ve got a leader with results that you can aspire to and emulate and who’s helping you and actively supporting you. You have that cadence of meeting, everything’s going great. Well, what do you do now? It’s like I hit the, I hit the jackpot. I’ll tell you exactly what to do. The most generous thing that you can give a mentor is applied advice. Do what they say and make those mentors proud. Make them proud. Make that mentor proud that they invest in you. Give them the feedback. Hey, I just want to say thank you for what you’ve been supporting me on. I took the actions that you suggested. I’ve gotten these tremendous results. Things are going well for me. Things are looking up for me. And I just want to let you know how much I appreciate what you’re investing into me. And I’m going to continue to take action, to challenge myself, to grow. And I just want to let you know how much that means. Wow. That’s what you want to do. When you think about what can I generously give back To my mentors when they’re giving of themselves into me. This is what it is. Give them the pleasure of knowing that their investment into you was not in vain, that it was not a waste. Go make them proud. And I’ll tell you the other reason this is super important is because this upper corner right here of the matrix, that’s the place you want every one of your mentors’ names to end up. So that you can ask them to be your sponsor in those moments that really matter. And I’ll do a whole separate conversation, separate episode talking about sponsorship later. But for today, just know that our goal is to move our mentors up into this top right quadrant where we can make them proud. And you want every single name of your mentors to land in that box. Now, If you haven’t already, take your list of mentors and let’s plot them on this chart. If you have somebody whose name is down here in the bottom left, have them, you know, say thank you and move on. Let them go. Cut them loose. If it’s a bad fit, low commit, let’s move on. If your mentors’ names are up here where they’re really committed, but it’s a bad fit, it’s time for you to take a new action in how you engage. To go dig for gold. If it’s in the ask for more bucket, go get the scripts, get clear, get courageous, and make that ask. Don’t just settle for whatever they gave you as their way of doing mentorship. I’ve heard this a lot. Yeah, but Zach, my mentor said they’re only available to meet quarterly. I get it. We’re going to be very respectful of that boundary For them. And we’re also going to ask them and invite them to something more. Let them say no. Don’t say no on their behalf. And if you have mentors in this make ’em proud box, then let’s push it all the way as far as we can so that you have a list of mentors who, even after the mentorship is over, you can go back to and pick up the conversation and asking for advocacy. And sponsorship in those moments that matter. This is how you maximize mentorship. If you activate this, I promise you, you’re gonna be ahead of 99% of other leaders out there who don’t have mentors, don’t meet with their mentors, and don’t ask for what they want and need. And I can tell you from my own experience that this works. I had a mentor named Josh. Josh and I were together for years. I kept asking him for more and more insights. I kept digging for gold if it ever felt like we were running out of things to explore. No matter what stage I was at in my career, Josh continued to invest in me. He was giving me time. He was up there in that top right, and I kept doing everything possible to make him proud. And when a key moment came that Whirlpool went through a reorg, Josh became that sponsor for me who helped me to land my first senior manager of engineering role. When who knows what would’ve happened otherwise. You see, investing in that relationship and asking for the things that I wanted and needed, making sure that Josh knew the direction I wanted to steer my career led to a huge promotion, a huge pay raise, and a huge opportunity for me at a really young age in my engineering career. This works. Mentors matter. And please remember, you are not Alex Honnold. Go and build that tribe of mentors for you. And notice, when you look at this diagram, every kind of mentor relationship you have sits in one of these 4 boxes, and every box has a next move. None of those moves is sit back and wait. Get proactive, go take action, and create the mentorship that you need. So let’s do a rapid recap. There’s 3 monster mistakes mentees make, and I don’t want you to make them. Number 1 is you don’t have world-class mentors. Number 2 is that you don’t meet with them on a regular cadence or in the right way to create momentum. And number 3 is that at the end of the day, you just don’t ask for the things that you actually want and need to get to where you want to go. And then you can take the names you have and put them onto the Mentorship Maximizer Matrix. Be honest with yourself. Score those mentors by name. This is not conceptual. This is with names, not with theoreticals, not with nice-to-haves. Take the names of your mentors, score them on fit. Is it a bad fit or is it a great fit, a perfect fit? Do they have the results, the skills, the experiences that you want? Can they impart that? And do they share your values? Is it fun to meet with them? All right, use your vision and values as the basis for fit, not their job title. And then score on the commitment. How much time and energy are they actually investing into you? Be honest with yourself. And remember, please, once a year coffee is not high commitment. That is a low commit. So you’re going to score each of the names on this Mentorship Maximizer Matrix. And your job is to make the quadrant move that’s listed here this week. Is it time to move on? Time to dig for gold? Ask for more or make them proud. Take that action now. Put the action in place. And look, if you have no names, if you’ve got an empty matrix, then it’s time to go fishing. It’s time to start building that tribe of mentors. All right. And if that’s you, go back and check out my episode on the life raft because you need to stop thinking you’re Alex Honnold and start Filling your life raft with the people who can support you. Now, my guess is if you’ve listened this far, you’re aware that a story like Lisa’s or a story like mine with Josh, yes, the mentorship is a critical factor to helping us create those inflection points and the success, but there’s more to the story. There’s an entire set of systems and strategies required for you to create rapid momentum in your engineering career to get that next promotion. It’s not just about mentorship. Your success requires a whole host of strategies, systems, and tools. And if you want to see that complete picture, if you want to see all of what it takes, then I’d encourage you next to go check out my Director Promotion Plan. It’s the fastest way that I know to help you achieve that next promotion that you’re looking for in a way that’s aligned with your vision, your values, your purpose. Whether you want to make it to director and beyond, or you’re still a senior engineer looking for that first manager role, the Director Promotion Plan is going to walk you through all of the strategies, the systems, the barriers, the things that I’ve seen that hold people back from getting to that next level. Go check that out. It’s absolutely free, and it’s the most comprehensive look at the way that we approach coaching here within the Oasis of Courage. So check out the Director Promotion Plan if you want to see how mentorship fits into the complete picture of your career success. And until next time, don’t forget, get out there and crush comfort, create courage, and let’s do this.
Log in
Deployment previews and Container Apps express
Environment management and pipelines
Extension APIs and command behavior
Bugs fixed
New to azd?
