zendesk.engineering Open in urlscan Pro
162.159.153.4  Public Scan

Submitted URL: http://zendesk.engineering/saying-the-quiet-part-out-loud-authoring-the-zendesk-engineering-job-architecture-68286d852f2c
Effective URL: https://zendesk.engineering/saying-the-quiet-part-out-loud-authoring-the-zendesk-engineering-job-architecture-68286d852f2c?g...
Submission: On July 19 via manual from US — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

Open in app

Sign up

Sign In

Write


Sign up

Sign In




SAYING THE QUIET PART OUT LOUD — AUTHORING THE ZENDESK ENGINEERING JOB
ARCHITECTURE

Adel Smee

·

Follow

Published in

Zendesk Engineering

·
5 min read
·
Jul 14, 2021

221



Listen

Share



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.





SUPPORT INDEPENDENT AUTHORS AND ACCESS THE BEST OF MEDIUM.


AUTHORS EARN WHEN YOU READ MEMBER-ONLY STORIES.

Upgrade for less than $5/month
Or sign up for free
Or sign up for free

Management And Leadership
Promotion
Career Development


221

221



Follow



WRITTEN BY ADEL SMEE

94 Followers
·Writer for

Zendesk Engineering

Nerdturer.

Follow




MORE FROM ADEL SMEE AND ZENDESK ENGINEERING

Adel Smee

in

Zendesk Engineering


WE NEED TO STOP BEING SHORT SIGHTED AND START HIRING JUNIOR SOFTWARE ENGINEERS
NOW


LAST YEAR AS I WAS WORKING ON A CONFERENCE TALK, I CAME ACROSS THIS LABOUR
MARKET RESEARCH CONDUCTED BY THE AUSTRALIAN DEPARTMENT OF…

6 min read·Feb 28, 2017

189

4




Shane Hender

in

Zendesk Engineering


WRITING AN ISTIO WASM PLUGIN IN GO FOR MIGRATING 100S OF SERVICES TO NEW AUTH
STRATEGY (PART 1)


WE ROUTE SERVICE-TO-SERVICE TRAFFIC THROUGH AN NGINX PROXY TO ACQUIRE AN AUTH
JWT FROM AN AUTH SERVICE. OUR WASM PLUGIN SAVES A NETWORK…

9 min read·Jun 13

16

1




Pete Smith

in

Zendesk Engineering


IOS — IDENTIFYING MEMORY LEAKS USING THE XCODE MEMORY GRAPH DEBUGGER


IN THIS SHORT POST I DESCRIBE,


·3 min read·Apr 20, 2017

1.4K

3




Adel Smee

in

Zendesk Engineering


SO THIS IS WHAT IT FEELS LIKE


I AM SITTING IN THE LOBBY OF THE GEORGE R. BROWN CONVENTION CENTRE IN DOWNTOWN
HOUSTON WATCHING THE FLOOD OF WOMEN ATTENDING THE GRACE…

2 min read·Oct 20, 2016

156




See all from Adel Smee
See all from Zendesk Engineering



RECOMMENDED FROM MEDIUM

Love Sharma

in

ByteByteGo System Design Alliance


SYSTEM DESIGN BLUEPRINT: THE ULTIMATE GUIDE


DEVELOPING A ROBUST, SCALABLE, AND EFFICIENT SYSTEM CAN BE DAUNTING. HOWEVER,
UNDERSTANDING THE KEY CONCEPTS AND COMPONENTS CAN MAKE THE…


·9 min read·Apr 20

6.3K

51




Jari Roomer



in

Better Humans


HOW I ELIMINATED PROCRASTINATION FROM MY LIFE (USING NEUROSCIENCE)


KEEP THIS PART OF THE BRAIN IN OPTIMAL CONDITION IF YOU WANT TO STOP
PROCRASTINATING.


·6 min read·Jun 22

9.8K

107





LISTS


HOW TO CAREER PLAN WHEN YOU’VE ALREADY STARTED A CAREER

10 stories·57 saves


HOW TO BOOST EMPLOYEE EXPERIENCE WITH CAREER CONVERSATIONS

7 stories·22 saves


WORK 101

26 stories·22 saves


NOW IN AI: HANDPICKED BY BETTER PROGRAMMING

255 stories·41 saves


Dominik Polzer

in

Towards Data Science


ALL YOU NEED TO KNOW TO BUILD YOUR FIRST LLM APP


A STEP-BY-STEP TUTORIAL TO DOCUMENT LOADERS, EMBEDDINGS, VECTOR STORES AND
PROMPT TEMPLATES


·26 min read·Jun 22

2.4K

22




Unbecoming


10 SECONDS THAT ENDED MY 20 YEAR MARRIAGE


IT’S AUGUST IN NORTHERN VIRGINIA, HOT AND HUMID. I STILL HAVEN’T SHOWERED FROM
MY MORNING TRAIL RUN. I’M WEARING MY STAY-AT-HOME MOM…


·4 min read·Feb 16, 2022

54K

836




The PyCoach

in

Artificial Corner


YOU’RE USING CHATGPT WRONG! HERE’S HOW TO BE AHEAD OF 99% OF CHATGPT USERS


MASTER CHATGPT BY LEARNING PROMPT ENGINEERING.


·7 min read·Mar 17

28K

514




David Theil




HOW TO CRAFT GOOD OBJECTIVES AND KEY RESULTS IN OKR AND RUN OKR ON A BIG SCALE


MY KEY TAKEAWAYS FROM RUNNING OKR ON A BIG SCALE


·8 min read·6 days ago

179

4



See more recommendations

Help

Status

Writers

Blog

Careers

Privacy

Terms

About

Text to speech

Teams

To make Medium work, we log user data. By using Medium, you agree to our Privacy
Policy, including cookie policy.