Drawing from real-world examples, this talk explores proven strategies for creating dysfunctional engineering teams. We’ll examine the art of micromanagement (“if you want something done right…”), the power of endless meetings, the subtle craft of cryptic communication, and the delicate balance of taking credit while distributing blame. Attendees will learn how these practices create toxic environments, drive away talent, and ensure project failure. By the end of this session, attendees will have mastered the essential skills needed to become the leader everyone dreads working with.

The Path to Awful Leadership

Throughout my career journey from student to intern to Director of Engineering, managing teams ranging from 7-8 people to organizations of about 150 people, I’ve witnessed many different leadership styles. And I’ve seen enough to know exactly how to be an awful leader, which, ironically, might be the best way to understand what good leadership actually looks like.

We are going to explore how to destroy team morale, kill productivity, and advance your own career in the process.

Some of you might be thinking about Uncle Ben’s wisdom: “With great power comes great responsibility.”

But let me tell you two things: first, being a lead isn’t that much great power, and second, Uncle Ben isn’t going to be there to see what we’re becoming.

So we might as well advance our careers in the process: if someone has to be the problem, why not you?

Case Study 1: The Art of Micromanagement

Picture this: an engineering team working on infrastructure was developing a product to replace a big system handling tons of traffic. They were doing the right thing: deploying step by step, moving traffic bit by bit, monitoring everything closely. They planned to stop at 40% traffic migration for the day and continue the next day.

Then an executive joined their Slack channel: “What are you doing? Why isn’t this product available to 100% of our customers?” The team tried to explain their careful approach. The executive’s response? “No, no, no. If it’s not done by morning, I’m going to come in and flip the switch myself.”

The team stayed late, working frantically through the night. Around 1:30 AM, the system broke down completely. They rolled everything back and posted a message explaining they needed to regroup. In the morning, the executive saw the message, said “point taken,” and left the channel.

Managing Isn’t Enough: You Need Micromanaging

This situation demonstrates several key principles:

  • Teams work harder under pressure. Who doesn’t want people working nights instead of waiting until the next day for the same results?
  • The team was too careful. The executive pushed them to overcome their limitations.
  • The executive showcased positive impact by forcing faster results.

The lesson? Delegation is dangerous. If you expect your team to do the right thing, you’re probably doing it wrong. Always be ready to press that button yourself, regardless of their advice.

Advanced Micromanagement Techniques

  • Ask them to screen-share everything they’re doing
  • If you’re in different time zones, request recordings of their work
  • Keep asking about other projects (bonus points if you’ve already canceled those projects)
  • Demand daily email updates about everything, emails you may or may not have time to read

Case Study 2: The Meeting Multiplication Strategy

An engineering lead joined a team and wanted everyone to be very synchronous. They set up a 15-minute daily meeting, but it wasn’t enough time to understand every decision and every line of code. So they added a two-hour weekly planning meeting on top of the daily meetings.

When team members asked to skip the daily meeting because they were waiting on a big deployment and could work asynchronously, the lead insisted on a “quick” meeting, which turned into 30-45 minutes anyway.

Then came the meta-meetings: pre-planning meetings to discuss the planning meetings, and pre-pre-planning meetings to plan the pre-planning meetings. Each meeting would end with “we need more time to discuss this” and spawn additional meetings.

Finally, they implemented “time-boxed silence”. The principle is simple: putting people in rooms and reserving half the meeting time to read documents they hadn’t had time to prepare, since they were in meetings all the time.

The Power of More Meetings

This approach delivers several benefits:

  • Complete alignment: You know everything your team is doing at any time
  • Up-to-date knowledge: Since they’re always in meetings, the information from last week is still accurate
  • Sense of purpose: People feel busy (which is almost the same as being useful)
  • Fresh documentation: Everything gets written during meetings, so it’s as current as possible

Meeting Optimization Tips

  • Schedule meetings to discuss what meetings you could have
  • Have meetings to determine availability for scheduling other meetings
  • Convert daily email updates into meetings where they read the emails to you
  • Use meetings for writing and reading documents, not actual decision-making

Case Study 3: Embracing Chaos for Opportunity

During the pandemic, many companies grew rapidly and hired extensively. An engineer was brought in to fix disconnect between teams. Some were constantly on fire, others were duplicating work that a third team had already attempted and abandoned for valid reasons.

The engineer proposed a tech lead summit to get everyone aligned, create a roadmap, and establish direction. Their manager’s response? "I haven’t been around the company long enough, I’d prefer things stay the same for now."

When the engineer persisted, the manager shut them down: “You just don’t get the big picture.”

Meanwhile, teams continued burning out from constant on-call work, while others duplicated efforts in isolation. The result? High turnover, no alignment, and the manager eventually getting promoted with expanded scope.

Learning from Chaos: Sun Tzu’s Hidden Wisdom

Sun Tzu ‒ The Art of War

“In the midst of chaos, there is also opportunity.”

And so to create more opportunity for yourself, you need more chaos:

  • Avoid organization at all costs. Change project priorities daily if possible.
  • Skip long-term planning. If there’s no plan, no one can criticize it.
  • Embrace scope creep. Shows you’re thinking big.
  • Reframe burnout as passion. That’s just misinterpreted.
  • Get bonus points by having different teams scope creep toward the same product without communicating.

Case Study 4: The Blame Distribution Matrix

An engineer was added to a project they knew would cause problems. They tried to realign the direction with the team lead, but were told, “We’re too far along, we’re launching soon.” They escalated to their manager, who said, “Let it go, do something else.”

Months later, the project failed exactly as predicted. The engineer was brought back to fix it and successfully got things back on track. Come performance review time? They were told they “failed to convince people to do the right thing” and their review suffered.

Meanwhile, the manager who avoided the conflict got promoted.

Success Is Shared, Mistakes Are Delegated

This principle is fundamental to awful leadership:

When things go well…

  • Take credit for your great leadership
  • Emphasize how you aligned things properly
  • Make sure your team knows how well you did

When things go poorly…

  • Don’t own up to anything
  • Tell your team you’re disappointed they could have done better
  • Blame the intern (they’re only there for a few months anyway)
  • Cite “industry best practices” as the reason for failure
  • Find someone who gave you feedback once and make it their fault

Case Study 5: The Art of Indecision

At a product-led company, engineers raised flags about competing priorities from sales and customers. They asked leadership for prioritization: “What are we shipping this year?”

Leadership’s response: “We don’t need to prioritize. We’ll try to do everything and drop things later if needed.”

The result was features built in parallel that were supposed to work together but didn’t. Like engineers on opposite sides building bridges trying to meet in the middle, except with multiple bridges and multiple middles.

The outcome? Many new features that didn’t work together, customers who eventually used them somewhat, and engineers working harder under pressure to make everything connect retroactively.

Decision-Making Through Avoidance

When asked to make decisions…

  • Be vague and indecisive
  • Say “we’ll circle back on that” until no one remembers
  • Offer to “take it offline” and never bring it back
  • Stall until someone leaves or forgets they care
  • Schedule meetings during people’s PTO to force delays
  • Call things “complicated” and “not worth blocking on for now”

But also, overpromise and miscommunicate:

  • You don’t need your team’s input on timelines
  • Always have time for “one more project”
  • Never push deadlines, just say it’ll be done “tomorrow”
  • Send cryptic one-word emails and let your team scramble to decipher your genius

Case Study 6: Herding Cats

In our final case study, we see an engineer leading a large, multi-team project who did something different. They brought all teams together to align on what needed to be done, understood everyone’s concerns and conflicting timelines, and worked together to deploy a critical system migration.

The result? Teams planned correctly, everyone knew what was happening and when, they structured things together effectively, and the project succeeded. There was public praise, collaboration was recognized, and some engineers even got promotions from the work.

So what we’re learning from this case study is that…

  • You could bring teams together early to align on scope and timing
  • You could delegate to grow people and build ownership
  • You could empower and recognize your team publicly
  • You could take accountability for decisions, both yours and the team’s
  • You could shield your team from distractions and enable progress
  • You could give away credit freely to the people who did the work

You could do all of that. You could.

But where’s the fun in that?