In May 2026, controversial crypto exchange company Coinbase announced 14% of the company was to be laid off. CEO Brian Armstrong justified his decision in an all-company email which he later published on X. After paying the slightest lip service to the fact that the crypto industry is suffering a major slump, and without mentioning Coinbase had just disclosed its second consecutive quarterly loss and a 40% revenue shrinkage, Armstrong pulled out the “AI excuse” that is now so popular among the executive class:

AI is changing how we work. [...] The pace of what’s possible with a small, focused team has changed dramatically, and it’s accelerating every day.

Given this insight, a reasonable person might think, “Wow, if AI is accelerating what’s possible with fewer human workers, imagine what amazing things we will now achieve with all the employees we have?” but no, a CEO like Armstrong concludes: “Wow, if AI is accelerating what’s possible with fewer human workers, imagine how much we can lower our operating expenses if we lay off a bunch of human workers?” Somehow they arrive at this realization without surmising that the largest and least impactful operating expense of all is their own salary.

In order to put some lipstick on this uninspired idea, Armstrong talked about the layoffs as a “flattening” that would make work life better for remaining employees. It almost sounds like he’s describing a new democratic utopia emerging from years of stifling bureaucracy and inertia:

“Fewer layers, faster decisions: We are flattening our org structure to 5 layers max below CEO/COO. Layers slow things down and create coordination tax. The future is small, high-context teams that can move quickly.”

Business articles have circulated about “flattening” ever since Zappos made waves with their (mostly failed) “Holocracy” experiments in 2014. But in the age of AI being the perfect excuse for making job cuts, the idea has become more virulent and is known as “The Great Flattening.” What this amounts to is essentially deleting all middle managers, leaving frontline managers as the only layer separating individual contributors from the C-suite. Which, as someone who has worked many long nights and years as an Engineering Manager, is a utopia I can almost believe in. Let’s face it, one of the biggest challenges faced by any line manager is how to protect your direct reports from flak from on high while managing up to middle managers who are usually just a little too far removed from the day-to-day work to have any empathy for you or your team. If anyone in your organization is going to make you feel worthless through micromanagement, narcissistic mind games, political manipulation, or outright gaslighting and bullying, it’s going to be a middle manager, especially in the tech field. Why? Because many people promoted to this level are smart but performative ass kissers chasing the higher salary rather than giving a shit about any of the employees under their purview. Most of them were never given any leadership training and have no real people skills. I won’t lie: many of the middle managers I’ve encountered in my career were overpaid douchebags who took out their own problems on everyone below them. Some of them were narcissists or had less backbone than Marco Rubio.

But I’m not a CEO who can’t imagine a world outside his own anecdotal experiences, so I can see that managers are more than just numbers in a payroll system. There is a purpose to the hierarchy, even if it’s often obscured or abused. While I was an Engineering Manager I had some terrible managers for sure, but I’ve also worked for enough good managers to understand how middle management is supposed to work. The bad managers set bad examples that leave psychological scars — which I’m not excusing — but the good managers taught me what true leadership looks like.

Middle managers disambiguate. On a good day, a middle manager should act as a communication and prioritization layer. They’re a filter that, when working as intended, turn messy, unrehearsed memos and mandates from the C-suite into relatable and actionable guidance and next steps for teams. They’re in the unenviable position of figuring out how the real work of the company aligns with the grand vision of people who are so far removed from the daily work they may as well be living on another planet. They help temper expectations at the top, advocating for their teams to get the resources and budget allocations they need. And they provide mentorship to line managers — whose shoes they’ve already walked in. In a healthy organization, middle managers are line managers who have been promoted because they were well respected and demonstrated an ability to lead and inspire teams. Now they get to multiply the effectiveness of the people around them within a larger sphere of influence.

Even if your experience with middle management has not been good, I’m arguing that they’re still a necessary evil. A corporate workplace without middle managers is a recipe for disaster. A few (not exhaustive) reasons why:

1. An unfiltered C-suite is a crippling distraction.

2. Without middle managers, line managers are overburdened and overstressed.

3. In the absence of formal hierarchy, unofficial tribes form anyway.

4. “Flattening” is doublespeak for Authoritarianism.

An unfiltered C-suite is a crippling distraction

Frontline managers need a buffer between them and the CEO. CEOs are generally not known for their unwavering adherence to roadmaps, patience for strategies to pay off, or even mental congruence with baseline reality. What they are known for is an almost child-like excitement for new ideas, strategic pivots, and performative decision making that often seems disconnected from what really matters.

One of the tasks of high level directors and middle managers is to somehow keep this creative but also chaotic force in check so that it doesn’t ripple through the company, impinging momentum or morale. Even level-headed CEOs who play to their strengths and are able to commit to long-term plans are still prone to distracting their company with too many ideas at once. It may seem counterintuitive, but constantly throwing new ideas at the organization leads to stifling inertia and indecision, not more innovation or guaranteed growth. There’s an interview with Jeff Bezos where he reminisces about a mentor who told him “you have enough ideas to destroy Amazon”, meaning his propensity to fill up a whiteboard with thought bubbles did more harm than good without a proper framework and process to distill, organize, and prioritize those ideas in a sensible way that didn’t distract the whole company and jeopardize existing goals.

You can’t do this without a middle management layer. Imagine trying to be the frontline manager who’s responsible for providing clarity, direction, and motivation to your team while simultaneously being pulled in the direction of every new idea that comes down from the top, no matter how out of left-field it might be? It’s completely untenable. Translating and tempering C-suite fantasies and whims into realistic goals that fit into the normal cadence and operating flow of the company can be a full-time job in of itself. Absent this corporate safety valve, frontline employees would just drown in the blast from the innovation firehose and would be forced to neglect so much of what they’re supposed to be responsible for. It’s true that long-term success requires a certain amount of change and transformation, but it also requires balance, focus and consistency. It requires prolonged investment in what works, not just experiments in what could.

Without middle managers, line managers are overburdened and overstressed

Point two directly follows my first point above. Without the necessary filtering layer between the C-suite and team managers, you are placing an enormous burden on people leaders responsible for the day-to-day operation of their teams to also find time to be CEO/CTO/CFO whisperers, and this is never going to work.

Leaders will own much more, with as many as 15+ direct reports.

This is just basic math. If middle management is gone, and the company is not hiring more frontline managers, existing frontline managers have to take on more direct reports and more responsibility overall. I can’t say this has ever been a good deal for managers or their teams. As if that wasn’t bad enough already, Armstrong piles on:

No pure managers: Every leader at Coinbase must also be a strong and active individual contributor

So let me get this straight: not only does he want line managers to do the work of middle managers, but they’ve got to take on some of the work of their direct reports as well? At the same time as having their number of direct reports double or triple. In what insane multiverse could this directive possibly make any sense? In what reality does this not lead to flawed and hurried decision-making, survival-first short-term thinking, as well as physical and mental burnout? It seems painfully obvious and yet these obtuse CEOs keep rehashing the same memo like it’s some sort of new gospel.

Readers of Humanware know that the IC vs manager misunderstanding is one of my pet peeves. An Engineering Manager doesn’t need to be the smartest person in the room and the most experienced developer on their team. That’s not the point or the purpose of being a people leader. And in fact, if you are the lead developer and a manager at the same time, it can be pretty detrimental to your direct reports. Writing code, managing direct reports, and managing up are three distinct skill sets that very few professionals are ever going to be able to master while maintaining a clear head and balanced view. And fewer still can find equilibrium between the extreme context switching, mental acuity, and political prowess that would be required to excel under such pressure.

In a world where the EM is acting as an IC as well as trying to manage multiple developer pods as well as reporting up to the C-suite — trying to translate their ideas, frustrations and tantrums into projects and meaningful improvements — some part of that equation has to fall by the wayside. Every manager will handle this differently, depending on their experience, comfort zone, and temperament, so in some cases you’ll get managers who are too heads down in their own code to care about stewarding team processes or improving team throughput, while others might decide the most important aspect of their job is sucking up to the C-suite while ignoring the legitimate questions or concerns of their direct reports. Either way, the overburdening of management leads to more ruthless prioritization as a sort of survival mechanism, which inevitably leads to apathy or neglect in other important areas.

Layering on new responsibilities and conflicting priorities for line managers ignores the many hats they already need to wear. Managers don’t just conduct 1:1’s and issue raises, they also act as hiring managers, delivery managers, cross-functional point person, meeting facilitator, a cultivator of company and team culture, a farmer of technical debt, a stakeholder synergist, a ceremony czar, an effective squeaky wheel, an advocate, a mentor, and an umbrella for political or systemic issues that could impact the morale or the efficiency of the team. One of the keys to building teams that go from storming to performing is a great manager that becomes the glue and the conduit. Not a manager who is too distracted and too overburdened to pay attention to what matters.

In the absence of formal hierarchy, unofficial tribes form anyway

In theory, an (almost) flat organization without middle management means that:

• Everyone is equally responsible for work culture and outcomes.

• More innovation: fewer barriers to getting buy-in on experimental projects.

• Communication is more efficient because it travels through fewer channels.

• Everyone has visibility at the top: no more unsung heroes.

Which is why the myth of the “Great Flattening” is so pervasive and alluring. It seems so democratic and freeing. Who wouldn’t vote for it? I love this, on principle. But we all know democracy fails without hierarchy, checks, and balances. The problem is almost always that we need more and better leaders, not fewer and worse.

Flattening isn’t a new idea. Even before everyone went nuts over AI, many startups and some more established organizations experimented with flattening, and by all accounts it was mostly a bust. Although a flat organization clearly provides the benefits listed above, it tends to devolve over time into a sort of mirror image of what was intended:

• Everyone is equally responsible, but no one is really accountable.

• An explosion of innovation turns into uncontrollable spending on dead-end initiatives.

• The dominant communication style becomes brevity and top-down decision-making, with nuance lost in translation.

• The C-suite can’t notice everyone at once, so favoritism occurs a lot.

One of the worst side effects is that, in the absence of formal hierarchy, informal hierarchy emerges, because it’s an evolutionary trait we can’t shake. In a flat organization, the loudest voices rise to the top and become unofficial leaders. Nobody elected or promoted them, but they hold sway over decisions and have an oversized influence over work culture anyway. It’s easy for these individuals to abuse their power by establishing cliques or tribes governed by bias and favoritism, unbounded by company rules or the normal patterns of office civility. This works out particularly bad for women and minorities, who tend to only receive respectful and dignified workplace treatment when there are rigid reporting structures and traditional advancement ladders that are supported by corporate standards and regulations. It’s no surprise that when you remove enough structure, chaos ensues. Basically what I’m saying is, flat organizations tend to become toxic over time because they naturally degrade into familiar social structures based on friendships, biases, and allegiances that have nothing to do with merit, rank, or tenure. It ends up operating more like Jack Merridew’s tribe in Lord Of The Flies.

“Flattening” is doublespeak for authoritarianism

Notice how with all the talk of flattening and doing more with less, Armstrong didn’t mention democracy or holocracy? I don’t think there’s anything further from his mind. This isn’t the flattening from 2014, this is a new autocratic leadership powergrab that just coincidentally removes the same players from the board.

As George Orwell prophesized, authoritarians use pacifying language to distort meaning and distract naysayers while they assert control. It seems the real drive behind “the great flattening” isn’t as a democratizing force that frees up workers to do more of what they enjoy, but simply a consolidation of power and authority, making them not just leaders of their company, but the leader of the company. Unrestrained, unquestionable, unmatched.

This is the stuff that many CEOs dream of. These are people fueled by ambition and ego more than decency or common sense. They exist behind icebergs of ignorance, believing that they have the finger on the pulse when more often than not they are woefully uninitiated in the nuances of their corporate culture and the limits of their own influence. So I don’t think I’m off base to suggest that one of the primary drivers of the call to remove middle management is an immune response to the friction and frustration CEOs feel when things don’t seem to be moving fast enough or in the precise direction they imagined. In short, what they want is to exercise more veto power over decisions and a chance to micromanage whomever they want, whenever they want.

This is what is fueling the authoritarian fantasies of Jack Dorsey, who fully believes he can comfortably oversee 6000 direct reports. It comes from the same toxic wellspring that inspired Elon Musk to grind 18 hours straight to publicly interrogate every single employee at xAI for five (impotent) minutes. And it’s what motivated deplorable CloudFlare CEO Matthew Prince to brag about his recent round of layoffs like a warrior king who’s finally defeated all his enemies, using the kind of language that seems straight out of eugenics and white supremacy: going out of his way to further insult the legacy and contributions of laid off staff by denigrating them as “measurers and operators” versus the more highly prized “doers and builders” required by his new agenda. Good luck operating a company without…operators.

The same authoritarian streak can be seen in all the other CEOs recycling the “AI-first” memo recently, touting completely mythical claims about increased productivity as a smokescreen for right-sizing in response to downturns. It’s all an act of toxic bravado masking greed, ignorance, and fear. And some of these over confident copycats are already learning the hard way that talking and acting like a dictator and lying about the transformative power of AI doesn’t pay off, whether it’s public backlash, employee discontent, or painful lessons in AI token economics.

Where all this leads

There will be trouble ahead. A reckoning. A time for CEO’s like Prince and Armstrong to realize (hopefully too late) that by putting AI first and humans last, they destroy their own companies and never recover. If they continue to get business advice from chatGPT instead of their peers and friends, they’ll continue to make bigger and bigger mistakes, and sooner or later, customers, costs, or calamities will come for them. We can only hope.

Middle managers get a bad rap, and sometimes for good reason, but they provide necessary cover for frontline managers, and they are the operators who work behind the scenes to keep the ship afloat. You can’t just dismiss the leaders of strategy, finance, research, auditing, legal review, marketing, compliance, and operations and expect to keep merrily sailing along. At best you’re going to miss your targets. At worst, you’re going to jail.

Middle management can be a bottleneck, which means organizations should make sure they’re properly trained and that only the right candidates are promoted. It doesn’t mean you can just wave a magic wand and make them disappear and pretend it’s business as usual. I don’t believe these bloviating CEOs even believe what they’re saying. It’s all so much AI theater. And nobody’s clapping.

The ping pong tables are gathering dust. The free lunches are gone. The judgement-free internal coaching and moral support is gone. The career ladder has lost its rungs. The surprisingly transparent all-hands town halls have become sycophantic cringe-fests. The slack channels for feedback and respectful dissent have been deleted. The company vision statement has been modified to remove all mention of doing good in the world. The ethics team has been laid off. The Quality Assurance team has been replaced with a policy of moving fast and breaking things. The CTO is a yes man who will build his boss a golden toilet if that’s what he asks for. There will be an AI pledge you have to sign. Resistance is futile.

“We’re hiring for new roles and have been explicitly told that no candidate will be considered for any job unless they’re on board with AI. Every department has to show how they’re “incorporating AI into their workflows.” I heard through the grapevine that anyone so much as expressing skepticism “does not have a future with the company.”
— ‘AI Killed my Job’, Brian Merchant

The egalitarian vision of the World Wide Web that began with Tim Berners Lee is now dead and buried thanks to a process of enshittification, a term coined by Cory Doctorow to describe the deliberate ruination of online platforms by business owners optimizing for shareholder value over user experience, regardless of the long-term consequences.

Now CEOs high on AI hype, or suffering from “AI psychosis” are throwing out all pretense of caring about mission statements and work culture and doing everything they can to jump on the AI train, even if it means alienating their entire workforce in the process.

I’ve been part of the tech industry for twenty years, and I feel a fading nostalgia for conscious capitalism, servant leadership, diversity, equity, and inclusion, and most of all: workplace empathy. I won’t pretend that a job in corporate tech was ever a fun-loving utopia, but it used to be populated here and there with leaders who at least tried to treat their direct reports like real human beings, and were empowered to do so at least some of the time.

But in just a few years, ideas like human-centered leadership, leading with empathy, inclusive work culture, defaulting to trust, and democratic openness, have been eroded or entirely replaced with cold, algorithmic efficiency, a nervous, performative culture, and authoritarian style leadership. Contrarians and advocates have been culled from the flock, the most toxic techbro bullies have been promoted to the C-suite, and HR have devolved into mere button pushers of automated hiring software. Mass layoffs are becoming a monthly calendar event even as these companies report record profits.

“AI-first” mandates and dogmatic adoption rituals have been normalized by CEOs who have started saying the quiet part out loud: AI is here to replace you if you don’t comply, and will probably replace you in the long-run even if you do. This puts employees in a terribly precarious and depressing position, having to defend their current role in the present, staying docile and compliant while facing down a seemingly inevitable future of permanent unemployment.

For employees who have survived the cuts thus far, work-life balance no longer exists, workplace surveillance is everywhere, and basic civility in the office has been ruined by workslop and the gradual erosion of basic human communication. Workers are being systematically deskilled, and AI hasn’t even delivered the productivity enhancements that made CEOs salivate in the first place! It’s all an illusion. Perhaps the most egregious and most expensive illusion ever created by the tech industry.

CEOs are decimating their workforce and siphoning profits back into AI services, not because there’s solid evidence of ROI, or any consensus about the value of this technology, but because of good old fashioned fear of missing out, herd mentality, sheer uncertainty about the future, and the potential of what AI companies have prophesized. The rational, data-driven philosophy of the past has been usurped by an entirely faith-based system: corporate America is now chasing the automation zeitgeist with religious fervor and a willingness to sacrifice anything for the cause, including decency and common sense.

AI hype has crossed the blood-brain barrier to become a memetic virus. What began life as delusional manifestos from nauseating oligarchs mutated into talking points coughed up in boardrooms by unoriginal consulting agencies that then blistered and erupted into the deeply insulting, dehumanizing “AI-first” memos and mandates that are turning 21st century offices into 19th century factories.

So far this is turning out to be an unmitigated disaster. Dogmatic AI adoption strategies can’t turn a productivity myth into profit. Three and a half years into the generative AI era, there is still no ROI coming from corporate AI initiatives. There is simultaneously a sense of reality settling in and a nonsensical doubling down on “agentic” AI called tokenmaxxing that is taking the vibe coding obsession to new levels of insanity.

By their own admission, companies are now having to spend more on AI subscriptions and metered AI tokens than they spend on human wages as AI companies gradually reduce the price subsidies that have always artificially inflated their MAU’s. The staggering costs of AI infrastructure and API services will come due anytime now, and CEOs are going to realize that even with mass layoffs, their operating costs are likely going north, not south.

There is a massive disconnect between how the C-suite perceives AI compared to ground-floor employees. This disconnect causes extreme resentment, a culture of fear, incivility, and even acts of sabotage. CEOs seem embarrassingly unaware that their strongman speeches about embracing AI or getting left behind fail to disguise their ultimate wishful thinking about running a company that no longer relies on flesh and blood humans who need to eat, sleep, and take breaks. They think they’re being leaders of the future when in fact they’re acting more like the ruthless, out of touch factory owners of the industrial revolution.

When I see bold statements from a CEO regarding AI adoption or transformation I check out company reviews on Glassdoor, and scan anonymous employee conversations on Blind and Reddit. What I invariably find is a glaring disconnect between the CEOs vision and the reality on the ground. I see lofty, wishful thinking and boastful pride from CEOs, versus reality checks, resentment, confusion, and disillusionment from staff. Employees are fearful and subservient. But when they’re in a space where they can express themselves free from the threat of retaliation? Boy, do they let it rip.

Why the disconnect? CEOs and founders are far more removed from day-to-day operations than they realize, or care to admit. C-suite executives have a distorted field of view. The higher up they are, the less they’re exposed to the everyday micro actions and reactions that move their company in a given direction. They influence macro strategies, but have no way of tracking or perceiving the thousands of realtime experiments, debates, constraints, decisions, and course corrections that produce final outcomes.

This is the paradox of leadership: commanding vision and wielding power from the top makes you short-sighted and ignorant of what’s going on at ground level. Many CEOs and founders suffer what we call “executive loneliness“ because of the isolating effects of this paradox. Of course, the evidence is often on Glassdoor, or in anonymous surveys, if you care to look: leaders and their employees see AI as completely different beasts. If you’re a leader and you’re not aware of this disconnect you’re likely on a devastating collision course fueled by hubris and FOMO. The C-suite vision of AI’s impact on work and productivity are directly orthogonal to reality as experienced by regular workers.

On the whole, CEOs seem ignorant of the common failures of large language models and so-called agentic systems. Some CEOs are too enamored with chatbots to see past their own bias and spiraling descent into AI addiction, while others are hardly even using the tools they’ve decided to force on everyone else. Either way, this leaves them operating with severe blind spots. What they see as amazing automations and efficiencies spearheading their company into a bright and golden future is often a barely contained hallucination waiting to wreck havoc on clients and customers, or an unpredictable and untenable Rube-Goldberg contraption duct-taped and constantly nudged in the right direction by software engineers too frightened to tell the truth about how many humans are still in the loop. Shit, even the AI coding benchmarks are fake. CEOs spend all their time listening to a few “yes-men” whose allegiance is born from either fear or selfishness, and uncritically buying into pro-AI propaganda, rather than paying attention to any of their employees brave enough to push back on, or question their myopic vision. Absent any opportunity to safely share their concerns at work, employees sound muted alarms to middle managers who never escalate, or go looking for solidarity among their peers in anonymous work forums.

More and more, I feel somewhat helpless to effect any change during these times. I still coach tech workers 1:1 on how to operate and lead on human terms, and I will continue to champion honesty, empathy, and openness until my dying breath, but it’s extremely disheartening to see this wave of fear, paranoia, and authoritarianism sweeping through an industry I once believed in. If only leaders could see past the fraudulent magic spells that have been cast over them, and maybe listen to those of us who are trying to dispel the myths, and if only tech workers could form unions so they could speak with one voice, free from the fear of being instantly fired for their dissent. I just hope that this is a period of temporary insanity that will eventually wear off.

Perhaps the bubble will deflate and the corporate world will eventually normalize and reorient itself back to a more humane center, with lessons learned. Perhaps the best remnants of AI tech will be salvaged from the wreckage of enshittification, and we can all get back to solving real problems that matter, in ways that don’t compromise our values or sidestep our humanity.

If you’ve read any of my other essays in this Substack you’ll know that I approach software engineering and management from a human-first perspective. I’ve always believed that cultivating and maintaining human relationships is central to how good software gets produced. But I know it’s common for people who write code to find the complexities of working with other people overwhelming at times. A lot of us are introverts, or neurodiverse, or have disabilities or health issues that we don’t disclose to our employers, but which affect our day-to-day work habits and routines. It’s not that we don’t want to make friends or that we’re not team players, it’s just that we may be awkward with certain forms of communication and collaboration. Team rituals don’t always feel natural, equitable or logical, and group meetings can often seem performative and geared towards extroverts. I’m mostly an introvert myself, whose store of confident energy gets used up quickly in stressful or intimidating situations, so working well with other developers, team leads, managers, and department heads has been a constant process of learning and adapting over many years. And I’ve made plenty of mistakes along the way.

But these awkward moments and mistakes can’t be avoided. Human interaction is part of life, and work doesn’t happen without growing as an individual and learning how to work as part of a team. At least, that used to be true until recently.

We went through a period of forced isolation during the Covid pandemic, starting in 2020. And the weird thing is, some of us thrived during that time. Some of us felt like we were in heaven. Loners by nature, we preferred working in the dark of our bedroom or home office: home-brewed coffee, familiar surroundings, perhaps a four-legged friend to snuggle, and all the other creature comforts of working from home. Yeah, we got sick of being in Zoom meetings where our face always looked too tired, we got flooded with slack messages all day long, and our work day no longer had a consistent beginning and end, but at least we could avoid the commute and all those water cooler distractions and just keep our head down and work, right? It seemed like a revelation: the physical office was just a theater for extroverts, and for confident people to capitalize on their physical presence because they lacked mental acuity. Whereas we had mental acuity in spades but didn’t really feel the need to shake everyone’s hand.

But during that time we were still connected to the office and our coworkers through the same rituals and hierarchies that we were hired into. Team meetings were conducted over Zoom, or Microsoft Teams (if your workplace sucked). You spent a ton of time on slack. And you probably spent more time using software like Jira, Monday, or Trello than ever before. If you worked at a company with decent leadership who at least pretended to care about employee wellness, chances are you were also encouraged to attend virtual team training and even social events from time to time where you could rekindle your sense of belonging and camaraderie. The company I worked for allowed managers to arrange virtual tours with Airbnb, and take time out for things like virtual escape rooms and online games. None of us knew what made sense, and we were all weary of how it might be misconstrued as “mandatory fun”, but we tried our best to keep people engaged and connected. There was a sense of importance around staying human. We worried that isolation would cause loneliness, stress, and the loss of empathy and coordination that makes good teamwork possible.

I’m concerned that the rise of AI assisted coding could isolate certain tech workers in a time when none of those concerns seem to be important anymore. Sure, CEOs made a big deal about returning to the office, but we know it was to satisfy their own inflated egos and to avoid wasting money on insanely expensive real estate. We live in different times, where the old human-first philosophies of leadership have been thrown out the window and workers are just fleshbags to be replaced by superior models. And in the absence of any concern for the mental wellbeing of the human worker, I worry that AI advances are rapidly becoming an excuse for SWEs to avoid human interaction altogether, and that this is having a real detrimental effect on team cohesion and code quality, as well as exacerbating what is known colloquially as the “loneliness epidemic”. How can it possibly be a good thing, psychologically and practically, to go from working side-by-side with human coworkers, reporting to a human manager, and mentoring human juniors — to managing a bunch of AI agents, being accountable only to work surveillance and algorithmic metrics, and no longer encountering entry-level workers? Our workplaces are becoming more and more dehumanized. We may still be in the loop (for now), but it’s a loop that’s increasingly isolated. We are disconnecting from our peers and drifting further away from teamwork, purpose, or anything anchoring our perception of the larger mission we’re contributing to.

Don’t get me wrong: I’m not squarely blaming developers for this unhealthy workplace shift — it was foisted on us by ignorant leaders following a herd mentality based on fear of missing out and a complete misreading of the tea leaves. But I’ve seen more than enough evidence that a growing number of us are reluctantly embracing the idea of an “agentic” future because it seems easier than continuing to go against our own instincts. Adopting an AI-centric approach to software development gives us the perfect excuse to avoid arguments and misunderstandings with our peers and to avoid the friction and frustration that comes from daily meetings, agile rituals, and basic human accountability. We may be somewhat conscious of what we’re losing in this process: shared experience, camaraderie, relationships — but what we’re gaining might seem more precious: more time to focus on planning, architecting, problem-solving, and building, rather than being held up by communicating, explaining, advocating for our point of view or methodology, and endlessly reporting on progress — mental exertions many of us have always felt to be suboptimal and unnecessary, or mere distractions.

And I don’t disagree: we do waste too much time in meetings, we do spend too much time arguing over the wrong details or focusing on the wrong features, and managers do sometimes waste our time and short-circuit our brains right in the middle of solving gnarly problems. There is much to criticize about agile methodologies and how we’ve been trying to run tech teams for the past two decades. But what I keep coming back to is this: throwing out all aspects of what makes work inherently human is not the answer.

Take for example, one of the lynchpins of good software development: the PR process. Historically, having a good team rhythm around PRs can make or break a team. They’re necessary, but can be a real PITA, depending on the make-up of the team, who’s leading it, and the amount of pressure you’re under to increase velocity. In my experience, confident engineers love reviewing PRs or having their own code reviewed, but less experienced or more easily intimidated engineers find the experience daunting, exhausting, and sometimes truly upsetting. It’s supposed to be about validating the appropriateness of the code, not a personal judgement about you and your ability to write code, but we all know it sometimes feels that way. An over-confident peer can consciously or unconsciously become a total bully in the comments, and send you spiraling into reactionary panic, defensiveness or self-sabotage. Having your handiwork under so much scrutiny, or directly challenged, can put a serious dent in your self-esteem.

The beauty of AI agents, in this case, is that the AI wrote the code, not you, so there’s literally nothing to defend or worry about: your team will be reviewing code generated by an algorithm with no ego and no such thing as self-esteem. And as long as the code was primarily or entirely generated you won’t feel directly responsible for any errors or omissions. You will probably still shoulder some blame if the code is really bad, but at least you don’t have to take it personally. You know it was just a dumb robot.

On the other hand, when you’re tasked with reviewing someone else’s PR, it can be a real time-sink. There are best practises that should be adhered to, like making sure a PR only encapsulates small, well-scoped changesets that are easy to parse, and providing clear descriptions of the goals, constraints, and challenges, but we all know how easy it is to fall out of these good habits and end up with verbose spaghetti involving huge refactorings that are hard to grok. The onus on the reviewer can be extremely taxing, and take them out of flow for long periods of time, which of course has a downstream impact on sprint velocity and burndown for the whole team.

Ironically, despite the fact that AI coding was supposed to make us all more efficient, AI assistants, copilots, vibe-coding IDEs like Cursor, and fully agentic rube goldberg machines like OpenClaw have turned code review into more of a bottleneck than ever. We’re now churning out so much code with so much (unnecessary) verbosity that code review is now more like reading complex case law: there are so many structural and syntax changes in a single stream, some relevant, and others completely hallucinated, that no human reviewer can realistically expect to catch every bug or deviation from code norms. It’s no longer enough to evaluate the appropriateness and effectiveness of the code, you now have to exert energy and attention to questioning whether the code is even real.

So why not avoid PRs altogether and let the AI coding agent open and review its own PRs? Developers who don’t like the process can delegate all responsibility to the AI, and developers who just don’t have the energy or the bandwidth to keep up with the sheer volume of changes coming down the pipeline can do the same. There are lots of options to choose from in terms of AI-powered code review tools that you can fully delegate to. This is the solution espoused by the folks over at Engineering Leadership, which I find quite preposterous. I just don’t buy it. You’re going to solve the problem of too much verbosity and complexity in AI-generated PRs…by adding another layer of AI to the process? In other words, we never liked code review anyway, so why not skip that part and focus on the more enjoyable parts of being a software engineer?

Except that, isn’t AI gradually encouraging us to skip all the parts of software development? If we’re no longer writing the code, and no longer reviewing the code, what’s even left for us to enjoy? The fashionable retort is to say that hard-earned skills and knowledge about what syntax to use was never the job anyway, that tomorrow’s software engineers will be prized for their discernment, judgement, and taste: qualities that can’t be approximated by the likes of a next-token prediction algorithm. So it is that spec-driven development is the new development philosophy du jour, which might make even a level 1 developer feel like they’ve risen to the height of a senior architect, but are you seeing that change reflected in your salary and job title? I’ll wager that most of us are not. And besides, like anything else in a non-deterministic system, a spec is just a suggestion for the algorithm to follow, not instructions embodied as hard rules once it’s been transformed into photons. Specs can be misinterpreted, ignored, or completely hallucinated. So you may end up being just an observer of something built that doesn’t even conform to your blueprints. You can take the credit I suppose, but you ordered that code from a vending machine, you didn’t architect it.

What’s really happening when you accept AI as a primary driver of your work is that you’re being systematically deskilled. You’re being reduced to the function of an AI supervisor, or AI janitor. Instead of using your own knowledge, skills, and instincts to solve complex problems — the job you probably signed up for — you’re spending more time waiting for the AI to burn enough tokens to arrive at a solution on its own and then pressing “enter” to accept the changes. After a while, you’re likely so bored and tired from being so passive in your role that you no longer care about the quality of code being generated, and suffer from what has been coined “brain fry.” In the end, all this results in is a generation of developers who can’t even debug their own code.

Is this really better than arguing with coworkers and attending a few meetings? Of course, I’m not suggesting the only motivation for using AI in software development is reluctance to work with humans, but I can’t discount it as part of the equation. I’m generalizing, but we can be an anti-social bunch, because our brains are wired for solving esoteric puzzles, not playing nice with others.

I do think there’s also an element of Stockholm syndrome, based on the seeming inevitability of the AI industry, and the overwhelming power dynamic stacked against us. But I also see a kind of rabbit-in-the-headlights reaction to AI advancement from developers who tell me they’re proactively trying to find reasons to jump on the AI bandwagon even though they have severe misgivings about the doctrinaire attitudes of their employers and the unethical sourcing and outlandish behavior of AI companies. I can read between the lines when they’re pouring praise on certain aspects of how they work with AI: it’s always about how quickly they can get from concept to prototype without the friction of communicating their intent or asking anyone’s permission, it’s always about how much more accomplished they feel when they’ve spent the whole day burning tokens instead of sitting in meetings. I get it. I really do. I’ve spent a good chunk of my own career wishing for the same autonomy and unfettered productivity. But I think it’s mostly illusory and taken out of context. And the ultimate price for this grossly exaggerated sense of progress is going to be too high.

For one thing, the more we appeal to the idea that we can just work alone with a bunch of AI agents, the more we’re in danger of reinforcing nefarious leadership beliefs about the logic of conducting mass layoffs. The more we’re showcasing how much more code we can produce on our own with an AI assistant, the more we’re justifying our own replacement. Believe me, there are plenty of managers and CEOs out there who also dislike working with humans, and they’d rather they didn’t have to lay eyes on you or pay you ever again. Teamwork means nothing to them.

Am I saying SWEs should resist AI tooling as much as possible and embrace the messy friction of working with humans instead? Maybe. If you can without losing your job. I certainly think you’ll be better off in the long-run, both financially and psychologically, if you avoid the allure of automating all your work, continue to sharpen your own development skills, and position yourself as one of the future fixers of our broken internet. At the same time, even if you have to play the part of good AI lapdog during work hours you could do worse than to spend some after hours time to build up your human skills to prepare for a world where good communicators are in short supply and badly needed. At the very least, try to be very, very aware of how and when you’re outsourcing your decision-making and judgement to the machine, lest you become completely subsumed or replaced by it. We shouldn’t allow the future to be dictated by leaders who don’t seem to care about society or culture. Even though the workplace may seem pretty inhospitable at times, I promise there are still cool people out there who can make your work more rewarding through collaboration and shared experience, even if you’re naturally introvert and find it hard to make friends. It’s not easy, but it’s worth the effort, and at the end of the day we’re usually building for people, right? So we can’t afford to ignore them even if it sometimes seems easier to do so.

As an Engineering Manager, I was always under the impression that employee performance was to be measured in terms of team and company impact:

• How effective is this employee as a functional member of the team?

• How has this employee contributed to the success of the organization?

With lots of nuance, of course, but generally all boiling down to those two metrics.

The problem with measuring these things in 2026 is that “AI-first” strategies are making a mockery of it all.

Firstly, software engineering is becoming much less collaborative and more of a solo activity. For most of my career I tried to break down silos, and championed communication and teamwork, only to witness the emergence of AI copilots that replace co-contributors, and automated workflows that replace peer review. And vibe coding has more or less spelled the end of developers prioritizing quality and accuracy over speed and convenience: there is dwindling motivation for developers to plan, discuss, and share their progress with one another or maintain team standards and coding norms beyond what can be achieved using automated linters and agent spec files. Devs have always had a reputation of being solitary and aloof, but what was once merely a stereotype is now in danger of becoming ingrained. So how does a manager evaluate a team member when the team itself is barely a shell, an org chart of people who don’t really talk to each other or share any common ground? Don’t pretend this isn’t happening.

Secondly, there’s growing concern that excessive outsourcing to AI is impairing workers and leading to the loss of skills over time and possibly even some cognitive impediment and loss of confidence, and the loss of comprehension in software engineering is becoming more and more apparent. How can one measure employee growth when they’re literally shrinking backwards into AI dependency and mental atrophy? What new skills are being developed when the only skill being used is writing a prompt and setting up a Ralph Wiggum loop? What impact can a siloed individual have on the rest of the organization? What obstacles are overcome to cause the personal and professional growth of the individual who exerts practically no effort to achieve their goals? How does any one individual using AI stand out from any other individual using the same AI?

Third: so much AI-generated code actually doesn’t contribute to the success of the company. So even the idea of focusing on outcomes rather than contributions becomes a non-starter. What do we measure when every team with an AI mandate is essentially failing, most of the time? When even the so-called AI productivity boost is merely a mirage? It sounds almost comical. The only way to guarantee a win with the current crop of AI tools is to pick very low hanging fruit: automate rudimentary processes that are easy to predict, easy to automate, and avoid letting AI near any critical systems. Some safe bets, duplicated by thousands of companies at this point, include customer service chatbots, automated data scraping and sentiment analysis, or (poor quality) content generation. Many AI projects are barely more sophisticated than what was achieved with regular natural language processing a decade ago. Most CIO’s don’t even know the difference between a true AI agent and a basic automation workflow in N8N or Zapier. And most corporations are woefully unprepared for anything more advanced because they don’t have their house in order. At the end of the day, the normal reaction to so many AI feature announcements should be: so what?

Managers know this, even if a complete lack of job security means they’re too afraid to acknowledge it. 96% of corporate initiatives fail, and the customers we’re designing for are actively resistant to AI. But CEO’s have become so authoritarian and misguided in their AI fantasies that they won’t stop pouring investment and resources into AI projects no matter how many of them fail. Like something straight out of a Kafka novel, any manager in charge of a failing AI project is going to be held accountable, even when the work involved was entirely vibe coded, and all evidence and common sense always pointed to the inevitability of failure. So how is the success of AI work measured in the Twilight Zone between hype and reality, and how does one keep one’s head? Probably through masterful manipulation of the truth and crossing one’s fingers: become best friends with the CFO and make sure your numbers can be fudged enough to save your team from elimination.

We’re so confused and defeated by the onslaught of AI-first thinking, devoid of reason or common sense, that we’re going back to measuring developer progress in terms of lines of code, number of code commits, or number of open PRs. This is completely backwards and undoes decades of progress that helped software development evolve from an unglamorous factory process into a serious and respected craft. In 2026, instead of methodical, analytical, and thoughtful software design, we’re going back to performative productivity that leads to brittle, insecure applications and crippling tech debt. We’re prioritizing convenience and making business owners happy, rather than staying focused on security, uptime, and stable business operations. Mark my words: this won’t end well for anyone.

And even if you somehow manage to come out of all this with some kind of rubric for measuring one team member’s success outcome, how do you reward them? The technical career ladder is fast losing all its rungs, ascending nowhere as AI adoption brings about the great flattening. Won’t future SWE’s be managed by a supervisor algorithm like Amazon warehouse employees? And won’t they in turn be supervisors of AI agents by default? If so, where is the advancement opportunity? Software Architects and Staff Engineers only make sense in a system that respects human judgement and expertise, which can hardly be expressed in cave-man prompts, and middle managers seem to be heading towards extinction. As for the CTO, what role can they possibly play in this new AI-dominated world, except as a punchbag or sponge for the CEO?

We’re heading off a cliff if we continue to put AI first and humans last. Not only are the current trends ruining careers and sinking profits, we’re also cutting off a future pipeline of talented engineers by pretending that “AI skills” are more important than a solid foundation in software engineering principles and best practices. We’re being steamrolled by the C-suite into jumping on the AI train blind-folded with our hands tied. We’re not pushing back on the hype and we’re not including the slide in our powerpoint demo that shows how the project failed because AI was too incompetent.

Heck, we’re even being explicitly told to keep doing our jobs under extreme surveillance until such a time that AI can replace us. We’re training our own proposed replacements on the remaining borrowed time that exists in our apparently soon to be cut-short careers. Even Black Mirror didn’t predict this distinctly dystopian outcome.

The only way out of this surreal nightmare, as far as I can see, is to find the courage to start talking honestly about the lackluster nature of what we’re really dealing with. For some of us that means we need to wake up from the fever dream of AI inevitability and start documenting the failures as they happen in real time. When we meet with our peers and leaders we need to be honest about the inadequacies of this technology and the negative impact it’s having on us and our direct reports. We have to sound some kind of alarm that work culture is being eroded and talk about how we might be on a path that leads to mistakes we can never undo. And if all that sounds too human-centric and you think your superiors might not care, perhaps work on communicating how AI is a security nightmare, or how costs are rising exponentially as the bill comes due for the extreme data center and GPU costs of the models that are now married to all your systems. Show them the proof that there’s no ROI you can measure, only magical thinking and waste. Not in a dramatic way that would seed contempt and burn bridges, just lay it all out there and don’t dress up the truth to make leaders feel better about their complete lack of foresight or common sense.

I know all too well about the fear of being fired for speaking up, but if we’re all headed that way anyway, even if we acquiesce, isn’t there a reason to risk it? The alternative looks like slow decay and burnout, maybe even PTSD. And you deserve better than that.

“Don’t bring me problems, bring me solutions!”

If your manager says this, you might be working for a bad boss, or working at a company with an irrational, unpleasant culture.

It’s one of those phrases that sounds good and authoritative. You might even interpret it as a positive endorsement for developing a problem-solving mindset and exercising personal autonomy.

But the flip-side of this coin is that your manager is effectively saying: “If you don’t know the solution, don’t notify me of any problems.”

That’s incredibly short-sighted and elitist. If a manager always expects the same person who reported the problem to also fix the problem, they’re going to be in for a lot of disappointment, because the real-world doesn’t work that way.

There may be all kinds of reasons why an employee might shout “fire!” without having the necessary skills or equipment to put the fire out. That doesn’t mean they should sit in silence and suppress the urge to raise the alarm while everybody succumbs to the smoke and flames.

Imagine if you work at a company where you’re writing software for a payroll system and you found a bug that will cause hundreds of workers to be underpaid or overtaxed, but you don’t have the knowledge, skills, the right access to the relevant systems, or enough time to fix it yourself. Obviously there will be some pretty bad fallout if you just let the problem go unnoticed. You have a moral and ethical responsibility to raise awareness of the problem, and any manager who puts up barriers to that is unprofessional and negligent, at best.

My advice: whether you have this type of boss or not, always ask yourself if you can solve the problem, but don’t assume you must become the hero. If you do know how to fix the problem and the fix involves you temporarily drifting away from assigned tasks you should keep your manager and immediate coworkers in the loop. Ask for clarity from your manager if you’re not sure whether or not fixing the problem is higher priority than what you were already working on.

If you don’t think you’re the right person to fix the problem, you can use your knowledge of other teams and departments to locate other people who might be better positioned or equipped to deal with whatever problem you’ve identified. Be a good team player and offer to assist them if they would find that helpful.

Either way, alerting your manager to the problem shouldn’t be blocked by a need to always be the expert of any system where you’re finding a bug. Identifying problems before they’ve wrecked havoc is an incredibly valuable contribution to your team and organization and shouldn’t be ignored or dismissed for any reason.

In the cyber security realm, companies periodically perform red-teaming exercises, where the point is to stress-test the security system and find flaws so that they can be fixed. I think more software engineering teams should adopt this practice because it would help to identify more quality or accuracy issues in critical code, and it would help to institute this idea that finding problems is a healthy and necessary part of the software development life cycle that doesn’t need to be burdened with the dogmatic demand to always offer solutions.

What this might look like in practice: perhaps once per quarter, each development team takes a few hours out of their normal work to “attack” the user interface, the data store, the testing infrastructure, the deployment tools, and any other working part of the overall system, with the goal of finding bugs and limitations. Later, everyone switches to the role of solution finder and you work collaboratively to fix the list of problems raised during the exercise, or at least write up stories/tickets to fix problems at a later date in accordance with your roadmap.

You’ll probably find that some people are better at identifying problems and some people are better at fixing them. You need both kinds of people on your team. In this exercise, person A might find a problem that person B can fix. And person C might find a problem that person C and person A can fix by working together. This normalizes the idea that not everyone can be a problem solver all of the time.

The manager can learn to deal with it!

I didn’t know I wanted to be a Tech Lead, or that I’d be any good in the role. I’d been a Senior Software Developer for several years when my manager pulled me aside one day and told me he thought I’d make a good leader and that he’d promote me to having direct reports if I wanted to go that route. At the time, I was so content with slinging code, grokking docs, shaving yaks, hunting down Heisenberg’s, and butting heads with designers and project managers on the frontline that the idea of leading a team hadn’t really crossed my mind. But we had a weird work culture where it was considered anathema to say no to any management suggestion — it could get you excommunicated to another team, or ostracized and passed over for special projects, and you’d be blackballed as a non-team player. The head of HR literally used to make a point of saying “The word ‘no’ does not exist at our company.” So of course I said yes and hoped for the best.

As it turned out, my manager was one of the good ones and his instincts were correct. I really enjoyed learning how to read people and how to support them. I took the challenge very seriously and had to put in a lot of effort on my own because there was no formal leadership program or much in the way of company-directed training. I had to lean on my “soft skills” much more than at any other point in my career and through trial and error came to recognize that my team had a host of human needs that stretched beyond tools, time management, and coding proficiency and that I instinctively wanted to help solve these problems. Even though I’m an introvert, I discovered hidden reserves of energy and a latent passion for deploying empathy that allowed me to thrive and make genuine connections in our small team setting.

But I honestly struggled in the new role because of how it had me juggling too many (non-complimentary) responsibilities at once. As Team Lead/Manager, I had taken on the duty of weekly 1:1s with team members, and official management activities like conducting annual 360 feedback, bi-annual company alignment check-ins, quarterly salary reviews, weekly code reviews, and organizing team meetings and events. The number of meetings I had to attend myself as part of a larger group with other leaders and stakeholders grew by 100%. At the same time, I was still expected to be a major contributor to our codebase and development standards, own our team roadmap, be the primary developer on some large projects, oversee architecture decisions, and hire and onboard any new team members. To pour salt in the wound, the “promotion” didn’t come with any kind of immediate raise. Part of the myth of management is that becoming a manager is an instant status boost and launches you on a course to becoming the CTO one day. But most of the time this simply isn’t true: management in the tech industry is a lateral move into a new career path, not a step up the ladder. You have to prove yourself all over again by establishing your proficiency and delivering results before earning new salary increases. And not every manager will go on to middle management and beyond, in fact, many line managers flame out and decide they don’t like the job and end up going back into a pure development role.

For better or worse, I stuck it out for years, trying and mostly failing to strike the right balance. Sometimes I was able to direct a lot of energy toward empowering and cultivating the team but would neglect my coding responsibilities and fall behind in projects, or conversely, I would get so heads-down in a development task that I wouldn’t be accessible for days and I’d be late for 1:1’s or miss them completely because I’d unconsciously dismissed the calendar notification as a nuisance while staring at my IDE and wrestling with some programming problem. This is why I spent the last two years in that role trying to convince my manager to assign someone else as Tech Lead instead and to allow me to be a dedicated Engineering Manager. As I’ve written about before, the Tech Lead and the Engineering Manager are really two distinct roles with very different requirements and one person can’t reasonably perform them both at the same time without causing more problems than they solve. It wasn’t until my job title finally changed to Engineering Manager that I felt truly empowered in my role and able to focus on the important work I wanted to do.

Code or people: choose one

So if you’re reading this and you’re considering a move into engineering management or have been offered an opportunity to take on that role, the first question to consider is: do you want to lead people or do you want to write code? Think carefully about this. Understand that a great manager needs to index on people, not code or tools. It’s a completely different mindset — one that’s more about encompassing the needs and perspectives of others rather than being rewarded for the impact you have as a technical problem solver. If you want to avoid the trap of being expected to wear both hats at once, you should clarify with your employer how they define the role. If you're lucky, your employer will comprehend the difference between a tech-focused team leader of peers and actual people management. If you’re not lucky, you may have to grin and bear it for a while like I did and gain as much experience as you can while learning about yourself and the role, or you can always wait for a better opportunity to come along.

I can’t hammer this home enough: as Engineering Manager you should not expect to be writing much, if any, of the code on your team. Any manager who is still dictating the code and coding standards for the team is either in the unfortunate predicament outlined above or is being led astray by toxic beliefs about what makes a good technology leader. You’re not measured on your own individual contributions to the codebase anymore; you’re measured in how well the team performs overall, how much work the team completes, and to what extent the team meets or exceeds its goals. You have to let go. You have to delegate. You have to be okay with trusting other people to do the work — even when they approach the work in a way that is different from the way you’d handle it. You need to be aware of your own biases and make sure you don’t try to influence the direction of your team so much that individual autonomy begins to decay. If you do assert your own ideas too much, this will lead to a kind of agency atrophy whereby your team will cease to know how to perform when you’re not there to explicitly guide them. Turn your team into robots that only follow your orders, and guess what? They won’t know what the heck to do when you’re out sick or take a vacation. That won’t end well for anyone. In the same vein, you really need to try not to become the single source of information or domain knowledge for anything that the team is responsible for. It’s fine to have a good understanding of everything your team is working on, but you shouldn’t be the go-to person for critical knowledge of any systems under your purview. Why? This also erodes the autonomy and confidence of your team to be able to operate on their own without you needing to be present at all times, flipping switches and pulling levers as if they are just worker bees that you control. Your reports need to be armed with all the knowledge they need to thrive in their roles. They don’t need you to be the gatekeeper to sacred knowledge or to act as an oracle they must all go through in order to achieve anything. Be a conduit, not a blocker, to your team.

Welcome to the dark side

As an Engineering Manager, you’ll be exposed to a lot more office politics, you’ll be interfacing with middle managers, other engineering managers, and other stakeholders on a regular basis and you will learn things about the inner workings of the company that you don’t like. You will encounter chaos and discord at the higher levels and you are bound to become somewhat disillusioned. This is normal. Truth is, corporate America is completely dysfunctional and many executive leaders get to lofty positions not by merit but because of tenure, networking, and in some cases simply kowtowing to the CEO. As soon as you step into a leadership role, this dark underbelly will start to be exposed to you and you’ll need to learn how to navigate the culture, deal with the surprises, and compartmentalize the contradictions and ethical concerns — all without becoming angry, uncivil, or too jaded to keep doing your job. Most importantly, you will need to shield your downstream team from the worst of it so they can carry out their work undistracted by things outside their control. You’re peeking behind the curtain now but if you want to keep your employees happy it’s best if they remain somewhat removed from and ignorant of these upper-level realities.

And it’s not just the internal culture flaws that you must filter for your direct reports, there will also be many operational hurdles. You’ll run into schedule conflicts with other teams, you’ll encounter unsympathetic stakeholders who blame your team for being too slow or for blocking them, there will be leadership changes and reorgs that temporarily throw everything into disarray, there will be disagreements with project managers over timelines and scope, there will be sudden strategic pivots that sideline or scupper your current project, and key priorities that shift without warning. Another myth dispelled here is that as a manager you will have more power and influence in your organization. Sorry to tell you that you’ll be up against just as much inertia as ever before. It’s more about empowering your team than gaining power for yourself. Try to focus on that and don’t let the often demotivational and unsupportive executives at the top get you down. Part of your job as the line manager is to constantly stay balanced while the ground beneath you is erupting into lava, finding creative ways to minimize the disruption to your team in terms of productivity and morale. Have you ever heard the euphemism “be a shit umbrella”? Yeah, that.

Some other challenging aspects of the role include:

• Delivering critical feedback to direct reports: you may have been their peer in the past, but now you’re in a position to influence their career for better or worse. You have to give guidance on any areas where they need to improve or any rough edges that need ironing out with the goal of a smooth-running team. You need to become comfortable with uncomfortable conversations.

• Dealing with interpersonal conflicts among team members: you may have an impulse to become a referee but sometimes that only makes things worse. You may have to get HR involved and things can escalate in unpredictable ways. You will feel responsible even if matters are out of your hands. HR may not resolve the problem and it may just bounce back to you. You will sometimes be swimming in murky waters and faced with all kinds of ambiguity.

• Meeting fatigue. Whether you are in-office or meeting on Zoom, your meeting time is going to shoot up. You’re going to have days when you’ll pray for the next meeting to be canceled just so you can rest your brain or get to work on something interesting that you keep having to neglect.

• You’re probably going to miss coding and may be envious of some of the cool projects your direct reports get to work on and accomplish. You have to fight the urge to step in and take over, even if your instincts tell you the team may not be approaching the project in the most optimal way. You can guide and mentor but you also have to leave room for people to learn from their own mistakes.

• You will need to hire people and may have to fire someone. The former is an arduous task that can take a lot longer than you might think and requires a whole set of interviewing and analysis skills that may not come naturally to you at first. The latter can be emotionally charged, and I won’t lie, can leave you with lingering trauma and self-doubt.

• Decisions, decisions, decisions: sometimes you’ll run a democracy and allow everyone on the team to weigh in on a decision that needs to be made, but other times you’ll have to make a decision on your own that could impact someone’s career or the outcome of an important project, and you’ll own the consequences — good or bad.

Shift your perspective

As an individual contributor, you may have spent a percentage of your time collaborating with coworkers on a shared codebase. You may have experienced pair programming. You will have spent a good deal of time reviewing code as a team and giving each other advice in GitHub pull requests. And if you worked in a physical office you probably all went to lunch together quite often. Hopefully, you worked on a team with a strong tribal identity and a good amount of camaraderie. As a manager, you’ll still meet with the team and you can still take a peek at the code, but your relationship with your direct reports is now more complex and involves unavoidable power dynamics. Much more of your time will be spent on your own or with people outside of your team: planning future work, reporting up the chain, assimilating company-wide news and information so you can figure out how it impacts your team, organizing team-building exercises or events in advance, working on formal administrative tasks like performance reviews and salary appraisals. You may find that you no longer get invited to lunch so often. The team needs their own space to be human with each other away from the possible scrutiny or judgment they feel is naturally going to emanate from you as the leader.

You’ll need to dedicate some time to a different learning path than the one you’re used to as an individual contributor. Instead of learning your way around the codebase and systems and helping to envision the future of the applications under your purview, you’ll need to spend a lot more time learning about the overall business, understanding how the financial numbers impact your team, getting to know the different strategies and processes that underpin the business and learning who the key players are in each department. That’s because part of your job is to help your direct reports understand how the work they do ties into the overall goals of the company. Knowing how their work aligns with tangible business objectives helps provide employees with a sense of purpose and a sense of how their work impacts the organization, your customers, and the world. This is much more satisfying for employees than just dropping completed work into a black box and moving on to the next task. They are an important player in the larger game of your business, not just a worker drone. You don’t want employees to feel like tiny, easily replaceable cogs in a vast machine they can never comprehend — that would be dehumanizing and uninspiring.

The personality quirks and qualities that made you a brilliant Software Developer won’t necessarily help you be an effective manager. To stand out in a leadership role you should be humble, honest, open-minded, psychologically strong but flexible, sometimes vulnerable, and always empathetic. You’re not paid to be the smartest person in the room anymore, you’re paid to get the best results out of the people who report to you so that everybody wins. As an engineer you may have indexed heavily on coding prowess and proficiency and you may have been consciously or unconsciously biased against peers who didn’t seem on par with you. You may have believed that coding ability is the most important or the only important skill for a developer to possess. But when you become a manager you need to put your ego aside. You need to understand that a successful team needs all kinds of operators. It’s not enough for your developers to be good at writing code, you need some of them to excel at communicating complexity, advocating for themselves and others, building rapport with coworkers and stakeholders, building vendor relationships, taking ownership of projects and processes, giving great peer feedback, cultivating healthy team norms, and speaking up about important issues that impact their work. And the only way you’ll recognize any of this is if you’re able to observe the team through a leadership lens rather than a purely technical one.

Eye of the tiger

Your on-the-job training and after-work learning will need to change: instead of watching tutorials on new coding paradigms or frameworks, learning design patterns, or practicing leet code or coding kata’s, you will need to start reading books and newsletters on management and leadership and taking online courses on subjects as wide-ranging as:

• How to actively listen and engage people in a 1:1

• How to present complex ideas and build consensus around them.

• How to communicate clearly and concisely without bias.

• How to manage up.

• How to give timely, effective feedback.

• How to conduct efficient, humane interviews.

• How to detect and deal with drops in employee morale.

• How to be an empathetic, trauma-informed leader.

• How to manage people who are neurodiverse.

• How to manage introverts.

• How to manage employees who are older than you.

• How to maintain an inclusive team culture.

• How to cultivate psychological safety.

• Detecting and avoiding employee burnout.

• How to motivate remote teams.

• How to encourage team camaraderie.

• How to take a team through the stages of forming, norming, storming, and performing.

I would also recommend reading books on work politics, world cultures, psychology, sociology, and religion. You are in the business of understanding and motivating people now, so you need to try to understand what it’s like to see the world through their eyes. A positive work environment requires treating employees like people, not just a resource. You can only do this by making a concerted effort to get to know them as unique individuals and learning what motivates them to be their best at work. This requires making an effort to maximize your communication skills and spending plenty of quality time talking to and listening to your direct reports. This isn’t a job for someone who prefers to spend most of their time working with machines or reading documentation.

The role of Engineering Manager can be hugely rewarding if you’re the right fit, if you go into it knowing what’s required of you, and understand how it differs from software development or the role of Team Lead. I’ve written before about how gratifying it can be to put effort into growing your team and seeing the results. Learning how to be an effective leader who not only delivers results to the company but builds a legacy of being the kind of person people want to follow is a truly transformative experience and worth pursuing despite how difficult it is. However, I’ve witnessed far too many instances where a company has promoted the wrong person into management, which can have far-reaching consequences for years to come. When a team gets an Engineering Manager who is too technically oriented and not able to communicate and empathize with their direct reports on a human level, employees find themselves ranked only by their hard skills and not recognized for the other qualities they bring to the team. In many cases, this happens because the middle managers in tech are themselves part of a broken lineage — unqualified Engineering Managers who in the past were promoted despite having no proven track record as effective leaders — so it is a self-perpetuating syndrome that frankly a lot of companies have been infected with. The solution is to lead by example: get promoted for the right reasons and build a future middle management layer that is made up of human-first leaders instead of toxic techbros or people who are just not self-aware enough to recognize they're not right for the role. Eventually, we need these effective leaders to move up into Director and CTO roles instead of the typically apathetic, zero-sum, cold calculators or CEO “yes-men” we invariably see being promoted into these roles. I think that’s how you build a tech culture that is nurturing, inclusive, as well as highly effective, instead of toxic and only effective because it’s hard for people to quit high-paying jobs. I don't know if there are many good examples of this out there in the world right now, but one can always hope.

The myth

I’m not writing this simply to refute a newsletter with over 10,000 subscribers, and I don’t disagree with everything Zaides wrote, but I am disappointed to see someone with such a large following perpetuate (perhaps unknowingly) what I think is a harmful myth in the tech industry: that Engineering Manager’s need to be very hand’s on in order to be effective leaders. What Zaides calls the slow death of the hands-on manager is actually a good thing. All too often, organizations fail to understand that the engineering manager is not a tech lead. 

Recently there has been a resurgence of this myth of the hands-on manager, with tech companies advertising roles that expect a manager to divide their time between substantial individual contributions to the codebase as well as handling all the responsibilities of a people manager—which is untenable and creates managers who succeed at wearing one hat but fail at wearing the other. 

To make matters worse, behemoth tech company trendsetters like Amazon are planning to do mass layoffs of managers, undermining the purpose and value of management altogether. I predict this is going to backfire on Amazon because other big tech companies have already experimented with working without managers, and it didn’t work. But it’ll cause a lot of career damage while they find out the hard way.

[Aside: I’m not saying that operating without managers is impossible. There are some intriguing case studies such as Morningstar that seem to have pulled it off—but they have a very different corporate culture that is people-first and egalitarian, the total opposite of how totalitarian companies like Amazon tend to function.)

Zaides says that there are two types of engineering manager:

1. Super hands-on - they take tasks in every sprint, know the codebase, and help the team fix hard bugs.

2. Full-time managers - attending meetings all day, having 1:1s, zero coding time.

Reality

In my opinion, example 1 above describes the role of a Tech Lead, not a manager. Example 2, whether you like it or not, is more realistic in terms of what an actual Engineering Manager should expect. Think about it: if you’re leading a tech team that consists of smart and talented software engineers that you have hired for the role, why would you need to spend much of your own time coding? And why did the organization hire you or promote you as a manager if what they really wanted was another software developer? No, what your team needs from you is oversight, guidance, coaching, mentoring, support, career advice, someone to set an example as an attentive, empathetic, and authentic leader. Trust your team to write the code, that’s why you hired them. 

Zaides goes on to say that Engineering Managers should find small coding projects to work on in order to stay sharp and technically proficient—and I have no problem with that. I totally agree that if you can fix bugs, create little apps or efficiencies to save time, or cut down on monotony and repetition it will benefit you and your team. That’s a cool and generous thing to do. Not only does it keep you up-to-date on new coding practices, languages, and frameworks, but being able to understand the code your team members are working on will validate your ability to empathize with them much more than if you never opened an IDE. Your developers will appreciate you being able to speak their language and grok the problems they are trying to solve. But staying outside the critical path is crucial, I can’t stress that enough. If you end up distracting the team too much by having large changesets that need reviewing, development branches that prevent code deployments or anything that causes major fires in production you are going to earn resentment and distrust from your direct reports.

Environmental hazards

You must also beware of the trap that any side work in code could severely distract you from your core responsibilities as a people leader. You should never let a code project make you unavailable or inaccessible to a direct report who needs you to be their leader at any given time. If you’re too heads-down and in the flow state when your team needs you to help with an overall strategy, facilitate an important discussion, make a critical decision, or handle a tough interpersonal conflict among team members, you will end up having a detrimental effect and you won’t build a good reputation as a manager that people want to work for. And I say this from experience, because I’ve worked as a manager/tech lead who was very much a front-line code wrestler while simultaneously trying to lead from the back, and it was a world of hurt for both myself and my team.

Another thing, be careful that you’re not projecting an air of superiority: maybe you were the smartest person in the room when you were a software developer, but you’re supposed to be a humble leader now. Don’t behave narcissistically and try to portray yourself as the expert who sets all the standards that your developers must adhere to. They need room to experiment, learn and grow, through trial and error and the right balance of autonomy and guidance. It might be okay to be a smart-ass when you’re a developer, but not so much when the people whose career is in your hands need you to be open-minded and in possession of a growth mindset. 

You should also be aware that your own manager may be a believer in the myth of the hands-on manager, because, as I’ve written about before, this is kind of an institutional problem born from a toxic tech idea that real techies are always coding and that soft skills aren’t as important and don’t require any effort to cultivate. The truth is, that developing the soft skills of a great manager is a whole journey unto itself and shouldn’t be taken lightly or neglected. Learning how to relate to people, how to motivate and inspire them, how to read them, and detect problems that prevent people from being their best at work is something you absolutely should be committed to if you want to become an effective leader. You’ll be doing yourself and other managers in your organization a disservice if you act in a way that undermines the value of people management. If you put little energy into the essential work that managers should do on a team and focus instead on writing code you’re sending a signal to upper management that your role isn’t very critical at all and maybe, just maybe, they should save some money and emulate the Amazon way in future. 

Choose the right path for you

In my opinion, if you find yourself missing the code wrangling so much that you resent having to close your code editor to have a 1:1 meeting or deal with some managerial overhead then you probably shouldn’t be in the role of Engineering Manager. You might want to consider moving back into a software development role. In this case, there’s no shame in recognizing that you have more passion or affinity for one track over the other. Either track can lead to future career growth and higher earnings, so there’s really no reason to force your round self into a square hole. 

Okay, my eyebrow is hurting so I’m going to lower it back down now. Leading Developers has some worthwhile content and I hope Anton Zaides will appreciate that I’m not trying to start a flame war, just adding to the conversation. Thanks for reading.

Sometimes decried as a waste of time or just another layer of management bureaucracy, the one-on-one meeting certainly comes under a fair amount of criticism by managers and employees alike. However, as a Software Engineer and Engineering Manager, I saw it as a necessary and critical component of running or operating inside a healthy, happy, and engaged team. It also establishes accountability on both sides. The key is for the manager to approach this meeting from a human-centered perspective, with the objective of unlocking human potential, rather than seeing it as an opportunity to micromanage or assert one’s own agenda. 

When done right, the one-on-one meeting can be a wellspring of trust and understanding, a powerful channel for the manager to connect with their direct report with the aim of supporting, coaching, and helping them navigate daily work life and guiding them through the various challenges of their career. For the employee, it’s an opportunity to be seen and heard by leadership, to ask questions and raise concerns, and to align their skills and values with the goals and temperament of the company through the wisdom, perspectives, and insights shared by the manager. 

When done poorly, the one-on-one meeting can be a sinkhole of despair for either or both parties: it can be a source of frustration or insecurity for the manager, and for the employee, it can trigger anxiety, paranoia, or resentment. It’s vital that both manager and employee make this meeting work because it forms the backbone of how they perceive each other in the workplace context and builds the foundation for all their other interactions.

In the notes that follow, I tend to write about this topic mostly from the manager’s point of view, but I’ll offer some employee perspectives as well.

Purpose of the 1:1 Meeting

From the manager’s perspective, a 1:1 meeting should be:

• Most of the time, an enjoyable, rewarding conversation that you have made psychologically safe for your direct report, where you are actively listening and defaulting to trust, and seeking to understand before making any snap judgments.

• An opportunity to build a more layered picture of your direct report as a human being: what motivates them, what aspirations do they have, what do they appreciate in life, what are their priorities outside of work? You should always spend some amount of time just getting to know them as people. You can do this with minimal effort.1

• A chance to build more layers of trust and mutual respect, which will pay dividends as soon as you and the team encounter a challenging project or unexpected obstacles.

• A conduit for learning about problems on the team, hopefully before they get too unwieldy or perilous.2

• A specific time and place for following up on any previous issues, challenges, or questions that were discussed in another meeting. 

• An opportunity to act as a coach or mentor for a particular type of task, skill, or behavior. 

• Periodically, a time to discuss your direct report’s career aspirations, even beyond the role that they have now. 

• A time to celebrate any recent achievements or to encourage them to reach their goals.

• Sometimes, a good way to gauge interest in upcoming projects, or get early feedback and a different perspective on a strategic, operational, or technological decision you need to make that will affect the team.3

• Occasionally, a chance to offer timely, relevant and nonambiguous, constructive feedback.

From the employee’s perspective, a one-on-one meeting should be:

• Most of the time, a comfortable, safe conversation where you check in with your manager without anxiety or fear of reprisals for anything you might share. You should have the undivided attention of your manager for the duration of the meeting.

• A chance to be seen and heard: ask any questions you have about how you’re being perceived on the team or in the organization. Raise any concerns that you have about life on the team or in the wider organizational context.

• An opportunity to learn from your manager in a coaching or mentoring capacity: this could involve guidance with either hard or soft skills, or help in navigating the politics and social mores of the company.

• A time to seek advice: get your manager’s opinion on work-related topics as a sounding board before making a decision or forging ahead with certain kinds of communication to team members or stakeholders — especially when the stakes might be higher than usual.

• A chance to brag about an accomplishment. Seriously! Managers are not magically aware of everything you do or every piece of work you complete. It’s okay for you to keep your manager in the loop on your wins so they can celebrate with you and be aware of your progress. This will pay dividends come salary appraisal time. 

• A weekly reminder to think about your personal growth and to reflect on your career progress. Ask for a gauge of how you’re doing in your role and what you could do to level up.

Responsibility 

Great one-on-one meetings are a two-way street. Both manager and employee have a responsibility to each other and the team to make a genuine effort to establish a healthy, productive relationship. They work best when both parties come with an open mind and are prepared to listen. They also work best when both parties seek first to understand, demonstrate patience, and keep the door open to compromise. Both manager and employee need to care about maintaining an authentic connection. As the employee, at times this may require suspending one’s cynicism carried over from previous experiences. If you had a bad reporting relationship in your last role, it doesn’t necessarily follow that every manager you encounter in your career will be lacking (and if so, you’re working at the wrong company!)

Some things an employee can do to make the one-on-one meeting productive:

• Try not to see it as just another official box to tick in order to collect your paycheck. Suspend your disbelief and at least give your manager a chance to demonstrate their worth before switching off your mind and robotically nodding your head, no matter how much you may be inclined to do so.

• Don’t be afraid to get to know your manager on a human level. Ask them if they had a good weekend or are having a good week. If they were recently out on vacation ask them if they enjoyed the time off. A good manager won’t mind some gentle inquiry into their lives outside of work, at least as an ice breaker at the beginning of the meeting. 

• Come with your own agenda. This is primarily your meeting so make the most of it. Before each meeting, write down what you accomplished last week, what you struggled with, any obstacles you overcame, and any lingering issues or concerns that are affecting your workday, including any communication issues with teammates or stakeholders and anything blocking your ability to make progress on whatever work you’re assigned to. Also, write down anything you’re proud of and want to celebrate.

• If things are going so smoothly that there is little to talk about regarding the present, consider asking your manager some forward-looking questions about how you’re progressing in your role or how you could work towards the next step up in your career.

Some general advice for managers conducting one-on-one meetings:

• If the employee doesn’t come prepared with questions or isn’t very forthcoming with things to talk about, it’s not okay to just cut the meeting short. You should be prepared to prompt your direct report into talking about something that matters if the silence grows too long. Some people are just less verbose or not good at preparing for these meetings at first. Hopefully, with positive encouragement, they will get better, but you should always be ready to take the lead in the conversation to get it back on track and make sure it’s a valuable use of their time. Keep a running list of conversation prompts that you can easily scan and refer to, perhaps categorized into groups like:

  • “Social ice breakers”: when you just need to help your report relax into the flow of talking.

  • “Wellness check”: check how they’re doing physically and mentally.

  • “Career questions”: guide them into thinking more long-term.

  • “Devil's advocate”: probing questions to nudge them into thinking about something on a deeper level, or to provide space for healthy disagreement.

  • “Open-ended questions for pivoting”: eg “Tell me something I don’t already know about you/the team/the project you’re working on.”

• Even though I’ve stated that this is their meeting, there will be times when you need to communicate something important, such as the rationale for a company decision or a critical piece of feedback for your report, and this might need to take priority sometimes. Use your judgment here.

Cadence

A good rule of thumb for the frequency of this meeting is to meet once per week with each direct report for at least thirty minutes. Ideally, both manager and employee should block off an extra thirty minutes on the calendar at the end of the meeting so that the option is there to extend the discussion to an hour if necessary or desired. I’ve heard of managers who only afford their reports ten or fifteen minutes each and blitz through half a dozen meetings on Monday morning just to get it all over with quickly. In my opinion, this is not appropriate and it sends the message to your direct reports that your time is more valuable than theirs, that managing people is not the most important thing you do, and that you don’t really care that much about fostering good working relationships on the team beyond small talk and status updates. Don’t be that manager.

Note: part of getting to know your direct reports is knowing when they do their best focused work and when it’s okay to distract them. Schedules may be hard to wrangle but at least try to ask your employees when they’d prefer to have their 1:1. If nothing else is viable, see if you can let them choose whether you meet in the morning or the afternoon. Empowering people to make even small choices like this can go a long way to establishing good patterns of interaction from the get-go.

Continuity 

Managers: take notes! One of the most powerful ways to establish strong bonds of trust and understanding between you and your direct report is to maintain some semblance of continuity between each one-on-one meeting. It doesn’t matter what method you use (I favor writing on index cards: a different color for each employee so I can easily grab the right stack before each meeting), what matters is that you keep track of important questions and concerns that come up, and record the general gist of the conversation you had. That way, at the beginning of the next meeting you can follow up and either continue the conversation where it left off or ask your employee if they managed to reach that goal/learn that thing/overcome that obstacle/make use of that advice you gave them in last week’s meeting or a meeting you had a few weeks ago. It’s necessary to go over your notes periodically to refresh your memory of what occurred — that way you can be present and mindful each time you meet.

Note: I’ve had some managers who thought that keeping these notes in a Google doc shared only between the manager and employee was a good idea. It might be, and certainly might be convenient. This makes the most sense in a remote work scenario. It could also be a win for transparency. However, I would caution managers to avoid making the assumption that every employee will feel okay with this. Instead, make a point of asking them about their preference and then honor those preferences. For some employees, even though you promise the document isn’t public, the idea of their personal progress or challenges being documented in the company cloud may give the impression that they are being too closely monitored or on some kind of personal improvement plan. Personally, I’ve always found that letting the employee know that I take notes purely on paper and that they are free to keep their own notes too allows everyone to feel comfortable. I also explain why I keep notes: for continuity, not for strict supervision or oversight. 

What a 1:1 isn’t

• The one-on-one meeting is not a status update. There are other meetings where that information can be brought forth, such as a daily or weekly stand-up or an official status meeting. It’s totally okay to talk about the work in progress, work coming up, or work recently completed: but instead of letting the conversation be reduced to a mere status update, dig deeper and discuss something learned, bring up relevant issues, talk about how you and the team overcame challenges or obstacles, and relate it back to the employee.

• The one-on-one meeting is not primarily for the benefit of the manager. It is time and attention extended to direct reports. It is their meeting, and as much as possible they should control the agenda.

• Not just a meeting for average employees. There’s a pervasive myth that ”high-performing” employees don’t need one-on-one meetings. Why would this be true? No matter at what level we perform we all benefit from human connection, guidance, and conversations that promote personal growth and self-reflection. 

• The one-on-one meeting is not just management theater or a waste of time. This is only true if managers don’t understand the purpose and benefits of the meeting, have not worked with their reports to establish the right timing and cadence for the meeting, or have failed to set expectations.

Location shouldn’t matter

Whether your workplace is fully remote, a hybrid environment, or part of the RTO mandates (unfortunately) sweeping back through the corporate world now that the pandemic is (mostly) behind us, I tried to write these observations and tips agnostic of location. I have experienced 1:1 meetings in-person as well as remote, and if you want to be a great manager or employee you should strive to be attentive, polite, engaged, and fully present in a meeting that is conducted over video chat. 

I empathize with sufferers of ‘Zoom fatigue” and I have certainly experienced days where I have had quite enough of the “weak connection”, visual distortions, sound glitches and just staring at the screen for long periods of time. But it’s important to keep in mind the other side of the equation: staff who are able to work remote really appreciate the extra mobility, freedom, flexibility, and personal autonomy that it brings to their lives. In other words, grin and bear it for the greater good :-) 

Conversely, if you're in a physical office, the one thing you can’t do in a remote scenario that you could occasionally do in-person is to go outside the office to grab a coffee and talk somewhere “off-campus” for a while. This may help nudge an employee to be more candid and open if the situation requires it, or just give both of you an excuse to get some exercise and enjoy some (ideally) good weather. As someone who generally prefers working remote these days, I think the out-of-office excursions to the coffee shop are the only thing about in-person 1:1’s that I genuinely miss.

Let me know if you have any other good pointers or suggestions in the comments, or if I’m missing anything important.  

Good luck with your next one-on-one meeting!

My part-time job since the summer of that year was assisting the local ‘Milkman’ with his deliveries in the early hours every weekday. Yes, in England we used to have milk (and other sundries) delivered to us long before online ordering was a thing — it’s a tradition going back hundreds of years. It paid pretty well, considering I was a teenager pulling just a few hours a week — much better than a newspaper delivery round or working odd jobs. But working through the colder months proved more difficult than the summer. Not just because of the temperature drop but because now I was working the hours before school and couldn’t climb back into bed after my shift was over. 

The milkman’s gauntlet

The work was very intense. To hit all the houses on our customer list and finish before 8 am, the Milkman and I would pretty much spend most of the time jogging to each house in turn and jogging back to the milk float. We were constantly on the move for three or four hours. The basic strategy and order of operations was:

• Drive to the next street on the delivery list.

• Both of us jump out (the float has no doors).

• If the house we are delivering to is listed for four pints of milk or less, we grab the bottles in our hands — you are wearing gloves, so you have more grip if they’re wet, and you hook two bottles in the two spaces between your thumb, index finger, and middle finger on both sides, so you’re able to carry a maximum of four bottles, two in each hand. 

• If the order is for more than four pints of milk, you grab an empty crate, place as many bottles as were ordered inside, lift the entire crate off the float, and carry it by the edge at an angle so the bottles don’t spill out while you’re running.

• You run up to the house, place the bottles neatly to one side in front of the door (or sometimes in a special place provided by bespoke customer instructions), and then you run back to the float. 

• Repeat the process for more houses in the street, or if there are no more delivery addresses on that street, drive to the next street on the list.

This was hard, fast-paced work. In another life perhaps it could have been fun, but the guy I worked with was a real mean brute of a man who constantly berated me for being too slow. Running with glass bottles that were slippery to the touch wasn’t easy and I constantly worried about dropping them. Also, instead of letting me scan the delivery list for myself, he would yell the house number at me while his back was turned and sometimes I had a hard time hearing him, so I’d have to run after him first to ask him to repeat the number. 

We would usually divide and conquer on opposite sides of the road, so he’d be running to one house while I ran to another. Whenever he beat me back to the float, if there were no more customers on that street he would literally drive away and force me to run by myself to the next location. Sometimes I’d completely lose sight of where he went and would have to follow my ears for the sound of the milk float to locate him again. Only a teenager hard up for spending money would put up with such Sisyphean work conditions. I honestly didn’t know any better. 

The ultimate test

My boss’s disappointment in me all came to a head one day when I learned to my dismay that one particularly big household had ordered twelve pints of milk. That’s about fifteen pounds that I had to pick up as a scrawny fourteen-year-old in one hand, and then run with while maintaining the correct angle to prevent spillage. All my boss did was shout something like “12 pints to number 1556!” and he was off on his errand on the other side of the road, leaving me to struggle on my own. I took a deep breath of the frigid air, picked up a fully loaded crate, which had a section for each bottle, and swung it down to my hip, almost dislocating my shoulder in the process. And I ran.

Oops

I almost made it. But at the last moment, I tripped on the uneven cobblestone path leading up to the house, twisted my ankle, and sent the crate splaying into a flowerbed, glass shattering on impact with a little stone wall and some plant pots. I looked down at the mess and counted six bottles miraculously undamaged and still in the crate while the other six formed a soup of milk and broken shards. In a complete state of panic, fearing that the milkman would fire me on the spot for my ineptitude, I could think of only one way out of the situation: I used my foot to kick soil over the broken glass while the milk slowly drained away into the ground. I did a rough but pretty thorough job of covering up the scene of the crime, placed six bottles on the doorstep then ran back to the float as fast as I could. I breathed a sigh of relief when I realized my boss hadn’t returned yet, so I quickly stocked back up with six fresh bottles and ran back to the house to complete the delivery. 

Consequences

It turns out I made a lousy criminal because I got found out as soon as I returned to the milk float. “What was that almighty crash I heard? It sounded a lot like breaking glass” my boss said as we both stood there in the cold. With tears of shame and rage in my eyes I walked with him back to the house where the evidence of my disaster was still plainly obvious to the trained eye. There are a lot of things he could have done at this moment, what he chose to do was scream at me. “Oh my god, you’re a clumsy idiot! Do you know how long I’ve had this customer and how much she buys from me? She’s probably going to cancel now. You’ve cost me a pretty penny. Jesus f*@king Christ!”. As we walked back he followed this up with “I’m going to dock this loss from your pay, and you’re now on notice that this is your last day. I’m done with you.”

I was too upset to say anything for the rest of the morning. I carried out my duty without any more incidents (luckily there were no more twelve-bottle orders) then silently stalked back through the back garden of my house after he’d dropped me off. I was angry at myself for making such a calamitous rookie mistake, disappointed in myself for trying to cover up my mistake, angry at being yelled at, and dismayed that my boss had offered me zero sympathy. The fact that I’d been fired barely even registered.

Why am I telling you all this, dear reader? And what does it have to do with what we normally write about here on Humanware?

The moral of the story: psychological safety

We’ve all heard this term being bounced around inside the walls of corporate America lately, and for good reason. But it hasn’t always been well communicated or understood. Gartner research defines psychological safety thus:

Psychological safety is an environment that encourages, recognizes and rewards individuals for their contributions and ideas by making individuals feel safe when taking interpersonal risks. A lack of psychological safety at work can inhibit team learning and lead to in-groups, groupthink and blind spots.

Much more than just a trending buzzword, psychological safety is a critical mechanism underpinning our ability to perform the functions of our job without succumbing to fear or worry. Some organizations choose to ignore this facet of work, or actively renege on their duty to uphold it. But the best organizations will make it part of their cultural DNA for leaders to create empathetic and risk-tolerant work environments because they know that doing so leads to teams that demonstrate:

• Positive morale and increased engagement.

• Improved levels of collaboration and camaraderie.

• Minimal staff turnover.

• Improved behaviors of inclusion.

• Improved team performance.

• Greater team awareness.

People are more motivated to do great work when they feel seen and heard, and when they are led by managers who encourage honesty and constructive feedback between all members of the team as well as themselves. As suggested by Gartner, the increased awareness that this brings about can lead to increased diversity of ideas and more creative solutions, and the team is less likely to fall into the trap of thinking too much “inside the box”. The way to foster psychological safety on your team as a manager includes things like:

• Allowing everyone on the team the privilege to speak up, ask questions, and point out any problems they see with the work, their teammates, or leadership.

• Actively eliciting brainstorming ideas and ‘thinking out loud’ without expecting perfect outcomes.

• Encouraging employees to challenge the status quo, suggesting alternatives and improvements.

• Fostering a spirit of calculated risk-taking and trying new things.

• Supporting the direct communication of team disagreements and resolving them in real-time in a civil and productive manner.

• Making it okay to fail and letting everyone know that failure is how we learn.

As much as possible, leaders should embrace these methods and model the behaviors themselves as an example to their team. It requires leaders to be honest and at times vulnerable, transparent in what principles they are guided by, and willing to admit their own failures and mistakes.

The American Psychological Association lists the following employee behavioral traits that are enabled by providing a psychologically safe work environment. Employees who feel safe and empowered will:

• Admit and discuss mistakes,

• Openly address problems and tough issues,

• Seek help and feedback, 

• Trust that no one on the team is out to get them, and 

• Trust that they are a valued member of the team.

If your team is consistently able to exercise their right to do all these things, you will find that they are happier and more motivated, and will work together more efficiently, especially at times when there is a greater need for trust and close collaboration or orchestration of related tasks. You’ll also see that employees are more positive about the future and will see themselves as having a career at your company, rather than just a temporary job. Instead of being in fight or flight mode, fearing the next unexpected PIP or out-of-context performance review, they will feel secure in the knowledge that they’ll be treated fairly, that their concerns will be listened to and addressed, and that you and the organization have a vested interest in making employees feel valued and respected as human beings. 

Don’t be a jerk

One important rule that always needs emphasizing: prioritizing honesty and the freedom to speak up does not give license to anyone to be offensive, obnoxious, overly argumentative, or otherwise detrimental to the smooth running of the team. There are some conversations that have an appropriate time and place and nobody should feel like they have complete liberty to blurt out anything and everything that comes to mind in a given situation. It’s important to uphold the spoken and unspoken rules of basic civility and to remember that you will often need to compromise and won’t always ‘win’ whatever argument you might be striving for.

Safety not guaranteed

Another thing to note that is harder to phrase but needs saying: psychological safety beyond your immediate manager is by no means guaranteed. It’s possible for a team to have a stellar team leader or manager who fosters an amazingly open and constructive team culture but ultimately reports to a department with leaders who are not evolved enough to embrace the tenets of modern leadership. So, that’s something to be aware of. A great manager will do their best to shield employees from the worst effects of a psychologically unsafe upper echelon, but sometimes there is only so much they can do before the effects of a rotten C-suite trickle down. Ideally, you want to work for a company where you feel that everybody gets it, not just the line managers or only up to a certain level. I hope I’m not being too idealistic in assuming there must be some solid examples of good leadership out there.

In terms of making psychological safety part of the process of a functioning team, a good team leader or manager will make it known which meetings support the full freedom of expression versus meetings where you need to keep things tight and business-like. Ideally, your team will hold ‘reflection’ or ‘retrospective’ meetings where everyone is encouraged to speak about what they’ve learned, what questions they still have, and what concerns need to be discussed. There may be some meetings, such as meetings where non-tech stakeholders or a third party might attend, where shooting from the hip might not be appropriate. Similarly, if you are an individual contributor and you have serious personal concerns or things to discuss with your manager, your 1:1 is a more appropriate setting than a team discussion. Conversely, if you’re a manager and you need to give some constructive feedback to a direct report, the team-wide meeting is probably not the right setting. 

The team should also do their utmost to avoid victimizing and blaming each other for problems or failures that arise. As much as possible, the team should challenge systems, ideas, and behaviors rather than people. Most of the time there is really no need to make things personal.

Remember: psychological safety means that at the appropriate time and place, everyone on the team is afforded the option to speak freely about what is on their mind, without fearing any kind of retribution or other negative repercussions.

Time to finish with a nice glass of milk

Returning to my woe-is-me story about my job as a junior Milkman, I’m now old and wise enough to be able to look back on the situation and realize that my boss at the time never fostered an environment that made me feel like it was okay to speak up, ask questions, try different things, make mistakes, or even admit to making mistakes.

If he had been a more supportive boss:

• He might have told me on day one that if he asked me to do something that didn’t make sense, it’d be okay to ask questions. I would have asked him why the f*ck he kept driving away and making me run after him because it wasn’t funny and at the time I had asthma that was triggered by sudden bouts of athleticism.

• He may have let me know that if I was having a problem with the work, I could ask for help.

• If he’d been open to feedback I would have told him that he wasted a lot of my time by shouting things at me while my back was turned to him.

• Maybe he would have invited me to come up with my own ideas for doing the work more safely or efficiently: for example, why couldn’t I put four bottles in an empty crate rather than nervously fumbling with two bottles in each hand, stretching my fingers to almost breaking point? And when I had to carry twelve bottles at once, why couldn’t I just take them in a crate six at a time?

• He could have encouraged me to be honest if I made a mistake and that he wouldn’t get angry and just fire me on the spot.  

But heck, I supposed if he’d been an awesome boss I never would have needed to ruminate on it and learn from the experience and eventually write this article for you. So I guess I owe the old bastard some gratitude for being such a bad example.

I’ll toast to his memory with a glass of milk!

Change

About a year after accepting my first role as Engineering Manager, there was a company-wide reorg. I learned that I would no longer be reporting to a business leader with whom I had a good working relationship and established routine. Now, there would be an extra layer of technical oversight, and I’d report to an ‘Operations Manager’ who happened to be a very technical former Software Engineer I’d worked with in the past. While the reorg was being communicated and figured out, things were a little chaotic at the company, and many employees were on edge. Perceiving this anxiety among my team, I called them all into a meeting where I hoped to reassure them by saying:

“As far as I understand things, this reporting shift won’t change much for our team. I’ll still be the boss, eg you’ll still report to me. It’s just that we will now have an extra layer of tech leadership. I’m not sure exactly how it’ll work in terms of who makes what decisions and whether or not my priorities and focus areas will need to change to accommodate the new leadership, but I think this will be a good thing once everything settles.”

Revelation

The reorg went quite smoothly and eventually, I forgot all about this meeting. But about two years later I was in a 1:1 with my manager and the subject of my leadership style came up. I can’t recall the exact details, but I had said something in a meeting with my direct reports that my manager felt might be in danger of being misinterpreted and was offering constructive feedback on my delivery. I sort of felt like his concern was unwarranted and told him so, but then he remarked that in his skip-level meetings, two of the developers had once told him about a time when I acted like an over-bearing boss.

I was shocked at this revelation, because I had always had an impression of myself as the opposite of that, and all of the feedback given to me by peers and reports had always reflected me as a fair and compassionate leader. When I asked how long ago this alleged incident had occurred he told me two years. That also shocked me: something that happened two years ago was still on my boss’s mind! How long had this been affecting his perception of me as a manager on his team? How had this affected our conversations over the past two years? I was suddenly lost in a dark maze of self-doubt and wondered if I had a false sense of my own success as a leader. When I asked him to repeat what the developers had told him two years ago he said:

“They said you sat them down one day, totally out of the blue, and told them in no uncertain terms: “Remember that I am the boss, okay? What I say, goes. It doesn’t matter if my reporting structure changes, I am still the boss and you report to me, and don’t forget that.””

I was stunned and dismayed. What the hell? I had good relationships with these developers, or so I believed. And I never considered myself some kind of ‘boss’ like we were working on a construction site or a warehouse. I had long followed the tenets of servant leadership and always tried to afford my direct reports as much autonomy as possible. How could they have misinterpreted me so badly? You could talk to anyone who ever reported to me and I’m confident they would not consider me to be any kind of authoritarian.

Reality

In truth, I don’t think my direct reports were as affected by this misinterpretation as much as my manager. I’d certainly made a bad first impression on one of the newest team members, and a more tenured one had agreed with him about what I’d said. But as the team evolved I don’t think they dwelled on it for long, and it didn’t seem to get in the way of me growing a team success story that was known throughout the company. I would guess that my team was able to make up their own minds about me in our 1:1’s and daily interactions. I went on to become a well-respected Engineering Manager with direct reports who always rated me highly as a leader, even in anonymous surveys conducted by HR.

But in the mind of my manager — someone I had fewer daily interactions with — who knows exactly how this negative perception of me festered and affected our relationship? I’m not sure if this is an accurate quote or not, but something I heard a lot around the office was:

“perception is nine-tenths of reality.”

It is not possible to go back in time to fix bad impressions, so it’s important to be aware of the nuances of communication and power dynamics that can go wrong and tarnish your reputation or credibility. I learned this lesson the hard way by being knocked off kilter by what my manager revealed after sitting on it for two years, but perhaps you could prevent this from happening to you by being more mindful of these two essential truths:

1. In any leadership role, it is paramount that you realize your words carry more weight than they did as an individual contributor, and that everything you say, especially in a public setting, is going to be scrutinized and not necessarily taken at face value. As much as you might think of yourself as just another team member or a super friendly, accessible manager, your direct reports will most likely harbor a certain level of skepticism against people in authority and will not trust you until you’ve earned it over a long period of time. This is perfectly natural and something you need to accept as part of your worldview if you’re going to successfully navigate life as a leader. 

2. It is easier to repair your reputation with the people who report to you than it is to change the way you are perceived by your manager or other leaders higher up in the chain. You may not even be aware of the damage done until years after the event. 

Hindsight

So, looking back on the situation I’ve outlined here, what could I have done differently in order to avoid having the unknown stigma of being thought of as a bad leader by the one person who held my career prospects in their hands?

The reorg happened so long ago that many of the details have faded, but putting myself back in my shoes as a new manager I’m okay admitting that:

• I must have been too hasty in calling the meeting. I should have been more mindful of the fact that everyone was on edge, and that I was not the only one facing uncertainty about the future of my role. Instead of calling a meeting and attempting to align my thoughts with reality in real time, I should have written down my thoughts and processed them before planning out what I needed to communicate to the team.

• ‘Boss’ is a word that doesn’t belong in a modern workplace. I honestly don’t know why I used the word. It’s a silly word to me. I have never since referred to myself or any other manager in that way. I don’t know for certain that I did use the word, but at the very least, something in my tone must have led to other people hearing that word. A slip of the tongue can have lasting consequences. I’ve never forgotten that.

• It’s possible that an all-hands team meeting was the wrong format. I could have opted to talk 1:1 with each direct report instead. I could have made more space for them to reflect and ask questions about what was happening. This is especially apparent if you consider that one of my direct reports was a new team member and wasn’t yet familiar with my communication style or any of the patterns of speech or turns of phrase that I typically used. 

• I should have been more mindful and confident about exactly what I wanted or needed to communicate. My honest intention was to reassure my team that I would still be there for them and that nothing was really changing in terms of who does what on the team. It should have been a message about not needing to worry about the future. Instead, what they heard were my own fears projected: “something is happening to my role but I think I’m still in charge.” I needed to spend more time processing my own emotions before narrowing down what would be the most meaningful and useful thing for the team to hear.

Reflection

Of course, you’ll go crazy if you over-analyze every single word you ever say as a leader, so I’m not advocating for that. But I hope this example demonstrates that as a leader you’ve got to become extremely self-aware of how you talk and act, and you do have to take the proper time to collect your thoughts, control your emotions, and prepare your communication before you blurt it out — especially when the stakes are high or when the morale of the team is at risk. 

Some lessons learned:

• Try not to use words that are going to trigger a misunderstanding or paint you in a negative light. Strive for the utmost clarity in your communication. 

• Stick to what you know to be true, not what you feel. 

• Put your team first: their morale and their psychological safety should be your first priority. 

• If you need to, put team meetings on hold until you feel like you fully understand what the situation means to you and how it will affect you. 

• Encourage your team to ask questions. Be honest if you don’t have the answers yet. 

• Be mindful of the power dynamic that authority bestows on you: you have the power to confirm or deny raises and promotions, which has tangible implications for an employee’s life. Because of this, in certain situations, nothing you say to them will be taken lightly.

Unfortunately, I don’t think there is any easy or repeatable way to develop this self-awareness except through trial and error. You must acknowledge that it is necessary and try your best to cultivate it within yourself as much as possible. You are bound to make some mistakes along the way — you are only human. If you’re starting out on this path, or have already found yourself being tripped up by negative perceptions that people have of you, you might benefit from mindfulness practices and any kind of training you can find pertaining to effective communication as a leader — LinkedIn Learning has a bunch of helpful courses on that topic that you might want to check out (not an official endorsement, just something that helped me along the way.)

We all make mistakes as first-time managers, I hope your mistakes will be small and that you will learn valuable lessons from them. If you stay humble and self-aware and develop a growth mindset you will evolve into the leader you are meant to be. 

I’m here to state the obvious: if you’re a manager, you should invest time and energy into getting to know your direct reports. It’s not an overstatement to say we spend more time at work with our coworkers than we do at home with our families. As much as one-third of our life is spent at work. So for our own mental health and the health of those around us, it would be wise to find some level of harmony with the people we work with. 

We all know that most workplaces do not offer great training for new managers, so there’s a tendency for people entering management to lack experience and understanding of what will make them successful in the role. In my experience with Software Engineering Managers and other tech leaders, I’ve noticed a prevailing deficit in a manager’s ability to empathize and build rapport with their direct reports. 

Leaning into being human at work

I don’t want to over-generalize, but I think it’s fair to say that a good number of tech managers are promoted internally from IC engineering roles where they excelled at the extremely technical aspects of their work and are not well-equipped or well-prepared for the shift from managing code to managing people. Sometimes it seems they are not even aware of the new skills and strategies that are required to be effective as a people leader. 

In a few cases, Software Engineering Managers and even some Directors never learn to lean into effective human leadership and continue to rely on their technical mastery to get things done: the result is usually some flavor of morale-reducing micromanagement and a purely technical results-focused manager who is emotionally unavailable to team members when they need understanding and support. 

If you only focus on the work and don’t pay attention to the people behind the work you will only ever be a task manager and won’t be looked upon as a leader. People will work for you and obey your instructions, but they won’t follow you or respect you. You will also find that if you’re not building trust and banking emotional equity with your direct reports, it will be much harder to lead them through times of struggle and uncertainty. 

Again, it may seem obvious to some of us, but a new manager needs to make sure they are prioritizing the development of their (so-called) soft skills. You may be working for a company that doesn’t really understand or appreciate the importance of human-centered management in tech, and you may be spending too much of your time still immersed in the code to be a truly effective leader, but you owe it to your team to at least try to be there for them in ways that matter.

There are no easy shortcuts that I’m aware of to becoming the kind of manager that people want to work for, but as a start, I’ll suggest some things that will get you off to a good start.

During your very first 1:1 with each report:

• Set aside plenty of time to ask them (non-invasive) personal questions. Find out about their hobbies, whether they have pets, where they like to travel, who they live with, how they got into tech etc. You may be looking at this and thinking it seems like a frivolous waste of time, but I promise this is an investment that will pay off. Show genuine interest in who they are as human beings and establish a baseline you can build on in the future. And don’t fake it: this is something that requires the same commitment you give to other important relationships in your life.

• Ask them how they like to receive feedback. Hopefully, they’ve already thought about this but you can prompt them to help arrive at a mutual understanding. You might include this as an agenda topic in the meeting invite so they can come prepared.

• Ask them when they prefer to work. If you are working in a physical office there may be strict working hours, but if the position is remote an employee will typically expect a more flexible schedule. Make sure they understand that the team will need to have at least some shared working hours where you all overlap, but knowing that someone is an early bird or a night owl can help you establish good lines of communication and not be tripped up later by unset expectations. 

• Ask your reports some open-ended questions such as “What do you need from me to do your best work?”. Establish that you are there to help them be successful. What obstacles are in their way, or what support do they need? There might be some pressing needs caused by whatever shift resulted in you becoming the team’s manager, or there may be more long-term issues to explore.

• Keep in mind this concept of human-centered management: “let people lead.” Ask a question like “What project, process, or change would you like to lead on our team?”. This is a great way to explore what motivates them, what ideas they have for improving the team, and whether or not they feel a healthy sense of ownership. It also starts a conversation around their career goals. You won’t dig in very far during this first meeting, but it sets the stage for a follow-up later and helps you think about how each person on the team can find their sense of purpose and become the best, most fulfilled version of themselves at work.

• Try to get into the habit of listening more than you speak. This is their meeting, not yours. Come prepared with lots of questions to spark conversation.

I like to keep records of these early responses so that I stay aware of them later and don’t need to rely on my fallible human memory to keep track of everyone’s preferences. Some companies may have a private wiki or internal employee intranet or hub where some of this information could be stored, at least the operational and communication preferences. But for other kinds of information and for tracking conversations over time, use some good note-taking software, or if you prefer something more physical, a simple stack of index cards that you can store in a safe place will suffice. 

Remember the date

Speaking of employee information — as a manager, you’ll typically have access to basic data such as employee start date and birthday. Look these up for each of your direct reports and create private calendar reminders for each important date. Ask your direct reports if they enjoy celebrating work anniversaries and birthdays in the open with the whole team or if they’d prefer a private note to mark the occasion. It’s a simple, genuine gesture you probably extend to friends, family members, and even some friends you only keep up with online — why wouldn’t you extend the same basic sentiment to people you will temporarily spend one-third of your life with?

I usually go one step further and try to mark down any anniversary that I learn about that is likely going to cause the employee some amount of stress. I’ve managed employees who have had loved ones or pets die while they’ve been part of my team, and knowing that as each year passes, they’ll revisit the initial shock of losing someone they love, I try to make sure I am giving them extra slack that week and that I’m prepared for them to be less engaged or productive. It’s also a chance for me to watch out for any signs that they may benefit from taking a day or two off work. This is about awareness and showing extra empathy during a tough time. 

We’re not family, but we’re also not strangers

All this talk of building emotional equity, understanding your employees as people, celebrating good times, and being aware of the bad times, etc might sound like I’m advocating for you to become best friends with your direct reports, so I want to be clear that I’m not. All I’m really saying is that managers should treat people like people, not just an employee ID on a spreadsheet. I definitely agree that there is a flip side: managers should establish authority and clear expectations from the start and not talk or act as if the team is their family. I’ll write more about this another time. I just want managers to understand that authority can and should be combined with human empathy and goodwill and that neglecting to understand your employees on a human level will only lead to the perpetuation of the idea that management doesn’t care or acts with moral impunity. Let’s strive to be good managers and become great leaders who people actually feel inspired by, rather than ruling with fear. 

Keep learning

As you settle into your role as manager, don’t neglect the personal side of your working relationships. Set aside at least a few minutes in each 1:1 for catching up personally, or for reflecting on something mundane but interesting like a current event or TV show. Keep up some genuine interest in the lives of your employees outside of their work and don’t make the entire meeting one big status report. You should give each of your reports at least thirty minutes of your time each week (more as needed) and you should treat these meetings as essential to the smooth operation of your team. Don’t let any other leader tell you that it’s okay to neglect these meetings or to reduce them to 15 minutes or less — would you feel appreciated and respected if your manager did that to you? This is time well spent, and if you take it seriously and continuously strive to become a better listener, coach, and mentor, I’m positive that your employees will agree. 

No unicorns available

I see Engineering Manager roles advertised like the one above, from Adobe, all too often. They are looking to hire someone who is an Engineering Manager but who will also act as a Tech Lead. It is my conviction that job descriptions like this are confusing two very different roles and trying to munge them together, which in my experience, never works out. 

The summation of the problem is that too many companies are looking for a unicorn who somehow:

• Possesses the exact measure of hard and soft skills required to contribute to code and lead.

• Has the ability to switch between manager and contributor modes at the drop of a hat without any side effects.

• Is equally qualified and experienced in writing software and managing people.

• Is equally passionate about writing software and managing people.

The type of person who can truly meet the requirements of such a role is so rare that in 20 years of working in tech, I’ve never interviewed or worked with someone who completely fits the bill. 

What usually happens is that the company hires or promotes an individual who genuinely believes they can do the job — or will give it their best shot while knowing they will realistically have to lean more or less into the coding or people management and not both. Someone in this role is destined to please their leadership but disappoint their team, or vice versa. Sometimes, people in these munged roles allow chaos to unfold on their teams because they are too focused on being a good Software Developer or Tech Lead. Others will do a great job of managing the people but will lose respect from higher-ups who expect them to have a stronger hand in guiding technical requirements and make frequent contributions to the codebase. 

Call me jaded, but middle management and above are often not aware of (or don’t particularly care about) the nuances of leadership challenges at the line-manager level. So ideas like creating a hybrid manager/tech lead role must seem attractive as a way of consolidating roles into a smaller headcount, but may not be very firmly based in reality. 

The crux of the problem

In some organizations, this misunderstanding about the Engineering Manager role stems from the fact that even at higher levels like Director or CTO, leaders are still overly focused on managing the technical roadmap and aren’t assigning enough importance to great people management. It is not unheard of for Director’s and CTO’s at some organizations to be very hands-on with the code themselves, or to micro-manage their direct reports with regards to technical oversight, therefore it is no wonder that the soft skills and responsibilities of people management are under-appreciated, downplayed, or misunderstood. At these companies, it is a written rule that managers must remain technically excellent and an unwritten rule that those skills trump all others. These same leaders are notorious for their lack of compassion, empathy, and basic leadership, and people do not enjoy working under them, but the low morale amongst tech teams and the constant churn of employee turnover don’t seem to get in their way or cause any self-reflection. 

Unfortunately, many leaders in the tech industry have never learned people skills, and may never have been encouraged to do so — many organizations lack formal growth and training plans for new managers. Then, as these leaders climb the corporate ladder, they continue to over-index on their hard skills and allow it to become their unwavering worldview, which then trickles down through all the other rank and file until the overtly technical bias of leadership becomes normalized. People who lack empathy and communication skills promote more of the same archetype. The fish rots from the head, ad infinitum.

Why this is a problem

My first foray into Engineering Management was in just such a hybrid role that we’ve been describing: I was given three Software Developers to manage and was expected to continue my previous role as Senior Software Engineer at the same time. In many ways, just as Wil Larsen has written, this manager/tech lead role is a trap. When I began, I was excited to develop my soft skills and learn how to be an effective leader, but I still had to stay fully immersed in the code, provide technical guidance to the other developers, and help make big architectural decisions. 

This ended up being a fool’s game where no matter what I focused on, I was losing, and letting down either my team or my manager. When I took deep dives into the codebase and tried to lead new feature builds, large refactorings, or migrations, I wouldn’t come up for air for days, leaving team members with an inaccessible manager who could not empathize with them when they were struggling.

Conversely, when I decided to focus on team behavior, individual career guidance, or learning how to conduct the best 1:1 meetings, my work was mostly invisible to my manager and higher-ups, and they seemed skeptical, even distrustful that I was providing value because it couldn’t be measured in lines of code or features shipped. I would arrive at my 1:1 meetings disorganized and unprepared because my mind was still dwelling on code problems, meanwhile, I was spending enough time thinking about the team or helping them overcome hurdles on other days that I then had to work extra nights and weekends to avoid missing code completion deadlines for products that needed to be shipped. 

Who cares about the people behind the work?

As I’ve alluded to already, I believe a major reason for this lack of trust is company culture that over-indexes on individual code contributions and a management hierarchy that assumes effective people management is of secondary importance and can not be measured. I was sometimes given the feedback that because I only managed three direct reports I had plenty of time to be heads down in code. After all, three 1:1 meetings per week only amounted to 90 minutes, assuming I met each of them for 30 minutes a week. I was told my time should be at most, 80/20 split between software development and management. This, of course, is an egregious error in understanding how a good people manager spends their time. 

So, should an EM be technically proficient?

An Engineering Manager can, and absolutely should be an individual with a background in software development, and ideally should have worked on the same or similar codebase as the one their direct reports are building and maintaining. For this reason, some of the best Engineering Manager candidates may come from within your existing employee base, rather than your external pipeline. The reason for this is that to be an effective manager of the team, they will need to be able to relate to the type of work performed by team members and empathize with the types of problems they will run into during their time on the team. But it’s important to draw a distinction around how they are measured in their role and what they are truly accountable for. 

The truth is, there are various ways to approach the Engineering Manager role, and that could depend on the kind of organization you have, whether or not the company is a start-up or a mature enterprise, and whether or not the tech department is split into large teams or consists of very small teams. Wherever your company lands on this spectrum, the Engineering Manager is going to be a role consisting of trade-offs and it’s critical to understand that not all hats can be worn at all times or provide the same level of value. To make the role of Engineering Manager fair and equitable, leaders should offer clear guidance and clarity within a framework that actively acknowledges the boundaries of the role and keeps expectations realistic.

Archetypes

Pat Kua did a great job of highlighting these trade-offs in his ‘5 Engineering Manager Archetypes’. You should read his whole article, because it explains everything in a nutshell, but I’ll call out the second archetype as the one that I think most established companies should try to hire or promote, which is the type of Engineering Manager I always strove to be:

I want my readers to be aware of the nuance here. The above archetype is for a team lead EM, not a tech lead EM (Kua’s 1st archetype). The trade-off is clear: a team lead can’t spend much time in the technical realm or focus on process or product because they are aligned with making sure they take care of team needs first and foremost. There is no such unicorn, not even a robot unicorn, who can navigate each of these responsibilities with equal attention and energy.

The reason I index on this archetype is that I believe an Engineering Manager is primarily a manager — it’s in the name for goodness sake, and any measurement of technical ability should be evaluated in the sense that individuals in this role should know enough to be empathetic toward their team and for the team to respect their prior background experience, not to the extent that they are still expected to fulfill the requirements of a Software Engineering role — because as we’ve already discussed, that is untenable and unsustainable and will lead to burnout and disengagement. 

What does an EM do?

In my professional opinion, a (non-exhaustive) list of what the Engineering Manager should be responsible for: 

• Cultivating team culture.

• Building an environment of trust and psychological safety.

• Providing career guidance.

• Maintaining consistent, meaningful, and impactful 1:1’s.

• Organizing team activities that build camaraderie and increase employee retention.

• Hiring and onboarding new team members.

• Staying in the loop on project progression, company policy changes, and best practices across the org and communicating these to the team.

• Raises, bonuses, and performance reviews.

• Fostering good relationships with non-tech stakeholders and other groups within the organization.

• Raising awareness of team-level and individual achievements and leading the charge to celebrate wins.

• Giving constructive, contextual, timely feedback regarding the individual behavior of direct reports.

At the same time, an Engineering Manager should be prepared to:

• Provide some technical oversight (but not micromanagement), particularly on aspects of the work where they have more layers of business knowledge, domain expertise or a history of working in the same codebase.

• Help senior developers plan out and design large architectural overhauls, leaning into trust but being accessible and ready to share opinions when it is helpful

• Identify and build relationships with vendors who can provide tools and services needed by the team

With the understanding that many such technical decisions can also be delegated to senior staff as long as they are trusted and are given adequate guidance.

The backlash

There is nothing controversial about the above archetype and the list of expectations for the role, and yet I’ve personally experienced coworkers and managers who are quick to cast dispersions at such an idea, usually for the reasons already outlined: they simply can’t imagine a world in which technical people benefit from management that is primarily more human-centered and not overtly technical in nature, and they could never see themselves prioritizing the soft skills necessary to be effective in a role bounded and measured by how well one can motivate, inspire, coach and mentor employees on the emotional, cultural and psychological level rather than the level of technical mastery. Some of them are critical of the idea of delegating technical decisions to senior development staff, who I’ll argue are sometimes more keenly aware of the requirements and specifics of implementation and in a better position to see the benefits and drawbacks of any particular solution. This is a shortcoming on their part, not mine.

The ideal partnership

Furthermore, there’s no reason why any good people manager in tech can’t be paired up with a Tech Lead or Staff Engineer whose role is primarily focused on technical leadership and mentoring, without the overhead of team leadership. This could be the ideal partnership for many organizations if they do it right. On large teams, you’ll ideally also have senior staff who are able to prioritize process (Project Managers) and product (Design leads and Product Managers). The whole point of building a great team is to have people who can dedicate their energy to the right things. You don’t want them to be uncertain of their responsibilities, or trying to juggle too many competing priorities. 

Don’t feed the robots

I really wish companies — especially the large ones with thousands of technical staff — would stop posting such confusing job descriptions which lead to the proliferation of this misunderstanding and the continued problem of new Engineering Managers being caught between a rock and a hard place. I believe the confusion and lack of respect that organizations lend to this role is the reason why so many Engineering Manager’s give up at some point and end up going back into the purely technical track. It’s also why so many Engineering Manager’s and more tenured technical leaders never learn the importance of leading people in a humane way. If you’ve ever received a top-down missive from the CTO that spoke to everyone like they were robots, you know exactly what I’m talking about. 

Companies that just don’t get it are allowing tech to exist in the absence of humane leadership. They are fostering a culture where tech leaders are robotic and treat their staff like mere cogs in an emotionless machine. They help to perpetuate an elitist and ultra-competitive culture where technical ability is the only currency. This may be why we have lately seen so many tech layoffs that have been devoid of empathy, why CEO’s have been mandating RTO, and why some companies seem to be poised to replace large numbers of workers with generative AI. The leaders at such companies are not demonstrating emotional intelligence, and it suggests to me that they never developed quality leadership skills, or the fundamental ability to read people, to empathize, or to seek to understand before they dictate. They don’t see people for who they are or for the potential of who they can become, they simply see skills, ROI, and numbers on a spreadsheet. They have a pretty fixed mindset when applied to people. 

A bit of self-reflection is a good idea

If you are currently working as an Engineering Manager, what are you most comfortable with? Providing technical oversight, slinging code, or talking one-on-one with your direct reports and learning how they tick? When you reflect on your career so far, are you more invigorated by the thought of all the features you’re helping to ship and the new code frameworks you’ve learned, or do you find yourself musing on the simple joy of watching people grow? I’m arguing that the manager who leans more to the latter is going to be a more effective leader in the long-run and that if your passion is for crafting code then you’d be happier and more productive if you returned to the engineering track and aimed to become Staff Engineer instead.

And a friendly warning from someone who has been there: if you find that you were feeling great about your management career for a while but then you’re asked to dive back in at the deep end and own a large piece of the codebase because your manager has become distrustful, the bus factor on your team has suddenly dropped due to your team being reduced by ‘budget cuts’, or team members are quitting because of unfavorable work conditions, don’t roll up your sleeves unless you really want to become an IC again. I’m serious: it’s time to polish off your resume at that point — because the right solution would be to hire back-fills for the missing staff but your team obviously isn’t considered critical and is therefore disposable. Know your worth, and own the path you want to be on. 

Becoming an Engineering Manager can be extremely rewarding and can put you on the path to Senior Manager, Director, and CTO roles, but only if you’re able to exercise the right qualities and prioritize the human aspects of your work. If you’re working for a company that doesn’t understand or appreciate the complexities, nuances, and value that management brings, outside of technical prowess, then in my opinion, you are not working for a company that truly understands the value of people or celebrates the myriad ways we can contribute.

December 2008. 2 Weeks before Christmas. Detroit. A heavy blanket of lake-effect snow covered all the sidewalks and buildings. A fleet of massive salt trucks sprayed all the major roads and turned the snow into a sallow slush. My car had no working heat fan, so ice crystals formed on the inside of the windshield in addition to the outside, which I had to scrape off before I could drive anywhere. The cold got into my bones and behind my eyes, making my morning commute seem like I was traveling inside a meat locker.

I worked at one of the countless advertising agencies in the area as a full-stack Software Developer on a small, tightly-knit team tasked with building and maintaining promotional websites for some of the biggest organizations in the auto industry, military, government, and telecommunications sectors. 

As I entered the office building I got hit with a wonderful blast of warm air from the overhead heater. As soon as I got to my cubicle, I removed my gloves, turned on my space heater, and turned on my ‘Mr Coffee’ machine. 

While the coffee machine hissed and sputtered, I noticed a few of my coworkers and my manager were all huddled in one cubicle on the other side of the room, so I strolled over to say good morning to everyone and to see what was up.

We were a very small and nimble team with a lot of work to do across a large portfolio of clients. Projects were never-ending—just one big launch after another—and we sometimes ended up working 60, 70, or even 80 hours a week. It was grueling and unfair, and our executive leadership was toxic. Still, we loved the work and maintained such a strong sense of camaraderie, perseverance, and excellence that none of us ever quit. We stayed strong and enduring in our little bubble, thanks to having a great manager and very collaborative, compassionate teammates. We were often there on Saturdays and Sundays and late into the evening. A couple of times, we were there overnight, fueled by pizza and Red Bull: the ultimate tech-worker cliché. Somehow, it all seemed worth it. It was a shared experience through troughs of hardship broken up by momentary peaks of triumph and celebration.

But that morning, something was definitely off.

As I approached the cubicle where everyone was huddled, everyone got quieter. I asked what was up. My manager seemed nervous. She mentioned one of the developers was trying to track down a bug in some code and that they were all helping him look for it. He didn’t even have an IDE open on his monitor, but at the time I didn’t really register the strangeness of the situation. Everyone seemed to be acting over-friendly toward me and there was a palpable atmosphere of anticipation I barely picked up on, like it was someone’s birthday and we were waiting to surprise them. 

Back then I think I was working too hard to keep up with the news. I was vaguely aware of the subprime mortgage collapse and how it was starting to put strain on the economy, but I was oblivious to how it might impact my own life: I didn’t have a mortgage yet and my car payment was all paid off. I had no idea that the mortgage collapse had triggered so many loan defaults and so many layoffs that nobody was buying cars anymore and that when you work in Detroit for an agency whose major clients include some of the biggest car companies in America—things can’t end well. 

Suddenly John from HR was standing beside me. “Excuse me, Jim, would it be okay if you joined Mac and me in his office for a few minutes? There’s a bit of business for us to address.”

My brain immediately felt threatened but I still didn’t know why. I followed John to Mac’s office while the others stared at me. I glanced back at them but I couldn’t tell you what I saw: to this day I can’t picture the way they looked, there is a mental block there and I can only try to imagine who may have been more or less concerned about what was about to happen. 

We rounded the corner and entered Mac’s corner office. Mac had only been at the company 2 years but was now in the role of CTO. 2 years prior, I helped interview Mac for a Software Developer role, and after he got the job I helped him learn the ropes and we became very good friends who had a lot of fun working together through the early mornings and late nights. We both developed cricks in our necks from turning to talk to each other while we worked side by side in adjacent cubicles. It was a workplace injury that made us laugh our assess off when we both got simultaneous jolts of pain. You had to be there. 

A recurring theme in my career is that I have helped hire and coach someone who then went on to be my boss or advance into upper management and that person ends up neglecting our relationship and behaving as if we were never friends. It’s as if growing in reputation, stature and responsibility triggers something inside a person to make them more emotionally distant, manipulative, distrustful, and resentful of anyone they used to fraternize with. Does corporatism have a dehumanizing effect? I know this runs counter to the idea that clicks stick together and nepotism rules: perhaps because of something in my own nature I find myself in a loophole.

I sat down and Mac absent-mindedly pushed his glasses up on his nose, looking across at me with stoic calm. John closed the door and sat down next to me.

“Jim, you’ve been a loyal and hardworking team member and an excellent Software Developer and I’ve enjoyed working with you. But today will unfortunately be your last day at the company. Please understand we are making this cut for financial reasons and not because of any performance deficit on your part. John will now go over the details and procedures we need you to follow”, he said, with no detectable emotion in his voice, his palms face down on the desk, looking straight at me as if we were professionally distant strangers, as if I hadn’t attended his wedding a few months before or sat in his driveway as we drank beers and barbecued that summer.

I understood the words he had said, but they seemed to be coming from a place that was very far away, like he was talking through a thick fog that somehow displaced the noise and made it hard for my ears to pick up the sound. Like someone had just fired a gun too close to my ears and caused me to experience temporary deafness.

“Today will unfortunately be your last day at the company.”. It echoed in my mind. I felt my whole body go numb, the blood draining from my head. I knew if I stood up I’d probably make an idiot of myself by dropping to the floor like a stone.

But what did that mean? My last day? It was Friday. This was my last day of the week. I was looking forward to the weekend, and Christmas coming up soon. I had a wife and a two-year-old baby at home in our first house that we rented. We needed a new car. I was looking forward to the annual Christmas bonus, which had been increasing year over year. 

I couldn’t hear what John was saying for most of his speech, then towards the end I heard words like “Escorted from the premises immediately”, “Collect your things later”, “Cobra insurance for one month” and “Severance is contingent on signing an anti-disparagement agreement.”

I glanced behind me and through the glass I could see that there really was a security guard standing there, waiting for me. What the actual fuck? What did they think I was going to do, go postal?

I signed some paperwork at Mac’s desk. I knew I had no choice but to sign whatever they asked because at that time we were living paycheck-to-paycheck and just staying above water. At one point I think I asked Mac something like “Are you serious? Why is this happening? Why me? Is anyone else getting fired?”, to which he replied something like “Yes I am serious. As I already stated, there are financial reasons for this layoff. I can’t speak about who else is or is not getting let go today”. Everything by the book. No words of compassion. Our friendship in tatters.

I was escorted by the guard. I was allowed to grab my winter coat from my cubicle but that’s all. I looked at my personal stack of programming books, my work laptop (which also had a bunch of my freelance projects on it because I couldn’t afford my own machine), the framed photos of my wife and child smiling back at me, happy and radiant, and the Mr Coffee which had finished chugging away and now held a pot of cheap, murky liquid I would never drink. I had to leave it all behind. I tried to glance over at my coworkers, but the lights seemed to be too dim, and I couldn’t make them out. I asked the guard if I could go say goodbye, but he put a hand on my back and nudged me towards the door at the front of the office.

I stood outside in the cold winter wonderland, clutching my car keys. A mere 30 minutes had passed since I’d started the work day. Now I was unemployed and would have to go home and tell my wife that I’d fucked up somehow and that maybe Christmas was canceled.

Layoffs are happening more frequently lately, and to more and more tech workers— who have traditionally been able to fare better during down periods and recessions than some other professions because our skills and experiences are usually in such high demand. Statistically, there have never been enough of us to fill all the roles that are needed. Even after my layoff in 2008, it only took me 2 months to find a new position, and that was right in the middle of a major recession. 

But present times are different. At the time of writing this in 2024, there are hundreds of thousands of tech workers who have been laid off in the past 18 months, and many of those workers have been looking for work for months or even over a year, applying to hundreds or thousands of applications only to be blocked by ATS robots, ghosted by recruiters, or told that the position went to someone else. The reasons for the ground shifting from under us vary depending on where you go for your news, but personally I believe it boils down to:

• Many companies over-hired during the pandemic boom years when internet-based services saw a surge of new customers and increased demand but naively did not factor in the reality that a global pandemic is a singular anomaly and not the beginning of a new economic trend. Now that this realization is kicking in, and the revenue spikes have leveled off, CEOs are using mandates like RTO to justify layoffs or resignations in order to return headcount to ‘normal’, pre-pandemic levels.

• The growth rate of R&D spending by companies has shrunk from an average 6.6% to less than 1% due to changes in US Tax Code, Section 174, triggering budget cuts that have led to layoffs and caused some startups to stagnate or catch fire on the launchpad. 

• In 2022, “An unprecedented era of rock-bottom interest rates [...] abruptly ended”—an NY Times article detailed how rising interest rates caused venture capitalists and other innovation funds to dry up, leaving startups dead in the water and causing more established companies to declare a retreat from growth mode, reluctant to hire or start new projects.

Additionally, many companies, especially public ones, have been advertising open positions that literally don’t exist. This deplorable practice seems to be either a way for public companies to keep up appearances that they are still in growth mode so that investors don’t sour on them, or a kind of stick to wave at existing employees to remind them that they are replaceable any time. Such companies are unethical and should be ashamed of themselves. It’s no wonder that so many tech workers are losing hope of ever getting back into roles they’re qualified for and end up joining the gig economy or retraining for a different line of work outside of tech.

More recently there have been newspapers that allude to the advent of generative AI and the end of Software Development and other technical careers as we know it. Jensen Huang, the founder and CEO of a famous shovel company, has said that “the days of every line of code being written by software engineers, those are completely over”.

I personally believe these predictions and statements are very premature and ignorant of the factors I listed above that have directly contributed to tech layoffs since 2022. I also believe that the current abilities of generative AI have nowhere near reached a level of sophistication whereby they could viably replace experienced, multi-skilled Software Engineers. Writing clean, secure, future-aware code doesn’t just require knowledge of programming syntax and a stable of code snippets pasted from Github or Stackoverflow—it requires deep contextual understanding of the business space, knowledge about the history of the codebase, awareness of system constraints and caveats, adherence to coding standards, deployment practices, security protocols and things like branding and style guidelines—none of which are easy, inexpensive or even logical to ‘teach’ the AI through reinforcement learning techniques, prompt injections or API calls. 

In my estimation, any CEO who makes a decision today to dramatically reduce headcount in their tech department because of their belief that an AI can maintain their software as well as, or better than human staff, is going to be headed for an embarrassing and costly day of reckoning when the computer catches fire and they are all alone on a sinking ship with nothing but hallucinating robots for company.

All this is to say: if you’ve been laid off recently, please don’t blame yourself. There are so many factors outside your control that have brought you to this place at this time, and it’s not your fault. 

As someone who has been through this trauma twice now, I’d like to offer the following advice:

• In the immediate aftermath, don’t despair. Catch your breath. Breathe deeply. Calm your heart and still your mind. Things will be okay. Reach out to friends and family, tell them the news, let them comfort you—let them in. 

• Don’t overthink the ‘why’. Like I said, it’s not your fault. It’s usually out of your control. Shit happens. 

• If you can afford to take some time for yourself, do it. Go on a short vacation, or watch Netflix for a few days, take your mind off what has just happened. Don’t fall into a slump and risk triggering a bout of depression though: try to stay active if you can, if nothing else, go for walks in nature by yourself or with friends or family.

• Be angry for a while, but not too long. Let the anger turn into sadness. The sadness is a natural part of the process because losing a job can be like losing a loved one—it is a piece of your life that has suddenly gone away. But the sadness and sense of loss will eventually become acceptance, then resolve, perhaps even relief. Maybe you were not a good fit for that company anyway, or perhaps they were toxic and didn’t deserve to have you working there. 

• Realize that most corporations are a soulless artifice. No matter if they treated you ‘like family’ or gave you amazing perks and benefits like free lunch and awesome healthcare—at the end of the day you were always replaceable and the corporation does not care. It sounds awful—and it is, in the grand scheme of things—but the sooner you can recognize this truth the better and the more resilient you will become.

• Take this opportunity to think about your career: was it even on track or would you actually prefer to be doing something else? Use this as an opportunity to consider what other options you may have. Let your imagination run wild and revisit your dreams and ambitions. You could reinvent yourself now or at least push yourself to try out a different path from the one you were on. 

The layoff experience will be different for everyone, but the most important thing to remember is that a layoff is not really the end of anything. It is a temporary fork in the road. Just like any other turning point in life, you still get to choose your own adventure.

This episode of the Magical Overthinkers podcast is enjoyable and on-point. A friend shared it with me and I found it to be cathartic to know that I’m not crazy. I hope it brings you some comfort, too.

The story is for a new feature request. Not a bug. You’ve got to implement something new that doesn’t exist yet. Cool. What’s the first thing you do? Have you already opened your IDE?

What are you doing? Remember when you were in school and your English teacher taught you to create an outline for an essay before diving in to write it? Apply that to your software development before you code yourself into a corner, misconstrue a critical requirement, or produce immaculate code that doesn’t gel with the existing codebase.

It’s important to remember that software development is knowledge work. As much as we like to use physical construction or product metaphors like “building” or “shipping” to describe our work with software, in reality, it would be more accurate to say we are “thinking” or “manifesting” software because, like spoken language, software is the result of contemplating a problem with your mind and using knowledge to solve it. No shovel or jackhammer required. You may be feverishly bashing keys with your fingertips and throwing back vast quantities of coffee or some garishly designed energy drink, but the magic is all happening in your cerebral cortex, which is a good reason to be kind to your brain and why the first step of any sizeable piece of coding work should begin with research, understanding, contemplation of the problem, planning, and design. 

It’s actually quite fascinating to consider everything that is going on in the mind of a Software Engineer and similar knowledge workers. The neuroplasticity of the human brain allows us to adapt our way of thinking in ways that may be quite unique from the normal evolutionary adaptations we are born with or develop over time in everyday life. A 2017 study titled ‘Characterizing Software Engineering Work with Personas Based on Knowledge Worker Actions’ conducted by Microsoft summarized the characteristics of the “adapted mind actions” of software developers:

• Learning: Learning and acquiring new knowledge, skills, or understanding, for example taking courses, training, or observing others. 

• Analyzing: Examining something carefully in order to understand it, for example, understanding unfamiliar code, debugging, and reviewing log output. 

• Authoring: Independently creating text or media content NOT with other people, for example, writing code for personal projects, documentation, tutorials, architecture documents, creating technical presentations, etc. 

• Co-Authoring: Collaboratively creating text or media content with other people, for example, writing code with a team (such as company projects), documentation, tutorials, architecture documents, creating technical presentations, etc. 

• Dissemination: Sharing information about work results, for example, presenting in technical meetings or brown bag lunches. 

• Expert Search: Finding an expert to help discuss or solve a problem, for example finding someone to help fix a bug. 

• Feedback: Providing feedback on technical documents and code, for example, code reviews, or architecture reviews. 

• Information Organization: Managing personal or organizational information, for example, taking notes, tracking, and prioritizing work for yourself or others.

• Information Search: Retrieving specific information, for example, finding a bug report, wiki page, specification, or API documentation. 

• Monitoring: Keeping oneself or the organization up-to-date about selected topics, for example, public task lists, and reading status reports. 

• Networking: Interacting with other people and organizations to exchange information and develop contacts, for example, attending meet-ups, conferences, and participating in online discussions.

• Service Search: Finding specialized tools, for example, tools to visualize data.

Consider how many of the above actions you frequently perform in your work, sometimes many times over just one work day. You’re someone who has trained your brain to use all these actions to solve complex business or engineering problems. These are adaptations that you learned through study and practice, probably over many years. You’ve given your brain a serious workout! 

Now, you wouldn’t abuse your desktop computer or laptop, right? You need it to get your work done, and you’re probably proud of your monitor setup. Everything in its place, just the way you like it. The cat is in real trouble if she knocks your mouse off the desk again. 

But we often abuse our brains without realizing it.  We don’t get enough sleep, for one thing. And all those snacks or employee-sponsored pizzas we eat while we’re working all night to solve a hard problem are probably adding to our premature cognitive decline. 

Consider this a PSA for taking better care of your brain. It’s even more important than your iPhone.

As previously stated, coding work should begin with research, understanding, contemplation of the problem, planning, and design. If you do this instead of going immediately into your editor and writing speculative lines of code you’ll be using the deeper capabilities of your brain instead of the shallow, rote memorization and muscle memory that might convince you that the solution doesn’t require any planning, and you’ll commonly find that it results in much better solutions and a happier team. 

I know a lot of tech jobs are highly stressful, and as they say in the job description, “unpredictable and fast-paced!” (as if that is something to be proud of) and you may worry that taking any time to pause and consider your first move might be a waste of precious time. Don’t worry about that. Not your problem. Take the time anyway: as much as you can spend without incurring criticism. Even a minimum of up-front thinking will pay dividends. 

On teams where this is not only encouraged but expected, one might call this beginning phase something like ‘Analysis and Design’. Unless you are working on a complete overhaul of your codebase or something equally monolithic, you don’t need to spend weeks or months on this phase of the work and you don’t need to break out heavy duty UML. But depending on the size and scope of the requirements of the task you may easily justify a day or two spent making your brain happy by taking the following steps (in roughly this order of execution):

• Meet with the PM to clarify any unclear requirements or acceptance criteria listed in the Jira ticket.

• Talk to other knowledge or domain experts if you’re not one of them (this includes other software engineers but also non-tech stakeholders) so you gain a more nuanced understanding of the business requirements, expected outcomes, and the codebase you’ll be integrating with or potentially refactoring. 

• Read any relevant documentation your team can provide (you do write documentation, yes?)

• Hold the problem in your mind, whatever it is, and examine it from all angles. Take notes, draw diagrams, mind map - whatever helps you get a holistic understanding of what you need to do.

• Step away from the computer for a while if the problem is complex and requires novel or creative thinking. Seriously, go for a walk or take a shower or take a nap in a hammock. Mull things over. Let things percolate in your mind and when you get back to your desk, write down any more ideas or approaches that seep into your conscious mind from your subconscious mind.

• Turn your notes into a slightly more formal step-by-step plan. Include checkboxes for motivation. No need to share it - it’s your mini roadmap to completing the task.

• For more complex additions to the code where there is interplay with other systems, API’s or models, consider creating a basic user flow diagram, sequence diagram or whatever is appropriate for the task. Especially for visual thinkers, this will really help you process the logical steps to achieving the desired outcome and help you identify edge cases. Some managers appreciate visibility into your planning so if you can attach it to Jira, so much the better.

Once you’ve spent enough time (‘enough’ time is somewhere between what you instinctively feel is appropriate and what your manager can tolerate) in Analysis and Design, you can break out the IDE and start writing code. I won’t say you should use TDD, because I was never a devoted acolyte of that school myself, but if you’re comfortable with TDD it’s probably a pretty logical place to start for many code projects.

This preliminary thinking, planning and designing will set you on a course to solving the problem that is reasoned, rather than conditioned and purely reflexive, and most of the time — trust me — this is what you want. Your instincts will still come into play as you get further into the execution of code and when you inevitably run into mysteries and edge cases you didn’t account for, but it’s better than running blindly into a problem and only relying on instinct to guide you through.

Stop, look, listen, before you code.

It wasn’t always possible, but eventually, it became a source of pride for me to be able to say that any new Software Developer on our team could be up and running on our stack and have an innocuous piece of code move through our build, test, and deploy systems on the first day of their new job, all the way from test, to staging then out to production, before the end of that day. 

Getting to the point where we could do this relatively smoothly — without a lot of hand-holding or the new hire having to spend a whole day reading documentation or stuck in configuration hell — was itself a project for multiple team members, including myself. But our efforts paid off as always when we dedicated time to improving our workflows.

Enabling a new developer to deploy something trivial on the first day achieves a few goals:

• It makes for a more satisfactory onboarding for the new hire - they get to experience the gratification of completing a task on their first day, instead of spending the whole day setting up their machine, or shadowing someone else, or going through the documentation, which is more open-ended and less fun. 

• They get an immediate glimpse of the whole process from beginning to end. Later, when you do have them look at documentation, they’ll likely be able to visualize some of the processes they’ve already observed, and it’ll be much more likely to stick in their memory.

• It takes away some of the pressure some teams inadvertently add to the onboarding experience where there is a stated or understated rule like “You are expected to deploy your first code change within the first 2 weeks”. Giving them the chance to do so in a guided, low-stakes learning exercise on day one takes away some of the mystique of that expectation and lets them see (hopefully) how straightforward your processes are and that there’s nothing to be over-anxious about. It may even stave off the inevitable first round of imposter syndrome. 

Seeing the new developer content and not too lost or confused at the end of the very first day should give you a good feeling as an Engineering Manager. It should also mean that your newest team member is already looking forward to tomorrow. They’re already off to a great start.

That feeling is a thread that you should be consistently pulling on if you’re serious about cultivating and growing the people on your team. It is the team’s productivity, engagement and success that are the foundation of what you are measured by as an Engineering Manager — not your individual contribution. 

So if you’re doing your job well and your team is hitting milestones you should take some credit. Any time your team celebrates a win, allow yourself to take pride in it! Give everyone on the team a high five, then give yourself one.

Why did you become an Engineering Manager?

What compels us to embark on this particular journey into tech leadership rather than climbing the ladder to Staff Engineer? I confess, at first, that I didn’t want to go into management at all. I was happy sharpening my skills and providing value as a Senior Software Developer when my manager at the time asked me out of the blue if I’d be interested. 

“Why me?” I asked. 

“We think you’d be good at it. The other developers respect you and you have good ideas. You ask good questions.” 

The idea of management had never seriously crossed my mind up to that point. But after a weekend of reflection and some discussion with my wife, I realized that there was part of me that wondered if I could be effective at leading others and if I could break out of my natural introversion by taking on a role where I’d be forced to spend a lot more time in face-to-face communication with team members and higher-ups. I basically agreed to take on the role as a personal challenge. Not exactly the right reason, but better than some alternatives. What were your reasons?

It took me more than 6 months to start realizing the simple joy of watching my team grow. In those first few months, I suffered from terrible imposter syndrome, was clumsy with my strategic direction and communication, and according to early feedback, my attempts at coaching came across as micromanagement.

In hindsight, it takes a certain amount of time for one’s perspective to shift from individual contributor to leader, even if you’ve had some practice along the way via the tenets of unofficial leadership. Learning how to delegate tasks you used to be responsible for, learning how to trust others to do things in a way that might be different from the way you approached things, and learning how and when to provide feedback and guidance and at what level of detail — these are puzzles that don’t get solved overnight — even more so if you work in an organization that doesn’t provide much in the way of management training (this is very common in the tech world, tbh).

At some point, life on the team stabilized and I began to get to grips with the nuances and challenges of the role. I’ll talk about some of these in later articles. But today I want to focus on those simple moments of joy one can feel when things are going right for you and your team, because ultimately, I think this is what kept me on the manager’s path. 

If you’re new to Engineering Management you may not have experienced many or any of these moments yet but they’re something to look forward to. Here are a few of the moments I’ve experienced over the years:

• Supporting and celebrating team members before and after huge life changes, like having a child, getting married, buying their first home or first pet, moving to a new city, or obtaining citizenship. These glimpses into your direct report’s life can be so enriching and heartening.

• A big salary raise or bonus changes someone’s life, and I have the privilege of advocating for them and rewarding well-deserving team members. 

• A direct report’s self-confidence grows by leaps and bounds as they adapt to speaking up more in meetings or becoming more involved in decision-making — coming out of their shell when they realize the team environment is safe in contrast to previous experiences on other teams. 

• A proud feeling when someone I hired into the company and managed is recognized for their excellence by higher-ups when word gets around about the quality of their work or character.

• Celebrating with the team when we cross a big finish line on a project or product launch, knowing that we all worked together and played our part. Joyful recognition of each other and the daily commitments we make to each other. Confident that I’ve helped set healthy team norms and standards and a sense of how our purpose aligns with that of the larger organization.

• Watching a team member onstage at a conference talk about all the cool things we do on our team to build applications or be more productive. Watching them overcome their nerves as they shine and captivate their audience.

• Goofing off with the team by organizing and/or participating in team-building or random fun activities. Some memorable ones include escape rooms, virtual tours, pub crawls, theater events, visits to art galleries, many summer walks to the downtown restaurants, a samurai sword class, cocktail classes, and hilarious multiplayer games like Codenames, Among Us, and Draw Something. The simple joy of spending time with each other outside of work goals, of laughing at ourselves and each other in good faith. 

• Heartened by how team members naturally help each other overcome hurdles and challenges, or go out of their way to restore balance when one team member is out of office — happily recognizing the inherent upstandingness of most of the people I’ve hired. 

• Receiving gratitude from direct reports I’ve coached through a difficult time at work such as interpersonal conflict with a peer, imposter syndrome, confusion with the tools or codebase, challenges with office politics, etc — and witnessing the amazing mental and sometimes physical transformation that comes over them when they are unburdened and less weighed down by the stress of that thing. 

• Knowing that critical feedback I’ve given in very tough conversations has had a positive impact on the person. Something that often starts out incredibly uncomfortable and stressful can have a transformative effect on you and your employee for the better. It doesn’t always end up like this but when it does I know it was worth the effort and the risk.

• Helping more than one developer ‘graduate’ out of our team and go on to become proud alumni as they join other teams and perform or lead even higher visibility work for the company and earn accolades. 

I didn’t become an Engineering Manager to accrue power, or command a higher salary. I stayed the course because I enjoyed watching people grow and feeling some responsibility for their growth. Don’t laugh, but in some ways, it’s a lot like parenting on a good day. 

I’ve enjoyed the simple act of getting to know other human beings who have gifted me a certain amount of trust that I leveraged into having a positive influence on them in some small way that they may remember many years into the future. That’s what it’s all about. The knowledge (based on feedback) that I’m leaving honesty, good humor, wisdom, and kindness in my wake. And the realization that the ‘soft’ skills I’ve acquired and honed in this role have made me better at life and relationships, even outside of work.

In the comments, tell me why you became an Engineering Manager, and what keeps you there.

Picture it: you’re a hiring manager for a team of Full-Stack Software Engineers charged with building and maintaining a cloud based CRM solution with a backend written in Python and a React frontend. 

Sitting in front of you is a candidate for a new developer position that has recently opened up on your team. They look confident and ready to dive in. You close the door to the office to cancel out the noise from employees playing Beat Saber in the other room, and make yourself comfortable opposite the candidate. There is a large white table between you and the candidate, and an empty whiteboard behind you. 

You exchange a few pleasantries, check the time on your phone, then start in with the technical interview.

“Given a sorted integer array, find the k closest elements to target in the array where k and target are given positive integers.” You say, slowly and clearly.

You stand up, pick up a black dry erase marker and write on the whiteboard:

Input:  [10, 12, 15, 17, 18, 20, 25], k = 4, target = 16

You roll the marker along the table towards the candidate. It slides onto the floor. Oops. It seems like the candidate wasn’t ready for it. You smile and sit down.

“You’ll hopefully recognize this as a binary search question. We ask this in most of our interviews. You can use whatever programming language you want, but we use Python and Typescript on our team, so it’ll be best if you can use one of those. Just roughly sketch it out on the whiteboard if you can.”

To your surprise, the candidate looks immediately flustered. Their relaxed composure has been shattered. They bend down to pick up the marker but then they just sit there, eyes fixated on the whiteboard, not saying a word.

You glance down at their resume which is printed on two sheets of crisp white paper in front of you. It looks really good! Plenty of relevant skills listed, a handful of jobs with interesting experience that seem to overlap quite strongly with the work your team has been doing. And they didn’t use Papyrus font. So what’s the problem? Now the candidate is starting to look really nervous. They’re spinning the marker around on the table while they think, and they’re muttering something under their breath rather than speaking aloud to explain their train of thought.

Should tech hiring managers be using LeetCode and DSA (Data Structures and Algorithms) white-boarding or live coding to test candidates in 2024? In my opinion, no they should not.

I can safely say, after 20+ years working on software engineering teams, that the best Software Engineers are not people who memorize solutions to abstract problems that are not likely to crop up in the actual job function they were hired to perform.

You win at LeetCode if you can solve puzzle-like challenges such as ‘FizzBuzz’ in your coding language of choice, or if you can provide a concise answer to something like “Given a string s, return the longest palindromic substring in s.”

If you can fire off answers to questions like this you are supposedly demonstrating your ability to tackle complex coding problems and that you understand the necessary math and reasoning involved.

But arguably, the former is just seeing if a candidate knows how to use the modulus operator, and the latter expects the candidate to have memorized the ‘expand around center’ algorithm, which seems like a very esoteric way to test their understanding of memory optimization (or whether they can peel an onion).

When these types of question proliferate through tech hiring practices, it forces candidates to become competitive in the wrong way — they spend so much time studying and trying to ‘win’ the game of LeetCode that they neglect the actual skills and instincts they’ll need to be a successful developer: things like SOLID principles, detecting code smells, best practices for refactoring, and design patterns, to name a few. Even if you land a LeetCode champion for your role, can you be sure that they know how to solve real problems they’ll encounter from day one on the job? You’re looking for candidates who want to level up in their career, but not treating software development as if it’s just a game.

Outside of the big FAANG companies, and any organization that really wants to emulate that elite club, or for roles in embedded systems/IOT, one can enjoy a long and satisfying career in software development without ever being a LeetCode pro. 

In 20 years of working in software, I can safely say that, yes, I have used the modulus operator 😊, but I understood why I was using it in the context of the application I was building and why it was necessary, rather than how it applies to some abstract puzzle.

And I’ve always used garbage collected programming languages, so I confess to not really thinking much about memory management outside of common considerations like optimizing for cache hits and avoiding circular references. Call me whatever nerd insult you want, but I earned a nice salary as a software engineer for many, many years having never had to solve these kinds of problems by myself. And I don’t think I am such an outlier.

If a Software Developer ever does hit up against an obscure problem that can’t be solved with their own bag of tricks or a conversation with a teammate, there’s almost certainly going to be a reference guide, a mentor, or an already established solution that they just need to look up and learn when the time comes. Better yet: most of the data structures and algorithms they might try to memorize as a LeetCode gold medalist are already built into the core of the programming languages themselves, or provided by optional frameworks and packages.

Let’s be honest: unless you are recruiting for a very big tech company that needs to hyper optimize or hyper scale beyond the usual constraints of language or hardware — think Google or Amazon AWS — the person you hire is probably going to spend most of their time working with the most common data structures like:

• Array

• Linked List

• Dictionary/Hash map

• Queue

All of which can be learned through theoretical and practical means without ever grinding on LeetCode problems for months on end.

As for algorithms, the most common types are used for sorting, and they’ll already be implemented by core methods of the language being used.

And yet many companies still expect candidates to participate in LeetCode whiteboard exercises, even in interviews for basic software development roles where they will likely never need to call upon such specialized knowledge in their day-to-day.

As a manager, or as a highly trained LeetCoder yourself, you may believe this is the best way to ‘prove’ someone is as skilled as they say they are on their resume, but I assure you it’s not — it’s a surefire way to optimize for a kind of competitive elitism that is more a measure of how much a candidate understands computer science and how well they perform under examination-style pressure than how equipped they are for the daily trials of software development. Meanwhile it psychologically crushes many candidates unnecessarily, excluding good people who deserve better.

As hiring managers, we must know how irrelevant such questions are in context of the position we are trying to fill, yet we seem to keep following this urge to test a candidate’s objective intelligence (or rote memorization skills) rather than spending enough time evaluating their subjective real-world problem solving abilities. Which, if you think about it, is quite counter-intuitive: would you hire a plumber who can instantly recall the scientific formula for water flow rate but can’t demonstrate how to use a pipe wrench?

And really, we’re hiring a human being for our team, right? We’re not hiring an android that requires instant recall and to be completely unemotional under pressure. The interview should make them sweat a little, sure, not make them wish they could melt into the floor!

That’s not to say that the concepts introduced in LeetCode are worthless or always irrelevant. These are interesting brain teasers and they do reveal details about programmatic thinking that will certainly expand a developer’s mind and improve their mathematical reasoning overall. One could well argue that if the candidate is applying for an advanced Architect or Staff Engineer position they should know more about DSA than your mid-level engineers.

But honestly, I’m not going to hold it against a candidate if they’ve never completed more than a handful of LeetCode challenges on their own time and never committed them to memory. If you’re a technical hiring manager, I don’t think you should either. Let’s just stop doing it — unless it is legitimately critical on a practical level for that role.

Back to the interview. You’ve had a change of heart and decided that LeetCode is not appropriate for this interview and is only making the candidate so nervous they will undersell themselves, or worse.

You don’t want to miss out on what could be your next great hire. So you ask them a series of questions that are useful in getting a sense of how they approach problem-solving, how they handle obstacles and setbacks, and what drives them to do their best work, based on the prior experiences listed on their resume.

Additionally, you’ve come prepared with a basic example of some code that the candidate might be expected to work on if they join your team, and some related questions that you can score against a rubric. You open your laptop and ask them to look at the code and talk you through how they think it works while pointing out anything they consider suboptimal or potentially error prone, which is intentionally included in the code as part of the test. The candidate isn’t required to write anything on a whiteboard, you simply prompt them to talk through their thinking process while they examine the code. You build a conversation around this sample of code and really get a good glimpse into how the candidate’s mind works, and their earlier nervousness is gradually replaced with genuine interest and focus on the task.

The candidate before you is a human, not an android, and might just be the perfect choice for the role. And even if they aren’t, they’ll walk away from the interview with a positive experience and a good opinion about you and your company.

That’s worth something too.