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.
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”
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!
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.
We linked these consolidated cards back to the original card so we could trace individual input through to final 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.
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.
And finally, publishing our living set of developer expectations to the public. You can find them here at Developer Expectation.