Staff-Track and Senior-Track Careers

A pattern becomes a product feature through four stages: recurring engagements, a selected pattern, a generalized version designed with the product team, and a build into the core product

Programming

Two Engineers, One Year

Imagine two engineers who both spend a year doing excellent client work. Each one ships solutions, keeps customers happy, and learns the domain well. Yet over time their careers can drift apart. The difference is not how hard they work on individual jobs. It is whether their work also changes the product that every customer uses.

This article follows one assignment that makes that difference concrete: a task for a designated set of months that asks you to carry one lesson from the field back into the shared software. As you read, keep one question in mind. When you finish a customer job, what, if anything, from that job reaches the code that every other customer will run?

From Dirt Track to Highway

The source frames this assignment as paving a highway. A single customer's custom path through a problem is like a dirt track: it gets you there once. When many customers keep needing the same path, it becomes worth building a road that anyone can drive on without special effort. The metaphor captures the central idea. Custom work solves one problem for one customer, while a built-in feature solves that problem for everyone who needs it.

The rest of the article explains how to find that road, what it takes to build it, and how it ties into two different career tracks.

The Four Stages of Generalization

The assignment describes a movement with four stages. Read the diagram as a one-way path. Many individual engagements feed the search for a pattern, but only one pattern is selected for generalization. The generalized version then becomes part of the product itself, which is the point where the work stops belonging to one customer and starts belonging to everyone.

What happens at each stage, and in what order, as a recurring engagement pattern moves until it is built into the core product?

Stage one is the engagements you have already worked on. Stage two is choosing one of them: among those engagements you look for a recurring pattern, meaning a piece of work that keeps reappearing, and you select the one pattern you will carry forward. Stage three turns that specific pattern into a generalized version, one that is not tied to any single customer. Stage four is the build, in which the generalized version is placed into the core product so that future customers receive it without needing a custom effort each time.

Choosing a Pattern by Counting Customers

The selection rule in the source is concrete: pick the pattern from your engagements that has come up at the most customers. Counting is the whole method. The rule counts distinct customers, so a pattern that appeared five times for the same customer counts once. Notice what the rule does not ask. It does not ask which pattern is the most technically impressive or which one you enjoyed building most. It asks which one recurs most often across the people you served.

Given several recurring patterns with different customer counts, which one is selected, and which decision steps lead to that choice?

Worked example

Applying the count to a set of engagements

Over the assignment period you completed twelve engagements for six customers. Three patterns recur: a CSV import fix, a custom login flow, and a report export change. The table below records which customers each pattern appeared for. Which pattern should you generalize?

1
Identify each pattern
CSV import fix appeared for customers A, B, C and D. Custom login flow appeared for customers B and E. Report export change appeared for customers C, E and F.
2
Count distinct customers, not occurrences
CSV import fix has 4 distinct customers. Custom login flow has 2. Report export change has 3. If one customer needed the CSV fix three times, it still adds only one to the count.
3
Compare the counts
4 is higher than 3, and 3 is higher than 2, so the CSV import fix comes out on top.
4
Confirm the choice against the rule
The rule asks for the pattern that has come up at the most customers. Technical interest and personal enjoyment are not part of the count, so they do not change the answer.

Result

Select the CSV import fix for generalization, because it recurs across the most distinct customers.

What do you think happens?

Using the same counts (CSV import fix 4 customers, report export change 3, custom login flow 2), which pattern does the selection rule choose, and why would a fast-running or exciting pattern not change that answer?

Reveal answer

Answer:

The CSV import fix is chosen, because the rule selects the pattern that has come up at the most distinct customers.

The rule is a count of distinct customers. Speed, cleverness, or how much you enjoyed the work are not part of it, so they cannot change which pattern wins.

Mistakes When Choosing a Pattern

Common mistake
Counting engagements instead of distinct customers
What it looks like
One customer sent you the same export problem four times, so you count four for that pattern.
Why it fails
The source's rule counts distinct customers. Repeated work for one customer shows that one customer needs the path, not that many customers do.
Do this instead
Count each customer once per pattern, then compare those totals across patterns.
Common mistake
Choosing the pattern you enjoyed most
What it looks like
You pick the most elegant solution because it was the most fun to build.
Why it fails
The selection rule does not ask which pattern is most impressive or enjoyable. It asks which recurs most across the people you served.
Do this instead
Apply the count first, then build the pattern with the highest distinct-customer total.
Common mistake
Treating one customer's custom fix as a generalized feature
Why it fails
A custom path is like a dirt track. It works once for one customer, and it is not yet a road anyone can drive on.
Common mistake
Skipping the product team, so the generalized version is never designed with them

Senior Track Versus Staff Track

The assignment's most important idea is that the contribution to the code separates two career paths. Both paths involve doing customer work, and the source describes both as shipping engagements. The difference lies in what happens after the engagement ends. On the senior track, the engineer keeps shipping engagements. On the staff track, the engineer also takes patterns from those engagements and pulls them into the product.

How do the senior-track and staff-track roles differ in what each contributes, and where does each sit along the generalization path?

Read the two columns side by side. Both tracks share the engagement work in the left-hand position. Only the staff track has the extra step of moving a pattern into the product. This is why the assignment is not a demand to become a different kind of engineer. It is a demand to make one additional contribution, the one that carries your knowledge into the shared code.

What the Promotion Claim Does and Does Not Say

The source notes that the labs and the better vertical AI startups promote the staff-track group at materially faster rates. This comparison is the one claim the source supports.

Trace Your Own Engagements

MEDIUM

Suppose your last several engagements produced these patterns, with the customers each one appeared for listed next to it: pattern X for customers 1, 2 and 5; pattern Y for customers 3 and 4; pattern Z for customers 1, 2, 3, 4 and 6, with pattern Z also appearing twice for customer 6. Using the source's rule, which pattern should you generalize, and what is its distinct-customer count?

Hints

Count each customer once per pattern, even if that customer appeared many times.
Pattern Z appears twice for customer 6, but customer 6 still counts only once.
Compare the totals for X, Y and Z, then apply the rule: the most distinct customers wins.

Your attempt (not saved)

Key Takeaways

A pattern becomes a product feature through four stages: recurring engagements, a selected pattern, a generalized version designed with the product team, and a build into the core product.
The selection rule is to pick the pattern that has come up at the most distinct customers, so counting customers matters more than counting occurrences or judging how impressive a pattern is.
The senior track keeps shipping engagements, while the staff track also pulls patterns from those engagements into the product; that added contribution to the code is the difference between the two tracks.
The source reports that the labs and better vertical AI startups promote the staff-track group faster, but gives no figures, so that comparison is the only claim to rely on.