“No one ever quit!” “Look at our hackathon!” “We hard-allocate time to fight tech debt.” Ostensibly, good things. In reality? Just the advice to follow… if you want to lead a mediocre team.
You’re often tempted to follow the “common” playbook as a tech leader. But what if that playbook is the very thing holding your organization back? Here are six unconventional defaults that, while unpopular, can help you build resilient, innovative, and truly impactful teams.
No Nano Teams
When you create a team comprising a manager and 1-2 people, you’re really introducing overhead without meaningful impact. Those nano teams are rarely self-sufficient and often short-lived (or unnecessarily long-lived). You’re then left to tackle the issues of dividing work across a fragmented organization just to appease people’s egos.
I regularly see organizations with 100% managerial overhead. We could literally cut half of the managers and only then reach sane team sizes (and fewer levels in the org chart). That’s not scaling; it’s indulging inefficiency. Teams should only be created when the pain of not having one is unbearable. A team needs enough critical mass to be autonomous, not a skeleton crew that’s just a glorified task force.
No Hackathons
Hackathons are adrenaline-fueled chaos, great for pizza and team bonding but rarely for long-term innovation. You end up with half-baked projects that die the moment the event ends. If you’re serious about innovation, ditch hackathons and embrace intermissions instead.
An intermission is a structured pause from regular work, allowing teams to pursue meaningful projects. Unlike hackathons, intermissions aren’t about proving you can build something in 36 hours but about creating lasting impact. Whether it’s tackling engineering velocity, experimenting with a new product idea, or solving gnarly operational problems, intermissions focus on quality over speed and ensure the work doesn’t disappear into a forgotten branch. For more on these, grab the free chapter of my book that covers precisely these here.
No Hard-Set “Engineering Time”
Too often, tech leaders wield the “tech debt” card to justify unstructured engineering time. While the intention is noble, the execution is usually flawed. Most of the things we treat as “tech debt” aren’t.
Instead, whatever you have on your backlog should be treated like any other task: Make it visible, quantify its impact, and collaborate with Product to weigh its ROI against new features. When tech debt is treated as part of the roadmap, it forces discipline and ensures alignment on what truly matters.
Don’t Coddle Engineers’ Time Too Much
Some in Engineering orgs feel that developers’ time is precious and must be protected at all costs—fingers must be typing as much as possible. Product is expected to deliver pristine specs, and engineers are kept away from the messy realities of customers and support tickets. This is a recipe for detachment.
Your engineers should spend time understanding the broader context of their work. Encourage them to shadow customer success or support teams quarterly. Better yet, have them rotate into those roles for a day from time to time. Don’t allow them to look for “sign-offs” from Product, but expect collaborative and iterative work. The goal isn’t to burden them but to give them exposure to the real-world impact of their work. Engineers who understand customer pain points and business priorities make better decisions—and aren’t stuck in ivory towers.
Aim for Healthy Turnover
No one ever left your team? That’s not a badge of honor—it’s a red flag. No one’s being challenged enough to outgrow their role. Similarly, if no one’s ever been fired, you’re either hiring far too cautiously or avoiding the tough conversations that drive real growth.
Healthy turnover is a sign of a dynamic organization. It means people are growing. It also means you’re willing to acknowledge when someone isn’t a fit anymore and make space for fresh talent. Embrace turnover as a byproduct of progress, not as a problem to solve.
Break Over-Specialization
Feeding people the tasks they’re best at might feel like a productivity hack, but it creates brittle teams. When one person becomes the go-to expert in a specific area, you’re setting yourself up for bottlenecks and stagnation.
Encourage engineers to take on tasks outside their comfort zones. Even better, create opportunities for internal moves every 12-24 months. Cross-pollination within teams fosters resilience, prevents silos, and keeps people engaged. It’s not about throwing people into the deep end; it’s about building a culture of learning and adaptability.
These guidelines might not win you popularity contests, but they will create an organization that’s stronger, more innovative, and better aligned with its purpose. If your goal is to build something truly great, it’s time to stop playing by the book and start writing your own. If you need help, reach out.