Staff+ self-onboarding questions
Useful questions to get a head start as a newly hired Staff, Principal, or Distinguished engineer
Congratulations on getting a role as Staff+ (Staff Engineer, Principal Engineer, Distinguished Engineer, etc.).
Now you need to quickly onboard yourself to a new technology landscape, product area, operation model, and new people (T-POP).
There are a few aspects that makes self-onboarding particularly tricky for Staff+ roles:
As a senior IC (individual contributor), you’re given more freedom and trust which implies less land holding. Somehow it’s assumed that you know what you’re doing even if it’s not always the case.
As a higher level engineer with elevated voice, you also act as a role model for the other engineers. The way you approach your onboarding sets the bar for how others navigate ambiguity.
As a technical leaders, your deep understanding of the T-POP is key to do your job effectively, but you cannot gain that knowledge without building some credibility and gaining experience. At times this catch-22 can feel like changing tires while the car is driving! 😄
In a previous post we have covered what your manager can do to facilitate your onboarding:
This post is about what YOU can do as a senior IC to self-onboard. More specifically: how to ask questions as a senior technical leader.
Characteristics of good questions
Questions are the primary tool to build a knowledge base. Another tool is to dig in the code but that’s out of the scope of this article.
There are big differences between poor questions and excellent ones:
Collaborative vs. judgmental tone: good questions invite partnership rather than suggesting criticism of existing systems.
Forward-looking vs. backward-blaming: good questions focus on understanding for future improvement rather than assigning blame to previous decisions.
Curious vs. prescriptive: good questions demonstrate genuine interest in learning rather than suggesting you already know the answer.
Specific vs. vague: good questions target precise information rather than general complaints or observations.
Open-ended vs. closed: effective questions encourage detailed responses that reveal context and nuance.
Me vs We: effective questions frame you as part of the group facing the same problem. They avoid putting the spotlight on you as the hero and savior but rather invite the group to have a constructive dialogue that helps evolve the status quo together.
Pulling ranks vs Service Minded: while it’s true that you may be hired at a higher position in the career ladder, pulling ranks can quickly alienate you. Instead adopt a service-minded approach (e.g. how can I help? What can I do with my elevated voice to unblock you?)
The primary purpose of the question is to gain knowledge, but for senior IC roles, the secondary objective is to build a connection and make a good impression.
The next section goes through good/bad questions to navigate:
T - Technology, architecture, and technical health
P - Product and Business
O - Operation and Culture
P - People and networking
Example Questions
Note: generative AI (Claude) was used to create the initial draft of this section. I have gone through every word and edited the result heavily to make sure it reflects my views and experience. Hope it will be useful for you as well.
The format is intentionally made to be easy to skim through so you don’t have to read the whole thing.
1. Technology, architecture, and health
Current Architecture and Systems
❌ "Why is the architecture so complex here?"
This question assumes complexity is negative rather than necessary.
It puts the respondent in a defensive position.
Lacks specificity about what information you're seeking.
Can be perceived as criticizing previous decisions.
Doesn't acknowledge the evolution and constraints that shaped the system.
✅ Effective Questions:
Could you walk me through how the main components of our system interact and the reasoning behind these design choices?
I'd love to understand the architecture diagram from a historical perspective—what were the key inflection points that shaped our current system?
Which parts of our architecture are you most proud of, and which areas do you think might benefit from fresh perspective?
System Evolution
❌ "This looks outdated. When are you planning to modernize it?"
Makes a judgment about the system being "outdated" without understanding context (e.g. maybe there was a time or budget limit).
Presumes modernization is needed and already planned.
Implies criticism of the current maintainers.
Any fool can criticize a system, but do you have a fit solution and more importantly are you going to be part of the solution beyond talking?
✅ Effective Questions:
How has this system evolved over time, and what were the key decision points that shaped its current state?
What trade-offs were considered when designing the current architecture, and how have those trade-offs aged as the business has grown?
I notice we're using [specific technology]—could you share the context behind that choice and how it's served the team?
How can I help improve this system’s most immediate pain points?
Pain Points
❌ "What's broken that I need to fix?"
Assumes systems are broken rather than evolving.
Positions yourself as a fixer before understanding the landscape.
Lacks specificity about problem areas.
Can come across as arrogant or dismissive of previous work.
Misses opportunity to understand prioritization and constraints.
✅ Effective Questions:
Which areas of our technical stack currently face the most challenges or would benefit most from improvement?
What technical areas keep you up at night or consistently require the most maintenance effort?
Where do engineers typically encounter friction when developing or deploying changes to the system?
[If there’s verified tech debt] Do we need to set a payment plan for the tech debt?
Long-term Direction
❌ "Why doesn't the company have a clearer technical strategy?"
Assumes a negative (lack of strategy) without evidence.
Signals judgment before understanding context
Puts the respondent in a defensive position. Implies criticism of leadership while conveniently ignoring the reason you’re hired as a technical leader.
✅ Effective Questions:
How is the long-term technical vision developed and communicated across the organization?
What are the biggest technical bets the company is making in the next 2-3 years?
How do technical leaders balance tactical delivery with strategic architectural evolution?
Technology Selection
❌ "Why aren't we using [trendy technology]?"
Suggests you've already decided what's best without context.
May come across as bringing baggage from previous employers.
Doesn't acknowledge the costs of technology transitions.
Can seem dismissive of previous decisions and constraints.
Presupposes the current technology choices are suboptimal. It may well be the case, but while you think of yourself as the guy with the wheel, the others may see the move as arrogant and simplistic. Read more here.
✅ Effective Questions:
What processes do we use for evaluating and adopting new technologies?
How do we balance innovation with standardization across the tech stack?
What criteria guide our technology adoption decisions, and how do we measure success after implementation?
Technical Debt
❌ "Why is there so much legacy code?"
Assumes negative judgment about existing codebase.
Presupposes so much legacy code exists without context. How do you even measure code? Lines of code? Number of invocations? File count? Git pull volume? Number of components in a system? In general stay clear from code size metrics especially in a negative context which motivates the maintainers to put their critical thinking hat on and find flaws in your argument.
Implies criticism of previous engineering decisions and makes maintainers of that code defensive.
Frames legacy code as purely negative rather than evolving. Legacy code may be intimidating to you but once you bother to learn the constraints, you get a better picture about the limitations and where you can improve it with surgical precision.
✅ Effective Questions:
What's our perspective on our technical debt landscape and how it's currently being addressed?
How does the team balance maintaining existing systems with introducing new technologies?
Which parts of our codebase have stood the test of time, and which areas might benefit from investment in modernization?
Technical Standards
❌ "Who enforces coding standards here?"
Focuses on enforcement rather than collaboration.
Suggests standards need policing rather than facilitating. Policing can also be disguised behind more benign terms like governance. In general, when someone focuses on governance and making the rules without actually being part of executing those roles, you’re dealing with an ITA (Ivory Tower Architect) —which is by the way the biggest risk ahead of Staff+ engineer positions.
May signal a rule-oriented rather than outcome-oriented mindset.
Doesn't acknowledge team autonomy and different contexts.
Misses opportunity to understand how standards evolve.
✅ Effective Questions:
How are technical standards or best practices developed and adopted across the organization?
What balance have we found between team autonomy and technical consistency?
How do we measure and improve the adoption of shared architectural principles?
2. Product and Business
Current Priorities
❌ "What should I work on first?"
Puts the burden of your direction on someone else.
Signals passivity rather than strategic thinking.
Doesn't demonstrate awareness of organizational goals.
Misses opportunity to show you've done homework on priorities.
Positions you as waiting for direction rather than driving impact. As senior IC role, you are expected to navigate the ambiguity and be self-motivated to focus on what matters.
✅ Effective Questions:
What are the organization’s top priorities this quarter (e.g. OKRs), and how do they align with broader company and business goals?
I've reviewed our roadmap and am particularly interested in [specific area]. How do we assess someone in my role contributing most effectively to this priority?
What technical capabilities would unlock the most value for the business in the next 6-12 months?
Business-Technology Symbiosis
❌ "Does the business side understand what we do?"
Creates an us-versus-them division between technical and business teams where in reality, there should be a strong connection and symbiosis.
Assumes lack of understanding rather than different perspectives.
Places blame rather than seeking shared understanding.
Doesn't acknowledge your role in bridging potential gaps. Senior IC positions have a key role to play to bridge that gap. And that question doesn’t give a proper answer about the width of that gap.
Frames technical work as separate from business outcomes.
✅ Effective Questions:
How do we ensure business and technical priorities remain aligned as we scale?
What have been effective ways to translate between business needs and technical solutions?
How do senior ICs contribute to shaping business strategy, not just implementing it?
Product/Tech Strategic Alignment
❌ "Why are we focusing on this instead of that?"
Challenges current priorities without understanding context.
Positions yourself as questioning leadership decisions immediately.
Creates an adversarial dynamic.
Suggests you think current priorities are wrong. We’re not aiming to normalize self-censorship, but when you’re new at the company and haven’t built credibility, you may first want to focus on delivering on some of the existing priorities before challenging the system from the get go.
✅ Effective Questions:
How do our current technical investments align with the company's strategic direction over the next 1-2 years?
I'm curious about how technical strategy gets developed here—how do product roadmaps and technical roadmaps influence each other?
What business outcomes are we trying to achieve through our current technical priorities? (note: instead of sharply piercing the prio list, this question is inviting to connect them to what matters to the business model)
Measuring impact
❌ "How do I prove I'm adding value?"
Focuses on personal validation and seeking approval rather than organizational impact.
Reveals insecurity rather than confidence. Please note that our goal is not to fool those who confuse confidence for competence. If you’re not confident but honest, that’s OK. But asking so bluntly sends the wrong signal and confuses people about what your role actually means.
Frames contribution as something to prove rather than deliver. The results should speak for themselves.
Doesn't acknowledge different types of value senior ICs can provide.
Misses opportunity to understand success metrics.
✅ Effective Questions:
How is success typically measured for initiatives at my level, both in the short-term and long-term? (note the subtle difference: “initiatives at my level” vs “me”)
What types of impact have other senior ICs had that were particularly valued by the organization?
Beyond direct technical contributions, how do you evaluate the effectiveness of senior technical leadership? (note: technical contribution can be to code, design systems, introduce new tools, and even write/present ideas that lifts the level of the organization)
3. Operation and Culture
Previous Initiatives
❌ "What projects have failed here before?"
Focuses exclusively on failure rather than learning. It is easy to call out failure in retrospect, but when the decision was made, it was probably not that obvious given the circumstances and people involved.
Uses charged language ("failed") that may make people defensive. Instead of trying to look smart by calling out other people, focus your attention on the learnings.
May come across as judgmental of past work.
Shows no interest or acknowledgement to successful initiatives.
✅ Effective Questions:
Could you share examples of previous technical initiatives that either succeeded or faced challenges, and what we learned from them?
What patterns have we noticed in projects that gained strong adoption versus those that didn't achieve their intended impact?
I'd love to understand our technical journey—what major shifts in direction have we made over the past few years and why?
Working Style
❌ "Do people work late here?"
Narrowly focuses on hours rather than overall work culture. For knowledge work, productivity (
output/input) is notoriously hard to measure. Not all hours are equal.Could be interpreted as wanting to do minimal work. Could signal concern about work-life balance before even starting. While this balance is important, my experience as Staff+ across different organizations shows that the extra autonomy and higher expectations complement each other. The balance is more influenced by the internal drive than external expectation.
Doesn't effectiveness (doing the right thing) and impact on business bottom line through increasing revenue or reducing expenses.
Misses opportunity to understand different working styles. Many companies for example of Flexible Schedule where the employee can get the job done at their own pace even if it means resting during standard office hours and working outside those hours. As a parent, I appreciate this degree of flexibility, but it also requires discipline to not mix personal and professional life —again, as a senior IC, you’re supposed to know how to manage your time.
✅ Effective Questions:
What working styles have we found most effective in this environment, and how do successful senior ICs typically operate?
How does the team balance deep focused work with collaboration and meetings?
What communication norms and expectations should I be aware of as I join the team?
Organizational Learning
❌ "Does the team repeat the same mistakes?"
Creates a yes/no question instead of inviting detailed context.
Implies judgment about team's ability to learn. Assumes negative patterns without evidence
Positions yourself as an outside critic. If you continue that route, you’ll be cast out and lose the influence that is required to deliver more than one person (my definition of leadership: “Leadership is the ability to deliver more than any single individual is capable of”)
✅ Effective Questions:
How does the organization capture and apply lessons from previous technical challenges or incidents?
What mechanisms exist for sharing knowledge and learning across teams?
How do retrospectives or post-mortems influence future technical decisions?
Knowledge Sharing
❌ "Why isn't there better documentation?"
Assumes current documentation is inadequate. While that might be the case, as a senior IC role, you’re expected to roll up your sleeves and fix the problem instead of stopping at finger pointing.
Doesn't acknowledge trade-offs in maintaining documentation. Every word has a cost to write, edit, keep up to date, find, and read. The documentation may be just enough, because the code compliments it for its primary users.
✅ Effective Questions:
What knowledge-sharing practices have been most effective across the engineering organization?
How do you balance documenting systems versus building personal connections for knowledge transfer?
What opportunities exist for me to contribute to our collective technical understanding and documentation?
Executive Communication
❌ "How technical are the executives here?"
Can be interpreted as judging executives' capabilities.
May suggest unwillingness to adapt communication style. Although the best engineering leaders are technical (and your role may be an anti-pattern to cover their lack), you should probably stay clear from this kind of question where the answer can be very subjective.
✅ Effective Questions:
"ow do senior technical leaders typically engage with executives on technical matters?
What formats work best when communicating complex technical concepts to leadership? (for example: some companies run on PowerPoint and discussions behind closed doors while others rely on written text)
How involved are executives in technical decision-making, and at what threshold do issues escalate to their attention?
Growth Opportunities
❌ "What do I need to do to get promoted?"
Focuses on advancement before demonstrating value.
May appear presumptuous early in your tenure. This is especially tricky when the company is not growing and fails to prioritize employee growth accordingly.
Suggests primary motivation is personal advancement. While it’s true that no one cares more about your growth than you do, adding a few words, you can make it less personal and gain broader perspective.
Many companies use a Y-shaped career ladder where above a level, you get to continue as IC or manager. The promotion criteria beyond that level is often vague and subjective. Instead of focusing on the word “promotion”, you can ask about how impact is assessed.
✅ Effective Questions:
How do senior ICs typically grow their impact and influence within the organization over time?
What opportunities exist for technical leadership outside of people management roles?
How does the organization support continued learning and skills development for experienced engineers?
What mechanisms does the company use to map individual growth with the business growth?
Driving Change
❌ "How do I get other teams to adopt my ideas?"
Frames adoption as producer-consumer rather than a dialog and collaboration.
Positions your ideas as inherently worth adopting.
Focuses on personal evangelism rather than collective evolution.
May signal overconfidence before understanding organizational context.
✅ Effective Questions:
How do technical initiatives that span multiple business units typically get coordinated?
What governance structures exist for platform or foundational technologies?
What approaches have been most successful for driving organization-wide technical improvements?
Career Growth
❌ "Why aren't there more senior engineers on the team?"
Implies judgment about team composition. Promotion and hiring are hard to get right. In many cases, there’s a mismatch between people’s formal level and their impact. It’s not ideal but it’s very common.
Positions experience level as the primary value metric.
Could be demoralizing to current team members who are mis-leveled.
Pulling ranks may also put the other engineers in defense mode and severely reduce your influence and ability to drive change.
Doesn't acknowledge diverse forms of contribution.
✅ Effective Questions:
How are technical mentorship relationships structured here?
What opportunities exist to help grow and develop the technical skills of engineers across experience levels?
How do senior ICs typically influence technical practices and standards while empowering others?
Decision Making Process
❌ "Who do I need to convince to get things done?"
Frames relationships as transactional or manipulative.
Focuses on convincing rather than collaborating.
Suggests bypassing proper processes.
Overlooks the importance of building consensus.
Signals potential disregard for team dynamics.
✅ Effective Questions:
How are technical decisions typically made here? Who are the key stakeholders for different types of changes?
Could you walk me through the process for proposing and implementing significant architectural changes?
What's been your experience with the most successful cross-team technical initiatives? How did they navigate decision-making?
Information sharing
❌ "Do people actually read the documentation here?"
Contains a negative assumption about current practices.
Uses actually which signals skepticism.
Invites a yes/no answer rather than useful context.
Can be perceived as judgmental about team habits.
Misses opportunity to learn about effective communication strategies.
✅ Effective Questions:
What communication channels work best for different types of information sharing? How do teams stay aligned on technical changes?
How is technical knowledge typically documented and shared across the organization?
When proposing a significant technical direction, what formats and forums have you found most effective for building alignment?
Resources and Support
❌ "What's the budget situation?"
Vague and lacks context for why you're asking. It may appear to be fishing for sensitive information.
Doesn't specify what resources you're interested in.
Misses opportunity to discuss alignment with business priorities.
Focuses on constraints rather than possibilities.
✅ Effective Questions:
What resources are available for exploring improvements or innovations in our technology stack?
How does the team typically approach experimentation and prototyping new solutions? (note: this is clever because it works around the budgeting constraints and focuses on smaller experimentation rather than big bang changes)
What's the process for securing resources for technical initiatives that weren't initially in the roadmap?
4. People and networking
Informal Hierarchy
❌ "Who has the real power here?"
Suggests focus on politics rather than collaboration.
Implies distrust of formal organizational structure.
Uses loaded term real power which can sound manipulative.
May make the respondent uncomfortable discussing informal dynamics.
Positions relationships as power-based rather than collaborative.
✅ Effective Questions:
Beyond the formal org chart, how do ideas typically gain traction and support in the organization?
How do successful technical initiatives usually build momentum across teams?
What approaches have you seen work well for gathering feedback and building consensus around architectural changes?
Key Relationships
❌ "Who are the most important people I should know?"
Reduces relationships to hierarchical importance.
Suggests networking for political purposes.
Lacks context about why relationships matter.
Doesn't specify what kind of knowledge you're seeking.
May come across as calculative rather than collaborative.
✅ Effective Questions:
Which individuals or teams would you recommend I connect with to better understand our core systems and processes?
Who are the domain experts I should consult when working on [specific area of the system]?
Which team members have historical context that would help me understand why certain architectural decisions were made?
Team Collaboration
❌ "Which teams don't work well together?"
Focuses on negative dynamics rather than constructive patterns.
Invites gossip rather than understanding.
Can make the respondent uncomfortable sharing sensitive information.
Doesn't acknowledge your role in improving collaboration.
May position you as someone who focuses on problems not solutions.
✅ Effective Questions:
How do cross-functional teams typically collaborate on projects, and where do you see opportunities to improve this collaboration?
What collaboration patterns have been most successful for complex projects that span multiple teams?
As a senior IC, how can I best contribute to strengthening cross-team relationships and technical integration?
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
The simplest way to support me is to like, subscribe and share this post.
If you really want to support me, you can consider a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections and my online book Reliability Engineering Mindset. You can get 20% off via this link.
You can also invite your friends to gain free access.
And to those of you who support me already, thank you for sponsoring this content for the others. 🙌 If you have questions or feedback, or you want me to dig deeper into something, please let me know in the comments.