Good Engineering Leadership Habits

Picture this: It’s 6 PM on a Wednesday, and you’re finally leaving the office after another “productive” day of back-to-back meetings, urgent emails, and crisis management. But as you’re commuting back, a nagging question surfaces: “What did I actually accomplish today that mattered?” If this scenario feels familiar, you’re not alone. The gap between being busy and being effective is a constant struggle for most managers.

I’ve discovered through trial and plenty of error that certain daily habits have become essential for wrapping up each workday with that rare sense of genuine accomplishment, you know, that feeling where even though you’re completely drained, you can honestly say you moved the needle for your team, your colleagues, and honestly, yourself as a leader.

Put the fish on the table

I really enjoyed Mark’s article on Awkward 1:1s. Since discovering it several years ago, it consistently emerges as one of my most significant leadership challenges. This also represents a recurring theme I frequently observe among emerging managers. The silent 1:1s. When I talk with new managers and ask them about their 1:1 experiences, the predominant response is “quiet” or “uneventful.”

Putting the fish on the table originates from the Danish workplace culture, where directness and transparency are valued over polite avoidance. When you “put the fish on the table,” you’re essentially acknowledging that there’s something that smells, something that everyone can sense but no one wants to address directly. This approach requires considerable courage from both the manager and the team member, as it means confronting uncomfortable truths that may have been lingering beneath the surface for weeks or even months.

Consider the practical implications: instead of discussing project updates that could easily be shared in a team standup, you’re diving into questions like “What’s preventing you from taking ownership of this feature?” or “I’ve noticed you seem disengaged during architectural discussions—help me understand what’s happening.” These conversations require vulnerability from both parties and consequently create deeper professional relationships built on mutual respect and trust.

Additionally, addressing these substantial topics requires managers to develop more emotional intelligence and communication skills. You must learn to read non-verbal cues, understand when to push deeper and when to provide support, and recognize the difference between constructive challenge and overwhelming pressure. The fish-on-the-table approach demands that you become comfortable with silence, allowing your team member time to process difficult questions rather than filling every pause with easier conversation.

Moreover, this methodology creates accountability through clarity. When you discuss specific behaviors, set explicit expectations, and address performance concerns directly, you eliminate the ambiguity that often leads to repeated issues. Your team members leave these conversations with a clear understanding of what success looks like and what steps they need to take to achieve it, rather than wondering what you really think about their work.

Talking about the real stuff is challenging, especially when you have back-to-back 1:1s where each conversation goes into the difficult territory. Be conscious of this reality—it’s going to feel draining and likely exhausting after several hours of fish-on-the-table conversations.

However, in my experience, this approach to 1:1s builds stronger, more authentic relationships. More importantly, it helps you address real issues early, before they become larger problems. Yes, these are harder conversations to have, but they’re also the ones that create the most meaningful impact.

Keeping a WTF Notebook

The concept of the WTF Notebook is normally used as a practical tool for new managers joining teams, but since I started using it I never stopped. What initially began as a survival mechanism for navigating unfamiliar organizational dynamics has evolved into one of my most valuable leadership instruments. Furthermore, I’ve discovered that even seasoned managers benefit tremendously from this systematic approach to capturing and processing the constant stream of observations that define our daily experience.

The concept is fairly simple: on any given day, you will encounter lots of moments that will ‘raise an eyebrows’. From team meetings where decisions seem to contradict established principles, to 1:1 conversations that reveal underlying team tensions, to architectural decisions that appear to ignore technical debt concerns—all of those observations go into your notebook. These moments often occur during the most routine interactions: a developer’s subtle eye-roll during sprint planning, an unusually defensive response to code review feedback, or the conspicuous silence when you ask about project timelines. Additionally, the notebook captures positive anomalies—instances where someone demonstrates exceptional problem-solving or when a process works surprisingly well despite organizational chaos.

Consequently, after several weeks of consistent logging, you’ll begin to notice recurring themes that might otherwise remain invisible. Perhaps the same architectural concerns surface repeatedly across different projects, or certain team members consistently struggle with similar types of challenges.

My approach is to mark things in 3 categories: Urgent, Can Wait, and Not Important. The urgent ones would probably become action items or conversation points for my next 1:1s or team meetings. However, the categorization process itself requires considerable judgment and experience. Urgent items typically involve situations that could escalate quickly—interpersonal conflicts, critical technical decisions with tight deadlines, or performance issues that are affecting team morale. These demand immediate attention because delay often amplifies the underlying problem exponentially.

The “Can Wait” category encompasses observations that represent important systemic issues but don’t require immediate intervention. For instance, you might notice that certain development practices are creating inefficiencies, or that communication patterns suggest deeper organizational misalignment. These items benefit from thoughtful consideration and strategic timing rather than reactive responses. Moreover, allowing these issues to marinate often reveals additional context that informs more effective solutions.

I will revisit the “can wait” list every month, and the “not important” ones I’ll review and prioritize every 6 months. This temporal approach prevents both over-reaction and under-attention to emerging issues. During monthly reviews, I frequently discover that items previously categorized as “can wait” have either resolved themselves naturally or have evolved into more urgent concerns requiring immediate action. The six-month review of “not important” items acts as a crucial calibration exercise—patterns that seemed insignificant individually often reveal their true importance when viewed collectively over extended periods.

At the end, the review process itself becomes a powerful reflection tool that enhances your leadership intuition. You begin to recognize which types of observations tend to become significant issues and which ones naturally resolve without intervention. This pattern recognition dramatically improves your ability to allocate attention and energy effectively, preventing both the exhaustion that comes from treating every observation as urgent and the regret that follows from ignoring genuinely important signals.

The notebook also serves as an excellent communication tool during skip-level meetings or leadership discussions. Rather than relying on vague impressions or isolated incidents, you can reference specific patterns and provide concrete examples that support your recommendations for team improvements or resource allocation decisions.

I use Todoist for this, as I found it fairly easy to add and tag bullet points (todos) there, but even a normal notebook will do. It’s also quite interesting how many “WTF” moments will end up on this list after a year of work, and it serves as a good reminder and a “pat on the back” moment when you see how many challenging topics you managed to work through.

Doing the Hard Things First

If I look back at a year of work, I would probably find moments where things were pretty hard and moments where things were fairly manageable. Normally, this work comes in waves, and you can probably tell when a hard wave is coming in advance. One of the biggest learnings for me has been to prioritize the hard things first—to run faster when going up the hill, so to speak.

When you sit down and look at your work day, the most important things to prioritize are probably the harder ones: the difficult 1:1 conversation with your direct report, the complicated re-architectural project that has a bunch of stakeholders involved, the board meeting deck that you have to prepare.

Most of these tasks also tend to lack clear success metrics, which makes them feel more ambiguous and consequently more intimidating. Unlike responding to emails where you either finish or you don’t, preparing for a board presentation means you’ve got to synthesize complex technical concepts into business-relevant insights while anticipating tough questions from stakeholders, who might not share your technical background. This uncertainty around outcomes creates a psychological barrier that makes procrastination kick in hard.

What I’ve found is that our natural tendency is to do the opposite—we gravitate toward the easier, more comfortable tasks first. It feels productive to clear out emails or organize our workspace, but these activities often serve as sophisticated forms of procrastination.

Consequently, we develop elaborate justification systems for this behavior: “I need to clear my inbox before I can focus,” or “Let me just organize these files so I can think clearly.” These seemingly productive activities create what psychologists call “structured procrastination”—we’re genuinely busy and accomplishing tasks, yet systematically avoiding the work that would create the most significant impact.

Moreover, the timing of when we tackle difficult tasks dramatically affects their outcomes. When you attempt that challenging architectural discussion at 4 PM after six hours of meetings, you’re operating with diminished capacity for nuanced thinking and diplomatic communication. The conversation that could have been constructive and collaborative in the morning becomes tense and unproductive by afternoon.

The emotional bandwidth thing is just as important but gets overlooked way too often. Tough conversations mean we’ve got to handle our own emotional reactions while staying tuned into how others are responding - picking up on those subtle cues and shifting our approach when needed. When we’re mentally drained, we lose that emotional intelligence we need to navigate these interactions well. Furthermore, we’re more likely to get defensive or just avoid dealing with the real issues completely, which ends up making things way harder than they should be.

When you postpone the difficult 1:1 conversation, the underlying issues will probably become even worse, potentially affecting the team morale and productivity. The delayed architectural decision creates uncertainty that slows down multiple development streams. Furthermore, the board presentation that gets rushed together at the last minute fails to communicate your team’s value effectively, potentially impacting future resource allocation decisions. Therefore, what appears to be a personal productivity challenge actually becomes a systemic issue affecting your entire organization’s effectiveness.

Prioritizing the hard things first also gives you a nice psychological boost. It creates momentum that carries through the rest of your day, transforming what could have been a day of mounting anxiety into one of progressive accomplishment. This approach generates ripple effects throughout your team’s culture. Your team notices this shift too; they see someone who doesn’t shy away from difficult conversations or complex problems, which builds trust and sets the tone for how the entire team approaches challenges.

Remembering that working software is the primary measure of progress

We tend to forget that the primary measure of progress and delivery is actually the software product working—while other activities can support this goal, they shouldn’t become ends in themselves.

Working software doesn’t mean that the code was refactored, or that the team had a really nice retro meeting, or that the user personas are better identifiable now, or that the fancy design system has new components. These are all ways to get to working software, but not really necessary.

Furthermore, I’ve observed that many organizations develop what I call “productivity theater”—elaborate displays of activity that create the illusion of progress without actually delivering value to users. Consider the scenario where your team spends three weeks perfecting a component library. The component library represents excellent engineering craftsmanship, yet customers continue experiencing frustration with fundamental functionality. This disconnect between internal accomplishment and external impact reveals the fundamental challenge we face as engineering leaders.

The distinction becomes particularly big when examining how teams allocate their time and energy. I’ve witnessed engineering teams dedicating substantial resources to architectural documentation that never gets referenced, or conducting exhaustive user research that doesn’t influence product decisions. These activities often emerge from good intentions to follow industry best practices, but will create barriers between your team and meaningful outcomes if not properly managed or even challenged on the ROI.

Refactoring code feels productive and intellectually satisfying, it’s concrete, measurable, and demonstrates technical expertise. Retrospective meetings provide structured opportunities for team bonding and process improvement discussions. However, when these activities become ends in themselves rather than means to deliver working software, they transform from valuable tools into elaborate procrastination mechanisms.

My point is that we tend to surround ourselves with a huge number of processes, ceremonies, and activities that dilute the meaning of our actual goal and, frankly, don’t matter. Most of these things can be challenged if they aren’t actually helping you deliver working software more effectively.

The spread of these activities often comes from organizational or manager anxiety about looking “professional” or “mature.” As a result, teams adopt increasingly complex project management frameworks, implement comprehensive code review processes, and establish detailed documentation standards—all while losing sight of whether these additions actually speed up value delivery. I’ve seen engineering teams where developers spend more time updating project tracking tools than writing code, or where architectural review boards create such lengthy approval processes that innovation becomes practically impossible.

The cumulative effect of these well-intentioned additions creates “bureaucratic drag”—each individual process may seem reasonable, but collectively they form barriers that significantly slow down progress. When your team needs approval from three different stakeholders to implement a simple API change, or change copy to paragraph, you’ve essentially created an organizational structure that prioritizes process compliance over customer value.

I’ve found it really valuable to regularly sit with my teams and keep an eye on each recurring meeting, approval workflow, and documentation requirement through a simple lens: “Does this directly help us deliver working software faster or better?” If the answer isn’t clearly yes, then that process becomes a candidate for changing or cutting entirely. This approach has consistently shown me opportunities to reclaim substantial time and mental bandwidth that we can redirect toward activities that genuinely matter to users and business objectives.

I can’t tell you which of those things exist in your organization, but I’m sure there are many that you can challenge, remove, optimize, and improve. I’ve found it very valuable to constantly challenge these “good practices” and help your team see a path forward where they can deliver on their goals without having to jump through unnecessary hoops.

Staying Technical, for the Right Reasons

The constant struggle between staying technical or not is real for most managers, especially when it’s really hard to find the time to work on a task or continue a PR when you have back-to-back meetings every day. The reality is that in most cases, it’s really hard to perform well in this role without having a good sense of what’s happening with your team, and one of the best ways to do that is to stay technical.

However, the challenge goes beyond just managing your time, it’s really about understanding the difference between staying technical to maintain “credibility” versus staying technical to be effective. Many engineering managers fall into the trap of keeping their hands in the code mainly to prove they “still have it,” which often leads to wasting their limited bandwidth. The more productive approach involves strategic technical engagement that directly supports your team’s success rather than satisfying your own ego or even worst, what others expect from you.

A team struggling with architectural decisions requires different technical leadership than a team dealing with operational excellence issues. So, your technical engagement must be contextually appropriate, sometimes that means pair programming through a complex algorithm, other times it involves reviewing system design documents, and occasionally it requires hands-on debugging of production issues alongside your team members.

At the end of the day, you are in control of your calendar, and you should allow yourself time to dive deep into the architectural decisions that will impact how the team work together. You should allow yourself time to understand the technical debt the team is wrestling with and the tools that slow them down. With that knowledge you can remove blockers, advocate for better resources, and make better informed decisions.

Additionally, this technical understanding becomes particularly crucial when communicating upward in your organization. When you can articulate the specific performance implications of accumulated technical debt or explain why a particular architectural decision will accelerate future development, you transform from someone who merely reports status to someone who provides strategic technical insight.

It’s also an excellent opportunity to challenge existing practices. Coming in with fresh perspective, you might spot inefficiencies in workflows that the team has simply accepted as “the way things are done.”

This fresh perspective becomes particularly valuable when you’re looking at how technical decisions and team dynamics intersect. Maybe the team’s developed elaborate workarounds for a particular system limitation, or they’ve implemented complex deployment procedures to compensate for inadequate testing infrastructure. Your technical involvement helps you spot these patterns and ask the critical questions: “Why do we accept this complexity?” and “What would it take to address the root cause instead of managing symptoms?”

On AI

With the boom of AI now, I believe that managers staying technical is more important than ever. In just one year, the way the industry works has changed drastically, and change will continue to accelerate. It’s your job to have a good sense of the tools that are available and to guide decisions with the correct context—to experiment with AI-powered code review, automated testing, or documentation generation.

The velocity of AI advancement creates a unique challenge for engineering managers, your role involves not just understanding current AI capabilities, but developing the judgment to evaluate new tools quickly and determine their potential impact on your team’s productivity and code quality. This requires hands-on experimentation rather than relying solely on vendor presentations or industry articles.

Moreover, the integration of AI tools into development workflows raises fundamental questions about code ownership, quality standards, and skill development within your team. When a junior developer can generate better code with AI assistance, how do you ensure they’re still developing core programming competencies? When AI-generated code introduces subtle bugs or architectural inconsistencies, how do you balance the productivity gains against the potential technical debt?

Considering that different AI tools excel in different contexts, and their effectiveness varies significantly based on codebase characteristics, team experience levels, and project constraints. For example, AI-powered code completion tools might dramatically accelerate development in well-structured, conventional codebases while providing limited value in highly specialized or legacy systems. Understanding these nuances requires direct technical experience rather than theoretical knowledge.

Lead by example in adopting these technologies thoughtfully, showing your team that embracing AI isn’t about replacement—it’s about enhancement. This becomes particularly important when addressing the anxiety that AI adoption often creates within engineering teams. Many developers worry about their long-term career prospects or feel threatened by tools that can generate code at unprecedented speed.

Leading by example means being transparent about both the successes and limitations of AI tools in your own work. When an AI-assisted code review catches issues you missed, share that experience with your team. When AI-generated documentation requires substantial human refinement to be truly useful, discuss those limitations openly.

Your technical involvement helps you guide these AI conversations and ensure that AI adoption strengthens rather than replaces the collaborative problem-solving that defines exceptional engineering teams.

The compounding effect

With all of these habits, I notice that they provide a nice compounding effect. Each difficult conversation you have builds trust for the next one. Every technical challenge you tackle alongside your team strengthens your credibility. Every process you question and improve creates space for your team to focus on what truly matters.

The beauty of compounding becomes particularly more evident when you examine how these behaviors reinforce each other across as time pass by. Consider how your first “fish on the table” conversation might feel awkward and stilted, requiring considerable emotional energy to navigate successfully. That initial investment creates psychological safety that makes subsequent difficult conversations progressively easier. Your team member learns that you’re genuinely interested in their growth rather than looking for reasons to criticize, while you develop greater confidence in your ability to handle challenging interpersonal dynamics.

Also, when team members observe your willingness to address uncomfortable topics directly, they begin bringing issues to you proactively rather than waiting for problems to escalate. The developer who previously suffered in silence about unrealistic deadlines now feels comfortable discussing workload concerns before burnout. The senior engineer who noticed architectural problems but hesitated to speak up now actively participates in design discussions, knowing their concerns will be heard and addressed thoughtfully.

Your team is watching—not for perfection, but for authenticity and growth. This observation captures something fundamental about human psychology that many managers overlook entirely. Team members don’t expect their leaders to possess supernatural abilities or flawless judgment; they’re looking for evidence that you’re genuinely committed to improvement and willing to acknowledge your limitations openly.

The distinction between perfection and authenticity becomes particularly important when considering how team dynamics evolve over time. Perfectionist managers often create environments where team members feel pressure to hide mistakes or avoid taking reasonable risks, which ultimately stifles innovation and learning. In contrast, managers who demonstrate authentic growth encourage their teams to experiment, fail safely, and iterate rapidly—behaviors that are essential for navigating the constant technological change that defines our industry.

Your team’s also likely watching to see if what you do actually matches what you say matters most. In my experience, they notice when you drop everything to jump on a critical production issue, and they often keep track of whether you actually follow through on those process improvements you promised. This consistency—or when it’s missing—really impacts how much your team trusts you and stays engaged. Plus, they’re observing how you handle stress, uncertainty, and pressure from above, using your reactions as their playbook for professional behavior.

This goes way beyond your direct reports, it includes peers, stakeholders, and senior leadership too. Your reputation as someone who asks the hard questions and stays technically sharp spreads throughout the company, opening doors for more responsibility and influence. As a result, other teams start coming to you for input on tough decisions, and senior leadership begins seeing you as someone who can effectively bridge that gap between technical reality and business goals.

Six months from now, look back at your WTF notebook and notice how many seemingly insurmountable challenges have been resolved. Your team will be more engaged, your 1:1s will be more meaningful, and you’ll have more fun doing what you do.

The WTF notebook serves as tangible evidence of your growth trajectory, documenting not just problems you’ve encountered but solutions you’ve developed and implemented successfully. Reviewing these entries reveals patterns in your problem-solving approach and highlights areas where your leadership intuition has strengthened significantly. Furthermore, you’ll discover that many issues resolved themselves naturally as team dynamics improved and trust levels increased, demonstrating the power of creating the right environmental conditions rather than trying to micromanage every outcome.

Perhaps most importantly, you’ll rediscover the joy and intellectual satisfaction that initially drew you to engineering leadership. When you’re no longer spending most of your energy on crisis management and interpersonal drama, you can focus on the strategic and technical challenges that make this role genuinely fulfilling. The compound effect of these habits creates space for the kind of thoughtful leadership that benefits everyone involved while building systems for long-term success and personal growth.