(by Will Larson)

Overview

• At the career level, being promoted further is an exception rather than expected.

Staff Engineer Archetypes

• The four common archetypes are the Tech Lead, the Architect, the Solver, and the Right Hand.
• A Tech Lead Manager is similar to the Tech Lead archetype but exists on the engineering management ladder and includes people management responsibilities.

Tech Lead

• Tech Leads are the most common archetype. They're comfortable scoping complex tasks, coordinating their team towards solving them, and unblocking them along the way.
• They maintain many essential cross-team and cross-functional relationships, and are a close partner to the team's product manager.
• A tech lead defaults to delegating tasks, thereby growing their teammates, but they still define the team's technical vision and step in to build alignment on technical issues.
• An organization needs roughly one tech lead for every eight engineers, and so they are the most common archetype.
• A Staff-engineer is the intersection of your role, your behaviors, your impact, and the organization's recognition of all these things.

Architect

• Architects are responsible for the success of a specific technical domain within their company.
• For a domain to merit an architect, it must be both complex and enduringly central to the company's success.
• Influential architects dedicate their energy to maintaining and intimate understanding of the business' needs, the users' goals, and the relevant technical constraints.
• The architect role emerges in large companies, those with extremely complex codebases, and in companies struggling to repay technical debt created in their sprint to product-market fit.

Solver

• The Solver is a trusted agent of the company who goes deep into knotty problems, continuing to work on them until they're resolved.
• They generally stop working on problems once they're contained, which creates a feeling of transience and requires a soft touch to avoid upsetting the teams left to maintain the "solved" problem.
• The solver is most common in companies that think of individuals, rather than teams, as the atomic unit of planning and ownership.

Right Hand

• The Right Hand is the least common of the archetypes, showing up as an organization reaches hundreds of engineers. They operate as a senior organizational leader without direct managerial responsibilities.
• Borrowing authority comes with the obligation to remain deeply aligned with that leader's approach, beliefs, and values.
• Problems addressed at this level are never purely technical and instead involve the intersection of business, technology, people, culture, and process.
• The joy of these roles is that you work only on essential problems. The tragedy is that you're on to the next issue by the time those problems are solved.

Which is right for you?

• Success in these roles requires remaining engaged, so it's essential to understand what kind of work energizes you.
• The Tech Lead and Architect may work with the same people and on the same problem for years, developing a tight sense of team and shared purpose.
• The Solver and Right Hand bounce from fire to fire, often having only transactional interactions with the folks they're working with on any given week.

What do Staff engineers actually do?

• All archetypes set and edit technical direction, provide sponsorship and mentorship, inject engineering context into organizational decisions, exploration, and be glue.

Setting technical direction

• Think of setting technical direction as being a part-time product manager for technology.
• Setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology approaches that you're personally excited to learn about.

Mentorship and sponsorship

• You're far more likely to change your company's long term trajectory by growing other engineers than through personal heroics.
• The most effective Staff engineers pair a moderate amount of mentorship with considerably more sponsorship.

Providing engineering perspective

• Staff-plus engineers are the folks who will often get unexpectedly pulled into the room when time-sensitive or important decisions are happening.
• Such brief moments of input on critical decisions are unduly impactful and will allow you to inject an engineering perspective where it would otherwise be missed.

Exploration

• Staff-engineers may be assigned to do exploratory work, which is any ambiguous, important problem that the company's systems are ill-shaped to address.
• It takes a great deal of organizational trust to be trusted with this work, including having enough respect from the business that if you fail, it's a reflection on the problem and not you.

Being glue

• Staff engineers often do the needed, but often invisible, tasks to keep the team moving forward and shipping its work.

But will you still write software?

• Staff engineers don't write as much software as they did earlier in their career.
• If a Staff engineer finds themselves coding often, it's usually a sign of working on something comfortable rather than something important.

Slow but rewarding

• Most of the work you'll be doing at this level replaces the feedback loop with one that takes weeks, months, and years.

Does the title even matter?

• Three consistent advantages that generally come with being a Staff-plus title are:
• allowing you to bypass informal gauges of seniority
• facilitating access to "the room"
• increase in current and career compensation

Informal gauges of seniority

• A Staff-plus title allows you to re-invest the energy you've previously spent on proving yourself into the core work you're evaluated on.

Being in the room

• In more senior roles, you can provide input when it's relatively cheap to incorporate, because the roll out or implementation has not advanced too far.

Compensation

• Even if your current company doesn't compensate for Staff-plus engineer roles much differently than for Senior engineer roles, some companies do.

Access to interesting work

• Being a Staff-plus engineer does not necessarily give you access to interesting work. For example, as a tech lead you may be undermining your team if you operate that way.
• The most consistently effective way to get access to interesting work is being hired to do it.
• As a Staff engineer, you cannot pursue interesting work out of personal interest – you must put the business' needs first, and to model good behavior.

Different rather than better

• Many folks find that their Staff role's heightened expectations eliminate the work that used to excite them.

Material but not magic

• If you have a problem and believe that your title is the only thing holding you back, rest assured that focusing on developing your approach and skills will be far more impactful than the title.
• However, women and minorities often do find they spend significantly less time and energy proving themselves once they attain a Staff-plus title.

Operating at Staff

• A big part of the learning curve of Staff engineer is that much of the work you're doing has a much slower feedback cycle.

Work on what matters

• If you're continuing to advance your career, then even as your time available for work shrinks, the expectations around your impact will keep growing.
• Only through pacing your career to your life can you sustain yourself in the long term.

Avoiding snacking

• When you run out of easy and high-impact work, only hard and high-impact work or easy and low-impact work is left. The latter choice is snacking.
• In senior roles, you're more likely to self-determine your work. If you're not deliberately tracking your work then it's easy to catch yourself doing little to no high-impact work.

Stop preening

• Preening is the seductive subset of snacking that is low-impact, high-visibility work.
• Many companies can't distinguish between preening and impact, leading senior engineers to do work of dubious value that is frequently recognized in company meetings.
• To be a successful preener requires near invulnerability to criticism of your actual impact, and your true work will suffer if your energy is diverted to preening.

Stop chasing ghosts

• After joining a new company, taking the time to understand the status quo before shifting it will always repay diligence with results.

Existential issues

• Companies operate in an eternal iterative elimination tournament, balancing future success against surviving until that future becomes the present.
• If you're about to lose one of those rounds, then always focus there.

Work where there's room and attention

• The most effective places to work are those that matter to your company but still have enough room to actually do work.
• Teaching a company to value something it doesn't care about is the hardest soft of work you can do, and it often fails, so you should do as little of it as you can, but no less.

Foster growth

• If you start dedicating a few hours per week to developing the team around you, it's quite likely that will become your legacy long after your tech specs and pull requests are forgotten.

Edit

• With your organizational privilege, relationships, and ability to see around corners derived from your experience, you can often shift a project's outcomes by investing the smallest amount of effort.

Finish things

• We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage.

What only you can

• The final category of work that matters is the work you're uniquely capable of accomplishing, which is an intersection of what you're exceptionally good at and what you genuinely care about.

Why it matters

• Interviewing judges you on subjective measures like your accumulated prestige, your titles at companies you've worked at, your backchannel reputation, and how you present yourself in the interview process.
• The only viable long-term bet on your career is focusing on work that matters, doing projects that develop you, and steering yourself toward companies that value genuine experience.

Writing engineering strategy

• To write an engineering strategy, write five design documents and pull the similarities out. That's your engineering strategy.
• To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That's your engineering vision.
• Engineering strategy and vision are the output of iterative, bottom-up organizational learning.

When and why

• If you're rehashing the same discussion multiple times, it's time to write an engineering strategy.
• When the future's too hazy to identify investments worth making, it's time to write another vision.

Write five design docs

• A batch of design docs is the ideal ingredient for writing an effective strategy because they have what bad strategies lack: detailed specifics grounded in reality.
• A few recommendations as you write:
• Prefer minimal design document templates that allow authors to select the most useful sections and only insist on exhaustive details for the riskiest projects.
• Gather perspectives widely but write alone. Don't fall in love with what you've written until after you've reviewed it with others.
• Focusing on pushing designs to be good, rather than fixating on your own best as the relevant quality bar.

Synthesize those five design docs into a strategy

• Good strategies guide tradeoffs and explain the rationale behind that guidance. Bad strategies set policy without explanation.
• Some advice for writing a strategy document:
• Be specific, and if you can't be specific, wait until you've written more design documents. Specific statements create alignment.
• Be opinionated, or else the document won't provide any clarity on decision making.
• Show the rationale behind your opinions, so that others can modify and extend your work as the underlying context shifts.

Extrapolate five strategies into a vision

• Some advice for writing a useful vision:
• Write two to three years out, or expand a bit longer if you're at a fairly-established company.
• Ground it in serving your business and your users. Bad visions are grounded in technical sophistication, which isn't aligned with leadership's goals.
• Be ambitious but not audacious. Write what you could do if every project finished on time, and not what would be possible with unlimited resources.
• Stay concrete and specific. Details in visions are often illustrative rather than declarative, giving a taste of a future rather than a binding commitment.

Managing technical quality

• At a well-run and successful company, most of your previous technical decisions won't meet your current quality threshold.
• Rather than a failure, closing the gap between your current and target technical quality is a routine, essential part of effective engineering leadership.

The problem

• As an engineering leadership team, you must maintain an appropriate technical quality level while devoting as much energy as possible towards the core business.
• Technical quality is a long-term game. You don't win, but instead learn and earn the chance to keep playing.

Ascending the staircase

• When thinking of quality improvements, start with the lightest weight solutions and only progress toward massive solutions as earlier efforts fail to scale.
• If something isn't working, try for a bit to make it work, and then embrace its demise.

Hot spots

• It's more important to understand the problem at hand and try to fix it than to create process-driven accountability.
• Adopt the performance engineer's mindset, whereby you measure the problem at hand, identify where the bulk of the issue occurs, and focus on precisely that area.
• When the organization is creating quality problems faster than you can fix hot spots, move on to adopting best practices.

Best practices

• When rolling out a new practice, don't rush. Instead roll out the process to a few engaged teams, make adjustments, and then roll it out further.
• Channel all your energy toward making one best practice a success rather than dividing resources across multiple best practices that are rolling out concurrently.
• Adopting a single best practice at a time also forces you to prioritize.
• Transitioning from best practices to leverage points happens when you find yourself wanting to adopt a new best practice before your in-progress best practice is working.

Leverage points

• Leverage points are places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments.
• Impactful leverage points include designing interfaces that hide complexity, and data models that are rigid but still support evolution.
• A key advantage of investing in leverage points is that you don't need total organizational alignment to do it.
• If you've exhausted the accessible impact from leverage points, it may be time to move on to driving broader organizational alignment.

Technical vectors

• Effective organizations marshal the majority of their efforts toward a shared vision.
• Routing all technical decisions through an Architect aligns technical direction, but this is challenging to scale.
• Your fundamental tools for aligning technical vectors are:
• Giving direct feedback to the individuals who you believe are misaligned.
• Encapsulating your approach in your workflows and tooling. This nurtures habits far better than training or documentation.
• Training new members during their onboarding. Pointing them in the right direction starts them from a position of alignment.
• If none of the techniques above are enough, you may require heavier approaches, and the first step is always measurement.

Measure technical quality

• The more detailed your definition of quality, the more useful it becomes to measure a codebase, and the more instructive it is to folks hoping to improve quality.
• You must have a precise and measurable definition. And then you must have instrumentation to create a quality score that you can track over time.
• After defining and instrumenting quality, you must choose between investing in a quality team or a quality program.

Technical quality team

• This team's goal is to create and preserve quality across your company's software.
• Start with a small team of three to six folks, thereby forcing you to prioritize their roadmap on impact and maintain focus on the achieveable.
• As a rule of thumb, consider one engineer working on developer tooling for every fifteen product engineers, in addition to your infrastructure investment.
• Some fundamentals for success for such teams:
• Trust metrics over intuition.
• Adoption and usability of your tools are much more important than raw power, so do user research on your tools and listen to and learn from your users.
• Do fewer things, but do them better.
• Your quality team should have more high-impact work than you can take on. If that's not the case, then you aren't thinking broadly enough.
• If there is critical quality work that you cannot get to, then explore starting a quality program.

Technical quality program

• A quality program is an initiative led by a dedicated team to maintain technical quality across an organization.
• The core approach is:
• Identify a program sponsor. This must be a powerful person who can change the constraints of an organization, thereby allowing a change in behavior.
• Generate sustainable, reproducible metrics.
• Identify program goals for every impacted team, and then serve as a subject matter expert to provide a clear path to achieving them.
• Build tools and documentation to support teams toward their goals. Do as much as possible to avoid teams having to deeply understand the problem space you're attempting to make progress in.
• Create a goal dashboard and share it widely. For each team, this dashboard should be a scorecard and provide breadcrumbs for where to focus next.
• Send programmatic nudges to folks behind on their goals. Ensure they are helpful or else they will be forever ignored.
• Periodically review program status with your sponsor. Leveraging your sponsor to bridge misaligned prioritization is essential to your success.
• Keep your program lean enough to cancel, and remain self-critical enough to cancel it if it ceases driving quality creation.

Start small and add slowly

• With complex systems and interdependencies, moving quickly is just optics. Methodical movement gets the job done.

Stay aligned with authority

• Retaining organizational authority depends on remaining deeply aligned with a bestowing sponsor – generally your direct manager.

Beyond the safety net

• Staff-plus roles are leadership roles, and in leadership roles, the support system that got you there will fade away.

Serving at the pleasure of the President

• In a Staff-plus role, authority flows from your tight association with greater authority.
• In previous roles, your authority primarily accumulates through your personal actions and impact over time.
• To align with your manager:
• Never surprise your manager. Nothing destroys trust faster than this, and it calls into question whether you're taking responsibility for your organization.
• Don't let your sponsor surprise you. If they don't actively communicate information relevant to your work, take action to facilitate information flow.
• Feed your manager's context. Be clear that you're not bringing them problems to solve, but rather conveying information you believe will be useful.
• Managing up is about increasing bandwidth and reducing friction between you and your manager.

Influencing without too much friction

• Make the distinction between the values you hold and those the organization operates under, and find a way to advocate for the former without getting kicked out of the room.

To lead, you have to follow

• Management is a specific profession, but leadership is a trait one can demonstrate within any profession.
• Leaders both:
• Can define the gap between how things are and how they ought to be, and can identify proactive and congruent solutions to narrow that gap.
• Care enough about the gap to attempt those narrowing actions.
• The most effective leaders spend more time following than they do leading. In practice this means:
• Be clear with yourself on what your true priorities are, and don't dilute yourself across everything that comes up.
• Give support quickly to others who are working to make improvements. Someone trustworthy leading a project will almost always get to a good outcome.
• Make your feedback explicitly non-blocking.
• You must incorporate your worldview into those of people around you, accelerating overall progress around you even if it means detouring from your vision.

Learn to never be wrong

• You must build a deep perspective on technology and architecture, and then develop an equally deep pragmatism and agnosticism to technical religion to remain skeptical of yourself.

Listen, clarify and read the room

• Enter a room with the goal of agreeing on the problem at hand, understanding the needs and perspectives within the room, and identifying must happen to align on an approach.
• If the room isn't ready to agree and move forward on a solution, don't force it to happen.
• To do this, master listening through questions, defining the purpose, and reading the room.
• Listening through questions: Good questions are specific, and are asked with a desire to learn. They open up conversation, creating space and safety for others to ask questions.
• Define the purpose: If in a meeting with an unclear goal, ask if your understanding of what the group hopes to accomplish is correct.
• Read the room: If folks in the room are too far apart, dig into the problem together with a suitable subgroup, or escalate to an appropriate party outside the room.

Jerks

• A jerk withholds consent from the group, isn't willing to compromise, or doesn't listen.
• A jerk hasn't learned that their career depends more on being easy to work with than being technically correct.
• The two most effective ways to deal with jerks are:
• Include someone they can't be a jerk to in the meeting.
• Invest heavily into aligning with them before the meeting, so they feel heard and are less likely to derail the discussion.
• If you frequently work with a jerk, try giving honest feedback to improve their behavior. Then give it again. If that fails, communicate the concerns to their manager.

How it helps

• More complex projects get derailed by personal conflict than by technical complexity, and so you must replace tension with partnership.

Create space for others

• As a Staff-plus engineer the organization around you should increasingly benefit from, but should not rely upon, your contributions.

Discussions

• When you make a key contribution, reflect on what needs to happen for someone else to make that contribution next time.
• To create more space in discussions:
• Shift your contribution toward asking questions.
• If you see someone else who isn't participating, pull them into the discussion.
• Be the one to take notes, and thereby de-stigmatize taking notes as "low status," and free an alternative would-be note-taker to contribute more instead.
• If you realize someone's missing from the discussion who should be there, pull them into the next occurrence of the meeting.

Decisions

• To shift increasingly complex and important discussions to your wider team:
• Write it down: By writing down the process of finding an answer, as well as the answer's rationale, others can learn from your decisions rather than being directed by them.
• Circulate early, and do it before you've crystallized on a decision.
• Separate style from substance: If a piece of feedback won't meaningfully change a project's success, then consider not giving it.
• Don't try to show value: Don't weigh in on everything, or require each decision to mirror a decision you made. This makes you look insecure, and prevents others from growing as leaders.
• Change your mind: If senior leaders don't change their mind, then everyone will correlate bluster with success.

Sponsorship

• When critical work comes to you, ask "Who could be both successful and grown by this work?" Ask that person to lead the work and scaffold the project for their success.
• Counsel, give advice, and provide context, but ultimately sponsorship includes letting someone take an approach that you wouldn't.
• Keep a sponsorship journal, and ensure you're sponsoring others at least a few times per month.

What if you don't?

• If you don't create space for others, then the only company that can tolerate being constrained by your personal limitations is a company that doesn't grow.
• To remain a long-term leader of a genuinely successful company, you must create space for others to take the work, reward, and recognition that got you to where you're currently sitting.

Build a network of peers

• The two most common strategies to building your network are being easy to find, and networking internally.

Be visible

• There is so much pent-up demand for community among Staff-plus engineers that the easiest way to build your network is being easy to find as a Staff-plus engineer.

Internal networks, too

• If you're at a decently large or prestigious company, folks leaving and spreading across the industry will help bootstrap your broader network.

Quality over quantity

• Slowly build your network with folks you trust, respect, and who inspire you. They will help you solve the hardest problems and trickiest situations that come your way.

Present to executives

• As you get further into your career, your impact will be constrained by your ability to influence executives effectively.

Why this is hard

• Communication with executives is challenging because they may lack familiarity with your domain, and they have limited time for the topic at hand.

How to communicate effectively

• Communicating with an executive is always one of three topics: planning, reporting on status, or resolving misalignment.
• Your goal is to extract as much perspective from the executive as possible, and the best way to do this is by writing a structured document.
• The clearest sequence for presenting your ideas is to give the summarizing idea before you give the individual ideas being summarized.
• Every document's opening paragraph should follow the SQCA format:
• Situation: Define the relevant context.
• Complication: Explain why the current situation is problematic.
• Question: State the core question to address.
• Answer: State the best answer to the posed question.
• Aligning with stakeholders before your presentation, sometimes called nemawashi, is extremely effective at reducing surprises.
• A great meeting with leadership is defined by engaged discussion, and not by addressing every topic on the agenda.

Mistakes to avoid

• Never fight feedback: If you show up as resistant to feedback, then executives will start withholding their comments, and you'll get less out of the meeting.
• Don't evade responsibility or problems: By putting issues on the table, you can move towards solving them together rather than hiding them.
• Don't present a question without an answer: Doing so will make an executive wonder if they need to hire a more senior leader to supplement or replace you.
• Don't fixate on your preferred outcome: It's easy to get upset over the "wrong" decision being made, but keep in mind there is much context that you're missing.
• Send an early draft to an executive attending the meeting and ask them what to change.

Getting the title where you are

• A Staff engineer isn't a better Senior engineer, but someone who's moved into fulfilling one of the Staff archetypes.
• The promotion and performance system will no longer feel be designed around attaining a timely promotion and may take on the feel of gatekeeping.

Opportunity is unevenly distributed

• When pursuing a Staff role, it's simpler to align your approach with where the opportunity is concentrated than fighting the causes of inequality.

Should you try management?

• If you take on management with the wrong motivations, you'll regret the experience, but not nearly as much as your team will.

A semi-permeable boundary

• Folks with the privilege of seeming like they are already part of the existing leadership team have a much easier time making the transition.

Promotion packets

• Write your first promotion packet long before you think or you're likely to be promoted to Staff, similar to writing a brag document.
• A general template format is:
• What are your Staff projects?
• What are the high-leverage ways you've impacted the organization?
• Who have you mentored and through what accomplishments?
• What glue work have you done for your organization?
• Promotions, especially at this level, are built over years, and so temper your expectations.
• Edit the promotion packet with your peers, who are often better at identifying your strengths and contributions than you are.
• Maintaining this sort of document and reviewing it across managers will help mitigate the loss of progress toward your promotion that occurs after a manager change.

Find your sponsor

• Promotions are a team activity. Don't play team games alone, or you'll lose.

Finding your sponsor

• This is the person speaking up for your work in forums of influence and when advocating for constrained resources.
• If your skip-level manager isn't familiar enough with your work's impact to remember it in a meeting two months from now, you're unlikely to get promoted into a Staff role.

Activating your sponsor

• Sponsors have more organizational capital than bandwidth to deploy that capital, so they'll help you most when you align the pieces for them.
• Activating your sponsor should not happen only once before your promotion. Build a relationship over time, and put in the work to help them when they need your support.

What if it doesn't work?

• If you an your manager don't work together well, then you're not going to get promoted into a leadership role.
• If you have an amazing relationship with your manager, your promotion clock will likely get reset as you build a relationship with your new manager.

Staff projects

• Folks who attain the Staff role at a company they've grown up in are more likely to have completed a Staff project.
• Staff engineers who don't complete such a project either accumulated a track record of success over a long period without a single capstone, or because they've switched roles to reach the title.

Staff project required

• Staff projects are sometimes a "soft gate" that's brought up during a promotion meeting, sometimes to the surprise of the manager and the would-be Staff engineer.

Why you should do a staff project

• Staff projects are effective at stretching you as an engineer because they may have the following characteristics:
• Complex and ambiguous: Such projects generally start with a poorly scoped but complex and important problem.
• Numerous and divided stakeholders: Such projects may lack organizational alignment around both the problem and the solution.
• Named bet where failure matters: Such projects are important enough that senior leadership talks about it, and any failures will be very visible.

Getting access to Staff projects

• Getting access to staff projects comes down to three factors:
• Stay aligned with your leadership team.
• Be known to have the technical aptitude for the problem at hand.
• Your company having a pressing need to solve a Staff-level problem.

Should you pursue a Staff project?

• Beyond the pursuit of the Staff engineer title, in the long-term pursuit of self-growth, such projects are irreplaceable.

Get in the room, and stay there

• To reach senior levels, you have to become effective at not only entering but also staying in these rooms of power.

Getting in the room

• To get in the room, you need:
• To bring something useful to the room, and that the room doesn't already have.
• A sponsor to grant you membership. It may be the case that your sponsor's manager is also in the room, evaluating them based on their decision to sponsor you.
• Your sponsor needs to know you want to be there.
• Sometimes the easiest way to increase your value in the room is by decreasing the cost of including you. Some approaches include:
• Stay aligned with your manager: If you are especially aligned, then your manager is more likely to yield their own seat to you.
• Optimize for the group.
• Speak clearly and concisely: Remember that it's your obligation to be understood, and not the obligation of everyone else to understand you.
• Be low friction: You're more likely to be involved if you're known as someone who can navigate difficult conversations effectively.
• Come prepared: You'll stand out if you organize your thoughts before each meeting, as well as follow up on what you're committed to.
• Focus and be present.
• Volunteer for low-status tasks: Prioritize being useful, especially when it isn't the most exciting work.

Staying in the room

• There are a few patterns that will consistently get you kicked out of the room:
• Misunderstanding the room's purpose: Take the time to understand how the room operates and integrate into it.
• Being dogmatic.
• Withholding consent: Effective groups are formed from individuals who are willing to disagree and commit.
• Sucking the oxygen out of the room: Distinguish between brainstorm discussions where every idea is welcome, and when you've shifted into operating mode to unblock project execution.
• Embarrassing your sponsor.
• Not showing up regularly.

Exiting the room

• Exit any room that doesn't feel useful. While exiting, sponsor someone else into the opportunity you're leaving behind.

Being visible

• Your goal is to be known for good things while minimizing the organizational bandwidth you consume to do so.

Why visibility matters

• Staff-plus roles are leadership roles, and by recognizing you with such a position, the company is bringing you into its leadership team.
• The existing members of that team want to expand their ranks with folks they believe in, and they can't believe in you if they don't know you.

Internal visibility

• The best way to create internal visibility is to work on the things that matter to your company and company leadership.

Executive visibility

• All positive visibility above your manager will be helpful to you, but it's especially valuable to build a relationship with your manager's manager.

External visibility

• Building an external presence gives you more room to create a niche and name for yourself, as external efforts don't compete for attention with your peers like internal efforts do.

Should you focus on visibility?

• At some point, increasing your visibility is likely reducing the opportunities for others to create visibility for themselves.
• If you identify a lack of visibility is likely to hold you back in the promotion process, work to clear that threshold, but not much further.

---

Tags: reading   management  

Last modified 16 December 2024

---

© 2020 Ted Neward | Generated on 16.12.2024 07:04:01 | Mixed with Bootstrap v3.1.1 | Baked with JBake v2.6.5