Accidentally in Code

Tag: management

  • Useful AI skills for Engineering Leaders

    Useful AI skills for Engineering Leaders

    The volume is up. More PRs, more pings, more incidents, more asks coming from more directions. I used to have 8 directs that dealt with most things, and organized and routed information to me for what I had to help them with, but since embarking on a new adventure, I’ve been rebuilding a different system that helps me stay on top of things and prioritize it.

    Three jobs, in order: 1. route the tedious stuff so it doesn’t waste my time, 2. report usefully so I can orient quickly, and 3. understand what’s actually going on.

    These all run on Claude Code as part of a broader chief-of-staff setup. I started with this repo and have expanded extensively. Here, I’ll focus on the set of skills that cover the core of EM operational work.

    1. Routing: get the tedious stuff off your desk

    Tedious but useful: maintaining a source of truth, and making sure that incoming requests get appropriately routed. Many EMs try, reasonably, to enforce a process here, but let’s be real; that process never applies to the C*O or your boss. They send the request as and how it works for them.

    I had a Zap set up for this, but it relied on a narrow trigger. Now, I have a skill that scans the channels where work comes in and reconciles them against the boards where work is supposed to live. It is also instructed to read the thread before flagging anything. If the ask is resolved in the replies (“we already have this”), flagging it anyway just makes noise, which is the thing I’m trying to reduce.

    That last rule is important because I don’t want one more thing pinging me. The point of routing isn’t to surface more; it’s to surface usefully and reconcile quickly, so the backlog reflects reality.

    2. Reporting: start the day knowing what’s going on

    The reports run first thing, and they run ops-first. Strict ordering: anything broken right now beats anything in flight, which beats anything in the backlog, which beats anything in the future. The daily version is deliberately short; a few lines, only the highest-signal items, and if nothing flags it just says “clear.” I don’t want a dashboard I have to interpret; I want one line that tells me whether my initial plan for the day has to go in the bin.

    At longer cadence: a weekly view for what’s moving and what’s stuck, a monthly one for the board update. Same sources, different altitude. Daily keeps me from missing fires; weekly keeps me from missing drift; monthly is a quick and useful way to keep other people in the loop.

    “I have a morning report” is the most boring possible sentence. But I think of it not as a report, but as an orientation to my day; something that looks through everything in a structured way, so that I know where I am and where I need to go, quickly. The terminal is also the feature: plain text on a yellow background (so I can distinguish that terminal from all the others), and I don’t risk getting distracted by “just this one small thing”, which is a) never just the one, and b) rarely that small.

    At a previous job, once I stopped getting pinged on every incident, I stopped knowing they were happening as they were happening; I learned about it when I reached that particular channel in Mattermost, or got through all the explicit demands for my attention in Asana. On some level, that’s fine and expected: if, as a director+, you’re in every incident, that is itself the problem, and incident response being able to run to your standards without you being aware is evidence that it has resolved.

    But then I had to look at everything. Now I can have structured, prioritized information without needing to. Cheap operational awareness is a win.

    3. Understanding: what’s actually going on, versus what we agreed

    Once you’re organized, and oriented, you come to the actual work of an EM: making the team better.

    It had been a long time since I consistently looked at PRs, but now it’s ~daily. I have heard that PRs are redundant now, and maybe I’ll come around to that point of view, but currently I see a PR as a queryable unit of work. It’s never been easier to know:

    • Is this code good? Dispatch a review agent.
    • Does this architecture make sense? Ask questions or for an architecture document.
    • Does this conform to our standards of ways and working? Encode those in claude.md and check.
    • Are the docs up to date? Ask, and then update.

    Better understanding of the work used to convert into process changes; tweak the review policy, change how we run standups. That work is still important, more so than ever. But also think about claude.md or equivalent. Did I learn something about how we work more effectively? Propose a change to it. The file is a really useful lever for team effectiveness and consistency.

    The bonus: the skills are alive

    I’m not sharing these skills publicly because I think the skill.md, tailored to my work situations, is much less useful than the way of thinking. But here’s a snippet I think you should take. All my skills have it, and it ensures they keep evolving as I do, and as the work does.

    ## Living document
Update this skill when:
- Triage patterns emerge from real audits
- A new source of truth comes online
- The way the work actually happens shifts

    Coming back to the start – I used to manage a lot of people, and now I use AI to manage (and do!) a lot of work and far fewer people. The thing I loved, and still love, about managing people is that they would learn and grow. Skills doing that is not as rewarding – but it is necessary to function.

  • The New Realities of EM Lyfe

    The New Realities of EM Lyfe

    Image credit: Joe Groove

    A fascinating thing is happening. EMs are saying it’s better to be an IC. ICs think being an EM is where it’s at.

    This is part of the AI shift. The industry seems to be in chaos, and wherever you are, somewhere else seems better. But below that, it’s not just the job that’s changing. It’s the context we’re operating in hitting like a bucket of cold water.

    The seller’s market is over

    We lived in a seller’s market, and we thought it was because of our own brilliance. Jobs were easy to come by, and with them comp, job titles and perks.

    It’s a buyer’s market now and that loss of leverage means we have to justify our impact. If you think you can get a better job, the organization is more likely to say “okay” than give a meaningful counteroffer. It’s always been true you shouldn’t negotiate on a job you don’t mean to take, but now that needs to be a hard line as you’re more likely than ever to be called on it.

    It’s a hard thing to accept, being less special and less in demand.

    The attrition is the point

    When management is an abstraction over people, it only has value when people do.

    For example, during ZIRP, being a good hiring manager was a huge part of the job, and a good hiring process was a real differentiator. People were the constraint. Companies competed on how well they identified, attracted and developed talent, because that was what determined what you could build.

    That’s gone. Hiring is slow or frozen. The L&D budget has been slashed. I wrote last year that management debt was looking cheap. Now I would say it’s looking actively desired.

    Why develop your people if attrition will sort it out for you. Why give hard feedback if the person will burn out and leave. Why fix morale if the ones with options have already gone and the ones who stayed can’t go anywhere. The workforce that’s left is cheaper, quieter, and more grateful.

    The risk, of course, is that the people without options aren’t usually the people you most wanted to keep. This is the AI-era debt; we’ll see what it costs down the line.

    Mass layoffs are the new RTO

    Post-pandemic, return to office looked easier than management fundamentals. Remote work didn’t break those organizations. It made it visible long term deficiencies that were too expensive and structural to fix.

    Mass layoffs are the new blunt instrument.

    Running a layoff is, bureaucratically, easier than writing a PIP. A PIP requires you have been managing the person. Documentation, expectations, feedback they had a chance to act on. A layoff requires a spreadsheet and a comms plan.

    Both punish everyone for problems leadership created. I miss the time when a layoff included an admission of failure. Now they read more like an acceptance speech for visionary of the year.

    This is not to say I don’t think AI will restructure the workforce. I do. I’ve been realizing efficiency gains with it. Reflecting on my time running a large org, I don’t honestly know how I’d make those gains real without a layoff. But that’s not an indictment of the workforce, nor one that I would measure in a %. It’s the change-management and people-development bill coming due. What was less than optimal becomes a structural block.

    We never agreed what an EM is

    We never had a shared definition of what an engineering manager is. Sometimes you could figure it out from the job description, but not always. People-leader, technical-leader, project-runner, career-developer, information-router, scope-holder, vibe-shaper. The profile depended on the values of leadership and the outcome of the latest reorg.

    Fundamentally, you didn’t have to be great at all the things to be good enough for the org, and the people stuff was big enough and fuzzy enough that it often became the job.

    Now I keep seeing the phrase “player coach” and I don’t know what it means. But the overall shift is, I think, pretty clear: get closer to the work, drive delivery improvements, be able not just to know what is going on but consistently make it better (or at least faster).

    Without a good definition, it’s much harder to absorb the chaos of senior leadership litigating in public whether the role should even exist. Trying to “improve productivity” by “doing the work” has ICs describing the output as AI slop. Being told you could be more efficient by having fewer 1:1s, but no one gave that memo to the ICs who still expect their 30+ minutes a week as well as an actual fix for the things they’re complaining about.

    It’s hard to fit all this conflicting feedback into an undefined scope.

    The force multiplier

    A consistent thing I keep seeing from EMs is moral injury. They got into the job because they care about their teams and want to support them, and they feel conflicted between that calling and the organization’s demands.

    It’s fair and understandable. The challenge, I think, is moving to more of a collective care than an individual one. And rightsizing your care to the market we’re in. Taking personal responsibility for things where you have little to no power is a recipe for burnout.

    Something I have long believed: a manager is a multiplier on the team. The worst ones for bad. In a growth market, you didn’t have to be much more than a 1x to have value. Now, the expectations are higher.

    Framing the role this way, a force multiplier for the team, creates clarity. You’re expected to make the team better. It also explains the calculus in a way that makes sense. If being a great hiring manager was a multiplier effect before, now it’s not. Retention is not seen as valuable. I believe retaining your strongest team members still will be, but that’s unlikely to be everyone. You’ll need to pick your battles.

    The thing is, there’s a good chance your organization won’t tell you how to do that. You have to figure out how to take in the information you have, and figure it out for yourself.

    If that sounds like a lot, the EM Survival Guide cohort 2 starts in June. Join us, we’d love to help you.

  • What’s Your Job as an Engineering Manager?

    What’s Your Job as an Engineering Manager?

    Image credit: Joe Groove

    As a manager, maybe you start your day looking at your calendar, or the pings that are already piling up. It can be easy to get caught up in what people are asking of you – but your job needs to look beyond the requests and into the causes underlying them.

    Here’s what I think the job of an engineering manager actually is:

    You’re a force multiplier for a team, and you take responsibility for that team.

    There’s a lot to unpack in that. But here I want to talk about three things:

    • The timeframe you live on
    • The distinction between a learning opportunity and a fuckup
    • The Clarify and Shard

    The Three Timeframes

    As an EM, you don’t just live on one time horizon. You need to live on multiple, and that needs to change over time. Consider your week – how much time have you spent on the immediate, versus the longer term.

    This is clearest when you’re ramping up on a new role. Then it roughly looks like:

    This week: What is a problem this week? Get it fixed.

    This month: What is a problem this month? Systematize it. Delegate it.

    Next quarter, next year: What is a problem next quarter or year? Make a plan.

    It’s less clear when you’re in the middle of things. Of course you go back and forth. Of course you pitch in when someone’s sick or there’s an incident. A week when you don’t get to the future is okay. Every week is not. A problem you don’t fully root cause is not the end of the world. But some of them are probably connected, and you’ll never get to those connections if you don’t get to stop and think.

    The pull of the urgent is strong, and bluntly handling the urgent makes your immediate value clearer. Your real value, though, that shows up over time.

    Learning Opportunities vs. Fuckups

    As an EM you need to both develop your team, and hold them accountable. When faced with a person + challenge, you need to understand: what’s a learning opportunity and what’s a fuckup?

    A learning opportunity is when your teammate missed something. They didn’t know, they didn’t see it, with the best of intentions they made a call that turned out wrong.

    A fuckup is when the risk was called – by you or someone else – and they did it anyway.

    Your job as a force multiplier is to increase learning opportunities and reduce fuckups. Learning opportunities are how people grow – they’re the place for the blameless postmortem, the non-judgemental deconstruction, and the process update.

    Fuckups are unforced errors that erode trust. They are where you need to be clear on accountability, what’s negotiable – and what is not. Was the process ignored? Was something not clear?

    When you’re coaching someone through these situations, say what you believe. Ask the question about what you’re curious about.

    Delivery overshot by a week? Learning opportunity. A quarter? That’s a fuckup. And it shouldn’t happen again.

    New manager didn’t realize the hire needed specific feedback? Learning opportunity. You told them and they didn’t do it? Fuckup.

    Incident from factors no one saw coming? Learning opportunity. Same incident twice because the process wasn’t followed? Fuckup.

    The learning opportunity, you can get curious about what can be learned from it.

    The fuckup? The question is more direct – how did this happen, and why am I finding this out now?

    Clarify and Shard

    One of the ways to create learning opportunities is what I call the “clarify and shard”. It’s a leader’s job to navigate ambiguity, and create clarity for their team.

    In the ambiguity, you make the ~~vibes~~ concrete. That feeling that the thing is slow, or the initiative is not working, or the process is wrong – you go into it and you come out with a point of view.

    That clarity can then be sharded (delegated, not necessarily just to one person). It’s the learning opportunity – with some guard rails that prevent it becoming a fuckup.

    What does this look like in practice?

    For example: the vibes say you’re no longer confident in the hiring process – that’s the ambiguity. Making it concrete looks like figuring out why that is. What parts of it aren’t working, or aren’t giving signal. Once the outcomes needed are clear, you can delegate.

    Another: the vibes say DevEx is slowing the team down. Getting concrete is about digging into what is slower and why, and whether or not that’s a problem. Maybe the change is that you have a PM now and they want to spec things? That’s good. But if they are becoming a bottleneck – that’s not. Now you know what you need to fix.

    Bringing it Together

    Put these together:

    • This week’s problem, fix it – then figure out if it’s a learning opportunity or a fuckup.
    • This month’s problem, run the clarify and shard.
    • Next quarter or year – make space for the ambiguity. You have some thinking to do.

    So when you look at your calendar tomorrow, or that pile of pings – remember you’re not just responding to requests. You’re looking for patterns, building systems, and clearing the path ahead. That’s what makes you a force multiplier.

    The hardest part? You won’t see the impact of the third timeframe for months. Your calendar will keep filling up with the urgent. But your job is to protect that thinking time anyway – because that’s where your real value as a leader shows up.

    If this was helpful, you might also like The Engineering Manager Survival Guide. An 8 week fully async course, to help you survive – and thrive – as an EM in the post-ZIRP era. Start March 13th. Early bird ends Feb 28th.

  • Announcing: The Engineering Manager Survival Guide

    Announcing: The Engineering Manager Survival Guide

    Image credit: Joe Groove

    One of the biggest issues I saw running remote teams for the past decade+ was the lack of good engineering manager training. With a global team it’s harder (and more expensive) to get everyone in the same place at one time. With a small team, the cost of doing anything custom is infeasible.

    To help new managers I was responsible for be successful, I had a set of options. We’d attend LeadDev as a group – but that happens once or twice a year and not everyone could make it. Many people would take Co-Active Fundamentals training, which is great – but general. I had a roster of coaches I recommended for 1:1, but that budget wasn’t always available.

    In the post-ZIRP era, being an engineering manager is harder than ever. When headcount was a vanity metric, managers had value simply as an abstraction layer over a number of people. When things were growing fast, there were opportunities to move up just because someone needed to fill the position.

    That era is over.

    Now it feels more important than ever to have a clear point of view on how an engineering manager actually creates impact – and how to support yourself while doing it.

    What is the EM Survival Guide?

    Jean Hsu and I designed The Engineering Manager Survival Guide for managers navigating this new reality. Whether you’re a new manager trying to ramp up, or a more experienced one who knows you’d benefit from devoting some time to consider your approach, this course gives you the frameworks and tools to be effective without burning out.

    The course runs over 8 weeks with 4 modules. Each module includes:

    • Written content and frameworks
    • Audio conversations between Jean and me, with personal stories and reflections
    • Exercises to apply what you’ve learned to your specific situation
    • Personal feedback from us on your submissions

    It’s designed to fit into a busy schedule while still creating space for real reflection and change. Around 60-90 minutes a week, in pieces, as you can fit them in.

    Why now?

    The expectations for engineering managers have fundamentally shifted. The role used to be about coordination and headcount. Now it’s about tangible impact, strategy, and doing more with less.

    If you’re feeling squashed between what your team wants from you and what your boss expects, if you’re wondering how to be effective without burning out, if you want to feel intentional instead of reactive – this course is for you.

    It can be hard to make time to step back and learn. We get it, and we’ve designed this course to fit your schedule. Plan to spend a minimum of 60-90 minutes a week, and it’s completely asynchronous, so you can listen to our audio conversations on a walk or in the car, read the module content in between meetings, and do each module’s targeted exercises whenever is best for you.

    Enrollment is open now.

    Early bird pricing: $799 USD (available until February 28th)

    Regular pricing: $899 USD

    The course starts March 13th, 2026. Enrollment closes March 10th or when we are at capacity.

    👉 Learn more

  • Decisions

    Decisions

    Credit: Joe Groove

    Recently, someone asked me for my “Leadership philosophy”. My initial reaction was to panic, but after taking a deep breath and a bit of time to think, I came up with this answer:

    “My job is to make it easier for people to make good decisions.”

    What does that mean?

    Firstly – that my job is not to make decisions. Sometimes (often!) it is, but it’s important to think about when someone else should be able to make the decision and how to change it for next time.

    What do people need to make decisions?

    • Context: What is the information around the decision they need to understand? As you rise up the org chart, you end up with a broad amount of context,so think about what you need to be distilling and passing on.
    • Scope / Responsibility: This is clarity about the scope of the decisions people can make, and what they are responsible for.
    • Timeframe: What timeframe is being optimized for.

    Local / focused decisions can help teams move faster in the short term, but have higher costs over time – e.g. optimizing for features over infrastructure that would make more features easy. Shifting this requires:

    • Enough shared context such that people can identify possible overlap.
    • Clarity about how and when a broader scope can make sense.
    • Understanding of where it’s critical to just deliver vs where it’s possible to justify longer investments (i.e product market fit vs iteration).

  • Questions for the End of a 1:1

    Questions for the End of a 1:1

    Credit: Joe Groove

    I have a set of questions I ask in some variation at the end of my 1:1s.

    What are you taking away?
    What was most useful to you?

    These two I got from my coach and I use them both at work and in my own coaching. The concrete questions are useful, but it can also be a source of implicit feedback about what was useful / what was less useful.

    Is there anything I can help you with or do for you?

    It’s amazing to me how often this starts another conversation about what someone needs help with. I also like that it frames asking for help as a normal thing.

    Is there anything I can be doing better?
    Is there anything I do that you particularly appreciate?

    I ask these more periodically because I want it to be unexpected enough that people actually think about it and try to give me an answer. The second question is useful for getting at least some specifics if the first one doesn’t elicit any information.

    Is there anything that I didn’t ask you that I should have?
    If I made you complain about one thing, what would it be?

    Useful for flipping someone’s thinking around if I feel like there may be things I’m missing.

  • What Makes a Good Team?

    What Makes a Good Team?

    Credit: Joe Groove

    No team is perfect, but I think it’s often kind of obvious when a team is bad – there’s usually a level of chaos or drama, a sense that they can’t be relied on or don’t really deliver the value that the organization needs. I think it’s also quite obvious when a team is good, mainly from the output of the team, but the underlying operating that goes into that tend to be less obvious.

    Practically, most teams are somewhere in the middle. Not terrible, but not as good as they could be either. Here’s my list of what I think makes a good team. If you think I’m missing anything please let me know in the comments or on your preferred social media.

    Clarity of purpose – people understand why the team exists.

    Defined work streams aligned with purpose – people understand what the team is doing (and why).

    Good team communication (openness, psychological safety) – communication is the foundation of collaboration.

    Connected, but not cliquey – the biggest predictor of work happiness is having a friend.

    Good delivery fundamentals – this is the team delivering its purpose, consistently and over time.

    • Work gets done and to agreed standards
    • Delivery is consistent medium term, not just short term sprints + burnout
    • Mistakes are a source of learning
    • Team is reliable <> people are reliable
    • Time is spent on higher value activities (complex tech designs > linting)

    Good people fundamentals – the necessary ongoing maintenance work for any team. Without good people fundamentals, management debt gets generated, which over time becomes corrosive.

    • Everyone has a good manager
    • Onboarding is predictable
    • Feedback loops are solid
      • Under-performers are addressed (up or out)
      • High performers get developed
    • Equity (in work allocation, advancement)

    Good process fundamentals – like the oil that keeps a team moving, process is the base level organization that facilitates team effectiveness.

    • All process has a purpose
    • Easy things are easy
    • Hard things are possible
    • Processes are fluid and evolving (continuous improvement mindset)

    The above items were the static needs of a team, if a team is going through a period of higher growth there is some additional complexity, such as:

    • More complex hiring (new roles)
    • More intense people development (stretch assignments)
    • Removing bottlenecks before they hit
    • Updating processes before they break
    • Balancing risk/reward, (stretch assignments, creative bridging of gaps)

    If you liked this, you may also like my book.

  • Escaping The House Elf Management Trap

    Escaping The House Elf Management Trap

    Credit: Keith Williams / Flickr / CC BY-NC-ND 2.0

    I would love to find a new name for this, now that JK Rowling is cancelled, but in the Harry Potter books, house elves are powerful magical beings, who are condemned to (mostly invisible) servitude, largely of people who would uphold harmful power structures (much like JK Rowling herself).

    The tragedy of the house elf is that they could be capable of so much, but they do not get to do it, because they are busy pleasing people who can never be pleased. Some of them become so enmeshed in that situation, that they cannot allow themselves to be free, even when they have been freed.

    What does this have to do with management? Well, new managers often present exhausted and overwhelmed, and the question I often ask in this situation, is, “how are you house elfing your team?”

    House elfing comes from a good place, often tied to some idea of “servant leadership”. People who internalize this idea that they exist to work for their team, and the way they know how to do that is to pick up all the small annoying things, run all the meetings, plan all the team activities, pick up the boring grunt work, tidy up the bug list etc.

    The outcome of this is that they are:

    • Wholly reactive ➡️ unable to focus on bigger / more impactful work.
    • Buried in small details ➡️ unable to step back and see the bigger picture.
    • Exhausted ➡️ running around all day picking up after people does that to you.
    • Overwhelmed ➡️ see also: reactive. By being buried in the details, you don’t have time to make the meaningful improvements.

    Worse, these managers often start thinking it’s their job to make their team happy. Wrong! It’s your job to make your team effective. Constant picking up of small things does not make your team more effective – noticing the patterns and improving the processes, or the projects themselves does that.

    And here’s the thing, the biggest problem I have with servant leadership: you can’t be the servant of people you have power over. So either you deny that power dynamic, or you give away that power.

    Because if you behave in such a way that your team starts to believe your job is to make them happy, what is going to happen when you inevitably have to disappoint them? When you have to tell them they didn’t get the promotion, or the project has been cancelled, or the is no budget for the thing they want?

    They will blame you.

    Everyone on your team is – hopefully – an adult. You don’t need to “protect them” from the realities of the workplace. Trying to do so is patronizing and a recipe for making yourself miserable. If you believe people are adults, you can focus them – make it clear what’s important, what’s valued and what’s not – and trust them to take their share of team housekeeping.

    I’m not saying you should refuse to do anything – I’m saying you should not do everything. I’m also not saying you shouldn’t help your team, that is an important part of your job. But it is your job to help them through kindness not erode everyone’s effectiveness with niceness.

    The thing about house elfing, is that it comes from a good place – the desire to help. This is something to honour.

    It can also be a product of some level of insecurity, that by doing small tasks you are providing value. It’s a way to get the small dopamine hits that we miss from writing code. This is something to critically evaluate.

    To escape the house elf trap:

    • Pay attention to how often you are house elfing. Make a list of things you do when you catch yourself house elfing.
    • After a week or two, evaluate the list. How much is on it? What has that cost you in terms of focus time or energy?
    • Redefine your priorities. What are your most important things to do?
    • Catch yourself before you house elf. Let that thing go undone (by you). Does someone else pick it up? Does it need to be done at all?

    Remember that even if you can successfully house elf a team of five, there is no way to succeed in this mindset with five teams of five. This can be one of the biggest ways that people get in the way of their own advancement – so the time to readjust your approach is now.

  • Meta Problems and Where to Find Them

    Meta Problems and Where to Find Them

    Credit: PxHere

    Meta-problem (n): root cause issues of a collection of symptom problems.

    One of the things I do as an engineering director, is live in the realm of the meta problem. The thing that is behind the problems that people are talking about.

    For instance, a meta problem of an individualistic mindset on the team might result in:

    • Poor onboarding
    • Inequitable division of work
    • “Not my job” attitude
    • Lack of collaboration
    • Lack of feedback

    Yes, these things individually need to be addressed, but that will look different if you address them one by one, or guided by a North Star of “collective responsibility”.

    Similarly, a meta problem of poor people management might result in:

    • Lack of feedback
    • Lack of interest in management
    • Lack of growth
    • Lack of clarity around team purpose
    • Burnout
    • Fear of change
    • Resentment of authority

    Addressing the root cause by doing good people management and empowering others to do good people management will shift these issues more effectively than considered one by one.

    Teams that are struggling have a collection of issues, and part of transformation to a functional team is to root cause and address the meta problems. Working symptom by symptom may not change, may actually re-enforce the meta problem. E.g. if you have a problem of code review being slow and a meta problem of team workload, then the answer is different if you have a problem of slow code review and a meta problem of individualistic mindset.

    Addressing meta problems often involves shifting the culture in some way. Things are the way they are for a reason – a series of decisions reflecting organizational priorities at the time, distorted by the coping mechanisms of individuals (particularly those with more influence on the team). It takes time to address the ensuing consequences, but much less time if you take it holistically rather than symptomatically.