Bad code doesn't kill projects, poor leadership does
Tech leadership strategies when teams sandbag, platform teams don’t care, and loud extroverts try to steal the spotlight
Hello, it’s Ethan & Jason. Welcome to Level Up: Your source for executive insights, high performance habits, and specific career growth actions.
4 FYIs:
(June 11) Top 3 Product Insights from Stripe, Amazon, & Airbnb. Ethan & Rohan (Product at Airbnb; ex-Stripe) breakdown each. RSVP here.
(June 19) Who executives promote and why. We will answer questions first using EthanGPT and then Ethan will add more insight. RSVP here.
Watch Jason & Alexis Ohanian talk about the story of Reddit. They also discuss his career, life as a father, fun facts, and more. Watch here.
Watch “Driving a Culture of Innovation”. Ethan’s career talk on how to get your team to invent well. Watch here.
Most tech projects don’t fail because of bad code, they fail because of poor leadership.
Whether it's teams missing dates, disengaged platform groups, or silent introverts being drowned out by louder voices, the root issue is often how the work is led, not how it’s built.
In today’s article, technology executive, David Markley (Warner Bros. Discovery & Amazon), answers popular tech leadership questions from the first cohort of Ship it: Avoid Failures and Lead Tech Projects to Success (a course David co-teaches with Ethan).
Note, because the course is not a "tech class" but a class about "leading large tech to shipment" — these lessons will certainly help engineering leaders, but also product managers, business leaders, and anyone else who needs to help get a tech project out the door, on time and on budget.
Here are the 4 questions and David’s answers:
“How do you navigate teams that are overconfident & miss dates or teams that purposely sandbag estimates to give them more time?”
“How do you motivate platform teams who are critical to your product but have little skin in the game or enthusiasm for your product?”
“If there is a critical failure (e.g., scoreboard outage during a live event), how do you organize an incident response team to mitigate the issue within minutes? What proactive measures should be in place to ensure rapid recovery?”
“How can an introverted leader, who is successfully driving growth and financial success, effectively handle extroverted counterparts who loudly downplay their achievements and push less effective ideas onto the company's main agenda?”
1. “How do you navigate teams that are overconfident & miss dates or teams that purposely sandbag estimates to give them more time?”
If every team isn’t speaking the same estimation language, you’ll never know who’s over-promising or padding their numbers. Adopt a common framework for estimation and train everyone on it.
Some teams prefer story points as their framework, for example, where each task is given a number to indicate its complexity. It is critical that everyone has the same understanding for what that complexity translates into. If one team maps a story point to the work that an average engineer can complete in a day and another team says that mapping is to half a day, then your estimates are inherently misaligned.
Once teams are aligned, then set a clear target: teams should hit their commitments within about ±10% on average.
If a team never misses by more than 10%, they’re almost certainly sandbagging (always leaving extra time “just in case”) and should be challenged to take on more. Conversely, if they’re routinely overshooting by more than 10%, dig into whether their estimates are off or if capacity planning is too aggressive, and adjust your buffers and workflows accordingly.
The other part of this equation is that transparency and accountability aren’t optional—they’re your early warning system. Run demos during every development cycle with real data, share “How accurate were we?” metrics publicly, and celebrate squads that nail their forecasts as much as those that learn from misses. When a schedule starts to wobble, listen for the “squeaky wheels” (those first voices raising concerns) and convene a quick, blameless deep dive. Ask things like “Can we defer non-essentials, reallocate resources, or break the work into smaller slices?”
Over time, calibrating honest estimates, built-in slack, and rapid corrective loops will turn overconfident misses and padded promises into a reliable engine for delivering on time.
2. “How do you motivate platform teams who are critical to your product but have little skin in the game or enthusiasm for your product?”
If platform teams don’t have skin in the game, the best way to get them invested is to GIVE them skin in the game.
Start by co-owning goals and roadmaps, loop them in early on your feature requirements, and look for overlapping needs across your product teams so you can batch requests. When platform engineers see that multiple teams depend on “their” services, it becomes a shared mission rather than a one-off favor.
Equally important is making the work of the platform teams visible and celebrated.
Whenever a new client or feature goes live, shine a spotlight on the “platform heroes” who made it possible. While customer-facing teams bask in the limelight, a quick Slack shout-out, a “Platform MVP” badge, or even a mention in your all-hands can go a long way.
Show your platform partners you’re their biggest fan, and they’ll bring that same passion back to your next launch.
3. “If there is a critical failure (e.g., scoreboard outage during a live event), how do you organize an incident response team to mitigate the issue within minutes? What proactive measures should be in place to ensure rapid recovery?”
When a critical failure hits, you need a pre-defined playbook ready to roll.
First, trigger your incident response protocol (which should be defined ahead of time): page the on-call leads for each key discipline (infrastructure, applications, networking, data), spin up a dedicated channel or video bridge, and assign a single Incident Commander to keep everyone focused on the top priority: restoring service.
Within the first five minutes of the failure or outage, triage the problem’s “blast radius”:
Who’s impacted?
What systems are at risk?
Then, break the group into small “pods” with clear ownership so you’re simultaneously investigating root cause, applying a hotfix or rollback, and communicating status to stakeholders and customers.
In terms of proactive measures, these are your secret weapon for shaving precious minutes off your recovery time. The key proactive steps to take are: Maintain a living runbook for every critical path (including circuit breakers, failover procedures, and manual workarounds). Then, rehearse these scenarios in regular “game day” drills. Instrument your monitoring of surface anomalies before they become full-blown outages. This includes synthetic score feeds, end-to-end latency checks, and health checks for downstream consumers. Finally, don’t underestimate the power of a well-trained “customer ops” liaison in your incident room: they keep external communications calm and consistent, buying your engineers breathing room to fix the real problem.
Finally, once the dust settles, conduct a blameless post-mortem within 24 hours. Capture what went wrong, how well your team executed, and what improvements need to be made to your runbooks, monitoring, or architecture. Share those findings openly and track your action items to closure.
Turning every outage into a learning opportunity not only hardens your systems, but it also builds the muscle memory that keeps your team ready and confident when the next high-stakes event goes live.
4. “How can an introverted leader, who is successfully driving growth and financial success, effectively handle extroverted counterparts who loudly downplay their achievements and push less effective ideas onto the company's main agenda?”
As an introverted leader, I relate deeply to this question.
The answer is that leading as an introvert isn’t about shouting down the loudest voice in the room. It’s about bringing clarity, substance, and calm confidence to conversations.
When an extroverted, louder peer tries to steamroll discussions or divert attention away from your team’s wins, lean into your strengths: preparation, active listening, and data-driven insights.
Before the meeting, arm yourself with concise metrics and customer stories that illustrate your team’s impact. Lay them out early in the agenda and don’t wait for your louder counterpart to steer the topic elsewhere. This way, you set the record straight with good data before they get a chance to derail it.
Then, during the discussion, use strategic questions to guide the conversation back on track any time it veers off. For example:
“How does that idea move the needle on our key metrics?”
“Can we compare that approach to the results we saw last quarter?”
Questions like these force a collective reckoning with the data while keeping emotion and ego in check. When the louder person inevitably tries to steer the dialogue toward themselves, you can calmly say something like, “That’s an interesting angle. Let’s park it for our innovation backlog and circle back if it aligns with our current goals.”
Finally, build up support from friendly voices. One-on-one, share your results with key stakeholders: your CFO, your product sponsor, and your boss. Do this so that they become advocates for your work in any room they are in. When your louder counterpart tries to overshadow your achievements in a larger forum, these allies will back you up, often more authentically than a loud self-promotion ever could.
Over time, your steady, data-based approach will earn you respect and influence in a way that raising your voice never could.
Let us know if we’ve missed anything in the comments.
If you enjoyed this article, give it a like so we know to write similar types in the future.
Watch Ethan & David’s talk on how you can leverage AI to better ship big tech projects. And if you found this helpful, consider their course (starts June 7th), Ship it: Avoid Failures and Lead Tech Projects to Success.
Thank you to our Level Up Community Member scholarship volunteer judges.
Without our community members, providing course scholarships would not be possible. Our judges review every application and select based on course fit and need.
We know scholarships work because our alumni tell us — many share that they either got promoted, found a new internal or external role (oftentimes with bigger comp and title), or it helped them deliver stronger results.
Thank you to this batch of judges for our upcoming course, Ship it: Avoid Failures and Lead Tech Projects to Success:
Alex Luke (Meta)
Waqar Shaikh (Databricks)
Arun Selvaraju (KPMG)
Dan Monahan (LTK)
Matt Liu (USAA)
Hüseyin Oktay (The Trade Desk)
Joe Woodhouse (Prima Donna Consulting)
Olga Potishuk (ad Originem)
Sergii Dyniovskyi (Halo Lab)
Princiya Sequeira (Anaconda)
Connect With Ethan & Jason
Follow Ethan on LinkedIn.
Get Ethan’s career advice on YouTube.
Connect with Jason (Ethan’s COO) on LinkedIn.
Learn more about Ethan’s live online courses and on-demand courses.
Contact us for corporate training, keynote speaking, guest writing, and more.
 | A guest post by
|