• The challenges teams face when technical work is mislabeled as "BAU" or overshadowed by reactive and support tasks.

• A practical framework for categorizing work into Strategic, Reactive, and Production Support to prioritize effectively.

• How tracking work allocation data can drive continuous improvement, elevate technical work, and inform smarter planning decisions.

Uncovering the Challenges

The journey began with mounting frustrations among teams. Engineers often expressed how business, product, and operational demands overwhelmed their ability to focus on technical investments. Much of the work fell into the reactive category, such as minor escalations or on-call firefighting, leaving little room for innovation or addressing technical debt. This operational burden signaled a deeper issue: technical work was often categorized as "Business As Usual" (BAU) rather than as strategic investments worthy of prioritization.

Initially, we identified two primary challenges:

• Neglected Technical Improvements: Efforts to reduce technical debt, optimize processes, or enhance tooling are often deprioritized due to unclear work categorization.

• Operational Overload: Teams frequently face heavy operational demands, leaving little capacity for strategic or technical improvements.

As the conversation progressed, we uncovered additional systemic gaps that further complicated the situation:

• Inconsistent Terminology: Different teams use terms like "BAU" (Business As Usual), "KTLO" (Keep the Lights On), and "Operational Work" in varying ways, leading to confusion and misalignment.

• Poor Capacity Planning: Without a shared understanding of work types, resource allocation during quarterly planning becomes inconsistent, leading to overcommitment or imbalances.

• Limited Retrospection on Execution: Teams struggle to evaluate how much time and effort are spent on different work types, hampering continuous improvement efforts.

By addressing these challenges through a shared framework for classifying work, teams could finally align priorities, improve communication, and lay the foundation for better planning and execution.

Definitions of Work Types

Inspired by this post, this post, and the book The Phoenix Project, we developed the following definitions:

• Strategic: Strategic work involves deliberate, long-term planning to achieve overarching goals. This type of work is primarily planned and well-defined. Meaningful technical improvements cannot be achieved by small, arbitrary allocations like "20% of a team's time"; they require deliberate investment to ensure impactful results.

• Reactive/Tactical: Reactive/Tactical work is primarily unplanned and originates from the business or product. It addresses immediate needs or shorter-term goals.

• Production Support: Production support refers to tasks that maintain the reliability and stability of live systems and handle customer escalations.

Work Type Classification Table

The initial baseline guidance for this framework was informed by conversations with industry peers who shared their experiences on "normal" work allocations.

Why does this work?

It improves flow. Like traffic lanes dedicated to different speeds, this establishes different allocations for work with distinct characteristics. Strategic work is like the express lane, ensuring high-impact initiatives reach their destination without unnecessary delays. Reactive work is the middle lane, handling faster-moving, unplanned tasks requiring attention. Production Support is the slow lane that keeps the system stable and addresses escalations.

By organizing work into these lanes, the framework achieves:

• Improved Flow: Work progresses more smoothly when resources are allocated according to clear priorities.

• Reduced Congestion: Teams can focus on high-priority initiatives without being constantly derailed by operational noise.

Aligning Work Allocation Guidance with Actuals

Overview

To better understand how well guidance for capacity allocation aligns with actual work distribution, teams were encouraged to track their activities sprint-by-sprint and conduct a summary review at the end of every quarter.

Approach

1. Classifying Work Types: During each sprint, label tasks or tickets with categories reflecting their nature, such as Strategic, Reactive, or Production Support.

2. Analyzing Distribution: Use sprint-level data and tools to quantify resources spent across Strategic, Reactive, and Production Support categories, culminating in a quarterly review for patterns and trends.

3. Documenting Findings: At the end of the quarter, convert findings into percentage allocations, aggregating sprint-level data for a comprehensive view. Provide context through examples of initiatives contributing to these allocations. The examples helped normalize definitions across teams.

Example Allocation Table

Leveraging Data for Future Planning

Using data collected through sprint-by-sprint tracking and quarterly reviews, teams can directly address the challenges outlined earlier:

• Aligning Engineering with Business Strategy: Insights from work allocation data help justify investments in automation and tooling, demonstrate how engineering efforts align with business goals, and foster stronger stakeholder alignment. Patterns in reactive and support work also justify targeted investments to free capacity for innovation and reduce firefighting.

• Proposing Targeted Investments: Patterns in reactive and support work justify investments in automation, tooling, or even bringing in contractors to handle operational tasks. This approach frees capacity for innovation and reduces firefighting, enabling teams to focus on strategic goals.

• Balancing Workloads and Priorities: Analyzing resource allocation helps reduce operational strain, address reactive and support tasks, and prioritize technical improvements. It also enables more realistic planning cycles and balanced workloads across Strategic, Reactive, and Production Support tasks.

By tying these insights back to the challenges of operational overload, neglected technical work, and poor capacity planning, teams have seen encouraging success in driving continuous improvement and aligning with organizational priorities.

"Honest disagreement is often a good sign of progress." - Mahatma Gandhi.

As you begin to manage managers, your job changes from focusing on individuals within a team to supporting managers to deliver broader outcomes successfully. Your role is to facilitate clear, effective communication to maintain a high degree of alignment between managers within your team (say, Engineering Managers in your organization) or between managers across different functions (say, Engineering Managers, Product Managers, and Designers). Every once in a while, these folks end up with differing opinions. If you haven't clarified to them how to escalate these situations, it leads to inaction, inefficiency, and deterioration in team culture.

In this post, we will discuss:

• Why clean escalations are necessary?

• How to escalate cleanly?

• Tips for escalators

• Tips for decision-makers

Why clean escalations are necessary?

• Faster decision-making: Having a defined escalation path can help make decisions quickly in the face of competing paths of execution or approaches to design. By knowing who to contact and when, debates can be escalated to the appropriate level of authority or expertise, which can help speed up the decision process.

• Improved Communication: Clear escalation paths can enhance communication between teams, departments, and stakeholders. By knowing the communication channels and expectations for collaboration and resolution at each level of escalation, everyone involved can stay informed and avoid misunderstandings.

• Empowerment and Accountability: Clear escalation paths can empower team members to take ownership and help hold individuals accountable for resolving them. By having a defined escalation path, team members know when and how to escalate, which can help to promote a culture of ownership and accountability.

• Reduced confusion and chaos: With a clear escalation path, team members know who to contact or what steps to take when a situation arises.

• Continuous Improvement: Clear escalation paths help identify improvement areas in processes, procedures, and communication. By regularly reviewing the escalation path and analyzing the reasons for escalations, organizations can identify areas for improvement and make adjustments as needed.

Escalating Cleanly 

• Figure out who you'll be escalating to. Use RACI, DACI, RAPID, or any other framework if necessary. It doesn't matter which one you use since any of these will drive clarity.

• Let the other party know you intend to escalate. E.g., "It looks like we still see things differently. I want to escalate this. Would you like to be part of that conversation?”

• If you and the party you disagree with are from different functions, escalate to the next higher level of the respective functions simultaneously.

• Sometimes, you may not be comfortable with escalating together. That is okay! This should be the exception, not the norm.

• If your first level of escalation is enough to resolve the differences, great. If not, escalate up to the next level. This continues until the differences are resolved. In my experience, most escalations get resolved within two levels of escalations.

• Gathering all the necessary information to make the most informed decisions is essential. When dealing with escalating parties, decision-makers may have to request more information to understand the situation entirely. You may feel like you are being "interrogated." However, we must know that the decision-makers are simply trying to gather as much information as possible to make the best decision possible. To help smoothen this, come prepared with different options and their pros and cons.

• If you don’t agree with the decision made, disagree and commit. Once the decision is made, everyone is dedicated to making it succeed. You shouldn’t actively undermine the decision once people have committed.

Escalators

• Things to try to resolve before needing to escalate

  • Understand who is affected by what you’re doing and seek to align with them as early as possible.

  • Always assume good intent from all parties. 

  • Seek to understand the other person’s point of view. A little empathy can go a long way in preventing the escalation from happening. 

  • If you have a differing opinion with someone, switch roles with them and then debate again!

• When all else fails, go for a quick, clean escalation.

• Avoid continuing to argue until everyone agrees. “You’ve worn me down” is a suboptimal decision-making process. It’s slow and de-energizing.

• Avoid one-sided escalations. One-sided escalations can cause you to lose the other person's trust. Remember, trust is built in drops and lost in buckets.

• Escalations are simply a means of ensuring global optimization rather than local optimization. Please do not use them as weapons.

• Escalations are a tool for resolving differences quickly. If you need time to gather critical information, that’s okay; do not let it drag on.

Decision Makers

• Backchannels and one-sided escalations further deteriorate trust. If people come to you individually, suggest they escalate together. You must build trust and remain neutral until you have all the information.

• Be very clear about the timescale for the decision. Your job is to make decisions quickly.

• Communicate a change in decision clearly. If people have committed to a course of action and you change course, you’ve undermined everyone involved. There may be times when new information arrives that renders a decision obsolete. Your job is to communicate clearly what new information led to a change in decision.

Sources and other reading material

Atlassian's Playbook on Clean Escalations
How do you resolve conflict in just five days?
Escalations
How do we escalate disagreements cleanly?

In this post, we will discuss:

• A four-step workflow—Capture, Organize, Engage, and Reflect

• Tools and Methods

• Workflow, Tools and Methods in Action

• Getting started on building your system

Workflow

This workflow is an adapted version of the system behind Getting Things Done (Capture, Clarify, Organize, Review, Engage) and Building a Second Brain (Capture, Organize, Distill, Express).

Capture

Set up your system so that capturing relevant information is quick and frictionless. Don't think a lot about what you are capturing. It can be a stream of thoughts, ideas, inspiration, articles to read, etc.

This is because our brains go through what is called the Zeigarnik effect. It postulates that people remember unfinished or interrupted tasks better than completed tasks.

“Your mind is for having ideas, not holding them.” – David Allen

Todo-list applications like Todoist, Things give you features that help you capture tasks in a frictionless way. Applications like Reader provide extensions to your browser and mobile devices so you can capture reading material quickly.

Organize

Areas, Goals, and Projects

• Areas are dedicated spaces for every significant long-term aspect of your life. Some examples are Career/Work, Home, Family & Friends, Health, Wealth, Growth/Learning, etc.

• Goals: You will have goals you want to achieve in each identified area.

• Projects: These are the things you do to achieve your goals.

Make sure to organize everything around your goals. If your "goal" is to get promoted, lead high-impact "projects" that are in your "Work & Career" area. If your "goal" is to lose weight, your "projects" would be to run/walk daily and eat healthy to maintain a calorie deficit. This would be in your "Health" area.

Use systems like prioritization techniques like Eisenhower Matrix, LNO framework, The Daily Trifecta, Hell yeah or no, etc.

Engage

This is the do part of the workflow. Seek to optimize for deep work using the tools at your disposal. Use methods like Time Blocking, Pomodoro Technique, Eat the Frog, etc.

Reflect

On a regular cadence, review and reflect. You review your emails, messages, tasks, thoughts, and ideas, as well as the system.

When you review your emails, messages, tasks, thoughts, and ideas, tag them appropriately and add context for your future self or archive what doesn't need to be followed up. Use methods like Inbox Zero for your email, messages, and tasks. Develop habits like journaling and note-taking for your thoughts and ideas.

Reflecting on your system is vital. This is when you adjust your workflow to your needs and preferences.

Tools and Methods

Remember, tools and methods should be adapted to your needs, not the other way around. Don't hesitate to experiment, mix and match, and even switch between digital and analog, depending on the task. Here are some tools and methods for you to explore:

Workflow, Tools and Methods in Action

Task Management

While I have previously used Things for task management, I currently use Todoist.

• Capture

  • I use Todoist's quick add shortcut and natural language detection to capture my tasks in the Inbox quickly.

• Organize: During the organization process, I:

  • place these tasks into specific projects.

  • apply the Eisenhower Matrix to prioritize my tasks and use the “leverage“, “neutral“, and “overhead“ labels to apply the LNO framework.

  • tag tasks that can be done quickly with a "quick" label.

  • use a "delegate" label on the tasks I need to delegate and remove them from Todoist. I move them to Notion with the name of the person I delegated to and the date so I can follow up promptly.

  • use "someday" and "bucketlist" labels for things I want to keep around and delete tasks I don't intend to do.

• Engage

  • I use the Time Blocking method and Focus Modes (a feature in the Apple ecosystem) to focus deeply.

• Reflect

  • Daily, I clear out my Inbox. This is where I Organize. Every week, I plan my tasks for the week. I use Google Calendar's Focus Time to keep my calendar free and use Todoist's integration with google calendar to place my tasks into those specific focus time slots. I do not slot tasks that are labeled "quick."

Reading and Retention

Tools of choice that assist my reading and retention are Goodreads, Reader, Audible, Kindle, Substack, Shortform, and Readwise.

• Capture

  • I use Goodreads to keep a list of books I want to read.

  • I use Reader extensions for my browser (Arc) and phone to capture web articles I want to read later.

  • I have also set up Substack RSS feeds on Reader. So anything published by people I follow on Substack appears on Reader.

• Organize

  • On Reader, I clear out the Feed and Inbox regularly. I move them to the "Later" or "Archive" sections. Reader app has features like Daily Digest that help me stay caught up.

  • I label articles accordingly.

• Engage

  • I use Reader, Kindle, and Audible to read.

  • On Reader as well as Kindle, I highlight and label.

• Reflect

  • Readwise implements Spaced Repetition and presents some highlights daily for me to review. It also gamifies my reviews through its "streaks" and "leaderboard" features.

  • Readwise also syncs all my highlights into Notion and Obsidian, which I can later use for my writing if needed.

  • Shortform is a service that summarizes books. Re-reading the summaries keeps the concepts fresh.

  • I (try to) manually create notes in Obsidian for books that I “read“ on Audible.

Getting started on building your system

Planning your productivity system needs exploration and experimentation. Perfecting your system will take time. Here are some tips:

1. Explore and experiment, but start! Exploring a lot of tools & methods and finding what works for you will take time. Get started!

2. Prefer tools that integrate with each other: Use tools that integrate with each other so your workflow can be automated as much as possible.

3. Setup an "Inbox" in every tool and Organize on a regular cadence

4. Review the system regularly: Don't let your system get cluttered. Archive what you don't need. Adjust the system to your needs and preferences.

5. Trust your system: You will notice that the system will work for you over time. Your energy should solely be focused on keeping the system running.

6. Do not over-index: The goal is not to do everything but to do important things. It is crucial to prioritize self-care, establish clear boundaries, and periodically reassess goals to ensure they align with overall health and happiness.

In this article, I cover:

• What is glue work?

• Examples of glue work

• Glue work in individualistic cultures

• Too much glue work

• Promoting glue work

What is glue work?

Glue work refers to tasks or activities that connect different parts of a project or team. Glue work is required for a project to be successful because it helps ensure that all the individual pieces of the project work together seamlessly and efficiently. Projects are often complex, with multiple moving parts, different teams or stakeholders involved, and various systems or technologies that must be integrated.

Beyond a particular project, glue work helps, well, "gluing" different teams together. At work, the drive to bond accounts for the enormous boost in motivation when employees feel proud of belonging to the organization and for their loss of morale when the institution betrays them. It also explains why employees find it hard to break out of divisional or functional silos: People become attached to their closest cohorts. The most effective way to fulfill the drive to bond—to engender a strong camaraderie—is to create a culture that promotes teamwork, collaboration, openness, and friendship. Source

Examples of glue work

Here are examples of glue work that apply to software engineers:

• Taking on the role of a technical lead or a feature lead. Such a role has leadership, project management, and collaboration aspects.

• Reviewing technical design documents and providing meaningful feedback commentary pointing out gaps, suggesting alternative solutions

• Recognizing people both in private and public forums

• Promoting pair programming and mob programming within teams

• Helping other engineers when they are stuck

• Mentoring other engineers

• Onboarding and accelerating productivity for new team members

• Improving team processes or processes that make customers happy

• Answering questions from business or operations teams

• Participating in company or department "Lunch & Learn" events

• Participating in or leading different committees and communities within the company, technical or otherwise

• Participating in interviewing loops and recognizing areas of improvement

• Playing an active role in paying technical debt, improving observability, and documentation, etc

• Organizing team get-togethers, game nights, focus weeks, launch celebrations, etc

Note: Some of these may already be in your job descriptions/leveling guides and expected in your role as an engineer.

Glue work in individualistic cultures

While individualistic cultures tend to place more emphasis on personal achievement and individual success, successful projects and organizations still rely on effective teamwork and collaboration. Glue work can be even more important in individualistic cultures, where there may be a greater emphasis on individual autonomy and less on collective responsibility. In these cultures, creating a sense of shared purpose or community may be more difficult, making glue work even more crucial for ensuring that everyone is aligned on project goals and that communication channels are open and effective.

Too much glue work

Like all things, it is about balance. While glue work is essential for the smooth functioning of a team or project, it should not be encouraged by a manager as a primary focus for team members for several reasons:

• Limited growth and development: Being seen as "less technical": Tanya Reilly writes about issues engineers could face for Being Glue. I strongly recommend this article to engineers, particularly senior engineers or engineers who want to become more senior.

• Time and resource wastage: Spending too much time on glue work can distract team members from the project's primary goals and take up valuable time and resources.

• Low job satisfaction: Team members constantly bogged down with glue work may feel that their skills are not fully utilized, leading to low job satisfaction and disengagement.

Therefore, while glue work is necessary, a manager should ensure that team members can handle it and that it is balanced with technical work that contributes directly to the success of the project as well as the career growth of the individual.

How can managers promote glue work?

• Set expectations: Managers can set clear expectations for glue work and make it part of team members' job descriptions and performance evaluations. This can help ensure that team members understand the importance of glue work and are held accountable for their contributions.

• Recognize and reward glue work: Managers can acknowledge and appreciate the glue work that team members do by highlighting it in team meetings, offering public praise or recognition, or even rewarding team members for their contributions.

• Create opportunities for collaboration: Managers can promote glue work by creating opportunities for team members to collaborate and work together on projects. This can help build stronger relationships and improve communication and teamwork.

Let us take a look at three fictional scenarios at Acme, Inc:

1. Isaac, Roxanne, and Yasir worked as a remote team for over three years. Robbie joined the team four months ago but struggled to gel with the team. The rest of the team thinks he is less responsible. He doesn’t respond to pages while on-call as quickly as the others do and is not as responsive as the others on Slack. They all talk to Donna, their manager, about Robbie’s engagement.

2. The Personalization team doesn’t trust the Growth team to change the codebase. The last time the Growth team made changes, they introduced bugs in production. While the Personalization team struggled to resolve the issues, the Growth team didn’t help.

3. The Marketing and Product teams are not operating in lock-step with each other. While both departments are working toward fueling growth in the company, the groups, and their leaders don’t interact much. Their planning and delivery cycles are out of sync.

One common theme across all of these scenarios is that people need a shared understanding of how to work with each other. An agreement typically consists of who is going to do what by when. It is a simple idea. We waste an obscene amount of time and energy because of unclear and unkept agreements.

You know what I'm talking about if you have been in team meetings like this.

Isaac: “I expected your technical design document to contain the non-functional metrics as well as the call flows”

Robbie: “No, no, I never said that. We were going for a general outline of how it would work.”

The real problem is people. People weren’t aligned. People weren’t supported. People weren’t bought in. In order to make transformation, the culture has to shift to allow for it. This is why culture eats strategy for breakfast.

Sarah Drasner in Engineering Management for the Rest of Us

Fun fact: Peter Drucker, one of the most influential management thinkers, gets famously attributed to the quote, “Culture eats strategy for breakfast/lunch,” but he never said it! Source 1 Source 2

Sometimes an organization doesn’t need a solution; it just needs clarity.

Ben Horowitz in The Hard Thing About Hard Things

Clear Agreements

Clear agreements help drive clarity, improving communication, accountability, and team dynamics. A high-functioning team makes clear agreements, keeps them, and lets the other party know when they cannot keep it so they can renegotiate. Lastly, if they break it, they take responsibility. The first key to being impeccable with your agreements is to make clear agreements. Who is going to do what, and by when? So simple.

Decision-Making Frameworks

Decision-making frameworks address the “who” part of an agreement when a group of people is involved. There are frameworks out there, and much literature exists on this topic. We won’t be going into more detail. Pick a framework that works for you and use it consistently.

Some popular frameworks:

• DACI

• RACI

• RAPID

• SPADE

Let’s get into three situations where teams benefit from a written working agreement.

• Between the members of a team

• Between two teams; a “home” team and an “away” team

• Between departments

Team Working Agreement

Left to their own accord, most teams will develop a documented or undocumented working agreement during the norming stage of a team’s development cycle. Read Tuckman’s stages of group development.

I recommend managers start thinking about and looking to write a Team Working Agreement as soon as the team is forming so the storming stage is as controlled as possible (storming never really “ends” in practice). Writing working agreements is also particularly helpful when you want to reset a team’s culture and help new team members quickly understand the team’s culture.

Team values

Company values come first. The company’s values guide a team’s values. But a group might choose to extend the company’s values with what the individuals within that team value. This section should contain a bulleted list of the values that the team wants to embody.

Ways of working

This section should cover the things one would do to enact the values. For example, if the team values a blameless culture, they might act that value in team retrospectives, project/feature pre-mortems, and incident post-mortems.

Governance

Availability

• Hours

• How to Out of Office?

Communication

This section will go into what each other expects in different communication mediums. Things to think about:

• Team Report

  • Who is responsible for sending the team’s report?

  • How should each team member help in crafting it?

• Instant Messenger

  • Are the team members expected to appear online when they are available?

  • What is expected of them when they are “away”?

  • What is expected of them when you tag them during off-work hours or when they are OOO?

• Video communication

  • Is everyone expected to turn their cameras on?

• Google Docs & Confluence

  • Often, at companies, both tools are available. When do you use google documents, and when do you use Confluence?

Escalation process

Considering how the team will escalate when faced with a pressing issue that cannot be resolved through consensus is important.

The general playbook looks like this. All parties:

• Acknowledge the problem or difference in opinion

• Clarify the options and understand the trade-offs

• Determine who will be the decider; usually a manager or respective managers

• Determine how the escalation will be handled

• Determine what level of transparency will be provided

• Align how the decision will be communicated to others

Escalations are good! Clear escalation paths can be highly beneficial in resolving issues quickly. By using established escalation procedures, issues can be addressed promptly, avoiding lengthy alignment periods. Managers and leaders can play a crucial role in this process by encouraging team members to utilize escalation procedures and helping to reduce any stigma associated with doing so. Overall, well-implemented escalation paths can be a powerful tool for promoting timely issue resolution and maintaining productivity within a team or organization.

Roles and Responsibilities

A software engineering team has a Product Manager, Engineering Manager, Designer, and a team of engineers. Role expectations are usually well-defined within an organization.

However, Feature Lead or Tech Lead is typically unofficial, and the standard can vary between teams. Project management activities and testing activities are two other areas where the role and responsibilities aren’t clear for teams, primarily because of the absence of a dedicated project manager or scrum master in the case of the former and the lack of a dedicated QA engineer in the case of the latter.

Note: This example uses RACI as a decision-making method.

Project Management Process

Typically, most software teams follow an adapted form of Kanban or Scrum. This section is to clarify what the process looks like.

Meetings

On-call expectations

This section either contains the content or could link to another company standard document. It must include what is expected of them when they are on-call.

Address ambiguities like:

• Can they go out for dinner when they are on-call?

• Is it ok if they carried their laptop and had access to the internet so they can triage issues?

• Can they have a beer when they are on-call?

SLAs

A working agreement can have anything that improves communication, collaboration and team dynamics. Some of the interesting ones that I have seen:

• How to spell E-commerce?

  • ✅ E-commerce, Ecommerce, e-commerce, ecommerce, ecomm

  • ❌ eCommerce, e-comm, ECommerce, e-Commerce, Ecommerce

• Standardized on a date format that the team would use!

Working Agreement between Teams

Software engineering teams frequently collaborate to achieve organizational goals. Collaboration between two software teams takes two forms:

• Collaboration: Two teams work with each other toward a common goal.

• Away and host team model: An away team is a self-sufficient engineering team that works on code owned by another team (the host team) to deliver features they are dependent on. The away team design and releases the needed changes in the host team services. The away team is working towards its own goals but needs assistance from a host team.

I have consistently seen friction between teams in the latter case. A working agreement between groups with a RACI will dramatically reduce that friction. Here is an example that could help drive clarity:

Working Agreement between Departments

Creating a working agreement between departments at a large company can be a complex task, but it’s essential for ensuring that teams can collaborate effectively and achieve shared goals. There are entire books written on how senior leaders should create alignment within an organization, but the key considerations carry through.

Key considerations:

• Communication: Establish clear communication channels and protocols for sharing information and updates between departments. Consider tiering your huddles. First, the front-line workers meet. If they can’t make decisions, the issue is escalated to the next level. Provide clear guidelines for escalations.

• Performance metrics: Establish performance metrics that align with the company’s goals and objectives and share them across all departments. Ensure that they are publicly and readily accessible. Use a well-known goal-setting process like OKR or 4DX. Companies inevitably develop “house rules” as they employ a well-known method. Make sure the “house rules” are documented.

• Shared goals and objectives: Identify shared goals and objectives each department can contribute to and ensure that everyone understands how their work contributes to the company’s overall success. Departments should focus explicitly on their “Shared OKRs” during yearly, half-yearly, and quarterly planning sessions.

• Roles and responsibilities & decision-making: When coming together to achieve a particular shared objective, define the roles and responsibilities of each department and the individuals representing that department.

  • Consider everyone’s input by establishing decision-making processes involving all relevant departments. Use one of the decision-making frameworks.

  • Make sure each department has an “Ownership Map” which ties specific areas within the department to individuals accountable for those areas and then make it publicly accessible. Having a map dramatically reduces the number of “Who is responsible for X?” questions.

• Conflict resolution: Develop a strategy for resolving conflicts between departments that allows for open and honest communication and encourages collaboration and compromise. Conflict resolution begins with creating psychologically safe spaces for people to bring up issues. Pre-mortems, post-mortems, and retrospectives are examples of some of those safe spaces.

Summary

Organizational productivity is about your systems, not individual people. If a whole group doesn’t understand how to work with each other, it’s likely because their managers and leaders have not set up mechanisms like this.

A common argument for not doing something like this is, “Once it’s written, no one ever looks at a working agreement. It’s a waste of time”. The process of writing together will help form the norms and alignment necessary. It’s a problem when people agree to work a certain way but don’t follow through. When people deviate from their agreements, as managers and leaders, you refer back to the working agreement, diagnose what is not working, and take action, even if that means you need to modify the working agreement. Working agreements, when appropriately used, help build the culture of teams, departments, and organizations.

Before the call

Prepare. You get to pick who you work with. Before the meeting, take the necessary time to learn more about the candidate. Go through their resume, cover letter, LinkedIn profile, or other sources like their blog, Github, etc. Learn about their interests, biases, past jobs, and the cultures at those companies.

During the call

Ask them what they care about most and answer their questions. I used to ramble on about what I thought they would want to hear without giving them a chance to ask their questions. I now start the call by asking, “What are the top two or three things that you care about most at this point in your career so I can best tailor my answers.”

Most candidates want to know the following things. Be prepared to answer them. But like I said earlier, expect to tailor this answer to them.

• Company culture

• Your management style

• What opportunities do they have to grow?

• How will they be challenged and recognized in their positions?

• Is Engineering at the table when making decisions?

• How is tech debt prioritized?

• Why did you join, and what keeps you there?

Tell the truth with a bit of positiveness. Refrain from falling into the trap of overselling the role.

• Your moral obligation is to give the candidate your realistic take on the position and the company. When talking about problems that exist, talk about how you would like to solve them and how they can help!

• You gain trust by being honest! Candidates feel much better about working with a manager who acknowledges problems. Keeping it real and “selling” the role are not mutually exclusive.

• Lastly, candidates are smart. They know when you are taking them for a ride.

Know the next steps. Usually, a closing call is the last step before the candidate makes a decision. Every situation is different. Be in line with your recruiter on what the next steps are and communicate them clearly to the candidate. Let them know they can converse with more folks before making a decision.

After the call

Nothing to do but wait. Don’t take it personally if candidates don’t accept. It feels like you lost a deal when someone does not join even after you “sold” to them. They consider numerous parameters beyond your control before accepting an offer. It is a profoundly personal decision.

Other tips

• If you consistently struggle to hire senior+ level candidates, it is likely because they haven’t found the role challenging. Either you need to explain where the complexity is or question whether a senior candidate is necessary to fill the position.

• Candidates try to find as much information as possible before accepting an offer. Put your team’s work out in the world. Write posts on your company’s blog, and speak at conferences and meetups. They are surprisingly helpful in closing.

• If you have an effective internal mobility program at your company, talk about the process and how other folks have successfully navigated through it. Knowing that they can change teams easily if it doesn’t work out comforts candidates.

Inspired by Will Larson’s post on Closing Calls: tell the best version of the truth

An excellent way to think about this is to invert the issue at hand. When you have a poor relationship with your manager, you probably talk less to each other. This means you get little advice on your personal development and career growth and little information about what is going on across the company. This significantly decreases your chances of influencing your company. Now, let's flip this. By maintaining a good relationship with your manager, you are privy to valuable information, get the resources and advice you need to excel, and have an influence.

In the piece What holds people back, Shane Parrish says:

When we think of improving our value to an organization, we often think about the skills we need to develop, the jobs we should take, or the growing responsibility we have. In so doing, we miss the most obvious method of all: reducing friction.

He gives this example. If John and Jane have a boss who spends more energy trying to get John to do something than Jane, it's obvious who will get ahead and who will be let go when it's time to cut one of them.

Let's take this idea a step further. Managing up is much more than reducing friction. It's about creating a symbiotic relationship with your manager so that you both can succeed in your roles.

Maintaining a great relationship with your manager is easier said than done. They are trying to be your coach and evaluator simultaneously, making it hard to tell which role they are playing when talking to you. Every manager is different and brings different baggage with them.

Your relationship with your manager is one of mutual dependence. You need your manager to succeed in your role, and they depend on your commitment to succeed. Your manager is human, too (some have argued otherwise!) – they have aspirations, frustrations, strengths, weaknesses, and fears, just like you. Consider these questions carefully. Source: Managing your boss

Scenarios

I have pulled some of these scenarios from Design Patterns for Managing Up (some parts verbatim) and have added a couple of my own. It's important to remember that the scenarios are just a starting point and should be adapted to each unique situation. By considering the potential outcomes of each scenario, you can develop a plan tailored to the problem and help you achieve the best result.

Staying on the same page with your manager (literally)

The most common way to keep in touch with your manager is through 1:1s. These meetings cover various topics, such as updates on key projects, feedback, coaching, and support. However, some topics can be forgotten or not discussed.

Will Larson takes the idea of "Do not surprise your manager" a step further in this post, adding "Do not let your sponsor surprise you" and "Feed your manager's context.” One way to do this is the 15-5 document. The idea is that this document takes 15 minutes to write and 5 minutes to read and should be shared with your manager weekly. I have slightly modified Lenny's "State of Me" format (Twitter post).

An SVP asks you a question, and you do not know the answer

It can be challenging to admit it when you're put in situations where you don't know the answer. However, a senior individual usually asks questions out of genuine curiosity, not to test you. Here's what you should do instead:

• Admit you aren't certain

• Take ownership of finding the answer

• Give a timeline for when you'll follow up

• Provide a correct, concise, and thoughtful response

You think you are ready for a promotion

I used to think it was my job to do the work well and my manager's job to get me promoted. However, promotions at big tech companies take a lot of effort. Typically, a case must be presented to a committee of other engineering managers and directors (sometimes VPs for Staff+ roles). The case must include a lot of evidence. While most managers have a good idea of your significant contributions to major projects, they may need to be made aware of your day-to-day contributions. Managers will need your help gathering this evidence and will put in as much effort as you do in your promotion.

Promotions at senior levels (Senior Engineer, Staff+ Engineer) can take several quarters, halves, or even years. Avoid the expectation of instantaneous results. If someone pushes to get promoted quickly, it is often a sign of not understanding the expectations clearly.

Go to your manager well-prepared to have a deeper conversation. Write a document that contains all of your significant contributions. Some things to think about:

• What projects did you work on? What was your role? What was the impact? Why was it complex? What documents do you have?

• What did you do outside your immediate role expectations to improve the organization?

• Have you mentored others?

• Who can advocate for you?

You get negative feedback from your manager

Negative feedback can be challenging to receive. However, it is also difficult for your manager to give it. No one enjoys conveying bad news; some managers may even admit it before giving it. But, handling it correctly can create a positive encounter with your manager and be an opportunity to grow.

When receiving negative feedback, it's essential to remain calm. Focus on slowing your breathing, be aware of your heart rate, and keep your face relaxed. Then, say, "I hear you. I will be more mindful of that in the future."

If you would like more information to understand their perception or suggestions on how you can do better, ask. If you are calm at the moment, ask them immediately. If not, stop with those words, walk away, and follow up later.

There is a decision made that you disagree with

At work, there is no one-size-fits-all solution. It is not necessary to always agree with leadership decisions, but making the company as successful as possible is essential.

It is essential to take emotion out of the equation and wait a day or two to clear your head if needed. Instead of immediately disagreeing, ask about the context and reasons for the change. If you have a prior relationship with the primary decision maker, start with them. If not, start with your manager and escalate through the chain of command. Research and present alternative options that will achieve the same goals. If you cannot sway the decision maker, support the action plan. Be sure to share the context and reasoning with your team, and then do everything you can to improve the situation, such as helping the cause succeed or mitigating any fallout.

There is a problem that is your fault or responsibility

Funnily enough, this looks like incident management!

Let key people know and establish yourself as the owner. Share the next steps if you know them. If you don't know, share a time by which you can provide an update. Be as specific as possible. Communicate known unknowns. Give a timeline, what solutions you will try, and when to expect results.

You notice a problem or opportunity that is NOT your responsibility

There will be many problems that you encounter in your daily work. A shared understanding of your role expectations can help you understand your responsibility and what isn't. Many workplaces expect you to have a "Bias for Action,” encouraging you to have a sense of ownership in your work; if you notice a problem, you should take ownership of it until you find someone better suited to handle it.

When dealing with a problem, there are a few things to keep in mind:

• If you are working on something more substantial, take note of the problem and don't let it distract you. Let your manager know that a problem exists, but you have more important tasks to focus on now.

• When you are ready to tackle the problem, communicate with your manager in their preferred style (mine is generally a document). Describe the issue, identify a solution or approach (with multiple solutions considered), and consider any second-order effects.

• Finally, take ownership of the outcome.

Now that we have discussed some principles of managing up and how to apply them in everyday work situations consider how you would manage up in the following cases:

• Your peer is not contributing their fair share

• You wish to switch teams

Don't suck up! Manage up!