How Adobe’s Tech Lead Works and Uses AI

How Adobe’s Tech Lead Works and Uses AI

Case study from my book The Multiplier Mindset, published by O’Reilly.

Gregor Ojstersek

Nov 3

This newsletter is sponsored by Unblocked.

A Pile of MCP Connectors Is Not a Context Engine

Your team connected Slack, Jira and GitHub over MCP, and engineers still spend their time steering agents to the right answer.

This article looks at why: connectors fetch from one tool at a time, so every agent stitches the pieces together itself, trusts the first doc that looks right, and adds a search to your token bill each time.

Read what changes when a context engine sits on top of your connectors: the same coding task finished 83% faster at 48% lower cost.

Read the blog post

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

My book The Multiplier Mindset published by O’Reilly has recently been released, and has also been a #1 Bestseller (or close to) on Amazon for the past 2 weeks.

Learn more about the book

In the part 2 of the book, I feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:

• How they multiply others

• What makes them successful

• How they use AI

• Their advice to engineers and engineering leaders to thrive in the AI era

Today, I am sharing the case study of Navya Agarwal, Tech Lead at Adobe, which is included in the book.

Let’s start!

What Navya Agarwal Does

A few years ago, if you’d asked Navya Agarwal what a tech lead does, she would have answered in technical terms: the tech lead is the person who knows the system best, makes design decisions, reviews code, and keeps projects moving.

Today, as a tech lead herself, she says this:

That is not wrong. It is about 40% of the picture. The other 60% is harder to explain.

It is turning ambiguity into structure before engineers hit it at full speed. It is noticing when a meeting is about to produce a decision that sounds clear but is not.

It is reading a design doc and asking the uncomfortable question, the one that might mean more work, because it is better to ask it now. It is knowing when someone is stuck but will not say so unless you create the space.

At Adobe, her work spans technical direction, cross-functional coordination, and team support. She works with product managers, designers, engineers, and other teams.

She helps shape scope, surface trade-offs, and make sure teams are solving the right problems, not just the most visible ones.

She also spends a lot of time on what she calls the infrastructure of clarity: documentation, decision logs, onboarding guides, and thoughtful code reviews.

These might not be glamorous, but they’re where much of the real leverage lives. A well-written architecture decision record (ADR) can save a team from having to reconstruct context months later, when the original conversation is long forgotten.

The biggest shift in Agarwal’s thinking has been moving away from the idea that her value is measured by how much code she personally writes.

Early in her career, impact felt like output. More features, more commits, more visible progress. As she grew into leadership, she realized that real leverage comes from helping other people do excellent work.

If she makes the team better, faster, and clearer, the resulting impact outweighs anything she could build alone.

1. How Agarwal Succeeds In Her Role

What makes Agarwal most effective in her role, she says, isn’t technical skill. It’s being willing to slow down and say, at precisely the moments when social pressure says the team should just get started, “Wait, do we actually agree on what we are trying to do here?”

Building a culture where raising concerns is valued

Early in her leadership journey, Agarwal explains, she had a habit of absorbing ambiguity herself. She’d read between the lines of a brief, make a judgment call, and hope it was right. It often was.

But the cost of correcting problems late in the development process was always much higher than it would have been if the problem had surfaced earlier.

Now, she tries to externalize uncertainty quickly. If she doesn’t know something, she says so. If a goal feels not as clear, she calls it out, saying “I want to make sure we are all picturing the same outcome. Can we spend five minutes on that?”

Most of the time, it turns out they were not picturing the same thing at all. Agarwal also cares deeply about building a culture in which raising concerns early is genuinely valued, not just tolerated. There is a difference.

Tolerated means people can speak up but sense a slight friction when they do. Valued means the team treats early warnings as useful data, not as someone being difficult.

She shared a story that illustrates this point:

We were four days from shipping when Dan sent me a message: “Hey. I have been looking at the animation rendering on lower-end Android devices, and something feels off. I think it could get ugly under real usage. Should I dig in, or are we too close to the deadline?”

The feature had been in development for four months, and the team was in final bug-bash mode. Everyone had mentally moved on. Dan had been on the team for seven months, and while he was sharp and thorough, he sometimes hesitated to trust his instincts when the timeline was tight.

I told him to dig in. He was right to flag it. On midrange and lower-end Android devices, which represented a significant portion of our Adobe Express user base in the APAC region, the animation engine was queuing canvas repaints in a way that caused visible frame drops whenever a user interacted with an animated element mid-sequence.

It looked fine in our testing environment, on the MacBooks and flagship phones we all used. It would have looked broken to millions of people on day one.

We delayed the launch by two weeks. We fixed the compositing logic, added a device capability check, and built a graceful degradation path for lower-end hardware. The PM was frustrated for about two days. Then she saw the user feedback from the actual launch: clean, fast, no reports of jank. Delaying, she said, had been the right call.

But the part I keep coming back to is this: Dan almost did not say anything.

He had the technical instinct. He had found the real problem. What he was unsure about was whether it was safe to raise it, whether the timing made his concern unwelcome, and whether he would be seen as slowing the team down rather than protecting it.

That gap between knowing something and feeling safe enough to say it is one of the most expensive gaps in engineering. My job, in that moment and in every moment like it, is to close it.

This story, Agarwal says, is the one she comes back to most often:

Not because we caught a bug. Because he felt safe enough to raise it when it mattered. That did not happen by accident. It happened because of a hundred smaller moments before it, where I had made it clear that speaking up was welcomed, not just permitted.

Building a psychologically safe environment

There is a large body of research on psychological safety, the idea that teams perform best when people believe they will not be punished or humiliated for speaking up.

Google’s Project Aristotle, which studied over 180 teams, found that this was the single most important factor in team effectiveness, more than talent, structure, or resources.

Agarwal has seen this play out enough times that she no longer thinks of psychological safety as a soft idea. She sees it as a performance input.

Building a psychologically safe environment requires consistency from the tech lead, who must respond to candor with curiosity, not defensiveness, enough times and clearly enough that it becomes the team’s default assumption about how they operate.

Agarwal shares an example of modeling this:

We were in the final stretch of a project when a junior engineer (I’ll call him Rajan) came to me after standup and said, almost apologetically, “I don’t want to slow us down, but I think there might be a data consistency issue in how we’re handling concurrent edits.”

He had been sitting on it for two days, unsure whether to raise it.

He was right. It was real. If it had reached production, we would have been scrambling in a way that would have been far more disruptive than the half-day we spent addressing it then.

I made a point of saying to the whole team in our next sync, “Rajan caught something important by speaking up. That is exactly what we want.” Not a big ceremony, just naming it clearly so the team could feel it was real.

That kind of small moment shapes culture more durably than any process or framework. When a leader actively names and appreciates someone for raising a hard thing, it sends a signal that the whole team absorbs: speaking up is what you actually want.

2. How She Multiplies Others

The word multiplier clicked for Agarwal when she understood its opposite: a tech lead who is the answerer of every question, the approver of every decision, and the person the team waits on before moving.

She has seen that pattern and admits that she’s probably been that person at some moments. “A multiplier,” she explains, “is not the person everyone depends on. A multiplier is the reason the team does not need to depend on any one person at all.”

The damage that comes from feeling psychologically unsafe is quiet but real: people stop developing judgment because they don’t need it. They stop feeling ownership because they don’t really have it.

Truly multiplying your team means increasing their capability without increasing their dependence on a tech lead. According to Agarwal, the levers she uses most are clarity, documentation, and deliberate restraint.

Creating clarity

“Clarity first,” Agarwal declares. When people understand the objective, the constraints, and what “good” looks like, they can make better local decisions without escalating.

That creates velocity, but more importantly, it creates ownership. People grow when they are trusted to think, not just told what to do.

Documenting everything that’s important

Agarwal considers documentation one of the most consistent (and widely underrated) multipliers in engineering. She thinks of it as “paying forward context.”

Creating documentation isn’t just a bureaucratic obligation but part of the engineering system itself. If something is important enough to keep explaining in Slack, it’s important enough to write down.

Each person who finds what they need in her documentation is someone who isn’t blocked while waiting for her to answer a question.

Exercising deliberate restraint

One of the most rewarding things Agarwal ever did as a tech lead, she says, was watch one of her reports step up to a level of ownership that they didn’t think they were ready for.

This engineer was “technically strong but consistently deferred in design discussions.” She waited to see what others thought before speaking. When I asked her about this pattern, she said this:

She didn’t think her opinion carried as much weight as the senior engineers’. So I started asking her first in technical discussions, before the more vocal people had set the tone.

Within two months, she was leading the design review for a key component entirely on her own: clear, confident, with strong opinions she could defend. That felt like a real impact. Not something I built, but something I helped unlock.

“Deliberate restraint is the hardest lever,” she adds:

When you know a system well, it is genuinely tempting to answer every question or solve every problem yourself. It is faster in the moment. But if I do that too consistently, I am building a team that cannot navigate without me.

Sometimes, the most useful thing I can do is ask a question back, give a nudge, and let someone else own the thinking. The goal is to make myself progressively less necessary.

3. How She Builds a Thriving Team

There’s a big difference between a performing team and a thriving team. A performing team hits goals. A thriving team hits goals, develops its people, surfaces problems early, and doesn’t crater when something goes wrong. The foundation of a thriving team is genuine trust.

Being on the lookout for the politeness trap

Agarwal says she’s learned to watch for what she calls the politeness trap: a situation in which a team is technically aligned but nobody voices their reservations.

Everything sounds smooth in meetings. The real concerns live in one-on-ones or in direct messages between engineers after the call ends. When that happens, it usually means they feel unsafe disagreeing in public. She counteracts it by modeling uncertainty herself:

I say, “I do not know” when I don’t know. I say, “I changed my mind” when I change my mind. I say, “I got this wrong, here is what I would do differently.” Not performatively, just as part of how I communicate.

The signal it sends is: you do not have to be certain to speak. You do not have to be right to contribute.

Being transparent

Another way Agarwal builds trust is by being transparent about what’s possible. She describes a project where the timeline and scope were not compatible, not dramatically, nobody was panicking, but the math just did not add up.

The project was going to be late, or the team was going to ship something rushed, or she was going to put the team through a bruising sprint for a medium-priority feature. So here’s how she responded:

I took it to the PM and said, “I want to show you what we can deliver by the deadline versus what we can deliver well. Right now, those are not the same thing. Can we decide which matters more?” It felt uncomfortable.

Nobody wants to be the person raising a flag. But we cut two features that, in retrospect, were not as critical as they had seemed in the planning doc. The team shipped the core experience cleanly. Nobody burned out. The cut features were picked up in the next cycle.

Avoiding heroics

She also cites a piece of internal Adobe engineering guidance:

Heroic behavior is tempting because it is visible, and it comes from a genuine desire to own the outcome. But a team that depends on heroics to ship is a team whose planning is broken.

I would rather build a boringly reliable team than one that runs in rescue mode. When the same people are always staying up late to save a release, that is not a sign of dedication. It is a signal that something upstream needs to change

4. How She Leverages AI

Agarwal says that while AI hasn’t fundamentally changed the role of tech leads, it has placed more of a premium on clarity, alignment, and judgment.

When the incremental cost of producing code approaches zero, the question shifts from “Can we build this?” to “Are we building the right thing, the right way, for the right reasons?” That’s a leadership question. That’s a clarity question. That’s a documentation question. These questions were always important; now, they’re critical.

Exercising good judgment and being deliberate

Agarwal quotes Kent Beck, one of the pioneers of extreme programming, describing the moment when he encountered generative AI for the first time.

In a blog post titled “90% of My Skills Are Now Worth $0”, Beck wrote that while 90% of what he’d spent his career learning had suddenly become less relevant, “The leverage for the remaining 10% went up 1000x. I need to recalibrate.”

That 10%, he explained, is about judgment: understanding the system, reading the trade-offs, knowing when something works technically but not organizationally, and sensing when a plan is sound on paper but wrong in practice.

AI is most dangerous, Agarwal says, when it creates the illusion of progress. A model will produce code confidently, and the code will often run. But code is written for humans to read as much as for machines to execute.

AI-generated code that nobody on the team truly understands is not an asset; it’s debt with a faster accumulation schedule. The antidote, she says, is being deliberate:

Design before code. Tests alongside code. Review with the same rigor whether the author is a human or a model. And keep asking: “Does the team understand what we’ve built and why we built it that way?” If the answer is no, you have outsourced something you shouldn’t have.

Writing the first draft, not the final draft

Agarwal advises her team to use AI as a way to lower the cost of the right behaviors rather than a way of skipping them.

• Want to write documentation? AI can produce a solid first draft in ten minutes.

• Want to write tests? AI handles the repetitive parts well.

• Want to explore an architectural alternative before committing? A short conversation with a model can surface edge cases that would have taken days to discover otherwise.

“That is the multiplier effect I am after: more time on thinking, less time on typing,” she says.

“AI raises my floor,” Agarwal says. “It makes the average quality of my work more consistent. But the ceiling, the work that is trusted, differentiated, and irreplaceable, still requires a person who has context, relationships, and taste.”

She says AI has changed her work the most in terms of drafting written documents:

I used to be slow on first drafts, not because I did not know what to say but because the gap between messy thinking and usable text takes real effort to cross. AI closes that gap.

I can share a rough outline or a brain-dump and get a working first draft back. Then I edit, which is much faster than creating from scratch.

I also use it to think through alternatives. When I am evaluating an architectural decision, I might ask AI to enumerate failure modes, edge cases, or angles I have not considered. It is like having a tireless brainstorming partner.

The output still needs my judgment to filter; a lot of it is obvious or not applicable, but it consistently surfaces one or two things worth sitting with.

She notes that tech lead work requires a great deal of context switching: “In a single hour, I might move from a technical review to a planning discussion to a teammate’s question to a cross-functional conversation.” AI, she says, helps her clarify her thinking quickly and move on. But she protects “the relational and judgment-heavy work.” She explains it this way:

[AI] cannot tell me that a technically correct plan is organizationally risky because of the history between the two teams. It cannot sense that someone is frustrated but covers it well.

It cannot decide which trade-off is worth making, given what actually matters this quarter. Those are human responsibilities. And as AI makes the output parts of the job faster, the judgment parts matter even more.

5. Her Advice For Engineers

Here are Agarwal’s tips for thriving in the AI era.

• Use AI to expand your leverage, but protect your judgment

Let it draft, summarize, and explore. Use it to learn faster, write better, and help you move into unfamiliar domains with more confidence. But keep your stand

ards high, your communication honest, and your thinking genuinely your own.

The engineers who will thrive in the AI era are the ones who combine technical fluency with taste, who know when generated output is wrong even when it looks right.

• Resist the pull of zero-shot building for production work

The dopamine hit of going from prompt to running app is real and addictive. But anything you are going to maintain, evolve, and stand behind requires the boring discipline: design before code, tests alongside code, and review that actually engages with what has been built.

The fundamentals do not disappear because generation has gotten easier. They become more important because the cost of skipping them has gotten harder to see.

• Invest in the infrastructure of trust

Documentation. Realistic planning. Honest onboarding. A culture where people surface problems early rather than absorbing them silently. These are not soft investments. They are the foundation that determines whether technical work can actually succeed.

• Reward teams for building well, not for rescuing things at the last minute

If your team’s heroes are always the ones staying up late, ask what the system is doing that keeps requiring rescue. Heroism that becomes routine is a planning problem in disguise.

• Don’t make the team move faster, but better

Speed without clarity is just faster confusion. Use AI where it genuinely reduces friction on the right behaviors. Do not let it become a way to skip the conversations that create alignment.

• Double down on engineering

If you care about the craft, about building systems that are well-designed, well understood, and built to last, then this is the best time to be doing it. The parts of the job that are being automated are the parts that were always the least interesting. The parts that remain are the parts that were always the most important.

Final thoughts

Agarwal says that while she used to measure her success by what she built, she now measures it by what the team becomes:

Did the people around me get stronger? Did they ship work they are proud of? Did they feel safe enough to raise the hard issue before it became the hard incident? Did they grow into ownership they did not have before?

Agarwal thinks of the engineers she works with not as resources to direct but as people who make the actual work happen. “My job,” she says, “is to make that work possible: clearer, safer, and more impactful than it would be without me in the room.”

Last words

Special thanks the Navya for sharing all these insights with us! If you haven’t yet, make sure to check out the book The Multiplier Mindset, where you can find more case studies similar to this one.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset”, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to [email protected].

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

© 2026 Gregor Ojstersek
548 Market Street PMB 72296, San Francisco, CA 94104