Saying The Quiet Part Out Loud — Authoring the Zendesk Engineering Job Architecture
By: Adel Smee
Tags: Management And Leadership, Career Development, Promotion

Saying The Quiet Part Out Loud — Authoring the Zendesk Engineering Job Architecture Adel Smee Follow Jul 14 · 5 min read

A few years ago I was in a one-on-one with an engineer who reported to me at the time. They had created unhappy waves by making critical comments about colleagues on a public work Slack channel. I was trying to be a manager, talking to them about the impact their words had and how generalised, public put downs of this nature were unacceptable behaviour. The conversation as I remember it went something like this:

Me: And when you said [that thing] it hurt their feelings and made them feel devalued in their work.

Engineer: But I was right.

Me: It hurt their feelings and damaged our relationship with them, and we need to have a good working relationship with them to get our jobs done.

Engineer: But I was right.

Me: *sigh*

Me again: I need you to be more mindful of other people’s feelings.

Them: Where does it say that? Where in my job description does it say that?

Me: Huh. Fair point.

That conversation really stuck with me both because it’s such a stereotypical software engineer interaction, and contrary to popular culture those don’t happen very often, and because I think they had a good point.

Fast-forward a couple of years and I was working on authoring a job architecture for Zendesk’s large, fast-growing, and globally distributed engineering team. Going through the original, very brief, and technically-focused job architecture there wasn’t one single mention of communication skills, relationships or empathy. And yet those were highly valued at the company. At promotion time management were likely to include them as a factor for (or against) promotion. But because they weren’t explicitly described it was up to the manager if they would use them or not. As a result there were some very uneven applications of the promotion criteria when considering both the ability to human and the ability to technology. My goal was to create a job architecture that firmly included the whole (professional) person and didn’t leave as much wiggle room for managers to focus only on the parts that they resonated with (i.e. were biased in favour of/against).

The resultant Job Architectures have been in use for over a year now and the initial feedback has been promising. The approach taken for both the Individual Contributor and Management tracks was the same - there is a general section that applies to all and then a specific section for each job level. The general sections are those attributes that all employees of any level are expected to demonstrate whereas the specific job level sections describe the technical expectations at that level.

As I was authoring the first draft of the Job Architecture I realised I could either repeat things like “Clearly and respectfully communicates technical ideas” at every single job level, or be a DRY engineer and extract them out into their own section. After extracting out these generic elements I realised that a lot of them were way too specific, and depending on the person, their job, the context in which they had to do their job and more, they might not be as generally applicable as I’d first thought.

The next iteration was to group the generic elements into categories and then try and generalise those in a way that wouldn’t be too prescriptive or biased towards a certain type of person or a certain type of work. Here’s what we ended up with.

For All Individual Contributor Outcomes

Owns Quality

Owns Culture

Owns Relationships

Demonstrates Communication Skills

The way in which any given individual might “Own Relationships” is going to vary too much from person to person to reasonably prescribe a checklist of measurable actions so we just provide some examples that give a better idea of what it might look like. For example in Owns Relationships we have:

Mindfully works with one’s own mental state, and takes the necessary breaks or seeks assistance to maintain mental health.

In order to evaluate performance using this section of the Job Architecture, the bottom line is: Is the Outcome successfully demonstrated?

And for those that are curious, here’s the All Engineering People Manager Outcomes

Develop relationships with direct reports based on mutual respect and trust.

Own delivery for team/s, product or organisation.

Create career progression at Zendesk for your direct reports.

Develop relationships with stakeholders based on mutual respect and trust.

Partner with recruiting to hire effectively.

Embody leadership behaviour.

Prioritise people over technical.

Create an inclusive environment.

Common sense is used in the application of these Outcomes. Obviously the ways in which a Senior Vice President of Engineering can “Create an inclusive environment” is very different to the ways that a Team Lead might. Likewise developing respectful relationships is a two way street — if the direct report is antagonistic then of course the outcome has to be assessed in that light. Again, the standard being applied is: Is the Outcome successfully demonstrated?

In addition to the generic sections we have our individual job level descriptions. I won’t bore you with them, they are quite long, but here are the guiding principles that went into their authorship:

Always avoid specifics. Something like Can configure a Kubernetes cluster is obviously way too specific for a company with over 1000 engineers working on all kinds of tech. The different teams and contexts in which work is done need to be catered for, so any specific tech/tool/process/anything will be exclusionary and create room for bias.

Define everything. We operate in 11 different countries, and need to make sure we share a common language. Which doesn’t come naturally. So for keywords that appear over and over in the Job Architecture, like “Owns” for example, we have definitions that we all work from.

If there is something that “everybody knows” then write it down. To not do so opens the door to all kinds of unfairness.

Make sure, as much as is practical in the real world, that the specific job level outcomes are measurable or verifiable. If a person is expected to do a thing in the performance of their job we need to be able to point to instances of that thing. Note: this isn’t necessarily lines of code or technical artefacts, they can be meetings, PR reviews, Slack conversations, feedback and more.

Promotions and career progression are really important to get more right than wrong. And at the same time, creating a system that is fair for everyone, especially at a larger organisation, is really hard. By saying the quiet part out loud we aimed to reduce bias and make it clearer to folks on the team what they need to focus on to get the career outcomes they are aiming for.