Most Engineers Misunderstand What “AI-Native” Means

Most engineers think “AI-native” means using Copilot to write code faster. Or adding a chatbot to their Slack channels.

Honestly, that’s AI-Enabled, not AI-Native.

In 2025, Amazon launched AI-DLC (AI-Driven Development Lifecycle). They didn’t add AI features to their old SDLC tools. They replaced the whole thing.

There’s a difference between using AI and designing for AI. The engineers who understand the second are the ones with the clearest path to senior and leadership roles in 2026.

What AI-Native Actually Means

AI-native means building systems, workflows, and architectures that assume AI exists from the start.

Here’s the difference:

• AI-Enabled:

  • Adding AI features to existing workflows (a chatbot on Slack)

  • Using AI tools to speed up old processes (e.g. speeding up coding).

• AI-Native:

  • Redesigning the entire process around AI capabilities.

  • Building workflows that wouldn’t make sense without AI.

It’s the difference between “we use AI tools” and “we designed this process assuming AI exists.”

Example 1: Amazon’s AI-DLC

Amazon replaced their traditional SDLC tools with a system designed for AI-first development, including ticketing, planning, code review, testing, deployment pipelines.

The key shift:

In the existing SLDC workflow, humans create tasks, write code, review code, and deploy. Most engineering teams add AI to support and improve each step.

On the other hand, in AI-DLC, AI drafts implementations at every stage: PRD, code, tests, deployment config. Humans review, approve, and provide judgment. You can think of AI as the “worker” in that famous meme below, and humans are those who observe.

The key difference:

Regular SDLC: PRD takes a day. Tech design takes two days. Implementation takes a week. Each step waits for PMs, designers, and engineers working on their own schedules.

AI-DLC: PRD and tech design alignment happens in one hour, in the same room. AI spots inconsistencies and suggests improvements in real-time. AI generates the initial implementation. Developers spend two days reviewing it, handling edge cases, and making architectural decisions, rather than writing boilerplate from scratch. Code review submission drops from 5+ days to 2.

Time use shifts from creating to polishing. It dramatically reduces the project lead time.

And yes, AI-DLC has its own challenges too, but that's a topic for another day 😄

Example 2: Incident Response (This Works in My Company)

Our organization redesigned our incident response process around AI.

In our old workflow:

• Alert fires at 2 AM → engineer wakes up 😫

• The engineer manually checks logs, dashboards, recent deployments → spend 20-30 minutes determining if it’s real or a false alarm

• Finally, they roll back, escalate, or decide that it’s a false alarm and go back to sleep.

In the new workflow:

• Alert fires → AI checks logs, dashboards, and recent changes 🤖

• AI determines false alarm or real incident → If false alarm: engineer sleeps through it. If real: engineer wakes up

• The engineer starts their investigation with a pre-written investigation report with possible root causes. It saves them that 20-30 minutes from the investigation.

Result: Our team’s false-alarm wake-ups dropped significantly. MTTR for real incidents dropped as well, because engineers started with context instead of starting from scratch.

Better productivity. Better sleep. Better incident handling.

Subscribe now

Why This Matters for Your Career

Notice the pattern in both examples: we didn’t add AI tools to existing processes. We redesigned the processes around AI. That creates a gap between engineers who think AI-native vs those who simply add AI to their existing processes.

The Hiring Shift

Companies have been aggressively promoting AI use, including Meta, for example, reportedly ranks teams by token consumption (whether that’s a good practice is a different conversation 😅)

That means companies are already hiring AI-native thinking engineers, but they don’t know how to ask for it yet. Job descriptions only say “good at leveraging AI tools” when what companies actually want is engineers who can think and operate in an AI-native environment.

How AI-native Engineers Think Differently

Most engineers can use AI tools, but not all of them can make good use of it without breaking the production environment.

My observation is that AI-native engineers answer different questions than regular engineers:

• How do you do code review more effectively? AI can catch syntax errors effectively. What should be the focus for humans?

• How do you structure your codebase when refactoring costs change? If AI can rewrite a module in 10 minutes, does that change your architecture decisions?

• How do you avoid relying too much on AI? We let AI provide ideas and implementations, but how do we avoid giving up our agency and individual thoughts?

• How do you avoid AI decision fatigue? When AI can generate 10 variations in 10 minutes, how do you know when to stop iterating?

The Takeaway

The pattern in both examples is the same: stop adding AI to old processes. Redesign the process around AI from the start. The gap between “uses AI tools” and “makes AI-native decisions” is where the mindset makes a difference. To get started, you need to start asking different questions about your current work:

• What would our code review process look like if we designed it today?

• What would the incident response process look like?

• What would sprint planning look like?

All assuming that AI is the driver of these tasks.

Your AI-native thinking starts here.

Last Words

Our engineering teams have been working on multiple AI initiatives. Some work well, and some not so much. Over the next few weeks, I’m breaking down the specific AI decisions I’m making as an Engineering Manager. You don’t want to miss it if you are forming your AI-native mindset.

Subscribe to get them in your inbox.

Already dealing with AI-native decisions at work? Hit reply and tell me what you’re working on. I read every response :)

See you in the next post.

Adler from Tokyo Tech Lead

I just finished the performance review season. 15+ people. Around 10k words of written feedback in one week. 😅

I’ve been doing this for years, but this time, something kept bothering me as I was writing.

Some engineers on my team had a hard year. They did solid work. And yet, I found myself needing to keep them at “Meeting Expectations”, but not “Exceeding Expectations”.

Honestly, the system pushed toward this result, not their performance. And I realized that most engineers (including younger me) have no idea how performance reviews work behind the scenes.

Let me show you what I mean.

The System Most Engineers Don’t Know About

Most engineers assume their performance rating reflects how well they did their job. And that’s true. Your output matters.

But there are also two important factors:

First: your manager has to justify every rating they give

In most review processes, your manager needs to provide concrete examples for a rating. Other managers will cross-reference it against their own team members. This is called calibration. Managers align on standards across teams, and adjust ratings based on those discussions.

So, for example, what counts as "excellent" on your team might look like "normal" on another. And that is one main reason your rating could still change after your manager submits it.

Second: there are constraints on how many people can receive top ratings.

Top ratings almost always come with financial benefits: salary increases & bonuses. Because of this, companies manage how many people receive these outcomes, mostly for budget reasons. This is true across most large organizations.

What this means in practice: even on a strong team where everyone performed well, there’s a ceiling on how many people can receive top ratings.

This is also where adjustments can feel arbitrary. In one calibration meeting, I proposed an upgrade for someone. It was pushed back because that member “hasn’t been in the company long enough”. 🙄

The Problem: We’re All Busy, and Things Slip

In addition to the system, a common problem between members and their managers is misalignment. This could lead to you working through the entire year without getting the recognition you expect.

In practice, the “Exceeding Expectations” rating usually goes to the most visible people. Writing 10k words of reviews this past week made that very clear to me.

For the rest of the team, here are the common problems:

Alignment Conversations Not Happening Often Enough

I try to give feedback in real time. That’s the goal, at least. But the reality is that I’m managing a lot of people and projects at once. Things fall through the cracks. Some contributions I only learned about when the engineer mentioned them during the review conversation itself.

Most engineers have regular check-ins with their manager. Those who ended up surprised by their reviews were the ones who never had alignment conversations. They talked about projects and statuses all the time, but never aligned on whether their achievements helped them demonstrate sufficient impact in reviews.

They assumed things were fine. Their manager assumed things were fine. And neither of them caught the gap until review season.

Managers Are Busy. That’s Just Reality.

Most managers I know face the same challenge, myself included. We’re not ignoring people on purpose, but alignment conversations don’t happen naturally.

I want to be clear that managers should be doing better, including myself. However, the responsibility for your career sits with you, not your manager. That’s a hard thing to say, but waiting for your manager to surface the right feedback at the right time often doesn’t work.

Two Keys to Get a Strong Review

So what actually moves the needle when it comes to your review ranking?

In my experience, it comes down to two things.

One: Visibility

Your manager writes your review from memory. Make sure the right things are in it.

Your manager doesn’t track every contribution you make throughout the year. Make sure to bring those projects and tasks to your 1-on-1 meetings.

This doesn’t mean bragging. Think of it as weaving visibility into your regular status updates, so your delivery stays on your manager’s radar without feeling like self-promotion.

Two: Value Alignment

Performance reviews are about whether your work moved the right needle for the team (and the business). Make sure you and your manager agree on what that needle is.

This is the one most engineers overlook. You can do good work and still get a bad review if your manager doesn’t see that work as a priority.

So What to Do About It

The good news is that none of this requires a personality change. It just requires building a small habit before review season, not during it.

The obvious one: Start with a regular one-on-one meeting with your manager, if you don’t have one already. It makes visibility and alignment a lot easier if there’s a consistent touchpoint. Aim for at least once every month, and treat it as a career alignment.

And at least once a quarter, make the conversation explicitly about your performance. Keep it direct, not formal:

• What’s going well?

• What needs to change?

• Is there something new worth trying?

• Am I on track to exceed my current expectation?

• Have you seen any improvement in X since we talked about it last time?

That last one is particularly underrated. Following up on past feedback signals that you took it seriously, and it gives your manager concrete evidence to point to when writing your review or advocating for you in calibration discussions.

The goal here is to make this a regular habit throughout the year, not a one-time panic move in the weeks before review season. By the time your manager sits down to write your review, you want them to already have a clear picture of what you’ve done and where you’re headed.

Last Words: The Engineers Who Grow Fastest

Performance review systems aren’t always fair. Forced or guided distribution means that your hard work might not pay off as you expect, and you can’t fully control over that.

But here’s what you can control: whether your manager has an accurate picture of you when they write your review. That part is entirely in your hands.

Talent is one thing, but the engineers who grow fastest are the ones who actively manage their own visibility and feedback loop throughout the year. They have uncomfortable questions. They follow up. They make alignment a habit.

If you’re not sure where you stand right now, or what questions to even ask your manager, that’s exactly what we work through together.

In a 45-minute session, we’ll look at where you are, what your manager is likely seeing, and what to do about it before your next review cycle.

Find Your Path to Senior

See you in the next post.

Adler from Tokyo Tech Lead

I Expected Mentorship in My Early Career, But…

My first job was at a small startup. The team was around five engineers, all mid-level.

No one was clearly senior. No one had a strong grasp of best practices. We didn’t have structured code reviews, no real onboarding, and definitely no one guiding you on how to grow.

So I learned the way most people do in that situation: by breaking things 💥.

I set production DB password as 12345678 (yes, I did that :P). I shipped buggy features. Incidents occurred. We improved after that. I kept learning from those experiences and started building instincts.

Two years later, I switched companies. The team was about the same size, but the dynamic was familiar. I was the most senior engineer on the team (with two years of experience 😅). I was still running the same playbook: learn through experimentation, figure it out as I go.

And that lasted another three years. I moved, stumbled, and learned.

How I Learned Without Any Senior Dev in the Team

Most engineers I know in that situation wait. They wait for someone to assign them the right task, or tell them the right approach. I didn’t have that option, so I did the only thing left: I started experimenting 🧪.

It turns out that’s exactly what senior devs do anyway.

Plan, Execute, and Adjust with Confidence

Stop waiting for someone to teach you. Start learning from your peers, even if they’re at the same level as you. And go outside your org, because the internet has more senior engineers than any single company ever will.

What actually accelerated my growth was giving myself permission to try things without asking for approval first:

• Make a plan, then run the experiment. No senior dev means no one blocking you. I would pick an idea, think through the tradeoff, and just do it.

• Invite discussions after. I would share what I tried and what I found with peers. They pushed back, asked questions, and helped me think through gaps I had missed.

One concrete example: I introduced CI into our org during that period. CI tools like Jenkins and TravisCI were already the gold standard for maintainability, but most engineers around me hadn’t adopted it yet.

We implemented it, and it turned out to be a massive improvement for the release process.

But Not Everything Worked as Expected

I also introduced GitHub Issues for project management. It flopped. People migrated back to Google Spreadsheets within a few weeks.

That felt like a failure at first. But it taught me something more useful: how to identify the gap between what a tool offers and what an org actually needs. That framework became an approach I still use today.

The failed experiment gave me more than the successful one did.

If you're not sure whether you're experimenting on the right things, or moving toward a senior role, that's exactly what I help people in Your Path to Senior Engineer. You'll leave with a clearer picture of where to focus.

Having a Mentor Didn’t Go the Way I Expected

In my sixth year, I moved to a new company. For the first time, there was someone on the team who was clearly more senior than me, and willing to invest in my growth.

I Almost Lost My Senior Mindset

Honestly, I didn’t know what to do with having a mentor, even though I finally got one.

My instinct was to defer. He had more experience, more context, and more credibility in the org. So I started following his lead. When he suggested a direction, I took it.

But after a while, I noticed something was off: I found myself simply following his suggestions, but not thinking for myself.

The curiosity that drove me to introduce CI and torun experiments had almost gone. I was doing good work, but I was doing his version of good work.

I realized that in one of my managers’ feedback. Those proactivity and adventure spirit were part of my workflow, but I didn’t possess them anymore. Having a mentor should amplify what we have, but not replace it.

The Right Way to Work with a Mentor

Once I understood that, my approach changed. I stopped bringing him problems to solve. I started bringing him conclusions to challenge.

The difference looks like this:

• ❌ Before: “How should I approach this project?”

• ✅ After: “I’m thinking of doing it by X because of Y. Any feedback?”

In the first version, I was outsourcing the thinking. In the second, I was using the mentor as a validator.

The logic is straightforward: If you bring your own thinking into a discussion, you’ll walk out with a sharper version of your own.

Last Words

You don’t need permission to experiment. You don’t need a senior dev to tell you what to try.

Pick one thing in your codebase or workflow this week. Something you’ve been curious about, or something that feels slightly broken. Form a hypothesis. Try it. Reflect on what happens.

And when you do eventually get a mentor, bring your thinking to them first. Use them to validate your ideas, not to generate them.

⭐️ The senior mindset starts the moment you stop waiting for a mentor. Your growth only stagnates if you always wait for one.

If you’re not sure whether you’re building the right habits to reach the senior level, that’s exactly what I help with in Your Path to Senior Engineer, a 1:1 session where we figure out what’s actually standing between you and the senior mindset.

Find Your Path to Senior

See you in the next post.

Adler from Tokyo Tech Lead

Moving Too Fast with AI Can Backfire

Earlier this month, Amazon rolled out a new policy: any AI-generated code now requires a senior developer to sign off before it goes into production.

It’s funny because Amazon is also one of the pioneers in driving the AI-first development forward.

It’s a reminder that moving too fast with AI could bring more incidents. A lot of them. Amazon knows this, and GitHub knows this, too.

It also proves that we’re still not at the stage where AI can completely replace software engineers. For now, humans are still the bottleneck.

In this post, I want to dig into what that actually means for your career as an engineer in 2026.

Why AI Won’t Replace Engineers Anytime Soon

The “AI will replace engineers” argument usually focuses on one thing: AI can write code.

But writing code has never been the hard part of software engineering. The hard part is everything surrounding the code, and AI isn’t close to replacing any of that.

Someone Has to Own the Outcome

I’ve seen AI-generated code that looked clean, passed review, and made it to production. But it missed some edge cases in the system, then it caused an incident.

When the postmortem happened, nobody blamed the AI. We blamed the engineer who approved it.

That’s the reality of how accountability works in software teams. AI doesn’t get paged at 2am. AI doesn’t write the incident report. AI doesn’t explain to your manager what went wrong and what you’re doing to prevent it from happening again. A human does.

This is exactly what Amazon’s policy formalizes: the human who signs off is the one who owns the outcome. AI is a tool. Ownership stays with the person.

Ownership is exactly the gap I help close in Your Path to Senior Engineer: an 1:1 session to figure out what's standing between you and the senior mindset.

Find Your Path to Senior

Most Problems Aren’t Even Software Problems

The majority of project failures aren’t caused by bad code quality. They come from everything else.

• Requirements that changed three times in a single month

• A legacy system nobody fully understood

• Legal or political constraints from compliance, security, or finance

These aren’t problems you can prompt your way out of. They require understanding the organization, the history, and the people involved.

That’s the work senior engineers do. And it has very little to do with coding.

What AI Is Changing

Let me be clear: I’m not here to downplay what AI can do.

The tools have gotten genuinely good. I use them myself. The engineers on my team use them. And the way we work has already shifted in ways that I don’t think are going back.

We Spend More Time Gatekeeping

Two years ago, AI coding tools were mostly autocomplete with better context. Now they’re doing most of the execution. It’s now mostly AI-DLC.

Engineers are using AI to pressure-test requirements, generate edge cases, and draft technical specs. AI can sketch out architecture options and flag tradeoffs. We also let them handle most of the coding and code review.

The pattern across all of these is consistent: less time executing, more time reviewing.

That shift sounds like a good thing. But it also changes what the job demands.

The Productivity Bar Has Moved

With AI, the expectation of what one engineer can produce in a given time has gone up. Not officially, in most places. But in practice, yes.

For individual engineers, this means the definition of “creating enough value” has changed. Doing what used to be considered solid output is now closer to the minimum. The engineers who stand out are the ones who use AI to amplify their impact across the team.

AI Becomes an Excuse of Layoffs

I’m fortunate enough to be able to work in Japan where layoffs are less common. But for the rest of the world, it’s changing fast.

Companies are actively trying to replace people with AI, and the number of jobs has gone down sharply, especially for entry-level jobs. It’s mainly because of the interest rate change, but AI becomes a convenient entry point for this cost reduction initiative.

Every time managers request a new headcount, we get pushback: “Can we use AI to finish the job?”

Software Engineers’ Skills that Matter Now

So if AI is handling more of the execution, what does a valuable engineer actually look like in 2026?

Two things stand out to me.

Technical Depth Matters More

There’s a misconception that AI makes technical knowledge less important.

I’d argue the opposite.

When you’re writing code from scratch, your mistakes are usually visible to you. You know what you don’t know. But when AI generates code confidently and fluently, the errors are much harder to spot. You need a stronger foundation to evaluate the output.

In practice, this shows up in two ways.

Identifying hallucinations. AI models make things up. Not always obviously. Sometimes it’s code that works on its own but breaks in the specific context. Catching these requires genuine technical understanding. You can’t evaluate what you don’t understand.

Knowing when the output is actually good. In addition to spotting errors, engineers also need to know when the AI’s solution is suboptimal, and when the approach works but will cause maintenance problems later. That judgment comes from experience and breadth.

Soft Skills AI Can’t Replicate

Teamwork, collaboration, and navigating politics. Getting a feature shipped often has more to do with alignment, negotiation, and knowing when to push and when to let something go. AI can’t sit in a tense cross-team meeting and read the room. It can’t figure out the politics behind a decision.

These skills have always mattered. They matter more now, because the execution gap between engineers is narrowing. What differentiates people increasingly comes down to how well they work with others.

Ownership mindset. Ownership means you don’t stop at “my part is done.” You care about the outcome. You flag risks early. You take accountability when something breaks, even if it wasn’t entirely your fault.

AI doesn’t own anything. It responds to prompts and moves on. The engineer who takes responsibility for the result, from requirements through production, is doing something the tool fundamentally cannot.

Last Words

Amazon’s policy is a small signal, but it points at the trend.

The companies building with AI need humans to be accountable. They are also raising the bar for what those humans need to bring.

If you’re a mid-level engineer reading this, I don’t think you should be worried about being replaced. I think you should be thinking about what you’re building toward.

Moving forward, the senior engineer who stands out is someone who thinks deeply, communicates more effectively, and takes responsibility more consistently.

If you’re working hard to adopt AI, but not sure whether you’re in the right direction, that’s exactly what I help with in Your Path to Senior Engineer, a 1:1 session where we figure out what’s actually standing between you and the senior mindset.

Book Your Session

I’ll see you in the next post.

Adler from Tokyo Tech Lead

Someone Found an Issue Last Minute...

A few years ago, I was leading a project that was moving pretty smoothly. The team was making steady progress toward the release. We had finished development, passed QA, and started preparing for launch.

Then, a few days before release, someone from Product Security joined a review meeting and asked: “Has this gone through a security review yet?”

At that moment, we realized we had never checked with them. The feature introduced a new way to upload user-generated files, which meant new security measures around validation and storage. The security team flagged several issues that needed fixes before launch. It delayed the release for an extra two weeks. We had to explain to stakeholders and upper management. Some of them were not very happy about it.

If we had looped Product Security in earlier, we could have addressed everything in the tech design. That experience taught me an important lesson: Many delays come from missing stakeholders, not technical issues.

Subscribe now

Goals: Alignment and No Surprises

In a software development project, many things can happen outside coding:

• Requirements change late.

• Another team suddenly depends on your API.

• Product priorities shift halfway through development.

Most of these situations share the same root cause: stakeholders were not aligned.

The goal of stakeholder management is straightforward: keep everyone aligned so that nothing becomes a surprise later.

Alignment helps spot issues early. Fixes can be applied early as well.

This is why stakeholder management becomes an important skill as engineers become more senior. The goal is to make sure the work moves forward smoothly across people and teams.

Types of Stakeholders (and What They Care About)

Stakeholders are the people you work with.

Each stakeholder looks at the same project from a different angle. Understanding what they care about helps you communicate the right information to the right people.

Product Managers & Business Teams

Product managers and business stakeholders focus primarily on timeline and risks.

They are responsible for making sure the product delivers and aligns with business goals. Their questions usually revolve around:

• Are we on schedule?

• Are there any risks that could affect the timeline?

• Do we need to adjust scope or priorities?

They typically don’t need deep technical explanations. They only need to know if we can deliver.

If there is anything that can impact the timeline, communicate early.

Other Engineering Teams

Engineering teams usually interact with your team in two different patterns:

Upstream Teams

Upstream teams are the one that your system depends on: platform, teams that provide APIs your service uses, etc.

What upstream teams usually care about is how your work affects their systems:

• What new functionalities do you need?

• Will traffic increase?

• Any edge case your changes might introduce?

All requirements and risks need to be communicated as early as possible, ideally at the tech design phase.

Downstream Teams

Downstream teams are the teams that depend on your system.

They might be calling your APIs or integrating your service into their features.

From their perspective, the biggest risks come from breaking changes, including API or schema changes, behavior changes, and deployment timing. Even small changes can cause problems downstream.

Experienced engineers usually communicate upcoming changes early and give teams enough time to prepare.

Product Team Members

There are also stakeholders within the product development process itself. They care about different aspects of the development process.

These are the common roles and what they care about:

• QA engineers: specs, spec changes, QA timeline.

• Designers: usability & product experience.

• Product Security: product risks, compliance.

Most teams don’t need regular updates, but they need to be included in the process when needed.

For example, QA teams need to know the specs and user stories to design test cases. After that, they only need to know if specs have changed, and the QA timeline.

These teams often surface issues that engineering might not notice during implementation. Looping them in early can prevent situations where problems appear right before launch, like a missing security review or a last-minute design change.

Keep Everyone Up to Date

Once you know who the stakeholders are, the next step is making sure information flows regularly. In practice, this usually happens in three ways.

Async communication: A short Slack message, project update, or ticket comment is often enough to share progress. These quick updates give stakeholders visibility without interrupting everyone’s schedule, and they help prevent surprises later.

Regular check-ins: These meetings are useful for discussing changes in priorities, trade-offs, or emerging risks that require input from multiple people. This is better than async communication when you need stakeholders’ full attention for discussions.

Ad-Hoc meetings: There are moments when a topic needs a quick ad-hoc meeting. This usually happens when issues need clarifications or a decision right away, such as a major priority shift, last-minute spec changes, etc.

Subscribe now

The Right Mindset

Never Assume Alignment in Silence

People tend to respond with silence if they are still processing information.

That does not mean they agree with your idea. It means they are still thinking about it.

I now treat alignment as something that needs to be actively created and regularly confirmed, not assumed after one conversation.

A simple habit that helps: at the end of a meeting, write down a short summary. “Here’s what we agreed on. Here’s who is doing what. Let me know if anything looks off.” It takes two minutes. It catches misalignments early, before they turn into real problems.

Keep Written Documents

Memories can get blurry and verbal agreements are usually unreliable. What you said in last month’s kickoff meeting is not what everyone remembers today.

Written documents are your safeguard: BRDs, PRDs, and technical design docs. These are clear, living references that capture what you’re building, why, and how.

Update the docs as new decisions are made. Archive docs that are no longer relevant.

It helps keep everyone, including new joiners, up to date.

Over-Sharing Is Better Than Under-Sharing

I know this feels counterintuitive. Nobody wants to flood people with updates they didn’t ask for. But in my experience, the cost of over-sharing is almost always lower than the cost of under-sharing.

In a meeting, if there is any concern, share it. When stakeholders feel informed, they trust the team.

People can choose to ignore irrelevant information, but there are always moments when seemingly irrelevant information reveals risks in a project.

Think of proactive communication as a way to protect your team’s focus, not just a courtesy to others.

Bonus: Ask for Feedback Regularly

Most engineers focus on pushing information out to stakeholders. But there’s a direction most people forget: asking for feedback.

Stakeholders often have concerns they’re not voicing. Maybe they’re not sure if it’s worth raising. Maybe they assume you already know. A simple “how is the communication working for you?” or “is there anything you wish you were seeing more of?” opens a door that most people won’t open on their own.

It also signals that you treat the relationship as a two-way partnership, not a broadcast channel. That perception alone builds a lot of goodwill.

I usually ask for feedback from stakeholders every quarter or after a project is delivered. It could be a general Google Form or a Slack message. Most people say things are fine, but occasionally there is valuable feedback worth acting on, such as how we communicate, frequency, or meeting agenda suggestions.

Acknowledgement & Follow-Up

Use that feedback to improve how the team works with stakeholders. Remember to send a short follow-up after you’ve taken any action based on their input. This is how trust compounds over time.

Last Words

Stakeholder management is a core part of engineering leadership, and it compounds over time.

The engineers and managers who do it well build trust, reduce friction, and make the whole organization work better. That reputation follows you throughout your career.

Start small. Pick one habit from this post and apply it to your current project. A weekly async update. An early risk flag. A single feedback question at the end of your next check-in. Small, consistent actions add up faster than you’d expect.

That’s it for today.

If this way of thinking resonates, I write about senior-level mindset, ownership, and career growth for engineers.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

Subscribe now

At some point, most senior engineers run into this tension:

Someone’s work is slowing things down. And the outcome is at risk.

Getting things done requires multiple follow-ups. Questions keep flowing back to you. You start spending more time helping them.

You’re not the manager. What should you do next?

It’s tempting to label this as “low performance,” and escalate. Right?

Not so fast!

When you frame the issue as performance, your options feel political. On the other hand, when you frame it as risk, your options become practical.

This is where senior engineers think differently.

Think First: Is It Low Performance?

Starting With Labels Won’t Work

Calling someone a “low performer” feels efficient, but it narrows your thinking too early.

Once you attach a label, the situation becomes personal. Conversations turn defensive. And before you know it, you have moved away from solving the actual issue.

Experienced engineers avoid this. Early labels rarely improve outcomes.

Reframe the Problem as Delivery Risk

A more useful frame is this:

Performance issues are risks to outcomes, not judgments about people.

Instead of asking “What’s wrong with this person?”, ask:

• What outcome is at risk?

• Where is the quality issue?

• What issues keep coming back to me?

This keeps the discussion grounded in facts. It also gives you room to act without needing authority over the individual.

Don’t Escalate Too Early

Escalation is the most common instinct here.

If you’re not the manager and something feels off, it’s tempting to escalate and move on. It feels responsible: someone else owns people management.

The problem is timing.

Escalating too early often backfires. You raise a vague concern without clear evidence. From the outside, it sounds like frustration. That’s when escalation turns political.

Senior engineers treat escalation as a last resort, not a first response.

Early Signals Senior Engineers Pay Attention To

Work That Always Needs Follow-Ups

Occasional follow-ups are normal.

The real sign is that you constantly have to remind someone to finish work. In addition to the cost of time, it also increases your cognitive load. You start tracking their tasks in your head.

It is a quiet form of compensation.

That’s an early warning sign.

Issues Always Escalate Back to You

Questions that should have been resolved by someone else keep coming back to you.

Small decisions. Edge cases. Things that they should have handled by themselves.

It usually means either expectations are misaligned, or someone is avoiding making decisions under uncertainty.

You Start Compensating Without Noticing

This is a hidden but big red flag:

• You rewrite parts “just this once.”

• You need to double-check everything.

• You unblock dependencies yourself because it’s faster.

At that point, expectations need to be revisited.

Subscribe now

The Solution Ladder: Step by Step

OK. Now it’s the important part. What do you actually do?

Here’s a list of actions you can take to reveal the problems before you escalate.

Think of this as an ownership ladder. You climb it one step at a time. If a lower step works, you don’t need the higher ones.

1. Make the Outcome Explicit

Start by removing guesswork.

Be specific about:

• What to deliver

• When to deliver

• What quality level you expect

This often means translating vague requests into concrete outcomes.

“Can you move faster?” is vague.

“We need to deliver by X, so please send your PR by Y” is clear.

2. Narrow the Scope Before Judging

Before assuming someone can’t do the work, check whether the work itself is too ambiguous.

Ask:

• Is the task too vague?

• Is dependency clear?

• Is success defined?

If the scope is fuzzy, shrink it. Break the work into smaller pieces with clearer checkpoints. Many “performance” problems disappear once the problem is constrained.

This helps pinpoint where the problem is.

3. Create a Short Feedback Loop

Long feedback cycles hide problems. Short ones surface them early.

That means:

• Smaller deliverables.

• Earlier reviews.

• Clear definitions for what “good” looks like at each step.

It helps both sides to see reality sooner, while there’s still time to adjust.

The goal is risk management

4. Decision: Contain or Escalate

At this point, you have information. Now you choose deliberately.

Consider:

• How critical is the outcome?

• How reversible is the risk?

• How much time do you have?

Your options:

• Contain: Narrow scope or add guardrails. Move on.

• Escalate: Report risks with evidence, and your recommendation.

Escalation here is to focus on achieving outcome, instead of handing over problems.

But whichever option you go for, you always share your findings with your manager.

Ownership Anti-Patterns

Absorbing the Work Silently

Most of the time, it’s faster if you fix it yourself.

You don’t say anything because it feels efficient.

But in fact, this keeps delivery moving in the short term, but it trains the system to rely on you as a safety net. Over time, you become the bottleneck and the risk increases.

Escalating Without Evidence

Raising concerns without proofs shifts the focus. It becomes an opinion.

❌ “I feel this person is underperforming” does not explain anything. Your manager needs to guess.

✅ “Here’s what’s blocked, what I tried, and what decision is needed” is clear.

Ownership requires preparation. Escalation without context weakens trust.

Turning It Into Mentorship Too Early

Not every delivery issue is a mentorship opportunity.

Jumping into mentorship mode too early can blur boundaries and create extra workload for yourself, especially when you’re not the manager.

Focus on stabilizing outcomes. Growth conversations can come later.

Last Words: Ownership Without Authority Is a Career Skill

Handling these situations well comes down to ownership.

Senior engineers don’t wait for titles to protect outcomes. When delivery is at risk, they step in to create clarity and surface problems early, even when the people involved don’t report to them.

Over time, people start to rely on you in ambiguous situations. You’re trusted with broader scope and more complex problems.

This is how seniority shows up in practice.

Develop that skill, and the role tends to follow naturally.

That’s it for today.

If this way of thinking resonates, I write about senior-level mindset, ownership, and career growth for engineers every week.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

Subscribe now

“I did what I was asked.”

That sentence explains more stalled engineering careers than any technical skill gap.

Most mid-level engineers are reliable. They ship work. They follow process. They escalate risks. But they are still not quite senior yet.

The issue is usually ownership.

In this article, I’ll walk through how ownership evolves from junior to senior engineers, and what ownership looks like in practice.

Ownership Skill in a Nutshell

Junior Engineers: Task Ownership

At the junior level, ownership is mostly about executing assigned work correctly.

Work starts with a clearly defined ticket. Requirements and steps are usually spelled out. Decisions are made by someone else.

If something is not clear, they push back and they expect others to resolve the ambiguity.

Success is simple and concrete:

My responsibility ends when the task is done.

At this stage, junior engineers are building fundamentals: learning the codebase & understanding team norms. The scope of ownership is intentionally narrow. They are mainly learning how things work in general.

Mid-Level Engineers: Project Ownership

At mid-level, engineers start owning projects or features.

The difference from pure execution is that they start making decisions. They help stakeholders understand the technical challenges and effort. They help them update requirements to achieve the best outcome.

At this stage, they still need help understanding the big picture from senior developers, but they can make most decisions themselves and deliver end-to-end.

But there’s a common ceiling.

When requirements are unreasonable, priorities conflict, or incidents happen, many mid-level engineers pause. Some can make decisions, but most can’t. They escalate and stop.

At this stage, success usually means:

My responsibility ends when the project is delivered.

Senior Engineers: Outcome Ownership

Senior engineers own outcomes, not just work.

• They take responsibility end-to-end.

• They act even when no one explicitly asks them to.

• They make progress in ambiguity instead of waiting for clarity.

The definition of success changes to be more business-oriented:

My responsibility ends only when the problem is solved.

Senior ownership often looks invisible on paper. It’s hard to track it on the Jira board, such as starting a tech design to align teams and pushing back an unreasonable request.

This is also why senior engineers are trusted with larger scope. Managers don’t need to micromanage them, because they don’t stop at “done” if the outcome is still broken.

Mid-Level Engineers Avoid Ownership Without Realizing It

In my experience, this avoidance usually comes from habit.

They Are Used to Clear Boundaries

Mid-level engineers often grow up in environments where responsibilities are clearly segmented.

• PM defines scope.

• Senior engineers make the key technical decisions.

• Mid-level engineers execute what’s assigned.

That structure works well. But over time, it creates a mental model where stepping outside a defined boundary feels like overstepping.

When something falls between roles, the default response becomes: someone else owns this. That’s how most team work, and that’s how the system has conditioned people to think. It comes as a habit.

They Over-Rely on Senior Engineers

The clear boundaries also create another problem: they stop at escalation.

There are many mid-level engineers not being in the part of the decision-making process.

After they escalate a problem to senior engineers, they wait. They don’t make their own recommendations in front of senior engineers.

In that case, escalation becomes the end of the action, ownership quietly stops there.

For example, a mid-level engineer might identify two possible solutions to a high-latency issue, but not sure which is better. They escalate to senior engineers and wait for their input. The senior makes the decision, and the issue gets fixed.

Nothing is wrong with that, but in this case, the mid-level engineer miss the learning opportunities. They could have proposed a recommendation, explain tradeoffs, and get feedback on their thinking. Many mid-level engineers miss opportunities like this.

Subscribe now

What Ownership Looks Like in Practice

Ownership sounds abstract, but in practice, it’s how you respond when things are unclear or unfinished.

Owning Ambiguity

When facing unclear requirements and conflicting priorities, owners don’t guess blindly and also don’t freeze. They ask clarifying questions, outline options, and move the conversation forward.

Typical behavior looks like:

• “Based on what we know, I’d recommend this, unless we discover X.”

• “I’ll need to talk to my manager, but I’ll get back to you by the end of tomorrow.”

The key is to move things forward. Even a small move is more useful than no action.

Owning Failures/Incidents

When something breaks, owners don’t stop at fixing the immediate issue. They stay with it end-to-end.

In practice, this looks like:

• Clearly stating what went wrong.

• Focusing on system causes (and not blaming).

• Making sure a prevention plan exists.

Owning failures is about ensuring the same problem doesn’t occur again three months later.

Owning Communication

Owners don’t assume information magically spreads. They close loops, confirm decisions, and make sure stakeholders know the progress and results.

This often looks simple:

• Summarizing discussions in writing.

• Explicitly calling out owners and timelines.

• Checking that everyone shares the same understanding.

None of these actions require a title. They require the mindset that if you care about the outcome, it’s your responsibility to make progress visible and real.

Start Small, Start Today

Practicing the ownership skill starts with small, deliberate shifts in how you approach your work.

If you want to start today, the easiest way to begin is to pick one area and fully own it. One project. One recurring issue. One process that keeps causing friction. Don’t try to fix everything at once.

For example:

• Take a problem and turn it into a concrete proposal.

• Follow one issue past escalation and stay with it until it’s resolved.

• Close one feedback loop that usually gets dropped.

You can also ask your manager for opportunities.

Consistency matters more than scope. Owning something end-to-end once a month is more valuable than half-owning ten things at the same time.

Over time, the scope grows naturally.

Last Words

Ownership is about what you choose to carry when things are unclear, unfinished, or uncomfortable.

Senior engineers are trusted because they don’t stop at “my part” when the outcome is still broken. You already have the skills. You only need that small change of mindset.

That’s it for today.

If this way of thinking resonates, I write about senior-level mindset, ownership, and career growth for engineers every week.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

Subscribe now

Congratulations! You just got a new offer 🎉

Now you are ready for a higher salary, better title, maybe a more ideal engineering culture.You’re finally “moving forward” again after feeling stuck.

Nice. Good for you 👍

But here’s the thing: the excitement can blur your judgment. You start imagining what life could be like at the new company. You picture yourself in that role, working with that team, solving those problems.

But before you accept that offer, you need to step back. You need to understand what you’re actually trading, not just what you’re gaining.

Every decision is a tradeoff, not “better offer = better life”.

Risks of Changing Jobs Nowadays

Behind your shiny offer, here are some risks that you cannot ignore.

The Current Market is Less Forgiving

Since AI tools are now the default, companies expect more from new hires.

⚠️ Less tolerance for learning through mistakes. When budgets are tight, mistakes feel more expensive. Shipping a production-breaking bug in your first month can leave a stronger negative impression.

⚠️ Faster ramp-up is expected by default. Instead of given six months, you’re expected to contribute meaningfully within weeks. Your manager needs earlier results to demonstrate productivity.

New Hires are More Exposed to Layoffs

We’re only one month into 2026 and the number of massive layoffs has not slowed down.

When priorities change, newcomers are more exposed. Layoffs and re-orgs happen. When they do, the people who joined recently are the first ones leadership considers cutting.

You don’t have the relationships or the track record to protect you yet.

The Grass Looks Greener Until You Get There

Even before the AI era, this problem existed: Every company sells you a dream during the interview process.

They talk about their culture, their tech stack, and their ambitious roadmap. They highlight the interesting problems you’ll solve. They show you the best version of themselves.

But you don’t know what you’re actually signing up for until you’re inside.

Their “modern tech stack” could be a half-migrated mess. That “collaborative culture” might mean endless bureaucracy.

It’s only a different set of problems. Sometimes worse.

Staying Has Its Advantage

Many people don’t think staying has any advantage. They have had enough, and they want to move on.

That’s understandable. But staying can be the smarter move if you have a clear career plan.

Trust and Credibility Give You More Options

At your current company, people know what you’re capable of.

Your manager has seen you handle incidents. Your teammates have reviewed your code. Stakeholders have worked with you on projects. You’ve built a reputation.

That trust opens doors to multiple possibilities.

👉 You may be able to lead a major architecture change. You know the system and workflow deeply. You have the connection who can support your decisions.

👉 You may also have options to move to management. You’ve mentored teammates and influenced technical direction. That track record makes the transition possible.

At a new company, you’re guessing. You don’t know the system. You don’t know whose opinion carries weight. The learning curve slows you down.

Comfort Can Be an Asset

Here’s something most people get wrong: comfort isn’t always bad.

Yes, being too comfortable can make you stagnant. But it can also free up mental energy for other things.

When your day-to-day work feels manageable, you have space to explore side projects. You can invest in your blog, your coaching business, or other long-term investments. You can pursue interests that might not pay off immediately but could become opportunities later.

I’ve seen engineers stay at comfortable jobs while building businesses on the side. Eventually, those side projects turn into a meaningful income stream. That only worked because they weren’t burning out at their 9-to-5.

So How Should You Choose?

Most engineers never think about this when they get an offer: What are you actually optimizing for?

Not just right now, but in the next 2-3 years.

Because the answer changes everything.

Different Goals Need Different Strategies

Here are some examples of what you should consider.

If you’re optimizing for learning new technologies, switching might make sense. A new company means new problems, new tech stacks, new challenges.

If you’re optimizing for career advancement into management, staying might be smarter. You already have the relationships and trust needed to move up.

There’s no universal right answer. It depends on where you are and where you want to go (and you might want to avoid asking your friends).

If You Need Clarity

If you’re sitting on an offer and feeling torn between a comfortable role and a new opportunity, that’s exactly the kind of decision I help people think through.

In career decision consulting, I won’t tell you what to choose, but help you clarify the tradeoffs and pressure-test assumptions.

Instead of making a “brave” or “safe” choice, you’ll make a decision you won’t second-guess six months later.

Learn More: Career Decision Consulting

That’s it for today.

If this resonated, feel free to like or share it.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

Subscribe now

What It Is

Your Path to Senior Engineer is a one-off, structured conversation designed to help you identify exactly what's standing between you and a senior role, and map out your next move.

Typical decisions include:

• You’re doing work but there’s no recognition

• You want to know what senior actually means and how to get there

• You’re unsure whether to push for promotion, switch teams, or change companies

What It Is Not

To set expectations clearly, this is not the following:

• Not ongoing coaching

• Not emotional processing or therapy

• Not generic career advice

How Does It Work

1. Book a Session

You book a session directly using the scheduling link (and complete payment at the same time).

If you don’t see a suitable time due to timezone differences, feel free to reach out to me directly and we can discuss alternatives. I’m based in Japan (JST).

Book Your Session Here

2. Prep: Submit Your Context

After booking, there will be an email confirmation with a list of questions.

You’ll be asked to share:

• Your current role and how long you’ve been at this level

• Where you feel stuck or unclear

This ensures the session stays focused on your specific situation.

3. Live Decision Consulting Session

During the session, we focus on:

• What’s keeping you from becoming a senior engineer

• What senior looks like in your specific context

• The concrete actions that will close the gap

I will challenge assumptions, identify blind spots, and share my perspective based on real engineering and management experience.

By the end of the session, you should leave with:

• A clear picture of what's missing

• A prioritized set of actions to take in the next 30–90 days

• Clarity on whether your current company is the right place to make that move

The value is in reaching clarity and being able to move forward.

Pricing

USD 90

It includes:

• One live session (45 minutes)

• Optional follow-up

FAQ

Refund Policy

You can cancel for a full refund up to 24 hours before the session.

If after the first 10 minutes of the session it’s clear that this is not for you, we can stop and I’ll issue a full refund.

Other Questions

If there’s any question, feel free to reach out to me:

• DM on Substack or LinkedIn

• Send an email to: me [at] adlerhsieh [dot] com

  Book Your Session Here

I get this question constantly from engineers thinking about their next career move: “Should I move into management?”

It’s a reasonable question, but slightly misleading.

The Real Question

When you try to label a decision as “good” or “bad,” you ignore the tradeoffs. Every option comes with downsides. A “good” decision doesn’t mean there are no downsides.

So the real question is: What are you optimizing for in the next 2-3 years?

Because once you understand what you’re actually trying to achieve, the IC versus management decision becomes a lot clearer.

So here’s how I look at it.

The Management Path Brings Advantages

I’m not going to pretend management is just a different flavor of the same job. It changes how you work and what opportunities become available to you.

Here’s what the management track actually gives you:

You Understand How Businesses Work

As an IC, you see projects from the execution side. You know what needs to be built and how to build it.

As a manager, you are involved with more business context. You are part of the decision before projects are brought to the engineers. You are also part of the discussions that connect projects with business outcomes and decide whether they’re worth doing.

This perspective is valuable whether you stay in management or not. Once you understand how managers think and what drives business decisions, you make better technical choices as an IC.

You Learn the Power Dynamics

Management exposes you to organizational politics in ways IC work never does.

You hate politics? Me too, but it’s there. And unfortunately, you usually need to get along with it to improve your impact level.

It’s tempting to believe that a well-designed idea will speak for itself. In reality, you usually need the right people to agree before anything moves forward.

As a manager, it’s much easier to see:

• Which stakeholders actually have influence

• How decisions really get made

• Who you need to consult before proposing something

This doesn’t mean you have to play political games. For me, it simply means navigating the organization more effectively.

You Can Usually Go Back

Some managers return to IC role later, and many people don’t realize that. Management does not permanently lock you in.

I’ve seen plenty of managers return to IC roles later. Some missed coding. Some realized management wasn’t for them. Some wanted to look for different challenges.

As long as there’s an internal opening for the IC role, companies usually are flexible.

Trying different paths is rarely a bad idea. Maybe the management path is perfect for you.

Subscribe now

The Management Path Also Brings Constraints

Let’s also be honest about what you’re giving up.

Management comes with real constraints that affect your career in ways most people don’t think about until they’re already committed.

You Need to Focus on a New Skill Set (and Less on Tech)

Management requires skills that have nothing to do with engineering.

Handling difficult conversations. Navigating organizational politics. Coaching people through performance issues. Managing budgets. Balancing competing stakeholder demands.

These skills are valuable. But learning them takes time and energy. That time comes directly out of technical work.

Every hour spent on management skills is an hour not spent on system design or technical depth.

For example, if you plan to target FAANG-level companies later, most still rely on LeetCode-style and system-design interviews. ICs tend to practice these continuously. Managers often have to relearn and practice from scratch.

That’s fine if management is where you want to be. It’s a problem if you thought you’d keep both skill sets equally sharp.

Your Responsibilities Become Fixed

IC roles like Staff and Principal Engineers have more flexible. Their role adapts with the company’s technical needs. You might be embedded in one team to help them get on track today, but move on to lead another cross-team project tomorrow. This brings a lot of variation, surprises, and challenges to work.

As a manager, your growth path is clear: manage more people.

The corporate ladder for managers is well-defined: Engineering Manager → Senior EM → Director → VP → C-level. Each step means more direct reports, bigger teams, broader scope.

Your impact becomes defined by planning, execution, retrospectives, conflict resolution, and people problems. They can start to feel repetitive if you don’t actively look for other meaningful work yourself.

The Job Market Is Smaller (And Harder to Navigate)

One uncomfortable truth is: There are fewer management roles than IC roles.

A typical engineering organization has one manager for every 6-8 engineers. That’s 6-8 IC openings vs 1 EM opening. Companies also prefer internal candidates because management hires carry higher risk.

And just like IC roles, there are “good” roles and “bad” management roles. There are “good” roles at companies with solid engineering culture, reasonable expectations, and growth opportunities. Those usually go to people with connections. So you can start to imagine how challenging it is to find a good management job.

By contrast, this is not a big problem for IC roles. Staff and Principal engineers are still rare. If you’re good, companies actively look to you.

As a result, job hunting for management roles usually takes longer.

Start Asking What You’re Optimizing For

Many engineers went into management because it seemed like “the next step”. Two years later, they realize they never wanted to do it at the first place.

Others stayed IC because management seemed stressful. Three years later, they realize that they should have started earlier.

So “IC vs EM” is the wrong question. The real questions are:

• What are you actually trying to achieve in the next 2-3 years?

• What kind of impact matters to you?

• What trade-offs are you willing to make?

Once you know those, the path becomes obvious.

If You Want Clarity

If you need help figuring that out, I’m here to help. I offer Career Decision Consulting for engineers at exactly this crossroads. It’s based on my own experience and how I helped other engineers make such decisions.

We’ll work through your goals, evaluate your options, and build a plan that makes sense for where you actually want to go.

Let’s map out your next move together :)

Learn More: Career Decision Consulting

That’s it for today.

If this resonated, feel free to like or share it.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

I have a friend who spent an entire month asking everyone he knew whether he should take a new job.

He collected dozens of opinions from his friends. Everyone had a take. Some said he should go for it. Others warned him to stay put.

He hesitated for weeks, and finally accepted the offer right before the deadline.

Six months later, I heard that he was already looking for a new job.

“What happened?” I asked. “I thought you had thought it through.”

“It turns out this job was not for me.” He replied.

He also talked about his friends’ suggestions:

“I spent a month asking everyone else what they would do. By the time I accepted the offer, I wasn’t confident in the choice anymore. I just wanted the debate to stop.”

That’s when I started to realize that relying too much on your friends for career advice can backfire.

You need the right mindset to get real values from your friends.

Why We Default to Asking Friends

When we face a difficult decision, most of us start with a message to a friend.

• Should I take this job offer?

• Should I start that side project?

• Should I quit my current role?

You start that conversation. It feels productive. It feels safe.

And that might be the problem.

It Feels Safe and Low Effort

Asking a friend is the safest possible starting point. It requires almost no preparation and very little emotional exposure.

• You don’t need to fully understand what you want yet.

• You don’t need to explain the risks.

You can simply say something like, “I’m thinking about changing jobs,” and see how it goes. That moment alone creates relief.

Asking Feels Like Progress Without Commitment

When you start a conversation with a friend, you’ll feel progress, even though no decision has been made.

Asking for advice creates the feeling of movement without forcing a decision. At the end of the conversation, it often ends with: “OK thank you. I’ll think about it.”

You delay the inevitable moment of committing. For high-stakes decisions, that can be very appealing.

Their Advice Comes with Hidden Costs

Friends care about you. But when they give career advice, there are often misaligned incentives and hidden biases.

Some friends can evaluate your opinions, but they don’t feel the consequences.

Life is Different

Even close friends often miss critical variables:

• They don’t share your financial situation

• They don’t have your visa or family constraints

• They aren’t measured by the same career timeline

Yet friend advice rarely comes with a disclaimer. They are just trying their best.

They Don’t Prioritize Decision Quality

Friends are nice.

Most friends don’t challenge you even when your idea is weak. They protect you from pain.

So you hear a lot of reassurance.

• “You’ll be fine either way.”

• “At least it’s stable.”

• “You can always change later.”

Those statements reduce anxiety. They don’t necessarily improve decisions.

The real advice you need to hear often buried under these comfort.

It Creates Noise

Asking one friend is ok, but asking five different friends for advice, it creates noise. Noise delays your decisions instead of clarifying them.

• You collect opinions instead of defining tradeoffs

• You feel informed, but not convinced

Without you knowing, you eventually pick something just to stop thinking.

Subscribe now

Talk to Your Friends The Right Way

Don’t get me wrong. You should still talk to your friends, but differently.

Here’s what I think you should use your friends for.

Sanity Checks

First, list your tradeoff, and have a tentative decision in your mind. It does not have to be perfect, but you need to go through it yourself first.

And then bring that to a friend.

Talk through your logic, and then ask them:

• “Does this assumption sound unrealistic?”

• “What am I missing here?”

Friends are better at spotting blind spots than setting direction. It’s a lot better than asking a vague question like: “So… what do you think I should do?”

Instead, tell them your tentative decision and listen carefully to where they push back.

Emotional Support

Friends are excellent at helping you live with a decision.

• They help you process doubt, fear, and disappointment after you commit.

• They remind you that a setback isn’t a personal failure.

• They help you recover when things don’t go as planned.

It works in a different way.

But emotional support should come after the decision. You need more sanity check than emotional support before you commit.

When the Decision Actually Matters

If the cost of being wrong is low, ask your friends.

But when the decision shapes the next few years of your career, you need a structured way to evaluate tradeoffs and commitment.

Once you miss that great job offer, the next one might take years to come.

That’s why I offer Career Decision Consulting starting this month.

It’s designed for mid- to senior level software engineers who are stuck between decisions.

For example,

• Stay in your current role or move to a new company

• Accept a promotion vs. change teams

• Staff engineer track vs. management

It’s an one-off, structured session that helps you with clear options, explicit tradeoffs, and narrowing down to one decision you can own.

Start deciding like the consequences are yours (because they are).

Learn More: Career Decision Consulting

That’s it for today.

If this resonated, feel free to like or share it.

I’ll see you in the next post.

Adler from Tokyo Tech Lead

2025 went by fast, and it’s that time again to review what I’ve achieved.

Before getting into numbers and charts, I want to say this first: thank you all for reading my newsletters 🙏

This year has been messy for me as a writer. I disappeared for months and changed directions. Many of you stayed anyway.

Let’s dive into what happened behind the scenes.

2025 in Numbers

• 33 posts posted, including 9 guest posts.

• 734 new subscribers.

• 1,405 current total subscribers, down from 2,469. (I’ll explain later 😁)

• 1,580 views per post on average.

Most popular posts

🥇 My Path Into Tech: What Worked, What Sucked, What Stuck by

I really appreciate Jenny sharing her story. She talked about her abrupt life changes, how she navigated through the uncertainty in life, and finally landed a job in tech.

She also highlights what worked and didn’t work for her. Even though the time is different now, I would still consider it very valuable for those who are experiencing the same.

🥈 A Day in the Life of a Tech Leader by

It goes through the life of a tech leader in a small startup. I also provide my perspective of working in a big company. It touches the day-to-day tasks that Engineering Managers need to handle. It’s useful for those who are interested in knowing what management job looks like.

It’s a collaboration post. Huge thanks to HipsterTech for guest-posting :)

🥉 I Stopped Writing for a While

I found myself cannot take it anymore mid-2025. I completely stepped away from Substack, and instead focused on my 9-5 and personal life. It gave me that space to breathe.

I ended up taking a break for six months. On my return, I got a warm welcome from the community. This break helped me rebuild my momentum and see writing from a fresh perspective.

Subscribe now

I Achieved Zero Goals

It sounds funny but I achieved exactly zero goals set in my 2024 wrapped post.

• Goal #1: 52 posts.

  • Result: I posted 33 posts.

• Goal #2: Subscriber count 10k.

  • Result: My subscriber count is now 1.4k, far from the goal.

• Goal #3: Paid content ready & published.

  • Result: I still do not have any paid content.

And no, that’s not a bad thing. In fact, it was necessary.

These “failures” reflect why I burnt out and needed to take a six-month break.

My goals were unrealistic and proved that I lacked a clear vision and strategy at the time.

Now that I’m back, I feel much better. I’ve been able to build a more realistic schedule and a sustainable system.

Changes After the Break

✂️ I Cut My Subscription List by 50%

Inspired by in his cleanup, I took action to clean up my subscriber list.

The main issue was that my original list was imported from my 10-year-old blog. Back then, I mostly posted coding tutorials rather than career content. Most readers have already lost their interests over the decade.

My open rate was terrible, hovering around 18% to 20%. It also gave me a false sense of popularity.

So I took some actions:

• I removed dead emails. Most of them are from the imported list, and are not being used anymore.

• I removed inactive readers who hadn’t read anything in six months.

As a result, my subscriber count dropped from 3.2k to 1.4k.

That’s good! No one cares about my subscriber count more than I do, and that 3.2k figure was just an illusion. Now the numbers reflect more accurately about how many people are interested.

Since then, my open rate has jumped from 19% to 35%.

I Built a Writing System to Prevent Burnout

One main reason that led to my burnout is that I focused too much on vanity metrics.

I didn’t have a product or a strategy. I was simply hoping the subscriber count would go high enough and I could turn on paid subscriptions.

And hope is not a strategy. 🤷

I realized that sustainability came from two essential factors:

• Knowing what’s the next big thing. That makes me write toward that direction.

• Focus on delivering value, not numbers. Build a close core audience.

Now my writing process is more realistic and motivating. It’s a lot better than shooting in the dark, hoping the numbers will go up.

Subscribe now

More Senior Dev Content in 2026

My writing was spread out in different directions in 2025. One day I wrote about engineering leadership, another day about tech culture in Tokyo, etc. They are not really connected, and it’s hard for readers to have a clear picture about my focus.

I’ll focus more on one area in 2026: Senior Software Engineer skills & mindset.

It’s a mix of technical skills, soft skills, career strategy, and engineering leadership. Overall, it provides a systematic way to levels up senior level, and stay sharp there.

But what do you think? Would you prefer hearing different stories from me? Help me shape my content by clicking one of the following options, or leave a comment.

Thank You for All the Guest Posts

I want to show my appreciation to those who have written a guest post on Tokyo Tech Lead:

• How an Effective Delegation Looks Like by

• A Day in the Life of a Tech Leader by

• Five Reasons I Maintain an Open-Source Project by

• AI-Powered Coding: The Best Free Tools Every Data Engineer Needs by

• My Path Into Tech: What Worked, What Sucked, What Stuck by

• Interpreting Software Engineering Work into Business Value: Lean Startup Basics by

• Becoming a Tech Leader: How to Shift from IC to Leader and What to Expect on the Way There by

• From Feedback to Fuel: How to Grow After a Disappointing Performance Review by

• Stop Negotiating Capacity by

I’ve learned so much from you and thank you for your contribution 🙇

Thank You All

Thank you all for reading my posts in 2025. There are more ups and downs than I expected in this year, but I’m grateful for all of you.

That’s it!

I’m going to take a short break during the holiday season.

Thank you all for the support. I’ll see you in 2026!

👋

Adler from Tokyo Tech Lead

Subscribe now

When No One Wants to Make the First Move

I had two team members who disagreed on how to move a project forward. But instead of working it out, they both got stuck. They were waiting for the other to make the first move.

At first, I didn’t think it was a big deal. Small disagreements happen all the time.

I had meetings with them separately, and identified action items.

To my surprise, two weeks later, nothing had happened.

They weren’t discussing solutions. They were simply not moving forward.

When I stepped in again, I put them in the same meeting. It felt like debugging two systems at the same time. I had to ask all the questions they avoided asking each other.

They pointed at each other: “Oh, but the other engineer didn’t do X first so my Y is blocked”. I had to track the actions one by one, with the project overview in mind so that I didn’t get lost in this blaming cycle.

Eventually we found the blocker: one of them was stuck on the development order. A small switch in sequence unblocked everything.

Honestly, I felt drained afterward 😰. The solution was simple. Getting there wasn’t. They both waited for someone else to resolve the conflict for them. They both hoped the other person would “just do something.”

Unblocking Yourself Without Waiting

I learned that engineers resolving their own conflicts is more efficient than managers stepping in.

Managers don’t understand the technical details better than the engineers. In my story, I didn’t realize that the project had stalled until I checked in again two weeks later, by which point emotions had already built up.

It would have saved us hours if engineers stepped up and owned the issue.

I’d like to recommend the framework that I usually use when handling conflict. I started using it when I was an IC, and I still use it today. It helps me with a more structured approach.

💡 The ARC Framework

ARC = Acknowledgement → Root Cause Analysis → Commit to Actions

It’s not revolutionary, but it’s a structured way to move from “we’re stuck” to “here’s what we’re doing next.”

It works because it forces both sides to slow down. It encourages people to walk through the arguments and understand each other’s perspective.

Let me break down each step.

Step 1: Acknowledgement

The goal of Acknowledgement is to stabilize the conversation.

When engineers disagree, they often just defend their position. They explain why their approach is right. They point out flaws in the other person’s thinking.

That doesn’t work, and it builds up emotions.

Before you can solve anything, you need to acknowledge the other person’s perspective and clarify what you’re both trying to achieve.

Assume good intentions

Everyone is trying to do the right thing for the project.

Start by reminding yourself: the other person is not being difficult on purpose. They have reasons for their position.

This sounds basic, but it changes how you approach the conversation.

You stop guessing, and start focusing on the problem instead.

Focus on the Problem, Not the Person

Focus on how you are blocked.

Try:

❌ “You didn’t finish X, so I couldn’t proceed.”

✅ “The project is blocked because X isn’t done yet.”

Notice how the focus shifts from blaming the person to the fact itself.

Name the Shared Goal

Before diving into solutions, make sure you’re both solving the same problem.

Say something like: “To clarify, we both want to ship this feature on time without breaking the existing system, right?”

This reminds both of you that you’re on the same team. You’re two people trying to solve the same problem from different angles.

Once you’ve acknowledged the other person’s perspective and clarified the shared goal, you can move to the next step.

Subscribe now

Step 2: Root Cause Analysis

Now you dig into the actual disagreement. The acronym is the same as the post-mortem framework, but it’s much simpler here. The objective is to find the root cause before moving on.

Symptoms vs. The Underlying Problems

Most conflicts have symptoms and root causes. Symptoms are disagreements you can see on the surface. Underneath are the root causes, usually unclear requirements, different priorities, or missing information, etc. These often require some digging to uncover.

One effective way to distinguish between symptoms and causes is to repeatedly ask “why.”

In my story, two members waited for each other.

Member A seemed unproductive and appeared to be blocking the other. He looked like the culprit. But it’s actually only a symptom. We kept asking member A why he could not prioritize unblocking the team. He explained that he was juggling multiple projects.

Gradually, we uncovered the real issue: Member B believed the development order couldn’t change. He kept pushing Member A to unblock him first because he was worried that changing the order would affect Scrum metrics.

And that, my friend, was the root cause.

It was a misalignment issue by their manager (me 😅). I should have made it clear that flexibility was more important than Scrum metrics. Any scope changes could be discussed during retrospectives afterwards.

There are also other techniques to analyze the options:

List Tradeoffs

Tradeoffs of each option should be visible to start a more objective discussion:

• Pros and cons

• Short-term vs. long-term impact

• Risk vs. speed

This moves the conversation from “my way vs your way” to shared decision-making.

Validate Understanding Before Moving On

Before moving forward, make sure everyone understands each other (including yourself).

Say: “Let me repeat what I heard. You’re concerned about X because of Y. Is that right?”

If you skip this, you risk solving the wrong problem. Once both sides feel heard, decision-making becomes possible.

Step 3: Commit to Next Actions

OK. You’ve had a good discussion. The root cause is clear. The next step is turning it into actions.

In my story, a simple change in development order unblocked the project. But in other cases, you might need more deliberate strategies.

Small and Reversible Actions

When choosing a path forward, start with small experiments when possible.

For example: “Let’s build a proof of concept for both approaches this week and compare.”

Set up measurements and compare outcomes. Data makes decisions easier.

Make Explicit Decisions

Remove ambiguity by clearly stating:

• What was decided

• Who owns what

• When it will be revisited

Explicit decisions prevent silent disagreement. Make sure everyone is on the same page.

Future Preventions

Congratulations. You just resolved another conflict 🎉

However, just like resolving an incident, it’s a good habit to revisit and implement preventions.

In my experience, around 80% of conflicts come from clarity and alignment issues. Many can be avoided with clearer processes.

The goal is to reduce situations where people are forced to guess.

Some examples:

• Task ownership

• Timeline and development order alignment

• Technical design reviews

You can invite people involved in the conflict to a retrospective and objectively discuss how to prevent similar issues in the future.

Prevention is always better than the cure.

You might want to go beyond handling conflict and cultivate your senior-level mindset. For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Find out what “senior” means in your company
✅ Identify opportunities in your team
✅ Build a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

As always, I’ll see you in the next post. Have a nice day!

Adler from Tokyo Tech Lead

Most Engineers Only “Hope” Instead of “Plan”

I’ve seen this pattern: Most engineers get stuck in their careers because they wait.

They wait for their manager to notice their hard work.
They wait for someone to say, “You’re a senior engineer now.”

Some managers might see it. But for many of us, that moment never comes.

In my experience, mid-level engineers have no problem with execution such as finishing tasks and delivering projects.

But here’s the problem: Most engineers rely on “hope” to get to senior roles. They rely on their manager to notice their effort, create a plan, and tell them what to do to get promoted.

Hope is Not a Strategy

Managers are busy. They have their own issues to handle. Yes, some managers pay attention to your career growth, but most don’t if you don’t speak up.

Most of the time, getting to a senior role is an outcome of strategy. Working hard alone does not get you to senior roles. You get to senior roles by working on clearly aligned goals and matching the expectations of the next level.

What Strategy Actually Means in Your Career

Career strategy is simpler than you think.

It is clarity about what matters, and actions that move you toward it.

Strategy stops you from optimizing the wrong things. And it makes your growth visible to the people who evaluate you.

Like any software project, your career strategy has three parts:

1. Knowing where you are & your goals

2. Knowing what your team needs

3. Creating impacts to close the gap

Let’s break these down.

1. Know Where You Are And Your Goals

You need clarity on questions like:

• What am I already doing well?

• What skills or behaviors are missing for the senior role?

• What examples in the team represent “senior-level impact”?

When you talk to your manager about these questions, you gain clarity.
Your target becomes clear, and you’re improving toward that specific target.

This is the opposite of hoping someone magically recognizes your potential.

2. Know What Your Team Needs

Engineers often invest time into the things they think are valuable, but those tasks might not be valuable to the team.

Just as entrepreneurs do market research before building a MVP, engineers do “team research” before starting work.

They ask questions like:

• What pain points frustrate the team most?

• What business outcomes matter this year?

• What roadmap items will resolve team bottlenecks?

You talk to PMs, EMs, senior devs, and teammates. Once you see the priorities, you start doing work that creates business values.

This is the difference between being “helpful” and being “essential.”

3. Create Impact to Close the Gap

Strategy is choosing work that gives you leverage.

It creates impact that converts to numbers or perceivable benefits, such as latency going down, incident rate going down, saving future time, etc.

Two types of work to consider:

Early wins: Pick 1-2 things you can complete quickly that make everyone’s life easier, such as fixing a flaky test or improving the deployment process. These build momentum and prove you’re thinking beyond your own tasks. They are also immediately visible.

A stretch project: This is your showcase. Choose something challenging but achievable in 2 to 3 months. Ideally, it involves multiple people, teams, or stakeholders. Seniority is measured by scope of impact. Refactoring code in isolation won’t get you noticed. Leading a technical initiative that improves how three teams work together is senior-level work.

The key is to be selective. You can’t do everything. You need to choose work that creates impacts. While it helps the entire team, it demonstrates senior thinking.

Note that work should create impact for not just yourself but to the entire team. That’s the essence of being a senior developer: acting like a technical leader.

That’s what stands out during performance reviews.

The Visibility Trap

Even if you have strategy, you should optimize for impact, not visibility.

You might remember those colleagues who care only about visibility. They only work on requests from managers. They are not the most likable among other teammates. They never disagree with leadership, even when they’re wrong. They only contribute to projects where managers are paying attention.

That’s not strategy. That’s performance.

Don’t become that person.

Being strategic means more than visibility. It means choosing work that creates real impact and making sure that impact is understood.

My Recommendation: A 90-day Roadmap

If you want to take this further, you need a clear, structured way to start applying strategies to your career path.

I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

In other words, it turns everything in this guide into a step-by-step plan you can use immediately.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox.

Subscribe now

(For those who have already subscribed, you’ll receive it in your inbox. 🙂)

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

As always, I’ll see you in the next post. Have a nice day!

Adler from Tokyo Tech Lead

My Disaster Story

There was a time when I was assigned a big project with my team.

It was a brand new product that required major changes in the existing system, involving 10–15 other teams.

I had no idea how to move it forward. 🤔

I thought: “Well, I’ll just get started.” So I started talking to different teams and asking for their help.

But I had no strategy in mind. I didn’t set milestones, and I didn’t know what the MVP should look like. I was just blindly walking into meeting rooms, talking to other teams about what we needed.

At the end of the day, I had scattered information from each team and still didn’t know what to do next.

After two months, the project had almost zero progress. Eventually, my manager removed me from that position.

The Illusion of Progress When There’s No Strategy

Here’s the truth: I felt busy all the time.

My calendar was packed with meetings. I was talking to stakeholders and engineers.

But being busy doesn’t mean being productive. That’s why we all need a strategy 📚.

Before starting a project, we need to clarify the goals, the options, and the unknown. Jumping right into action without a strategy almost guarantees failure, even if you know where you’re going.

I had already started seeing symptoms, but I ignored them. For example, I couldn’t resolve conflicting requirements, and meetings often ended with no action items.

So after that big failure, I looked back a lot and gradually picked up the strategies that I should have learned in the first place. Here’s what I’ve learned:

Subscribe now

📚 Strategies to Handle Big Projects

#1: Define MVP and Break It Into Phases

The business always wants delivery at the earliest possible date. However, a long list of requirements plus a tight deadline usually lead to disaster.

The right way to do it is to prioritize MVP (minimum viable product). Core features come first, everything else is nice-to-have. This way, you ship faster, and requirements become more manageable in smaller chunks.

Always ask: “What’s the smallest version we can ship that proves this works?” Then break down the rest into phase 2, 3, and beyond. Things might also change after initial user feedback.

#2: Start With the Riskiest Part

It’s counterintuitive, but it’s helpful.

Most engineers (including past me) start with easy wins. It feels good to check things off the list. But that only delays the risks.

Identify the biggest unknown first. Handle it as priority if it could completely derail the timeline. For example, if you’re unsure whether the system can handle the expected traffic, build a performance test first. Don’t spend months building features only to discover the foundation doesn’t scale.

Starting with risk feels slower upfront. But it prevents failures later.

❓ Strategies to Handle Unknown

#3: Start with a POC

Sometimes you don’t even know if an approach will work. That’s when you build a POC (proof of concept).

It’s a quick experiment to answer a specific question. For example: Can the payment provider support all our use cases? Can we build a POC to test all the critical payment flows like quick refunds or blocking certain users?

Use POC as verifications. Test it. Evaluate it. Then make an informed decision. That’s better than working through the entire project without verifying the critical path.

#4: Always Have Multiple Options

Even when you have a recommended solution, keep multiple options in mind.

For example, when integrating with a payment service, should you choose PayPal or Stripe? What are the pros and cons? List all the information, start with the top priority, and fall back to other options if it doesn’t work.

Don’t put all the eggs in the same basket.

#5: Look for Similar Past Work

When you’re stuck, start from digging into the history.

Look for documentation like Google Docs, Confluence, Jira tickets, etc. for similar cases or projects. This works because engineering organizations repeat similar challenges: migrations, breaking down monolith, scaling up, etc.

You can also reach out to people who have done the same in the past. Set a quick meeting, or even a regular meeting if it’s a big project. Ask for shortcuts, hidden risks, etc. Unknowns get clarified fast when you talk to the right persons.

👨‍💼 Strategies for Stakeholder Management

#6: Regular Meetings for Alignment

Schedule recurring check-ins from day one. Weekly or bi-weekly, depending on the project timeline. Put them on the calendar before you start any work.

The objective is to keep everyone aligned on what’s happening. If there is any misunderstanding, you can correct it early.

A regular report should include what has been done, blockers, upcoming tasks, and if any help is needed, like a scrum daily meeting.

This is useful for managing stakeholder expectations. They won’t feel like engineers are building things in the dark.

#7: Communicate Blockers Early (and Escalate)

We all have that experience of last-minute issues. People bring up a blocker two days before the delivery deadline.

Having a regular meeting tends to solve this problem. It encourages members to report their issues early, and allows stakeholders to react in time. It also allows the team to escalate when they find any challenges.

💡 A simple rule: Report anything that’s blocking you for more than 24 hours.

Subscribe now

🏃 Strategies to Speed Up Development

#8: API Contracts Go First

This is the gold standard of software development.

Cross-team collaborations involving server communications need teams to define API request/response formats, fields, error handling, etc. before starting the development.

In that case, teams can work on their side in parallel before doing integration testing.

#9: Parallel Assignment

As pointed out by The Mythical Man-Month, we cannot speed up development just by throwing more people to it. However, most software projects can break down into two or more parallel tracks.

For example:

• Backend builds the business logic while frontend mocks responses

• Infra team prepares environment changes while developers implement features

• QA builds test cases while development is still ongoing

In a single domain like backend, you can further break it down for multiple developers to work on it at the same time. All you need to do is manage the multi-track management overhead (as pointed out in The Mythical Man-Month, having too many tracks will slow it down instead).

💡 The rule of thumb: If two tasks don’t depend on each other, they shouldn’t wait on each other.

⚠️ Strategies for Risk Management

#10: Technical Design Doc

Many projects get delayed because risks show up too late.

A good strategy to identify risks early is to have a technical design document, which includes fundamental details like:

• Service workflow diagram

• Edge cases

• Testing plan

• Etc.

You can search for “technical design doc template” to pick items required for your projects.

#11: A Review Process to Identify Risks

The technical design doc should be reviewed by those who might identify risks, such as senior engineers, stakeholders, QA team, security team, etc.

For example, you don’t want security red flags showing up after development is complete.

Last Words

Strategy isn’t a leadership buzzword. It’s how senior engineers survive large-scale projects.

Strategies in this post aren’t complicated. They serve as a framework.

Start with one habit at a time:

• Communicate earlier than you think you need to.

• Structure work so developers can move in parallel.

• Create a tech design doc before the work begins.

Do these consistently, and you’ll be able to deliver faster and have less surprises.

Then you’ll become the person others rely on when the stakes get high.

You might want to go beyond project strategies and cultivate your senior-level mindset.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

What I’ve Read this Week

• You’re doing everything right… so why aren’t you moving up? by

• Top 5 Communication Frameworks for Engineers You Must Remember by

• All we need is more creativity by

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

As always, I’ll see you in the next post. Have a nice day!

Adler from Tokyo Tech Lead

So we talked about vision, and now let’s put it in practice. One major item that connects to vision is the team technical roadmap.

“But that’s not my job,” you might ask.

You are absolutely right. It isn’t your job if you are not a Tech Lead or an Engineering Manager.

However, you don’t have to be one to start it. Don’t wait. Start now, as a developer.

If your team already has a technical roadmap, use the system in this post and analyze whether the roadmap includes all the important details.

Technical Roadmap is Your Team’s Lighthouse

A technical roadmap typically is a list that includes:

• Goals

• Priority

• Category

• Impact / Risks if we don’t do it

Here’s what it usually looks like as a table:

It can also include other parts like:

• Team’s goal for the next year

• How is the roadmap connects to the division or company’s roadmap

• Timeline & Gantt chart

• Etc.

However, we’ll focus on building a list for now.

Subscribe now

The 3-step system: GPU

So how do we actually build a technical roadmap?

That’s where the GPU system comes in. GPU stands for:

1. Gather inputs

2. Prioritize

3. Use it

It’s intentionally simple because the goal is to create enough clarity for everyone to move in the same direction.

Let’s break it down.

#Step 1: Gather Inputs

At the start, you want to talk to people:

Take Business Inputs

Talk to your Product Managers or business partners. Ask them:

• What are we building in the next 3-6 months?

• Are there any major changes coming?

• Any pain points for them to using the software?

Take Engineering Team Inputs

Your members know what’s broken. They deal with it every day.

Ask them:

• What slows you down the most?

• What part of the system do you want to improve?

You can do this in 1-on-1s, team retrospectives, or a quick survey. Ask everyone, both senior and junior engineers.

Take Data Inputs

And then you look at the data:

1. Common incident causes

2. Recurring issues and bugs

3. What has been sitting there in the task backlog (E.g, Jira)

At the end of this step, you should have a messy list of 10-30 items.

You don’t judge anything yet. You just collect.

#Step 2: Prioritize

This is where your vision skill starts to come in.

Time to turn that chaos into a roadmap.

Add Categories to Items

There should be one category for each item.

If an item cannot be associated with anything, start thinking whether it needs to stay on the roadmap. It’s either a business feature, or it is not worth doing.

Here are the categories that I usually use:

• Security: framework & package upgrade, PII handling, legal compliance, etc.

• Maintainability: code refactoring, breaking down a monolith app, etc.

• Performance/Scalability: API latency, page loading speed, etc.

• Stability/Availability: Service downtime, disaster recovery, etc.

• Cost reduction: infra, DB usage, logging storage etc.

Add Other Details

Each item should include the following:

• Impact: What benefits does it bring to the team, or what if we don’t do it.

• Goal: What does the finished state look like.

• Priority: Translate the impact and urgency level to priority.

• Effort required: Using T-shirt size like L, M, S to represent how complex the solution is.

Note: If you are experienced with this process, you can complete it along with step 1 where you talk to the PM or the team.

#Step 3: Use It

Once you have a roadmap, it becomes your decision-making tool.

Use it in your day-to-day discussions like the following.

Push Back on Requests

Once you have a roadmap, not everything looks “important” and “urgent” anymore.

Next time someone asks your team to do something, you know whether the request is important compared with items already on the roadmap. (even if it’s always “urgent”).

Align Directions

You might find people optimize or refactor small things that they think are important, but they are not.

Run a meeting to go through the roadmap with the team. Use it to decide what they should work on first. Those small things can wait until we finish all the main projects.

Fill Windows

When you have a free week, you don’t wonder what to work on. You check the roadmap and pick the next important item.

Without a roadmap, teams usually don’t know what to do during planning sessions when they discover they need to wait for the next business project.

Subscribe now

Common Roadmap Mistakes

Making It Too Detailed

A roadmap is not a backlog. It’s a direction. If you have a big team, don’t squeeze all items onto the roadmap.

Only leave the important items. Most small items can stay on your task backlog like on Jira or Asana.

Only One or Two People Contribute

A technical roadmap is built by the entire team. Either one PM defines everything or the EM writes it alone. Neither works.

The step 1 of the GPU framework should not be skipped.

No Regular Review

Business priorities change. Tasks get done. It’s impossible to use the same roadmap forever.

I recommend reviewing it every three months. Adjust priorities, remove finished items, and ask people again about their pain points.

Start Building One Today!

You can build a simple roadmap today and use it in your meetings.

Even if your team already has one, use the GPU system to evaluate whether it misses important information.

If you want a shortcut, I’ve created a ready-to-use Technical Roadmap Template that follows the same structure from this post.

You can grab it here!

Bring It to the Next Level

You might want to go beyond building team vision and cultivate your senior-level mindset.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

What I’ve Read This Week

• Your Code Doesn’t Need to Be Perfect. It Needs to Ship by

• Freedom by Design: How He Lived in 5 Countries and Built the Free Visa Tool He Wished Existed by and

• The Future of API Design: Migration Strategies by

• Big Tech leaders are turning leadership into a fad by

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

As always, I’ll see you in the next post. Have a nice day!

Adler from Tokyo Tech Lead

Meet Ken

Ken joined the company as a software engineer. He’s responsible, collaborative, and easy to work with.

But during our evaluation discussion, he added one surprising comment:

“I think I deserve a better title.”

It turned out his previous title was Staff Software Engineer at a well-known big company.

However, his current title is just Software Engineer.

I explained to him that our organization doesn’t use those shiny titles. From junior to senior, everyone is “Software Engineer.” 🤷‍♂️

Title Actually Matters

This story isn’t to tell you that title doesn’t matter or to give you one of those corporate pep talks.

On the contrary, title does matter.

A good title brings real benefits to your career, such as:

1. Better first impression: They shape how others see you before you even start talking. It makes your experience easier to trust.

2. Better authority: In a company, your opinions usually carry more weight.

3. More leverage in the job market: It’s easier to get attention from recruiters, and you can use it during salary negotiations.

So yes, titles can open doors before you even say a word.

Fight for It, But Be Careful

You can fight for your title (and you should).

Ask for one that better reflects your contribution.

But don’t push too hard.

Sure, shiny titles can be motivating, and they give us a sense of achievement.

Still, if you care more about the title than the work itself, you might be missing the point. Beyond the title, there are other things that matter more:

• Whether you like the job

• Whether you have a supportive manager

• Whether you’re compensated well

Titles matter, but not as much as these do.

For example, I believe most people would choose to get paid twice as much for doing the same job, even with a worse title. 💰

Also, obsession with titles could lead to extreme measures:

• You start optimizing for visibility, not outcomes.

• You start doing work that looks impressive but changes nothing.

• You might stop learning once you reach the next big title.

You don’t want to fall into that trap.

Subscribe now

The Invisible Title

There’s another kind of title. If your title strategy doesn’t work, go for this one instead.

You earn it through how you work. (It sounds like a pep talk but it’s true)

• You can lead a cross-team initiative that unblocks others, just like a Staff Engineer would. You can improve a workflow that saves everyone time.

• You can share knowledge publicly through talks, posts, or mentoring, and become known for your insight.

These acts build your invisible title: the reputation that precedes you.

When that grows, better roles and better compensation follow naturally, either inside or outside your company.

Last Words

Yes, titles matter, and unfortunately, they’re not always in your control.

In my current organization, everyone is “Software Engineer.” It can be frustrating when you’re clearly operating at a senior level but share the same title as mid-level engineers.

There’s not much you can do. (Well, you could switch jobs, but do you really want to do that just for a title?)

Push for the recognition you deserve. But when that stops working, start optimizing for impact instead. At the end of the day, your career isn’t measured by your title. It’s measured by your actions.

You might want to go beyond this and cultivate your senior-level mindset.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

As always, I’ll see you in the next post. Have a nice day!

Adler from Tokyo Tech Lead

Vision Has the Highest Value of All Skills

Will the stock market go up or down tomorrow?

If you know the answer, you become one of the most valuable people in the world.

And that’s vision.

In engineering, the same applies.

The most valuable engineers aren’t just good at solving today’s problems. They can see tomorrow’s problems before they happen. That foresight is what companies pay senior engineers for.

The Cost of Building Blind

When engineers work without vision, decisions are made in the dark.
You fix what’s in front of you, only to realize later that it didn’t matter.

You’ve probably seen this before:

• Teams spending months on a feature that no one uses.

• Premature optimization that brings no benefit.

Both mistakes come from the same root cause: not understanding where the team is heading. They don’t know the business context or the technical roadmap.

Vision Brings Clarity

Engineers with vision make better decisions. Which shortcuts to take, which technical debts to prioritize, and which features to push back. When engineers know what the future looks like, they know what to do.

👉 Without vision, every decision feels equal. Every task seems important. You can’t prioritize.

Subscribe now

The Levels of Vision: Where Do You Stand?

Vision isn’t binary. You don’t either have it or you don’t.

It’s more like a spectrum. Different levels of engineers see different distances into the future. Understanding where you are helps you figure out where to grow next.

Junior Engineers: Task-Level Vision

Junior engineers see one task at a time. They get a ticket. They understand what needs to be done. They can picture what the code will look like when they’re finished.

Ask them what success looks like, and they’ll likely describe finishing the ticket:

“Once I fix this bug, I’m done.”

And that’s fine. When they’re starting out, their job is to learn execution. Finish the task. Make it work. Get comfortable with the basics.

Mid-Level Engineers: Project-Level Vision

Mid-level engineers zoom out to the project level.

They understand the full scope of what they’re building. They know all the pieces that need to fit together. They can anticipate technical challenges within the project boundaries.

But here’s where most people get stuck: they don’t know why these projects exist.

They can tell you the project will take three months. They can explain the technical architecture. They can break down all the tasks.

But ask them how it fits into the bigger picture? Or what the service will look like in six months?

They don’t know. They’re executing projects without understanding the strategy behind them.

Senior Engineers: Team-Level Vision

Senior engineers see six to twelve months to a year ahead.

They understand the business context. They know what the company is trying to achieve and how engineering enables that.

For example, if the business is planning to expand to a different country, senior engineers would already have the idea: “We’ll need to handle increased traffic. We’ll need multi-language support. We’ll need different payment integrations.”

They review the current system, estimate time and effort, and start discussions with product managers.

👉 In short, they connect the dots between business goals and technical requirements.

This is the vision that earns promotions. Not because they’re smarter, but because they’re thinking strategically about where the team needs to go.

Staff+ engineers see even wider and further, but we’ll discuss that another time. :)

Why It’s Hard to See Ahead

If vision is so important, why don’t more engineers have it?

It’s not because they’re not smart enough. Most mid-level engineers are perfectly capable of thinking strategically. The problem is, the environment makes it really hard to develop that skill.

Your Manager Doesn’t Share Context

A common story: Your manager knows the business strategy. They sit in planning meetings. They hear about upcoming changes. They understand the why behind every project.

And then they hand you a ticket with technical requirements and a deadline. No further explanations.

Sometimes it’s because they’re too busy. Sometimes they assume you don’t care. Sometimes they think “just focus on your work” is protecting you from distractions.

So engineers end up optimizing for projects, not achieving the business goals. They don’t see the full picture because no one took the time to share it.

No Documented Roadmap Exists

Some companies just don’t have clear roadmaps. Or they have them, but they’re buried in documents nobody reads.

This is especially common in startups and smaller companies. Everything moves fast. Priorities shift constantly. The roadmap from last month is already outdated.

“Just Ship It” Culture

Then there’s the culture problem.

Some companies reward speed above everything else: ship fast, hit deadlines, move to the next thing.

In that environment, asking strategic questions feels like slowing the team down. So engineers learn to keep their heads down and execute. And that habit kills vision before it can develop.

Subscribe now

💡 Upgrade Your Vision Starting Today

Okay, so you understand why vision matters and why it’s hard to develop.

Now the question is: how do you actually build it?

Here’s what worked for me:

Step 1. Build Relationships to Get Context

The more context you have, the easier it is to see the whole picture.

Here’s what you need to keep an eye on:

What does the business want? Talk to product managers. Understand their goals. Ask about upcoming features. Learn what KPI they’re looking at.

What does the team want? Talk to your manager or other senior devs. Understand what problems the team is trying to solve.

What does each person want? Talk to your teammates. Understand what they’re worried about.

The more conversations you have, the more context you gather. And context is what builds vision.

I know this feels like “networking”, but it’s not. You have a purpose in all these conversations. You collect information, and you go back to work.

Start small. Have a casual chat with your team’s product manager, manager, or your team members. Each conversation adds another piece to your mental roadmap.

Step 2. Extract Insights from Retrospectives

Another place to gather context is from your regular retrospective meetings. Your team probably has it every few weeks. Revisit old notes occasionally.

Pay attention to recurring themes:

• Which types of projects always get delayed?

• What technical decisions do we regret?

• What business changes surprised us?

These patterns reveal systematic issues. If you’re constantly surprised by business changes, it means you’re not getting enough context upfront. If you’re always refactoring recent work, your design or review process might need adjustment.

Identify what went wrong. That helps you build better team context.

Step 3. Build Your Own Roadmap

After you collect enough context, use them to build your own roadmap (or use it as the team’s roadmap).

On this roadmap,

• List team’s pain points

• List what business projects we are facing

• List what new tech we want to try

After you create this list, you’ll have a better idea what we are aiming to resolve in a few months. Label them with impact and priority.

It helps you understand what the team and the system will look like in 6-12 months.

Last Words

Vision is a skill you build it through practice.

But the truth is that most engineers never develop vision properly. They stay focused on their tasks and projects, wondering why their career isn’t progressing. They blame their manager for the lack of opportunities.

But you can be different.

Start small. Make small changes.

In six months, look back at your decisions. Notice how you think differently.

That’s vision developing. That’s you moving toward senior thinking. 🚀

You might want to go beyond your vision skill and cultivate a well-rounded senior engineer mindset.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

Weekly Shoutout

1. The 6 Systems That Take You from Manager to Strategic Leader by

Career progression is a system, not luck. Senior leaders don’t just grow through hard work. They design systems that keep it repeatable and sustainable.

2. Your Code Reviews Are Outdated — How AI Tools Like CodeRabbit Are Redefining Quality by

The old “find bugs” mindset of code reviews is outdated. With AI review tools like CodeRabbit, code review now enables more meaningful discussions on design and knowledge sharing.

Thanks for reading!

Also check the learning path if you want more systematic learning on moving toward a senior software engineer.

As always, I’ll see you next time!

From my earlier post, you already know the mindset shifts you need to make to transition to a senior developer role.

But How?

Most engineers read about senior thinking and nod along. Then they go back to work and… nothing changes. They still take tickets without asking questions. Things remain the same.

In this post, I’ll share the specific actions I personally used in the past to practice senior thinking. These aren’t big dramatic changes. They’re small, repeatable habits that compound over time.

Let’s get into it.​​​​​​​​​​​​​​​​

❓ Action 1: Always Ask Why

Take a quick pause before taking a task or project. Ask yourself if the following is clear:

• What problem are we solving?

• Who is affected by this?

• How does this tie to our current goals?

If anything is unclear. Ask. Don’t let it slip.

Sometimes, those questions reveal the real problem is something else entirely. Maybe users don’t need another filter. Maybe they need better default settings. Maybe the problem is unclear goals, not missing features.

Any project or any task should be tied to driving revenue, managing risk, or cutting costs

The follow-up Question

If the answer doesn’t tie to any of these, push back gently and ask: “Help me understand how this is helping the business.”

Weak outcomes should be ignored. For example, “this makes the title cleaner for internal employees” isn’t a business outcome. It’s a preference. Sure, if we have time, we can do it. But unless it impacts how internal employees do their jobs, it doesn’t justify development time.

But a small caveat is that don’t ask why for every single task. That would slow the team down.

Subscribe now

💡 Action 2: Know the Team Priorities and Roadmap

Ask yourself: Are you clear with the current team priorities?

Some examples include priority business projects, major technical debts, and ongoing organization changes.

It’s also important to understand your organization’s priority. For example,

• They work on 80% of business projects and 20% of technical debts every quarter.

• They aim for 100% delivery rate of all assigned projects

• They aim for 80% of KPI achievement rate

How is understanding this helping you?

Well, this helps you understand the team’s position.

For example, if you know the team must hit a 100% project completion rate this month and you’re only at 60%, you can raise it early. You don’t wait until the last week for your manager to change priorities. No one likes that kind of surprise.

If you’re unsure, talk to your manager in your next 1-on-1.

🗣️ Action 3: Speak Your Mind

Most engineers stay quiet when they don’t know what to do, because our culture encourages us to avoid mistakes. But that’s when you can be different.

The formula

Instead of saying “I don’t know” or just keep quiet, say: “We don’t have a clear answer, but here’s what I would consider...” And then you lay out what you know and what you don’t know.

During that discussion, you find out the next actions. Either you move forward, or you decide how to find out the unknown.

An Example

When someone asks for my opinion on an ambiguous topic, I could say:

“Here’s how I’m thinking about this. We have two constraints: timeline and team capacity. Given our deadline, I’d lean toward the simpler solution, even if it’s not perfect. We can always revisit later.”

Notice what I’m doing:

• I’m naming the factors I’m considering

• I’m stating my recommendation

• I’m staying open to other perspectives

This approach works even when I’m not 100% confident. In fact, it works better when you’re uncertain, because it invites collaboration instead of pretending you have all the answers.

🧑‍🤝‍🧑 Action 4: Think Team Improvement, not Individual Improvement

When something goes wrong, mid-level engineers fix the symptom.

Senior engineers fix the pattern.

Whenever you encounter an incident, a communication blocker, or any issue, you can ask yourself: “How do we prevent similar issues in the future?”

Not just this specific issue. Similar issues.

For example:

• If a deployment breaks production, don’t just roll back. Ask if you need better staging tests or gradual rollouts.

• If someone struggles to get info from another team, don’t just help them. Ask if the documentation or communication channel needs fixing.

• If a bug slips through code review, don’t just patch it. Ask if the review checklist or test coverage needs an update.

This habit takes more time upfront. Instead of fixing one issue, you’re thinking about preventing ten future issues. But that’s exactly what makes you a multiplier.

💡 Bonus tip: You don’t do this for every small issue. You act on those which happens more than once or affects multiple team members.

Subscribe now

✍️ Action 5: Raise One Observation in Every Retrospective

Most engineers attend retrospectives quietly. They think they have nothing important to say. But retrospectives only work if people participate.

Senior engineers share what they notice, even small things:

• What went well that we should keep doing?

• What went wrong that we should revisit?

• Any ideas worth trying?

If you rarely speak up, start now.

Make sure you raise at least one point in each meeting.

If you’re not used to speaking up, start small. Prepare it before the meeting so you’re not scrambling.

You don’t need solutions. Just observations. That’s how team learning starts.

And if your team doesn’t have retrospectives yet, create one. Every team needs that space to improve together.

Regular Personal Reflection to Track Your Improvements

Honestly, you cannot change all these overnight. And fortunately, you don’t have to.

Use your 1-on-1s with your manager to reflect on progress. Before each one, spend 10 minutes reviewing the past week or month.

Keep a running document with two sections:

Show-off list:

• Projects you completed

• Problems you solved (for yourself and others)

And personal reflection:

• What went well

• What you struggled with

You don’t have to share it all, but reference it during your conversation. After three months, you’ll see visible improvement. You can also ask for feedback from your manager based on your goals.

Again, the goal isn’t perfection. The goal is direction: one step at a time.

You might want to go beyond this and cultivate a well-rounded senior engineer mindset.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

Last Words

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

Also, I’ve uploaded my first template for help you get started with your team leadership journey.

Visit my store to get the template, and start assessing your team health!

See you in the next post!

Adler from Tokyo Tech Lead

Most software engineers are “good enough”.

And they always wonder how to be “great”.

The gap between “good” and “great” is no longer about technical skills. It’s about how you think. Certain mindsets keep you stuck in the mid-level spot and prevents you from moving to a more senior role.

In this post, we’ll cover three mindset shifts you can make to speed up your career growth.

Mindset Shift #1: From Output to Outcome

Focusing on “Output”

Most engineers start their careers focused on execution, the “output”.

You get a ticket.

You estimate, build, test, and deliver.

You move to the next one.

You’re fast and reliable 🏃

That’s a great start. But it’s also where most people stop growing.

During tech discussions, I’ve seen many engineers ignore the business context and project objectives. They only care about what they should do and when the deadline is.

The truth is: You can finish all that and still not change anything meaningful.

Because being great isn’t about finishing tasks. It’s about creating outcomes that matter.

Focusing on “Outcome”

When you start thinking about the outcome, your perspective changes.

You stop asking, “What do I do next?”

You start asking, “What problem are we trying to solve?”

We all know that situation: Business asking for a new metric on the system dashboard. Mid-level engineers start thinking about implementation and how to deliver as soon as possible.

Senior engineers, on the other hand, first ask questions:

• What problems are we trying to solve?

• How does that new metric make a difference?

Sometimes, those questions reveal that the new metric isn’t necessary at all. Or that the real problem is unclear goals, not missing data.

Mid-level engineers, without asking questions, start implementation right away. It’s very likely that the business side finds that it’s not what they want, and they need to revert the changes (we’ve all seen that before 😅)

Before jumping into the solution, senior engineers first clarify the problem, so their actions can create impacts. It’s not just doing what’s asked, but making sure it matters.

It’s how senior engineers turn execution into impact.

Subscribe now

Mindset Shift #2: From Certainty to Ambiguity

Early in my career, I needed answers before I could move forward.

• Should we fix this bug before moving on?

• Should we refactor this code or leave it?

I wanted someone to tell me the “right” answer.

But that’s not how senior engineers think.

Mid-level Engineers Need Certainty

Mid-level engineers want clear requirements, proven patterns, and best practices to follow. And that’s not wrong. It’s how we deliver stable, bug-free, and secure products.

But sticking to certainty keeps you in the “mid-level” zone.

You wait for all the information before making a call. When someone asks your opinion, you reply with “It depends”, but can’t explain what it depends on.

For example, your EM might ask you: “should we use Redis?”

You reply “Yes, we can. It depends. It can improve the performance, but it adds a new layer of complexity.”

And the EM asks you further: “So, what is your recommendation?”

You start to hesitate and you can only reply: “Let me think about it.”

This is the point where mid-level engineers hit their ceiling. They are too used to handle certainty, and it’s hard for them to handle ambiguity.

Senior Engineers Embrace Ambiguity

Senior engineers make judgments based on what they know, and decide next actions based on what they don’t know yet.

It means: You make decisions with incomplete information, because waiting for perfect clarity means never shipping. When someone asks your opinion, you say “Here’s what I’d consider” and walk through your reasoning.

In the same Redis example, senior engineers would have different factors in mind:

• Project timeline: Do we have time for adding this new component?

• Capacity: Do we have enough people to maintain this component?

• Simplicity: Can we resolve the performance issue by optimizing the current codebase?

• Trial and error: Anything we can try before moving on to a more complicated solution?

And your answer would cover all these aspects: “I’d recommend not adding Redis right now because XYZ”. By going through your reasoning, you also invite others to the discussion. You have your own opinions, but you’re open for input.

With this process, ambiguity is gradually broken down into manageable pieces and tasks.

Mindset Shift #3: From Individual Contributor to Team Multiplier

I used to measure my productivity by how much work I can do in one sprint. I was happy to help my colleagues when they have a question. I was happy to join team discussions to resolve pain points.

But most of the time, I focused on my own work. And that’s how it stopped me from growing.

Becoming a team multiplier starts with a mindset change:

You stop asking, “How can I finish more work?”

and start asking, “How can I help the team move faster?”

Owning Projects versus Owning the Team

Mid-level engineers are expected to handle projects by themselves. They focus on collaborating with other teams, connecting with stakeholders, and handling incidents. It is to make sure everyone is happy, and projects are delivered in time.

Good. But that’s in the scope of that single project. You think about how to deliver faster, how to unblock it, and how to make it to the deadline.

Now, imagine if you are someone who oversees multiple projects at the same time.

Your perspective changes dramatically. And that’s what senior engineers do.

Now you start to think about:

• What can we change to speed up all these projects?

• What workflow can we cut to save everyone’s time?

• Do we have sufficient test coverage to catch issues among different projects?

You think about the team, instead of just yourself.

That’s when you become a team multiplier.

Being a Team Multiplier

Senior engineers do things that are seemingly unproductive, but they provide long-term benefits.

For example, you could spend 1 hour building a feature yourself, or you could spend 3 hours helping a teammate learn to build it. The feature ships slower this time, but next time they don’t need your help. That’s multiplication.

This shows up in code reviews too. Mid-level engineers approve quickly to get back to their work. Senior engineers see reviews as a chance to share knowledge, catch systemic issues, and set standards. They’re not just reviewing code, they’re shaping how the team works.

Your personal productivity might go down when you start thinking like a multiplier. You’ll write less code. But the team’s output will go up, and that’s what senior, or even staff and principal engineers do.

Start the Shift Today

Here’s the thing about these mindset shifts: you don’t need a promotion to start practicing them.

You can start asking about outcomes in your next standup. You can make a judgment call the next time your manager asks for your opinion. You can spend an extra 10 minutes on a code review to help someone learn.

However, these shifts don’t happen overnight. I didn’t wake up one day thinking differently. It took months of catching myself falling back into old patterns.

The uncomfortable part? You might feel slower at first. You’ll spend more time thinking about problems before coding. You’ll have more discussions. You’ll get less work done.

That’s normal. You’re not becoming less productive, you’re becoming more thoughtful.

Start with one shift. Pick the one that resonates most with where you are right now. Practice it for a few weeks. Notice when you slip back into the old mindset. Reflect on what’s holding you back.

The gap between mid-level and senior isn’t about learning a new framework or mastering system design. It’s about changing how you think about your work, your impact, and your role on the team.

And you can start that change today.

For those who want a clear, structured way to continue to grow, I recommend using the roadmap I’ve created: Stop Waiting for Recognition: The 90-Day Senior Dev Roadmap.

It walks you through:

✅ Finding out what “senior” means in your company
✅ Identifying opportunities in your team
✅ Building a repeatable system

It’s a step-by-step plan you can use immediately, starting from today.

All you have to do is to subscribe to Tokyo Tech Lead. It will deliver to your inbox 🙂

Subscribe now

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

🎉 And I just renewed my coaching landing page!

Here’s the new design. I help engineers and managers level up their leadership skills. Feel free to reach out from here!

I’ll see you in the next post!