The Team That Never Worked Weekends (And Still Shipped On Time)
One team consistently shipped on time without weekend work. Here's what they did differently.
Jul 18, 2024
In my experience working with various teams, one particular group has consistently stood out. This team not only delivered projects smoothly but often did so within the set timelines. Remarkably, they didn't need to work over weekends, actively participated in our learning sessions, and maintained a high level of enthusiasm.
At first, I thought the reason was simple: three out of five engineers were full-stack, so maybe the team had fewer handoffs. But another team with a similar composition was not moving with the same ease, even though their quality was comparable.
Digging deeper, I realized that the smaller team of five members, let's call them Team Red, excelled because of their collaborative approach. The Project Managers (PMs) included at least one engineer in sessions with designers, and sometimes even during the wireframing stage. Additionally, designers contributed by helping to quality-assure (QA) the release candidates.
The difference was not heroics. It was the shape of collaboration. Team Red made expensive ambiguity visible before implementation started, so the team did not have to rediscover product and design constraints during QA week.
Key Instances Where Team Red Saved Time
1. Efficient Product Specification and Design Review
While reviewing product specs and initial Figma mocks, Team Red's engineers flagged an issue early on. They pointed out that adding specific information upfront on the home screen would significantly increase development time. If the content remained nested within the flow, the services could infer the information smartly, eliminating the need for additional service calls and preventing a spike in service throughput.
Although the designs were visually appealing and likely to be approved by stakeholders, considering the impact and effort, they wouldn't have been prioritized for development. If they had been, the implementation would have turned several L1 services into critical ones, unnecessarily complicating the system.
The important detail here is that the engineer did not simply say "this is too hard." They explained which services would become critical, why throughput would increase, and what product value the extra complexity would buy. That changed the conversation from taste to tradeoff.
2. Clear Drafting of Edge Cases
Team Red meticulously drafted edge cases on the Figma board. This practice gave designers a clear understanding of potential issues, allowing them to create appropriate screens and component states. Consequently, engineers could avoid cutting corners and accurately address what went wrong. A bonus outcome was that explaining errors to designers required engineers to simplify their language, leading to more user-friendly end-user messages.
The edge-case work also reduced hidden coordination cost. Instead of every engineer interpreting failure states independently, the team had shared language for empty states, partial success, validation errors, retries, and degraded experiences.
Why This Was A System Design Win
It is tempting to file this as a process story, but it is also a system design story. The team avoided a design that would have made a non-critical path depend on more services, more calls, and more operational attention. The architecture improved because the communication path improved.
This is where Conway's Law becomes practical. If product, design, and engineering only meet after decisions harden, the system often inherits that separation. UI choices assume data exists. Backend services expose awkward contracts. QA becomes the first place where the whole product is assembled.
Team Red changed the communication structure early enough that the technical structure could stay simpler.
How To Copy The Pattern
The pattern is small enough to reuse without a reorg. Put one engineer in early product/design review for risky flows. Ask for the cheapest version of the user value before discussing polish. Mark every state that needs backend support directly on the design artifact. Convert ambiguous states into explicit product decisions. Let designers see release candidates before final QA sign-off.
This does not mean engineers should dominate design discussions. It means the team should price decisions while they are still cheap to change.
Warning Signs You Need This
- The same "small" feature keeps causing backend surprises.
- QA finds missing states after implementation is mostly complete.
- Engineers feel forced to invent product behavior during implementation.
- Designers do not know which states are expensive or unreliable.
- Teams are shipping, but every release needs late coordination heroics.
If those signs show up repeatedly, the bottleneck is probably not individual productivity. It is the moment when cross-functional information enters the system.
The lesson
This effective collaboration could be seen as an example of Conway's Law, which suggests that organizations design systems that mirror their communication structures. Learning from Team Red's culture, we have started replicating their approach across all our teams. We will continue to monitor and update you with further insights as we implement these changes.
The lesson I keep coming back to is simple: the cheapest architecture decision is often a better conversation one week earlier. Team Red shipped smoothly because they reduced complexity before it became code.