Science vs. Engineering in Startups: A Tale of Two Methodologies

The following is excerpted and adapted from my private notes during my time at Predikto (2014-2018), exploring the intersection of scientific and engineering methodologies in startup environments. This is part of a series on startup structure and methodology, following Startup Structure and Information Flow and Decision Making Under Uncertainty.

The Challenge of Technical Startups

Startups in nascent technical markets tend to skirt the line between science and engineering, which brings a very difficult to manage concept into the planning equation: genuine uncertainty. Because of this unique position, many best practices for technical management fall short, or worse, seem to be adequate but cripple development in the longer term.

The Scientific Method vs. Engineering Approaches

The Scientific Method

Science follows a well-defined method that starts with observation and moves into the unknown:

  1. Make observations
  2. Form questions
  3. Formulate hypotheses
  4. Develop testable predictions
  5. Gather data to test predictions (perhaps by experiment)
  6. Refine, alter, expand or reject hypothesis

As hypotheses are formed, expanded, and validated, general theories can be formed to fit all known data. The hypotheses serve as iterative building blocks towards a general theory, and as tests for those proposed theories once established.

The Engineering Method

Engineering, in actual practice, does not follow the scientific method. Engineers start with requirements or an end goal and follow defined processes to apply theories and methods from science to accomplish those goals. There are multiple methodologies for this process:

Agile Development

Agile focuses on rapid iteration, evolutionary development, continuous delivery, and adaptive planning. The twelve core principles from the Agile Manifesto include:

  1. Customer satisfaction through early and continuous delivery
  2. Welcoming changing requirements
  3. Frequent delivery of working software
  4. Close cooperation between business and developers
  5. Building around motivated individuals
  6. Face-to-face communication
  7. Working software as progress measure
  8. Sustainable development pace
  9. Technical excellence and good design
  10. Simplicity
  11. Self-organizing teams
  12. Regular adaptation

Waterfall Development

Waterfall is based around sequential progress towards a larger end-goal, with phases including:

  1. Requirements
  2. Analysis
  3. Design
  4. Coding or Manufacturing
  5. Testing
  6. Operations

For projects with well-defined scope and requirements, waterfall offers minimal overhead, high transparency, and clear milestones. However, it struggles with change and uncertainty.

Systems Engineering

Systems engineering, developed by Bell Labs and heavily used in defense industries, sits between waterfall and agile in terms of flexibility. It follows a broad-narrow-broad approach:

  1. Concept of Operations
  2. High-Level Requirements
  3. Detailed Requirements
  4. High-Level Design
  5. Detailed Design
  6. Implementation
  7. Integration & Testing
  8. Subsystem Verification
  9. System Verification
  10. Operations & Maintenance

The Core Difference: Uncertainty

The primary practical difference between science and engineering lies in workflow. A scientist starts with an observation and moves forward into the unknown, while an engineer starts with a known end goal and works backwards to find a solution.

This has profound implications for technology development processes. Traditional methods like agile or waterfall depend on reliable scoping of tasks, whether we want that to be true or not. However, scientific work, by its nature, cannot be reliably scoped. In fact, the easiest way to determine if work is scientific or engineering in nature is often just to see if you can confidently scope it.

Managing the Science-Engineering Divide

For a technology-heavy startup in new markets, much of the development work is closer to science than engineering. Because it has never been done before, many parts of the work are difficult, if not impossible, to scope. This often leads to a problematic pattern where difficult-to-scope scientific work is conservatively estimated as very large and pushed down the priority list in favor of low-hanging fruit, regardless of potential payoff. For a structured way to think about technology readiness and scoping, see my analysis of NASA’s Technology Readiness Levels.

The key question becomes: how do you reliably plan for that which you cannot reliably scope?

The Solution: Separation of Concerns

In the nascent market technology company, there must be a distinct separation between research and engineering. This distinction is akin to that between sales and marketing. One feeds the other potential opportunities that may or may not filter through to product.

The research group should be free from the restrictions of product deadlines, allowing them to work within the construct of science, while the engineering group can focus on well-scoped projects with deadlines. Even in very small companies where people share roles between engineering and research, it’s crucial to recognize that each role requires different management and scoping approaches.

Science should serve as the ideation source for the company, with ideas filtering through engineering for feasibility at scale and through product/strategy for positioning and market viability.

Conclusion

The intersection of scientific and engineering methodologies in technical startups creates unique challenges that traditional project management frameworks struggle to address. Success requires recognizing the fundamental differences between scientific and engineering work, and structuring the organization to accommodate both approaches effectively.

Note (2024): Reading this now, years later, I’m struck by how similar these observations are to those in Safi Bahcall’s excellent book “Loonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries”. Bahcall describes two types of groups within innovative organizations: “artists” (who develop wild new ideas) and “soldiers” (who execute with discipline), emphasizing that both are equally crucial for success. This mirrors the research/science vs. engineering dynamic I observed at Predikto, reinforcing that the key to innovation isn’t choosing one approach over the other, but rather creating an environment where both can thrive.