Beyond Code: The Senior Developer's Evolution - Leadership, Scale & Career Mastery

Introduction: The Ceiling That Isn’t

You’ve been a senior developer for two years. You’re respected. You make good technical decisions. Your code is solid. You mentor juniors.

And then you hit a wall.

You’re not getting promoted. You’re not getting the interesting projects. You’re not being included in strategic decisions.

You ask your manager: “What’s next?”

They say: “You’re already senior. There are staff engineer and principal roles, but those are rare. Most people stay at senior level.”

You realize something: Being a senior IC (individual contributor) is a dead end.

Most companies have a pyramid. Lots of junior developers. Some mid-level. Few seniors. Very few staff/principal.

If you want to keep growing, you can’t just get better at coding. You have to evolve into something different.

This guide teaches you that evolution.

It’s not about coding better. It’s about thinking differently. It’s about multiplying your impact through others. It’s about understanding business, negotiating your future, and making strategic decisions that compound.

Because here’s the truth: The difference between a senior developer and a staff engineer isn’t code quality. It’s leverage.

Chapter 1: The Senior Developer Ceiling

First, let’s understand the problem.

Why Senior Developers Get Stuck

You’ve Optimized Locally

You’re great at your domain. You know the codebase. You make fast decisions within your area.

But the company has 50 domains. You’re an expert in one. That’s not leverage.

You’re Still Measured on Individual Output

Senior developers are measured on code they write, features they ship, bugs they fix.

Staff engineers are measured on impact on the entire organization.

Different metric. Different career trajectory.

You Haven’t Built Political Capital

You have respect within your team. But you don’t have visibility across the organization.

You don’t know the director of product. You haven’t influenced company strategy. You’re not in the room where big decisions happen.

You Haven’t Multiplied Yourself

You write good code. But five juniors write bad code because nobody trained them.

Net result: You’re a bottleneck, not a multiplier.

The Three Paths After Senior

Path 1: Staff Engineer (Technical Leadership)

You scale your technical impact across multiple teams.

You don’t manage people, but you influence how they build.

You set technical standards. You review architecture decisions. You build platforms that other teams use.

Example: “Payment infrastructure staff engineer. I’m responsible for making sure every payment at this company is built correctly.”

Leverage: You influence decisions across teams without direct authority.

Path 2: Engineering Manager

You manage people. You’re responsible for hiring, retention, performance, career growth.

You trade hands-on technical work for people leadership.

Example: “Engineering manager of the payments team. I hire, I develop people, I make sure we ship on time and with quality.”

Leverage: You multiply impact through people.

Path 3: Principal/Architect

You combine technical leadership with strategic thinking.

You influence company direction. You make key technology choices. You mentor other senior people.

Example: “Principal architect. I decide on company-wide infrastructure strategy, mentor senior engineers, and advise executive team on technical direction.”

Leverage: You influence the entire company’s technical trajectory.

The Common Mistake:

Many senior developers assume they have to choose: “Manager or technical?”

False. The best leaders combine both skills. They understand people AND technology.

Chapter 2: From Senior IC to Staff Engineer

If you want to stay technical (not manage people), the path is staff engineer.

But how do you get there?

What Actually Is a Staff Engineer?

Most companies don’t have a clear definition. It’s frustratingly vague.

Here’s what staff engineers actually do:

1. Solve Problems Across Domains

A senior developer solves problems in their domain.

A staff engineer solves problems that span multiple teams.

Example:

Senior: “I architected the payment service. It’s performant and reliable.”

Staff: “Every payment is a performance bottleneck because teams are using different integration patterns. I designed a unified pattern all teams now use. Payment latency dropped 40% company-wide.”

2. Set Standards

A senior developer follows standards.

A staff engineer creates standards.

Example:

Senior: “I follow the coding standards in our repo.”

Staff: “I evaluated Go linters, established company-wide standards, and integrated them into CI/CD. Every repo now has consistent quality.”

3. Unblock Multiple Teams

A senior developer unblocks their team.

A staff engineer unblocks the entire organization.

Example:

Senior: “I debugged the deployment bottleneck on our service. Now we deploy in 15 minutes instead of 4 hours.”

Staff: “I identified that deployment times are a company-wide problem. I built a deployment automation platform. Every team’s deployment time halved. This enables us to ship 4x faster overall.”

4. Think Long-Term

A senior developer thinks about the next 6 months.

A staff engineer thinks about the next 2-3 years.

Example:

Senior: “We should refactor this service to handle 10x load.”

Staff: “In 2 years, our user base will 5x. We need to redesign our database strategy now. Here’s a 3-year plan: Phase 1 is sharding foundation, Phase 2 is migration, Phase 3 is optimization. This positions us for 10x growth.”

5. Mentor Other Senior People

A senior developer mentors mid-level developers.

A staff engineer mentors other senior developers (and future staff engineers).

Example:

Senior: “I’m helping Alex improve their system design skills.”

Staff: “I mentor three senior developers toward staff-level thinking. They’re learning to see company-wide problems, not just team problems.”

The Staff Engineer Promotion Path

Most companies don’t automatically promote seniors to staff. You have to make a case.

Step 1: Understand the Gaps

What problems does your company have that cross team boundaries?

Deployment complexity? Monitoring inconsistency? Database scaling? API standards?

Pick a problem that:

Affects multiple teams
Costs the company (slow deployments cost money, inconsistent standards cause bugs)
You can actually solve

Step 2: Solve It (Before Promotion)

Don’t wait for the promotion to start acting like a staff engineer.

Start solving company-wide problems now.

You want to show staff engineer impact before being promoted to staff engineer.

Example:

You work on the payments team. You notice:

Payments team uses REST APIs
Fraud team uses gRPC
Analytics team uses webhooks
Everyone is reinventing integration patterns

You design a unified async event pattern. You get buy-in from all teams. You build the framework. You migrate teams to it.

Now: Deployment errors dropped 30%. Integration time halved. Everyone benefits.

This is staff engineer work. Do it.

Step 3: Document and Communicate

Write down what you did. Show the impact.

“Designed and implemented company-wide event-driven architecture:

Reduced deployment errors by 30% (was $50k/quarter in incident costs)
Reduced integration time from weeks to days
Enabled 15+ integrations that were previously blocked on infrastructure

This required coordinating across 5 teams and influencing architecture decisions outside my domain.”

This is your promotion case.

Step 4: Have the Conversation

Talk to your manager and skip-level (your manager’s manager).

“I’ve been solving company-wide problems [examples]. This is staff-level work. When is the right time to discuss staff engineer promotion?”

If they say “never,” you have options:

Move to another company that values staff engineers
Move into management
Stay senior and be content with the level

The Staff Engineer Trap

Warning: Staff engineer can be a dead end if done wrong.

The Trap: Becoming the Hero

You solve every problem. You’re on every call. You’re spread thin across 20 projects.

You become indispensable. Which means you become a bottleneck.

Your career plateaus because you’re too busy fixing fires.

How to Avoid It:

Don’t solve problems. Enable others to solve problems.

Bad: “I’ll build the deployment automation platform.”

Good: “The deployment problem is slowing us down. Here’s a design. [Team X], can you build it? I’ll review and guide.”

Now they level up. You don’t become a bottleneck.

Chapter 3: Building Influence Without Authority

One of the hardest skills for senior developers is influencing people you don’t manage.

You can’t tell the database team what to do. You can’t order the frontend team to follow your standards.

Yet you need to influence them.

The Five Sources of Influence

Source 1: Credibility

People listen to you because you’ve been right before.

You have a track record of good decisions.

You admit when you’re wrong.

You back up your recommendations with data.

Source 2: Relationships

You have genuine relationships across the company.

You know people. You’ve helped them. You understand their constraints.

When you suggest something, they think “Omar has helped us before, so I’ll trust this suggestion.”

Source 3: Clarity

You explain things clearly.

You don’t overwhelm people with technical detail.

You explain the “why” so people understand the reasoning, not just the rule.

People follow you because they understand where you’re going.

Source 4: Reciprocity

You’ve helped people. Now they want to help you.

You mentored a developer who’s now on another team. They value you. When you ask for their support, they’re inclined to help.

Source 5: Institutional Knowledge

You know how things work. You know the history. You know why past decisions were made.

People defer to you because you have context they don’t have.

“We tried this approach in 2020. It didn’t work because X. Here’s why this approach is different…”

People listen because you’ve seen similar problems before.

How to Influence the Database Team (Example)

Scenario: You think the company should standardize on PostgreSQL instead of having 5 different databases.

You don’t have authority. The database team decides. But you can influence them.

Step 1: Build the Case with Data

How many databases do we have?
What’s the operational cost?
How many people know each database?
What problems do we have from fragmentation?

“We have 5 databases. Operational cost: $500k/year. Only 2 people know Cassandra. We had 3 incidents from people using the wrong database. Cost: $200k in lost time.”

Step 2: Propose a Path (Not a Mandate)

“Here’s what I’m thinking: Move to PostgreSQL as the default. Keep [special case] on Cassandra. Timeline: 2 years. Phase 1: New projects use PostgreSQL. Phase 2: Migrate non-critical systems. Phase 3: Migrate critical systems.”

You’re not saying “stop using other databases now.” You’re proposing a path they can execute.

Step 3: Get Buy-in From Stakeholders

Talk to:

The database team (who will do the work)
The infrastructure team (who operate them)
The product teams (who depend on them)

“Here’s what I’m proposing. What do you think? What problems do you see?”

You’re gathering input, not announcing a decision.

Step 4: Build Support

The database lead says “I think PostgreSQL is right, but I’m worried about migration complexity.”

You say: “Let’s work together to figure out the migration strategy. I can help model what a 2-year transition looks like.”

Now you’re collaborating, not dictating.

Step 5: Guide Execution

As consensus builds, you step into a guiding role.

“Let’s do a pilot. Migrate 2 small services to PostgreSQL. Learn what works. Apply those lessons to the next batch.”

You’re helping them execute well, even though they’re doing the execution.

Chapter 4: Strategic Thinking vs. Tactical Coding

Senior developers often stay trapped in tactical thinking.

Tactical: “How do I solve this problem right now?”

Strategic: “What does solving this problem enable? What’s the downstream impact? What compounds positively?”

The Tactical Developer (Stuck at Senior)

Monday: “We need to optimize the user service. I’ll profile it.”

Tuesday: “Found the N+1 query. I’ll fix it. Response time improved 30%.”

Wednesday: “Great! That’s done. What’s next?”

This is good. But it’s local optimization. No leverage.

The Strategic Developer (Moving to Staff)

Monday: “Our users are complaining about slowness. Let me understand what’s causing it.”

Investigation: “It’s not just the user service. It’s how services communicate. Every service talks to every other service. It’s a network of N^2 dependencies.”

Tuesday: “I see the real problem. We don’t have an integration pattern. Teams are building point-to-point integrations. It’s chaotic.”

Wednesday: “Here’s what I propose: Async event-driven architecture. Phase 1: New integrations use events. Phase 2: Migrate existing integrations. Phase 3: Optimize.”

Thursday: “I’ve talked to team leads. They see the problem too. I’ll help design it. They’ll implement it.”

This is strategic. It enables everyone. It compounds. It’s staff-level work.

How to Develop Strategic Thinking

Habit 1: Ask “Why” Five Times

Problem: “Deploy times are slow. Takes 4 hours.”

Why? “We have to run comprehensive tests.”

Why? “We keep shipping bugs.”

Why? “Tests don’t catch everything.”

Why? “Our test coverage is inconsistent.”

Why? “We don’t have standards for what to test.”

Root cause (not the obvious one): Lack of testing standards.

Solution: Establish testing standards. Now other solutions (faster tests, better CI/CD) become possible.

Habit 2: Think About Enablement

Instead of: “I’ll optimize the database”

Ask: “What would enable all teams to optimize their databases?”

Instead of: “I’ll fix the deployment”

Ask: “What would enable all teams to deploy faster?”

This shifts from individual contribution to systemic thinking.

Habit 3: Look at Leverage Points

High-leverage point: A decision made by 1 person that affects 100 people’s work

Example: “Implement a logging standard. Now every team has consistent logs.”

1 person (you) creates the standard. 100 developers benefit. That’s 100x leverage.

Habit 4: Think in Quarters, Not Weeks

Tactical: “What’s this week’s sprint?”

Strategic: “Where will we be in 3 months? 6 months? A year?”

“If we do X now, what becomes possible in 3 months? What’s the compounding effect?”

Chapter 5: Building a Personal Board of Directors

One of the biggest mistakes senior developers make: They operate in isolation.

You don’t have mentors. You don’t have peers at your level to discuss decisions with. You don’t have people giving you honest feedback.

This limits your growth.

The Board

Your personal board has 5-7 people:

Member 1: Your Manager

They give you feedback on performance and career. They’re invested in your growth.

But they also evaluate you. So there’s a power dynamic.

Member 2: Your Peer (Senior Developer)

Another senior at your company or elsewhere who you can be honest with.

You can say “I’m stuck, here’s my problem” without worrying about politics.

You can get honest feedback.

Member 3: Your Mentor (More Senior)

A staff engineer, principal, or engineering director who’s been where you’re trying to go.

They can advise on career strategy. They can tell you what works.

Member 4: Your Domain Expert

Someone who’s deep in your technical area (systems, databases, frontend, etc.)

They help you stay current and deep in your specialty.

Member 5: Your Coach

Ideally someone outside tech who helps you with communication, leadership, negotiation.

They can see patterns you can’t see yourself.

How to Build Your Board

You don’t hire these people. You build relationships.

For your manager: Already there. Nurture the relationship. Have regular 1-on-1s.

For your peer: Find someone at your level doing similar work. Start grabbing coffee. Have real conversations.

For your mentor: Look for someone you admire. Reach out: “I admire your work. Could I grab your time monthly to get your perspective?”

Most senior people are flattered to mentor. They say yes.

For your domain expert: Follow them online. Read their work. Go to talks. Network.

For your coach: This might be someone you pay. But it’s worth it for career-defining decisions.

How Often to Connect

Your manager: Weekly 1-on-1
Your peer: Monthly coffee
Your mentor: Monthly or quarterly coffee
Your domain expert: Quarterly (reading their work, following online)
Your coach: Monthly or quarterly (during key career transitions)

Chapter 6: Negotiating Your Career

Here’s what they don’t teach you: Career progression is partly merit, partly negotiation.

You can be excellent and still be underpaid, undervalued, and stuck at your level.

The people who negotiate their careers move faster.

What to Negotiate

1. Title

Title affects your credibility inside and outside the company.

“Senior Developer” vs. “Staff Engineer” affects how people listen to you.

If you’re doing staff-level work, negotiate for the title.

2. Compensation

Senior developers should negotiate salary every time there’s an opportunity.

New offer? Negotiate.

Promotion? Negotiate.

Market rate increased? Negotiate.

Most people leave money on the table by not negotiating.

3. Scope

What are you responsible for?

One team? Multiple teams? Company-wide decisions?

Scope affects impact and career growth.

Negotiate for larger scope as you grow.

4. Support

What resources do you get?

Budget for training? Tools? Hiring? Time?

Staff engineers often get budget for projects and team support.

How to Negotiate

Rule 1: Know Your Worth

Research:

What do senior developers make at your company?
What do staff engineers make at similar companies?
What’s the market rate for your experience level?

Glassdoor, Levels.fyi, salary surveys. Get data.

Rule 2: Know Your Leverage

What leverage do you have?

You have offers from other companies (strongest)
You have promoted to senior and are now ready for the next level
You’ve solved major problems that are worth money
You’re hard to replace

Quantify your impact: “I designed the event architecture that reduced incidents by 30%. That’s worth $500k/year in incident costs.”

Rule 3: Have the Conversation

Don’t wait for your manager to offer more money.

“I’ve been reflecting on my compensation and career growth. I think it’s time to discuss a raise/promotion.”

Be specific: “Based on market research, senior developers in this market make $X. I’m currently making $Y. I’d like to discuss moving to $Z.”

Rule 4: Be Willing to Walk

This is the ultimate leverage.

If you’re underpaid or stuck, you can leave.

You don’t have to burn the bridge. But you have to be willing to walk.

Most people negotiate worse because they’re not willing to walk.

If you ARE willing to walk, you negotiate better.

When to Negotiate

Promotion: “I’m being promoted to staff engineer. Here’s the market rate for this level. I’m looking for a raise to $X.”

Annually: “I’d like to discuss my compensation for next year. Here’s my impact. Here’s the market rate for senior developers. I’m looking for a raise to $X.”

New Offer: “I have an offer for $X. I’d prefer to stay here. Can you match or beat this?”

Chapter 7: The Long-Term Career Arc

Senior developer is a waypoint, not a destination.

Year 1-3: Senior IC

Focus: Excellence in your domain

You write great code. You solve hard problems. You grow technically.

Goal: Become known for excellence in your area.

Year 3-5: Staff Engineer or Manager

Focus: Multiplying your impact

If technical path: Solve company-wide problems. Mentor other seniors.

If management path: Build great teams. Develop people.

Goal: Move from “excellent individual contributor” to “multiplier.”

Year 5-8: Principal / Senior Manager / Tech Lead

Focus: Strategic influence

If technical: Set company-wide technical direction.

If management: Lead teams of managers. Build organization strategy.

If both: Principal engineer. Architectural leadership.

Goal: Shape the organization’s technical and human systems.

Year 8+: Director / VP / Distinguished Engineer

Focus: Company strategy and culture

Influence at board level. Make major decisions. Shape company direction.

Goal: Long-term impact on the company and industry.

The Key Transitions

Senior → Staff (Year 2-3)

Transition: Stop being a domain expert. Become an organizational expert.

You learn: How other teams work. What problems they face. How to unblock them.

You shift from “deep in one area” to “broad understanding of many areas.”

Staff → Principal (Year 5-7)

Transition: Stop solving problems. Start setting strategy.

You learn: Business strategy. Board dynamics. How to influence executives.

You shift from “solve this company-wide problem” to “what should the company be building?”

IC → Manager (Can happen at any point)

Transition: Stop writing code (mostly). Start developing people.

You learn: Hiring. Performance management. Career development.

Different skill set. Not harder. Just different.

Chapter 8: Remote Senior Developer

The world is increasingly remote. This changes what it means to be senior.

The Remote Advantage

Remote work favors senior developers who can:

Communicate clearly in writing
Take ownership without micromanagement
Figure things out independently
Guide others asynchronously

Remote is often HARDER for juniors (less mentoring, less observation) but EASIER for seniors.

How to Succeed as Senior (Remote)

1. Over-Communicate

In office: People see you working. They know you’re solving problems.

Remote: You have to tell them.

“Here’s what I’m working on. Here’s the progress. Here’s what I learned.”

Write more. Share more. Communicate more.

2. Document Everything

In office: Institutional knowledge lives in people’s heads. They can ask questions.

Remote: Document decisions, rationale, patterns.

Write design docs. Write playbooks. Write decision records.

This makes you more valuable (knowledge is captured) and helps others (they can learn async).

3. Make Async Decisions

You can’t call a meeting. So make decisions asynchronously.

Post: “Here’s the problem. Here’s my proposed solution. Feedback welcome. I’ll decide on Friday.”

People async-review. You incorporate feedback. You decide.

Decision made without meetings.

4. Build Visibility

In office: Your work is visible. People see you in meetings.

Remote: You have to be intentional about visibility.

Share wins. Present work. Participate in async discussions.

Make sure people know what you’re doing.

The Remote Ceiling

Remote makes some things harder:

Building relationships (harder without in-person time)
Political capital (less visible to decision-makers)
Mentoring juniors (asynchronous mentoring is less effective)

If you’re trying to move into management or principal roles, you might need to be hybrid or in-office.

Otherwise, remote is great for senior ICs.

Chapter 9: Specialization vs. Generalization

Senior developers face a choice: Get deeper (specialist) or broader (generalist)?

The Specialist Path

Go very deep in one area.

Examples:

“I’m the database expert”
“I’m the real-time systems expert”
“I’m the security expert”

Advantages:

Very high demand
Can command high salaries
Become indispensable

Disadvantages:

Limited opportunities (only big companies need deep specialists)
Can become outdated (field changes)
Limited career paths (can’t move to management easily)

The Generalist Path

Broad knowledge across many areas.

Examples:

“I can build full-stack systems”
“I understand backend, infrastructure, DevOps”

Advantages:

More career flexibility
Can move into leadership (management/principal)
Valuable for smaller companies
Can move between companies/industries

Disadvantages:

Master of none (less depth than specialists)
Can’t command as high salaries on technical skills alone
Need to keep learning across many areas

The Hybrid Path

Deep in one or two areas. Broad in others.

Example: “I’m deep in systems architecture and distributed systems. I’m broad in backend, infrastructure, and DevOps.”

This is often the best path. It gives you:

Recognized expertise (you’re known for something)
Career flexibility (you can move around)
Leadership potential (you understand multiple domains)

Chapter 10: The Decision: What’s Next?

At some point, you have to decide. Where are you going?

Questions to Ask Yourself

1. Do I want to manage people?

Management is a different career. You trade technical depth for people leadership.

Answer honestly. Many senior developers hate management.

2. Do I want to stay technical?

Staff/Principal roles let you stay technical but with broader impact.

This is for people who love technical work but want more influence.

3. Do I want to stay here?

Some companies have clear paths. Others don’t.

If your company doesn’t promote to staff engineer, you might need to move.

4. What’s my honest assessment of my skills?

Can you influence across teams? Can you think strategically? Can you mentor others?

Be honest. If you can’t yet, what would it take to develop these skills?

The Action Plan

If you want staff engineer:

Start solving company-wide problems now (don’t wait for promotion)
Build relationships across teams
Develop strategic thinking skills
Have the conversation with your manager

If you want management:

Look for opportunities to lead projects
Mentor more people
Learn about team dynamics and people skills
Express interest to your manager
Take on a manager/tech lead role

If you want to move:

Interview at companies with clear paths for senior/staff
Find companies that value what you do
Negotiate from a position of strength (you already have senior experience)

Conclusion: Your Next Chapter

You’re at a crossroads. You can stay at senior level, doing good work.

Or you can evolve.

Senior developer is achievement. It’s a real milestone. Respect that.

But it’s not the end. It’s a waypoint.

The next chapter is about multiplying your impact. Thinking strategically. Building influence. Developing the next generation of senior developers and leaders.

That’s where the real career growth happens.

Appendix A: Career Progression Checklist

SENIOR IC SKILLS:

☐ Write excellent code consistently
☐ Make good architectural decisions
☐ Mentor mid-level developers
☐ Take ownership of projects
☐ Communicate clearly
☐ Debug complex problems
☐ Estimate accurately
☐ Maintain high code quality

STAFF ENGINEER SKILLS (On Top of Senior IC):

☐ Solve problems across multiple teams
☐ Set technical standards
☐ Think 1-2 years ahead
☐ Influence without authority
☐ Build institutional knowledge
☐ Mentor other senior developers
☐ Think about company-wide impact
☐ Communicate with leadership

PRINCIPAL / SENIOR MANAGER SKILLS (On Top of Staff):

☐ Set company-wide technical direction
☐ Understand business impact of technical decisions
☐ Negotiate with executive team
☐ Build and develop leaders
☐ Make strategic trade-off calls
☐ Represent engineering to board/investors

Appendix B: Building Your Personal Board

YOUR BOARD:

Member 1: Your Manager
- Meeting frequency: Weekly 1-on-1
- Purpose: Performance feedback, career guidance
- Questions: "What do I need to improve? When am I ready for the next level?"

Member 2: Your Peer (Senior Developer)
- Meeting frequency: Monthly
- Purpose: Honest feedback, peer support
- Questions: "How do you handle X? Am I thinking about this right?"

Member 3: Your Mentor
- Meeting frequency: Monthly or quarterly
- Purpose: Advice from someone who's been where you're going
- Questions: "How did you transition to staff? What surprised you?"

Member 4: Your Domain Expert
- Interaction: Quarterly or reading their work
- Purpose: Stay current, stay deep
- Questions: What's changing in my field? What should I be learning?

Member 5: Your Coach
- Meeting frequency: Monthly (during transitions)
- Purpose: Help with communication, leadership, negotiation
- Questions: How do I negotiate better? How do I communicate my value?

Appendix C: Negotiation Script

INITIATING COMPENSATION DISCUSSION:

"I've been reflecting on my career and compensation. I think it's time to discuss an update.

I've [specific accomplishments]. This has enabled [business impact].

Based on market research [cite sources], senior developers at this level make [range].

I believe I should be compensated at [specific number or range].

Can we discuss how to make this happen?"

---

RESPONDING TO "That's too much":

"I understand that might seem high. Here's my thinking:

- My [accomplishment] saved the company [impact] annually
- I've moved from individual contributor to solving company-wide problems
- Market rate for this level is [range]
- I'm not asking for the top of the range. I'm asking for [number], which is [percentage] below market

What would it take to get there?"

---

RESPONDING TO "We can't do it right now":

"I understand. Timeline-wise, when can we revisit this?

I'm interested in staying and growing here. I just want to make sure my compensation reflects my contribution.

Can we set a date to revisit this discussion in [3 months/6 months]?"

Appendix D: Strategic Thinking Questions

WHEN EVALUATING ANY PROBLEM:

1. What's the real problem? (Not the obvious one)
2. Who does this affect?
3. How much does it cost us (in time, money, impact)?
4. What would solving it enable?
5. What's the long-term benefit?
6. What would a company-wide solution look like?
7. How does this compound over time?
8. Who else should I involve?
9. What are the second and third-order effects?
10. Am I solving this, or am I enabling others to solve it?