Loading…
Engineering Principles at Ramp
Calvin Lee
- Source
- Ramp
- Published
- Added to Yomu
Summary
Ramp documents seven engineering principles intended to codify how its teams build systems, make decisions, and collaborate as the company grows. The principles call for choosing technology according to each system’s context, moving aggressively on reversible decisions while treating durable interfaces cautiously, and aligning system models with customer concepts. They also favor opinionated product experiences, accepting duplication over a harmful abstraction while continuing to seek abstractions that reflect meaningful shared behavior. Rather than implementing requests literally, engineers investigate underlying needs, such as notifying a CFO instead of making approval a bottleneck, and break projects into small, independently prioritized chunks. These chunks can be owned by small teams called “pods,” while the principles remain adaptable rather than ironclad rules.
Context
As Ramp grows, its engineering team is writing down cultural principles that describe how people build systems, make decisions, and work together. The principles are presented as ideas that have served the company well, not as permanent rules.
Approach / What changed
The principles recommend situation-specific technical decisions, distinguishing reversible from difficult-to-reverse choices, aligning systems with customer concepts, building opinionated experiences, investigating the need behind requests, and decomposing projects into small independent chunks owned by small teams called “pods.”
Takeaways
- Technical decisions should reflect a system’s requirements and context rather than enforce stylistic, data-model, or language consistency across every codebase.
- Ramp prefers duplication to an incorrect abstraction, while recognizing that a well-chosen abstraction can provide long-term value; its cards and Bill Pay products currently remain duplicated because their money-movement nuances differ.
- Breaking projects into independently prioritized components can expose ways to deliver about 80% of an initial idea’s value with 20% of the effort and lets small teams retain deep product and code knowledge.