How Engineers Drive Impact: Discovery vs Delivery

Originally written in 2021, updated in 2025 to reflect recent developments in our industry.

In a previous blog post, I explored career paths beyond Senior Engineer—the Staff, Principal, and Fellow tracks. That covered the "what" of career progression.

Now I want to address the "how": how do engineers actually create impact in a product organization?

As I mentioned earlier, a developer's first years are about learning the fundamentals: technique, collaboration, and method.

Then you need to focus on creating impact through your product contributions.

To be clear: I'm not saying we stop learning hard skills once we reach a plateau—not at all! It's a constant job, though I think it's done more intelligently over time.

But back to the point. At Malt, developers contribute to two key activities: discovery and delivery.

Delivery

Delivery broadly covers many activities: development itself (coding, testing, etc.), industrialization, production, monitoring, and more.

We also call this Build and Run.

This is a well-documented topic. There's a wide range of methods, patterns, and organizational approaches. Seasoned developers learn to adapt based on context.

At Malt, the dev team owns delivery in the broad sense.

Note that the PM isn't responsible for delivery. They're consulted, especially on timelines, but they don't manage the dev team—which lets them focus on Discovery.

While the whole dev team contributes, the Lead Engineer is the communication bridge with the product manager.

The Lead Engineer leads dev team discussions to determine how we'll industrialize and create a battle plan: tackling tech debt, building solutions from discovery, handling level 3 support, etc.

The dev team, represented by its Lead Engineer, must address key delivery concerns: reliability, security, scalability, and performance.

Their role is crucial in bridging discovery and delivery.

The Engineering Manager helps the Lead Engineer, facilitates communication with other teams, organizes necessary ceremonies (like retros), helps establish team metrics, and coordinates with the VP Engineering on squad staffing within their tribe.

In some companies, the Lead Engineer and Engineering Manager roles are combined into one person. At Malt, we've chosen to separate pure management (including people management, recruitment, 1:1s, etc.) from the Lead Engineer role.
This separation is ideal but not always realistic. In smaller teams or budget-constrained environments, these roles are often combined.

Discovery

While the Delivery phase isn't surprising to most, I've noticed that the Discovery phase doesn't always involve dev teams, who are sometimes seen merely as executors—arguably one of the biggest mistakes a company can make.

Unfortunately, I've observed many situations where dev teams discover what to implement during sprint planning or in flashy kickoff meetings.

It's a shame to hire software engineers and not involve them in Discovery. Their greatest value isn't "just" coding—it's designing technological solutions to solve problems. That's the "Engineer" in Software Engineer.

At Malt, experienced developers represented by their Lead Engineer should get involved in Discovery.

As a brief reminder, Discovery is a set of activities led by the Product Manager, aimed at:

• Determining all the problems to solve—the goal being "Design the right thing"
• Determining all the solutions to "Design things right"

The dev team contributes their knowledge of the existing product and understanding of customer needs.

They need to quickly set up simple solutions for A/B tests, data extraction, prototypes, and wireframes (low or high fidelity).

This phase requires pragmatism and ingenuity to test hypotheses quickly. We're not trying to build an industrialized, scalable product at this stage.

A mature team should run multiple experiments each week, and the dev team helps with that.

Obviously, the PM and Product Designer can often work without development (interviews, no-code tools, interactive Figma prototypes, etc.).

At this stage, the dev team owns feasibility questions and must quickly find the smartest AND most feasible solutions while discussing with the PM (who owns value and viability) and the Product Designer (who owns usability).

EDIT (2025): The AI Shift Makes This Even More Critical

When I wrote this in 2021, involving developers in Discovery was already important. In 2025, it's become essential.

Every company is now facing the same question: how do we integrate AI into our product? What gets automated? What stays human? These aren't product or design questions alone—they're deeply technical. You can't make informed decisions about AI capabilities, limitations, and tradeoffs without engineers in the room.

The tech team understands what's actually possible with current models, what's vaporware, and what will be commodity in 6 months. They know the difference between a chatbot wrapper and actual value creation. This expertise is crucial for Discovery.

On the flip side, AI has also transformed how fast we can prototype. With tools like Cursor or Claude, developers can spin up working prototypes in hours instead of days. We can test 5 different approaches in the time it used to take to build one.

This speed amplifies the importance of having developers in Discovery. If you can iterate 10x faster on prototypes, you need engineers involved from day one—not discovering requirements in sprint planning two weeks later.

The velocity potential is there.** But only if you involve the people who can actually ship.**