Founders Manual: SDLC

Table of Contents

Founders Manual

It is a long term goal of mine to be a founding engineer. I have notes scattered around in obsidian, notion, docs, margins of books, etc… that I think would be helpful to myself, and maybe others, as a founding engineer. This series will be documents I wouldnt want to have to guide the beginning of an engineering organization.

Software Development Life Cycle

♥️ The SDLC is not prescriptive, it is a set of best practices that can help us be successful. One set of guidelines will never fit every case; as such use your best judgement to try and follow the SDLC and depart from it when it best serves the situation.

Principles

  1. The SDLC is owned jointly by Engineering, Product, and Design.

  2. On a per-project basis, choose an appropriate SDLC Model.

🤝 By default, we lean towards a lower case (a)gile model (https://agilemanifesto.org) and we remember that being agile is better than doing (A)gile. Remember to be flexible.

Stages

The core stages of the SDLC are:

1. Planning & Requirement Analysis
2. Defining Requirements
3. Technical Design
4. Implementation
5. Testing
6. Deployment
7. Maintenance
8. Measure & Assess

Core Artifacts of the SDLC are

1. Product Requirements Document
2. Technical Design Documents
  - Design, Engineering, Data, etc...
3. Project Management Tracking (Linear Project)

Many of the stages may be parallelized and refined in an ongoing basis.

Changes should be reflected in project artifacts (PRD, Tech Spec, ETC).

software development life cycle

1. Planning & Requirement Analysis

Artifacts

  1. Research artifacts (UXR, Polls, Market data, etc…)
  2. Free form writing including Justification/Qualification of the project
  3. Rough ROI Calculation

Description

Justify/Qualify the proposed project against a larger organizational vision or goal. Everyone will have different reasons for why a project is justified. Remember that Consensus by Committee is impossible and sabotage the company. Work towards Disagree and Commit when possible. When not possible, leaders must earn their keep and make hard decisions.

Project Owner(s), often Product but sometimes a mix of organizations, take a first pass at gathering requirements and organizing them into a cohesive product description and or feature set.

Requirements for a project can come from many places:

  1. Stakeholders (functional/technical)
    1. Customer, Data Team, Security, Leaders
  2. Product (functional)
  3. Business Goals
  4. Design
  5. Engineering

With very rough requirements, measure ROI the project could provide and if it’s the right project, at the right time. Do not fall for the Sunk Cost Fallacy; if it becomes apparent at this stage the project is not feasible at this time, do not commit to it!

Present Planning and Requirements Analysis to internal LLM for additional evaluation: Missed any requirements? Anything else to consider? Are there better market opportunities?

2. Define Requirements

Artifacts

  1. Product Requirement Document (required in nearly all cases)
  2. Project Tracking Tool: Linear project, Notion project page (usually required)
  3. Design (optional, often required but parallelizable)
  4. EPD Project Document (usually required for medium+ sized projects, whatever that means)
  5. Early RFC (optional, depends on timing/information)
  6. Early Technical Design Doc (optional, depends on timing/information)

Description

This is the first stage which may be parallelizeable with future steps. Don’t force yourself into rigidity and require that this step be completed before starting the others if it doesn’t have to be.

Didn’t we define requirements in the last step? The project owner(s) did, yes. However, it’s going to save a lot of time spent on misunderstandings if we have the project team review and refine the requirements such that all future work has a solid basis.

  • Product, Design and Engineering jointly define the requirements, further refining them for presentation to stakeholders.
  • Define how it solves the initial hypothesis that justifies/qualifies the project.
  • Receive approval from stakeholders on the requirements and feature as understood.
  • Create a Product Requirement Document, which references initial Technical Software Requirement Specifications.
  • Define Measurements of Success, how to gather data, and how to Assess it.

After all this, we may start the project in ernest by creating a Project Document (probably the landing page for the project or initiative in Linear) and start tracking the project.

3. Technical Design

Artifacts

  1. Technical Design Document (required in nearly all cases)

Description

A technical Design document will often be thought to be an engineering document. However, technical design is something that many organizations may participate in depending on the scope/needs of the project. For example, a frontend which is implementing graphs that represent some technical domain of mathematics should probably be supported some some Data Science technical document, or at least the Design org figma (or similar) should consult with them.

4. Implementation

Artifacts

  1. Iterated on:
    1. Project Tracking Tool
    2. Product Requirements Document
    3. Technical Design Documents
    4. EPD Project Document
  2. Milestone and Feature Deliveries

Description

Jointly with Product, create an artifact in your Project Management Tracking tool. Engineers follow Engineering Principles & Standards to build the project according to the Design Document Specification. Track project in your project management tool.

  1. Consistently communicate up the status and process Change requests during engineering must be discussed and approved by stakeholders.

5. Testing and Integration

Artifacts

QA Testing Output (optional, depends on scope of changes) Alpha/Beta Enablement (optional, depends on rollout plan)

Description

Engineers, QA, and any stakeholders perform any assurance they require before moving the feature into production. Engineers, as part of their testing, follow the Principles & Standards for Testing. Testing is not second class or an afterthought. Software must be built in a testable fashion and be core to development.

6. Deployment and Maintenance

Artifacts

Documentation describing the feature, usage, and any maintenance,

Description

Engineers deploy to the durable live environment(s) according to the engineering organizations defined deployment strategy. Once the project is fully tested and considered stable it is fully released. The product/performance is monitored and iterative improvements are made after deployment.

7. Measure & Assess

Artifacts

Observability (metrics)

Documentation in PRD, and/or Technical Design Document, and/or EPD Project Page. Measuring does not always mean user analytics. In early-stage or 0 —> 1 projects, they can be something as simple as surveys/asking key stakeholders..