Are You the Boss They Celebrate When You’re Away?

How to build a team that values your presence, not one that feels relief when you are out of office.

Are You the Boss They Celebrate When You’re Away?
Sandeep Varma
10 min readApr 12, 2026
Are You the Boss They Celebrate When You’re Away?
Photo by Sandeep Varma on EMDock

I recently came across a comment that stayed with me for days. Someone wrote that the best two days of their professional life were when their boss went on vacation. There were no constant pings, no surprise status checks, no tension in meetings. Just uninterrupted time to focus and get real work done. If we are honest, many of us have felt that way at some point in our careers. I certainly have. Some of my managers were exceptional. Others were not. And on certain days, when a particular manager was out of office, the atmosphere felt noticeably lighter.

That realization led me to a simple but uncomfortable question. When I am on vacation, what does my team feel? If you are an engineering manager and you have never asked yourself that question, it is worth pausing and reflecting on it. The goal is not to build a team that tolerates you. The goal is to build a team that respects you both in front of you and behind your back. Respect is not built through authority alone. It is built through credibility, trust, enablement, shared responsibility, and consistency.

Technical Credibility Is the Foundation

Even though leadership requires strong interpersonal skills, as an engineering manager you cannot ignore technical strength. Your team needs to believe that you understand the domain, the architecture, and the tradeoffs involved in the decisions being made. When you speak in design discussions, your words should carry weight because they are grounded in understanding rather than hierarchy. If you are not technically credible, you risk steering the team in the wrong direction. Even worse, the team may follow you purely out of authority instead of conviction, which slowly erodes respect.

There is a short window where facilitation alone may be acceptable, particularly when onboarding to a new domain or inheriting a system you are still learning. In those moments, it is completely reasonable to stay out of the way and allow senior engineers to drive decisions. However, that window should not last indefinitely. An engineering manager who never builds sufficient technical context becomes indistinguishable from a pure project coordinator. At that point, the team might reasonably question the added value of the role. Technical credibility does not require writing production code every week. It requires understanding enough to ask meaningful questions, challenge flawed assumptions, and guide conversations in a way that improves outcomes. The question of how much to stay in the code is one many engineering managers wrestle with, and Should Engineering Managers Write Production Code? makes a direct case for where that line should sit.

That said, technical strength alone is not enough. If that is the only dimension in which you excel, you risk becoming a micromanager who overrides discussions and forces decisions. Respect does not survive in that environment either. An effective engineering manager must perform well across multiple dimensions.

Build Meaningful One on One Relationships

Teams operate as groups, but leadership is deeply personal. You cannot rely solely on group dynamics and expect respect to emerge organically. Individual relationships matter. When people feel understood, they engage differently. They are more open to feedback, more willing to challenge ideas constructively, and more likely to trust your intent during difficult moments.

One on ones are the primary mechanism for building this foundation. They are not status meetings. They are structured opportunities to understand motivations, frustrations, aspirations, and working styles. Through these conversations, you begin to understand who needs more guidance, who thrives on autonomy, who values recognition, and who prefers quiet ownership. These insights directly inform how you enable your team effectively. If you are looking for concrete ways to make those conversations more effective, How to Run 1:1s That Engineers Actually Look Forward To goes deep into structure, cadence, and what separates forgettable check-ins from trust-building conversations.

Enable Without Micromanaging

Enablement is where many managers unintentionally fail. Some engineers need more structure, particularly early in their careers. Others perform best with broad direction and significant autonomy. Applying a single management style to everyone is a mistake. If you are uniformly hands on, you will suffocate strong performers. If you are uniformly hands off, you may unintentionally abandon those who need support.

The relationships you build through one on ones give you the signal you need to adapt. Enablement means adjusting your involvement based on the individual while maintaining clarity of expectations for outcomes. It also means being intentional about how you request information. If your team feels relief when you are away because they are finally free from constant status pings, that is a sign that your process needs refinement.

Status updates should be structured and purposeful. Use standups, planning rituals, and documented reporting mechanisms to gather information. Avoid random interruptions that force context switching. Engineers often require deep focus to perform at their best. Repeatedly disrupting that focus for information that could have been collected more thoughtfully creates friction and resentment. The same principle applies to last minute requests. Emergencies are inevitable, but if everything feels urgent, the team begins to associate your presence with instability. Respect grows when people feel protected and supported rather than constantly interrupted.

Lead With Authority Sparingly

There will be moments when you must make the final call. External pressures, incomplete information, or time constraints sometimes require decisive leadership. However, these moments should be infrequent. If most decisions end with you declaring the outcome unilaterally, the team will eventually disengage. They may comply, but they will not commit.

Most of the time, you should operate as part of the team rather than above it. You wear the leadership responsibility when necessary, but your daily posture should feel collaborative. Respect deepens when people feel that you are building something together rather than issuing instructions from a distance. Authority used responsibly reinforces trust. Authority used excessively diminishes it.

Share Responsibility, Including the Unpleasant Work

Engineers are not always enthusiastic about documentation, compliance tasks, or security discussions. If you consistently delegate every unpleasant task away from yourself, the message is clear even if it is never spoken aloud. It appears as though you are protecting yourself from inconvenience while distributing it to others.

Occasionally stepping into these responsibilities yourself sends a powerful signal. Join the compliance call. Draft initial documentation. Handle the security review conversation. This is not about avoiding delegation. It is about demonstrating that no work is beneath you and that assignments are made thoughtfully rather than selfishly. Leadership is not about avoiding mundane tasks. It is about ensuring the right person handles the right responsibility for the right reason, and sometimes that person is you.

Be Missed for the Right Reasons

When you are on vacation, your team should ideally miss you because you contribute meaningfully. They should miss your clarity, your ability to unblock, your presence in difficult conversations, and your willingness to share the load. They should not miss you because approvals are trapped in your inbox or because critical knowledge exists only in your head.

There is an unhealthy version of being missed. That happens when control and information are concentrated so heavily in you that the team cannot function without your daily involvement. While that may feel validating, it creates dependency rather than strength. A strong engineering manager builds a team capable of operating effectively in the short term without them. Day to day execution should not collapse because you are offline. Your primary responsibility is long term direction, culture, and enablement. If operations depend entirely on your presence, you have built a bottleneck instead of a resilient team.

Final Thoughts

If your team secretly celebrates when you are away, the issue is rarely your vacation. It is how they experience you when you are present. Respect is earned when you are technically credible, when you invest in real relationships, when you enable rather than micromanage, when you use authority sparingly, and when you share responsibility rather than hoard it.

The ultimate measure is simple. When you are absent, does the team feel relief, or do they feel the absence of a valuable contributor? That distinction reveals more about your leadership than any performance review ever will.

I Would Value Your Perspective

How do you think about this dynamic in your own leadership journey? Have you experienced a manager whose absence felt like relief, or one whose absence revealed their true value? I would genuinely appreciate hearing your thoughts and experiences.

Enjoyed this post?

Comments

Loading comments...

Please log in to post a comment.

About the author

I write about leadership and software engineering through the lens of someone who’s worked as a software engineer, product owner, and engineering manager. With a Bachelor’s in Computer Science Engineering and an MBA in IT Strategy, I bring together deep technical foundations and strategic thinking. My work is for engineers and digital tech professionals who want to better understand how software systems work, how teams scale, and how to grow into thoughtful, effective leaders.

View full profile →
Continue reading
← Previous
The Real Meaning of Technical Debt in Software Engineering

Why software teams sometimes move fast with imperfect code and how responsible teams clean it up.

Next →
How Software Systems Scale: From One Machine to Many

From a single server to intelligent auto scaling, a practical mental model for how modern software systems grow with demand.

Related posts
Should EMs Code? A Balanced Perspective
Should EMs Code? A Balanced Perspective

An experience-driven argument for why writing production code often feels right in the short term, but quietly undermines the real responsibilities and long-term impact of engineering management.