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
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 DOMText 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.