Technical Prime: Enabling Engineering Decisions & Work
Software engineers as Individual Contributors [1] are regularly asked to tackle problems that are transient in nature, or support some domain of interest for a period of time. Sometimes they get asked to collaborate either as a long-lived team or a team pulled together to solve a one-off situation. As common as these allocation forms are, it’s less common to see contributors given guidance on how to organise technical work and reach decisions effectively.
This can lead to various problems: inability to make progress because of deadlock or debates, unclear ownership on who should do what, work falling through gaps (especially so for topics that are long-lived and need ongoing attention or investment), or technical expertise getting locked up inside individual engineers. Finally engineers simply sometimes want to change up what they focus on to refresh and learn new things, and this kind of mobility in turn can contribute to overall organisational and systems health.
Technical Prime is a lightweight mechanism for enabling clarity of decisions and who’s working on what that also affords learning and knowledge sharing.
The Technical Prime
Each initiative, project, or domain we want to focus on has an engineer, called the Prime, who shepherds and drives the technical design and work, or acts as technical steward and leader for a topic over time. Scope of work is a factor—you generally don’t (or shouldn’t) need priming to ship a feature or fix a bug.
Often a Prime is someone with strong in-depth knowledge of the problem and technical domain, not necessarily the most senior staff member, who can impair throughput by serialising work. The construct is in many respects, about expertise and capability rather than experience and seniority. (Further on, we’ll get back to another advantage of not always assigning complex work to senior staff.)
So far so good and this probably sounds familiar, even unremarkable. Here’s where it gets a bit more interesting—the Prime is also the authorised decision maker for the topic when agreement is not to hand. This is particularly useful with collaborations and within teams (which is how most of us work these days). If the group can’t reach consensus, the Prime becomes accountable for making the decision on behalf of the group. It’s all too common to make someone responsible without also giving them a means to close things out and reach conclusions. Likewise, groups of people can simply get stuck. This can be a result of poor group dynamics, but often as not, it’s about the lack of clarity and missing mechanisms for expediting technical decisions.
Giving the Prime explicit tie-breaking authority as well as a ring-fenced capacity for driving the problem, allows a group to make faster progress on a problem. The model, to be clear is not, Prime makes all the decisions. Instead it’s much closer to arbitration—in turn, constantly going to the Prime to break ties is a signal other issues may be at play. On the other hand, we ask the Prime to dedicate themselves to the topic and respect they will make progress and decisions that optimise and govern for overall outcomes. In that sense a Prime is not a consultative function, or at least must not predominantly be so.
Technical Primes & Technical Seconds
For complex or long lived topics, a Technical Prime can be shadowed and supported by one or more Technical Seconds. In turn this affords continuity of effort, workload sharing, diverse perspective from experts, and on the job approach to development and growth. Seconds also provide a kind of social connectivity back to the larger group. This can mitigate a certain kind of loneliness and isolation that can be associated with IC work.
Primes and Seconds can rotate on a topic. This is useful for both training and for scaling knowledge and ability on something that matters. It can even work to have Primes be Seconds and vice versa within a single area or team. For example I’ve worked in teams and domains where I’m the technical second for overall functionality but the prime on a specific concern, such as security or compliance. This extends to actual delegation. I can be the technical manager for an area in the organisational sense, but the technical second for specific functionality and give away control while still being able to contribute and help as a second.
Sidebar: Primes & Technical Leads
Technical Prime is a distinct concept to a Technical Lead, although they may seem similar in some regards, insofar as someone is leading something. There are three distinctions worth highlighting. First, is that Primes don’t require a formal organisational hierarchy to get started: as a result it can be applied to ad-hoc collaborations without the need to set up reporting matrices or management constructs, that though perfectly viable, are heavyweight in comparison [2]. Second, Primes afford throughput. Teams and projects often get bottlenecked on a single lead, or architect, whereas Primes provide a structured means for scaling beyond individuals. Finally, Primes lead on problems and not on people: this is a subtle but important distinction, when it comes to focus and ongoing investment. Primes for example can be useful to incrementally pay into an engineering practice topic such as test quality or builds, and move past harder to action abstractions such as “technical debt”.
Applying Technical Primes also provide a level of visibility to managers. A manager can look at the distribution of topics across Primes and Seconds and make basic sense checks on work in progress, concurrency and cognitive load, or say, advocate for a rotation.
Conclusion
I’ve been using this mechanism for a while, and I haven’t found an approach that has a better power-to-weight ratio when it comes to practical distribution of technical topics, and solving recurring problems, especially maintaining knowledge, training, and making progress. There are of course more structured approaches, such as the aforementioned team leads, and others such as programs or working groups, that may suit better, but are by any measure, more involved.
Finally and though I’ve mentioned decision making a few times, the most valuable outcome of this approach for me has been having a deliberate mechanism for not just resolving decisions, but also providing a sandbox for learning how to make decisions through practice. Good decision making is not the same as being right, but is a skill that can developed by anyone given the opportunity.
[1] Personally I like the term Expert Contributor (EC), but Individual Contributor (IC) is in wider use and better known.
[2] This also means you can try it out, and if it doesn’t work for you, back out easily as a Type 2 decision.