3 posts tagged with "engineering"

ADR means Architectural Decision Record, a mini-doc to capture significant architectural changes that are not worth a full design doc.

# [short title of solved problem and solution]

* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->

Technical Story: [description | ticket/issue URL] <!-- optional -->

## Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

## Decision Drivers <!-- optional -->

* [driver 1, e.g., a force, facing concern, …]
* [driver 2, e.g., a force, facing concern, …]
* … <!-- numbers of drivers can vary -->

## Considered Options

* [option 1]
* [option 2]
* [option 3]
* … <!-- numbers of options can vary -->

## Decision Outcome

Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].

### Positive Consequences <!-- optional -->

* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …

### Negative Consequences <!-- optional -->

* [e.g., compromising quality attribute, follow-up decisions required, …]
* …

## Pros and Cons of the Options <!-- optional -->

### [option 1]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 2]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 3]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

## Links <!-- optional -->

* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
* … <!-- numbers of links can vary -->

David Schneider, ServiceNow's President of Customer Ops, shares his sales performance metrics for SaaS companies that are aiming for hyper-scale. For the last 5 quarters:

• • Total Contract Value Attainment
  • Total Managed (ACV, Renewal, PS)
• • Net New ACV Attainment
  • Sales Quota Achievement
  • Q/Q Growth
  • Y/Y Growth
• • Cumulative Total New Customers
  • New Customers (incl. losses)
• • ACV Repeat Customers % to Net New
• • Cumulative Total Net Customers
  • New Customers
• • # Reps On-Board
  • Average Productivity per Sales Rep
  • Sales Rep Annualized Attrition Rate
  • Total Sales Annualized Attrition Rate

You need enough chips to play the game — hire a sufficient number of high-caliber talents who care about quality and are smart enough. You must repeatedly emphasize the company's culture of valuing quality, forming formal routines to check large pieces of work and fix what needs fixing.

Tactically, there is a best practice — reduce the difficulty of doing the right thing. The Stripe tech team makes various trade-offs to ensure that any engineer can improve any part of the system. Encourage a sense of ownership.

There are dedicated internal tools to check the level of internationalization, which may seem tedious but is worth the time. It goes back to the company's culture; when an individual contributor says, "I spent some time on i18n last week," they should assume that leadership values this enough to respond, "Of course, you took the time to do this, great job."

"Open a ticket for the relevant team, and someone will handle it" is a good practice, but if you can push this system to resolve tickets faster and better, you can motivate people to open tickets.

The company provides dedicated channels, such as mailing list aliases, to report product quality bugs. There are dedicated teams to triage these tasks or assign them to the appropriate groups for fixing, along with established routines to inform the entire company about the bug fix rate.

Before making significant API changes, both internal and external testing should be conducted. Regularly ask, "Who has a real Stripe account on hand? Can we update to the beta version and try it out?" People need to set aside dedicated time for this and document it thoroughly — imagine having a group of picky customers; while you may not be able to use your product as deeply and broadly as users do, this approach is much better than guessing.

Discovering that "a piece of payment code hasn't been touched in 5 years, and I don't know how it works, and there are no tests" is rare but valuable for the engineering team.

None of the above is high-tech, nor is it a sufficient condition to guarantee quality. Stripe never settles for the current level of quality and does not passively say, "Our standards are high," but rather maintains a proactive approach to continuously improve.