How Envato defined the expectations of our developers

The Envato development team has always had a strong sense of what we stand for, how we work together and what we expect of each other … at least that is what many of us thought. Around 9 months ago our company participated in the Great Places to Work survey, which gauges how our employees feel about Envato as a place to work. Each department received a breakdown of their feedback, and whilst much of our feedback was great, one statement was a clear outlier “Management makes its expectations clear”. This was a trigger to question our assumptions about those expectations. This post tells the story of that journey.

The Response

Step 1 - Review What We Have

We reviewed where we stated expectations, how consistent and available that information is, and how we applied that information. The conclusion was it is patchy and not consistent. Our position description alluded to some expectations, our annual review question didn’t at all, and were broad and generic across the whole company, and goals that line managers set for developers were unique to each developers and did not relate to a common set of expectations.

Step 2 - Organise a Working Group

Envato has around 60 developers right now, and about 45 when we started this work, so consulting everyone as a large group was not going to be productive. We got together a working group of 7 developers that was a cross section of disciplines and seniority.

Step 3 - Come Up with a Framework / Classification

We reviewed all the information we had and came up with a basic classification system of expectations:

  • Tech Competency
  • Learning and Teaching
  • Collaboration and Ownership
  • Envato Values

Step 4 - A Starting Set of Values / Expectation

Next the working group had a go at coming up with a set of these statements, as a template for more broader consultation. We came up with a way of stating them which was a first person assertion, so that a developer could “ask themselves” if they satisfy this expectation, not just so that a manager could “judge” the developer … e.g. “I define the problems I am solving before the solutions”

An Example Developer Expectations Trello Card

We came up with 13 statements in this first draft, although we chose not to be exhaustive, but more to provide starting points for the rest of the team.

Step 5 - Get Ideas all Team Members

The entire dev team of 35 staff members was split up into groups and and assigned to one working group member. There were 9 separate sessions ran.

They ran a workshop to come up with a unique set of statements themselves. Ideas were collected in individual trello boards, and categorised either with the existing categories or new categories.

There were 220 statements, around 20 from each group, generated in these sessions.

Step 6 - Merging all Input to One Master List

The working group got back together to attempt to synthesise all this feedback. We created a new “Master” board with 5 major lists. The working group moved cards from their workshop boards into the Master board. The lists we came up with, with number of cards in each list was:

  • Technical Competence - 86
  • Collaboration - 57
  • Learning and Teaching - 42
  • Envato Values - 19
  • What Makes and Awesome Team Mate - 8
  • Miscellaneous - 7

With everyone’s separate lists on the one board it looked like this! All Developer Expectations Trello Cards

Step 7 - Consolidating Ideas

The working group split into 3 groups to consolidate one list each. The outcome of the consolidation was to represent common themes in the input. For example the Collaboration list had 57 cards and was consolidated to 10 major themes, covering about 50 of the cards, with 7 being marked for review.

Consolidating Expectations

We linked these consolidated cards back to the original card so we could trace individual input through to final statements.

Linking Source Statements

Consolidating all our ideas revealed some outliers that were not common across the working groups. We wanted to reduce the final set of expectations to a workable number, so outliers were cut.

Step 8 - Finalise the List

After much re-wording we came up with our final set of lists and cards that we considered a small enough but not too large list of expectations.

Final Consolidated Expectations

Step 9 - Convert to a Github Repo and Request Reviews

Once we were happy with our trello cards, it was time to publish these expectations and open them up for comment and review. We decided to use the development process that serves us well for code, which is github hosted repositories and pull requests. After presenting our content to the entire team at a ‘code party’ we found team members started to start conversations via Pull Requests.

Expectation Pull Requests

An Expectation Pull Request

And finally, publishing our living set of developer expectations to the public. You can find them here at Developer Expectation.