Language as a tool for engineering teams

Written on September 24, 2020//8-minute read

I've been a lot more interested in language lately. That's likely due to the fact that I spent some time with other people who talk about the subject often. As a consequence of this, I have paid more attention to how powerful it can be for multiple purposes.

Take the video below as an example. Jacob Collier explains harmony in music to a variety of audiences, starting with a 7-year old and ending with legendary jazz musician Herbie Hancock:

I love how in just a few seconds, Jacob can explain harmony in an appropriate language to many audiences, ranging from no technical expertise in music (see 00:00 to 1:05) up to meta-language (see 11:00-12:00). At the final stage, the interactions are wordless – yet, communication is still very much there. That is language's primary purpose, communication.

I can't help but draw a parallel to technology, especially when we live immersed in terms, concepts, abstractions which are non-trivial to be understood, such as harmony in music. With this said, there are some areas where language can help engineering teams to be more effective and communicate better.

Cohesion between team and stakeholders

I think the best example I had in my career so far when it comes to language impacting a relationship with stakeholders and business outcomes was when I was exposed to payments systems for the first time. Trying to make sense of all the domain-specific terminology was terrifying. I remember trying to make sense of card authorisation, capturing funds, clearing funds, settlement, reversals vs refunds vs voiding, chargebacks... it was even harder trying to understand how these are connected when my stakeholders would articulate the same concepts in multiple different or interchangeable ways.

My main takeaway from this experience was that learning something new can be challenging, but when language is loose between business and technical folks, it makes everything much harder.

My favourite approach to this problem is Eric Evans' on Domain Driven Design. Here's a summary, in my words, of how he describes this problem in the book:

When stakeholders and technical teams do not share language you have serious issues, as each group builds its understanding in a siloed manner;
Because each party has its language, translation is expensive at best, or incompatibilities are unnoticed at worst;
This situation ends up bleeding into system design and code, which may render technical jargon or domain-specific concepts incomplete or wrong;
And to the same degree, language used by stakeholders doesn't serve the technical team's needs, leaving both in further isolation from each other.

The proposed way to solve it is what Eric coined as Ubiquitous Language: having a shared language which articulates a domain model in a simple, concise manner, without leaking implementation details or excessive domain-specific jargon. Everyone uses and plays a part in building this shared language. The outcome is a language which you can use everywhere as it is representative of the domain at the right level of granularity and abstraction for any context, hence useful for both technical teams and domain specialists.

Even though not related to a stakeholder/engineering team relationship, Ubiquitous Language can reduce the learning curve for onboarding, support internal talent mobility, facilitate inter-domain knowledge sharing, and lower the bar for engineers to have a broader impact within a domain.

Goal setting and accountability

When it comes to setting goals, it is common to use a combination of expected impact and measurable outcomes to achieve that impact. OKRs are a great example of how to do that. Here are some ideas on how to improve a goal through language.

Firstly, the benefits of achieving a goal should be obvious. If it is hard to articulate the value yielded by achieving a goal, this could potentially be solving for the wrong problem, or just be masking the symptoms of a problem. It is even harder as part of a team, as there is a natural inclination towards confirmation bias and herd behaviour and the other team members can easily empathise. When challenging whether or not this is the right problem to be solved, one technique that can help is five whys.

To make the goal itself obvious, language should be simple. To achieve that, avoiding overly technical terms, acronyms, component names, nicknames/aliases, business/domain-specific language, or lingo someone outside of your team wouldn't understand can help. Using such terminology in the context of extremely technical teams is fine as long as that's a conscious trade-off, as if someone new joins or there is a need to articulate the goal outside of that team, it will be harder to make the goal informative to them.

Moreover, a goal should be opinionated and outcome-focused instead of output-focused. An excellent read about this subject is Phil Calçado's article on how he approaches OKRs. Drawing the parallel of using KRs as the test to the Objective is very interesting from a language standpoint as there is an inherent opinion of what achieving the desired impact is through the choice of measurable results.

Finally, goals shouldn't be bendable. As a result of ambiguous language, I have seen goals be relativised unintentionally. Language should support accountability and keep the team honest about what success looks like. Ways to remove ambiguity include the choice of words for an objective and key results as previously described, but also the options on how to grade key results on review sessions. Common ways to do it are through a boolean outcome ("yes"/"no") which has less inclination to ambiguity, and percentages (x% completed) or statuses (completed, pending, in progress) which have more tendency to ambiguity.

In short, a well-written goal has an obvious upside and is written in simple language, has an obvious why, one or a set of obvious "how much"s, and should communicate what success looks like very clearly.

Metrics and baselines definition

Metrics are a fundamental part of goal setting, but goals also implicitly call for focus. It is hard to articulate a metric concisely while capturing all the nuances of that measure such as supporting metrics, baselines for competing metrics, or upstream or downstream consequences of optimising for a specific goal.

Nevertheless, it doesn't mean that a metric that isn't driving a goal isn't relevant. Not paying enough attention to supporting metrics or competing baselines might set you off course by meeting the target which you expected in a goal, yet not delivering the value which you expected. As Goodhart's law explains well:

"When a measure becomes a target, it ceases to be a good measure."
—Charles Goodhart

To exemplify, imagine a hypothetical situation of a set of teams responsible for onboarding new users to a product, with the goal of "increasing the number of registered users by 20% within the first half of the year". When over-indexing on lead quality, there is increasing friction through identity checks, which will increase churn and turn into additional cost upstream, on advertising for lead acquisition. On the other side of the spectrum, there is over-indexing on intake, which then will incur into fraud costs downstream for misuse of the product, or additional operational overhead for terminations for fraud reasons.

A way that language can help is creating a new metric, let's call it for the above example "genuine registration" which takes into consideration both baselines – keeps identity check churns at <5% and identity fraud declines at <0.1%. The new goal would be "increasing the number of genuine registrations by 20% within the first half of the year". That's a much more transparent metric: adding sign-ups while maintaining quality and intake at the same levels. As a complementary effect new metric is now attainable to the domain that set of teams owns and can help with focus with what must be done:

What could be done to improve the user experience when signing up?
What can we do to reduce friction or churn when signing up?
Which other ML fraud model features we can use for predicting fraudulent behaviour when signing up?

This technique turns out to be helpful not only when you have associated baselines, but also when you have implicit supporting metrics or a complex definition where value comes from. A great example of this is monthly active users (MAU) and daily active users (DAU). Every product will have its definition of what "active" means, such as product usage or engagement time. You can dive in if you want, or just get the information that you need from the word "active" itself.

An interesting read about baselines is Will Larson's article on Goals and Baselines where he explains similar dynamics to the above and a different approach to goal setting which I found very interesting.

In closing, as Jacob Collier shows incredibly well in the video at the beginning of this article, language is most effective when it is considerate of the audience. It will take different forms and shapes in different settings. The most exciting part of this journey is being open to trying and figuring what works out together.