Bad News vs Bad Surprise - Lessons From Managing My First Full-Stack Project

TLDR

With new responsibility of leading my first full-stack project, I’m putting into practice a crucial lesson from my previous organization: there’s a world of difference between “bad news” (which we can plan for) and “bad surprises” (which can derail projects). While I’m still learning to implement this principle, it’s already shaping how I think about team communication and risk management. This post explores this concept and my journey in applying it.

Whether designing mechanical systems or software, engineers ultimately serve business goals. As I manage my first complex full-stack project, a lesson from my former manager (CDO), Sylvain Auvray, has become indispensable: the critical difference between “bad news” (known risks) and “bad surprises” (unexpected crises). This distinction reshapes how teams approach challenges.

The Lightbulb Moment

Sometimes the most impactful lessons are the straightforward ones. When I was introduced to this concept, it immediately clicked. Now, as I’m managing my first complex full-stack project, I’m seeing its relevance in an entirely new light. While I’m still learning the ropes of project management, this principle has become my north star.

• Bad News: A known issue (e.g., “This API integration will take 3 weeks due to rate-limiting constraints”).
• Bad Surprise: An unforeseen problem (e.g., “The API failed in production despite passing tests”).

The Daily Reality

Managing everything from frontend to backend brings this lesson into sharp focus. In our current landscape, we deal with:

• APIs that don’t always behave as documented
• Performance considerations across the stack
• Rapid changes in the UI design of the ongoing project
• Integration challenges that emerge at unexpected moments

Looking Forward: Plans for Better Communication

As a new project manager still finding my footing, I haven’t implemented these solutions yet, but I’m excited about putting these ideas into practice:

1. Enhanced Stand-ups: Adding space to discuss potential future challenges before they become urgent
2. Risk Tracking Board: Creating a shared space to document and track emerging concerns
3. Open Discussion Sessions: Regular time slots for the team to raise concerns without the pressure of immediate solutions
4. The “Red Flag” Protocol: Define clear thresholds for escalating issues (e.g., “If X takes >2 days, notify leadership”). It removes ambiguity about when/how to share bad news.

Learning on Both Sides

Being on both sides has given me a fresh perspective on how the same situation looks different from various angles:

Engineering View:

• The challenge of estimating complex technical work
• The instinct to solve problems before reporting them
• The difficulty of explaining technical challenges clearly

Management View:

• The need for early visibility into potential issues
• The importance of creating safe spaces for discussion
• The balance between oversight and autonomy

Real World Application

In our current project, we’re dealing with everything from database design to user experience. Each layer presents its own potential for both challenges and surprises. The goal isn’t to eliminate problems - that’s unrealistic, especially for someone still learning the ropes. Instead, it’s about creating an environment where issues can be discussed early and openly.

Call to Action: Start Small

For teams at any scale:

• Tomorrow: End your stand-up with “What’s one thing that might become a problem?”
• This Week: Share a “I’m unsure about…” in a Slack thread. Normalize vulnerability.
• This Quarter: Retrospect not just on what went wrong, but how late it was discovered.