# Blueprint — Engine [2] Where I've lived deepest. Team · Product · Tech Jaco Swarts — productive.me --- ## Part 1, in one breath A company is formed around a **brand** — a **promise**. **Trust** is the foundation and the currency. **Consistency** is the uniform you put on to keep it. The **customer** is hiring you to become someone new. --- ## Part 2 is about the engine How the promise actually gets kept, day after day. Two engines: 1. **The Team** — who keeps it 2. **Product & Tech** — where it lives --- ## Engine 1 — The Team --- ### Each role is a promise Not a job description. A promise. Nested inside the company's promise. If you can't say each role's promise in one sentence, you don't have a team — you have a list. --- ### Wear your role like a brand Your role is your own brand inside the company. The way you show up in messages, meetings, handovers — that *is* your brand. Making and keeping realistic promises is a personal aspiration, not a compliance target. --- ### Small + trustworthy wins Three trustworthy people will outperform thirty mediocre ones. Friction collapses. Decisions take minutes. Add people only when the cost of *not* adding them exceeds the trust dilution they introduce. Note: Every new person is a new node in the trust graph. The graph gets harder to maintain non-linearly. --- ### Rituals to catch trust leaks Trust doesn't collapse — it leaks. - Standing 1:1 question: *"Who are you finding harder to rely on right now?"* - Retros that ask *"what did we promise each other, and did we keep it?"* - Pre-mortems on shared work - Promise check-ins: *"Anyone carrying a promise they're no longer sure they can keep?"* --- ### Keep each other honest The team's biggest internal risk is people quietly accepting promises they can't keep. To be polite. To look capable. To avoid the harder conversation. Treat over-commitment as a trust issue, not a planning issue. --- ### Reward the early signal The teammate who flags slippage two weeks out is more valuable than the one pulling an all-nighter to recover. Reward the early signal. Don't quietly reward the heroic rescue. --- ### Grace for failure. Intolerance for the pattern. People will fail. Two jobs at once: - **Grace for the person** — failure is a data point, not a verdict. - **Step in front of the pattern** — protect them from the destructive conditions that produced it. --- ### When a teammate fails 1. **Cover them publicly.** *We* missed this — not *they*. 2. **Get curious privately.** What did they see? When did they first sense trouble? 3. **Name the pattern, not the person.** 4. **Make the next promise smaller and clearer.** Rebuild with a small kept promise. 5. **Only escalate to the person** if the pattern persists after you've fixed the system. Note: Public blame and private grace is the wrong way around. Protect them in public; have the honest conversation in private. --- ## Engine 2 — Product & Tech --- ### The product is the brand made tangible Customers don't experience the pitch. They experience the product. Every load time. Every error message. Every email the system sends. The marketing site can say whatever it wants — **the product tells the truth.** --- ### The tech is the substrate Tech decisions made in year one are the constraints of year three. Ship fast on a foundation that can't bear weight → borrowing trust from your future self. Build a foundation nobody is using → borrowing trust from your present self. Neither is virtuous. --- ## Product Shape --- ### One product. Many services. From outside: **one product**, delivering one promise. From inside: small, single-focus services working together like a swarm. The gateway is the contract. Everything behind it can change. --- ### Simplicity beats features Do the thing the customer hires you for, exceptionally well. Every additional feature is: - A new sub-promise to keep - A new surface to support - A new way to dilute the core promise --- ### Don't rebuild the generic Accounting. Project management. Scheduling. Storage. Payments. Almost every company needs them. Almost no company should build them. Save your build energy for the part of the product only **you** can build. --- ### Every release: more credible, or less? The only ship/no-ship gate that matters. Force the team to answer it out loud. A feature that closes a deal but erodes the promise is net-negative. --- ### Ship for day 30, not the demo Demos optimise for first impression. Daily use optimises for the hundredth repetition. If you have to choose — **choose day 30**. --- ### The roadmap is a promise too Anything committed publicly becomes a sub-promise of the brand. Be **slow** to promise. Be **fast** to deliver what you did promise. A small roadmap kept > a large roadmap missed. --- ## Architecture & Design --- ### Design up-front beats pivoting A week of careful design that prevents a quarter of wrong build pays for itself many times over. Not waterfall. **Think before you type.** Sketch the shape. Name the trade-offs. Agree the interfaces. Then build. --- ### Small, single-focus services Each service: one job, owns its data, clear interface. - Faster builds and CI - Smaller blast radius - Easier to replace when something better appears - Easier for a person — or an AI assistant — to reason about --- ### Composability over completeness Build so pieces can be swapped, replaced, upgraded. When a better tool, service, or model appears, the architecture absorbs it instead of resisting it. --- ### Design for generative AI from the start Small services with tight, well-named contexts are exactly what an AI assistant uses well. Use **MCP** and similar protocols to **go where the customer is going** — meeting them in their existing tools rather than dragging them into yours. Note: This is no longer a future consideration. It's a present design constraint. --- ### Fire a tracer bullet Before committing to any new build: Build the simplest possible end-to-end path through the system, all the way to final state. Every step can be a stub. You now own the scaffolding. From here on, every conversation is about **business logic**, not plumbing. --- ### The boring tech bias For everything that isn't your differentiation, choose the **boring**, well-understood, well-supported option. Save your innovation budget for the parts where being unusual is actually an advantage. --- ## Engineering Practice --- ### Two-week cycles One week: too much reporting, not enough movement. Three weeks+: too slow for real focus. **Two weeks** is the sweet spot. Long enough to ship something meaningful. Short enough to course-correct. --- ### The tool stack - **Linear** — project management. Fast, opinionated, stays out of the way. - **Slack** — water-cooler *and* nervous system. Notifications, support events, PR activity. - **GitHub** — repos, CI, packages, PRs, docs. One home for code and code-adjacent decisions. --- ### PR-driven collaboration Open a PR **for every ticket, early**, with a WIP label. Announce new PRs in Slack the moment work begins. The PR isn't the end of the work — it's where the technical discussion **starts**. --- ### PR standards make history searchable Use Conventional Commit prefixes: `feat:` `fix:` `chore:` `refactor:` `docs:` `test:` The commit log becomes a navigable narrative of the work — not a wall of "wip" and "fix stuff." --- ### PRs are redundancy and learning Code review is not gatekeeping. It is **redundancy** — every PR is another engineer understanding a piece of the system they didn't write. A team that reviews seriously has no single points of failure in its understanding. --- ### Tech leadership: opinionated, evidence-driven Not neutral. Hold a sharp view of *how this team builds*. Hold opinions **hard** until shown otherwise. Change them **publicly** when shown. --- ### Technical debt is a trust ledger Every shortcut is a future promise to fix it. **Named, tracked debt** — healthy. **Unnamed debt** — a trust breach waiting to happen, against your future self, your team, and eventually your customer. --- ### Reliability is a product feature Uptime. Performance. Correctness. Recovery from failure. Not "ops concerns" downstream of product. This is how the promise stays kept on day 100. Budget for it. Staff for it. --- ## The Two Engines Together --- ### A team of promise-keepers building a **product** that lives the promise on **tech** that can carry the promise to the second customer, the hundredth, and the thousandth. That is the engine. --- ## Discussion — Team - Can each person on your team state their promise in one sentence? - What ritual catches trust leaks before they become resignations? - The last time someone failed: did you go after the person, or the pattern? --- ## Discussion — Product - Does your last release make the promise more or less credible? - What are you building that you could rent, buy, or integrate? - Are you optimising for the demo, or for day 30? --- ## Discussion — Tech - Where did you skip up-front design and pay for it later? - When did you last fire a tracer bullet? - Are your PRs a place for learning, or for gatekeeping? --- ## The Closing Principle A brand is a promise. The **team** keeps it. The **product** lives it. The **tech** carries it — to the second customer, and the thousandth. Everything else is detail. --- # Thank you productive.me