Farrel

Product Engineer

Sheet 001

Rare Candy / Customer Success Platform

Internal tooling that reduced repetitive engineering support work and gave the Customer Success team more autonomy.

Year
2026
Role
Product Engineer

Constraint

Support workflows depended on engineering.

Decision

Move repeatable workflows into internal tooling.

Outcome — CS requests to engineering

Measured: before about 4 per day, after 1 to 2 per week

  • Constraint
  • Before → after, measured

Internal product work at Rare Candy. Internal systems and workflows are described in general terms only.

The dependency

Customer Success regularly needed engineering to carry out operational actions. The actions themselves were predictable and recurring: the same kinds of requests, handled the same way, again and again.

Each one still went through an engineer. That interrupted engineering work throughout the day, and it left Customer Success waiting on someone else to finish tasks that were part of their own job.

Contents ↑

Not every request needed an engineer

Looking at the requests together showed a split. Some genuinely needed engineering judgment. Many did not: they were repeatable actions that only went through engineering because nothing else could perform them.

That made it a product problem rather than a staffing one. The dependency existed because the tools did not, not because the work required an engineer.

Contents ↑

The decision: turn repeatable actions into internal tooling

The decision was to move the repeatable workflows into safe internal tooling that Customer Success could use directly.

My role covered both halves of that: working out which requests were genuinely repeatable and safe to hand over, and building the tooling that let Customer Success perform them.

The aim was not to automate individual tickets one by one. It was to change the relationship between the two teams, so that Customer Success owned its routine operational work and engineering was involved when judgment was actually needed.

Contents ↑

Giving another team autonomy, safely

Handing operational actions to another team only works if it cannot break the systems underneath. Two principles shaped the tooling:

  • Only repeatable actions were exposed. Anything that needed case-by-case judgment, or anything unusual, stayed with engineering. The tooling removed the routine requests, not the need for engineering.
  • The constraints of the underlying systems were kept in the tool. Customer Success could perform the actions, but only within the rules those systems already required.

Contents ↑

Outcome

Engineering support demand related to these workflows fell from roughly four requests per day to around one or two per week.

That figure covers the workflows the tooling took on. It does not mean all engineering support disappeared; requests that needed engineering judgment went to engineering as before.

The organizational effect was the point of the work: fewer interruptions for engineering, and a Customer Success team able to complete its routine operational work without waiting on another team.

Contents ↑