The Guardian is a relatively flat organisation, between an ordinary developer and the CEO of the Guardian there are just three layers: the chief digital officer, the director of engineering and their line manager. As an organisation we also want to empower individuals to take control of their work and manage their own careers. In an utopian situation people would just be able to work on what they wanted and focus on maximising their own contribution to the organisation.
In practice though the organisation needs some things to happen within a particular timeframe and a structure-less organisation can be as intimidating as it is liberating. People cannot make meaningful decisions if they don’t have the right information to inform those decisions.
The impetus to change
Most organisations, tend to the status quo. By default they will carry on doing whatever they do at the moment. Whatever our intentions, the way that people ended up working on projects was historically by top-down direction.
People were assigned to projects by the director of engineering and the project managers, with developer managers arguing for assignments that aligned with what the people they managed wanted to do and product managers arguing that their current teams should be maintained as they were.
After one particularly fractious assignment process we, as a group, had managed to dissolve one operationally critical team and maintain another at a strength that far exceeded the work it was required to do. We had finally had enough pain to look at an alternative solution.
Working groups
One common way we address problems in our ways of working at the Guardian is to form a working group around the problem. Anyone is welcome to join the group and it is usually given a frame of reference for the problem from the stakeholders (in this case, the people in the department leadership who could authorise the organisational changes the group might recommend) and a timeframe in which they will report back.
So a group of people came together to address the issue of how we matched developers to projects. The first thing that people said they wanted was transparency about what new projects and teams were being created. They also wanted to allow anyone to apply to any new positions that were opened.
Implementing a solution
These first suggestions were actually really simple to implement. We created a Google document that lists all the internal positions that are currently open. We also send a departmental email when a new position is added to the document.
In addition to the Google document there is a Trello board with a column for each team and a card for each team member (or position if no-one current has the role). These cards can have dates and notes to indicate which changes are upcoming and when open positions are expected to be filled.
From the point the position is advertised people have a week to apply. When the week expires the person in charge of the vacancy reviews who is interested and arranges conversations with the applicants. If they want to offer the position to any of them then we look at how soon the people involved can change from their current work to the new role. The ideal is to facilitate the change within a month.
Where you have more people than roles, those not offered the role are given feedback on why they were not chosen. The applicants will understand a bit more about themselves and how they can grow and change and as managers we understand better what people’s ambitions are.
This situation has only arisen a couple of times to my knowledge and in most cases the people looking to move did get the chance to do so later as people moved out of the team they were trying to join. The process was much easier as a result of the conversations that had been had earlier.
Judging success
To determine whether the changes were a success or not we were able to use feedback from developers who had not been involved in the working group.
We already had a question in the staff feedback questionnaire asking whether the organisation makes the best uses of its peoples’ talents so we could look at how responses to that question changed.
Developer satisfaction did rise after the changes, but more importantly, the feedback we had on the improved visibility of upcoming projects and roles told us that we were actually fixing multiple problems at the same time. As an internal document, the descriptions of what the new team members would be doing had a lot of information about the goals of the team and the problems that they were tackling. Consequently, developers generally felt better informed about what was happening in other parts of the larger team.
What if I start a project and no-one want to work on it?
In the early days of the change we were very fortunate in that every position opened had someone interested in doing it and as the size of the development team was growing there was not generally a problem with back-filling someone’s position when they moved. Generally any position not filled by an internal move was instead allocated from our recruitment pool of new starters.
It was probably about six months before we had a situation where we had positions that would benefit from experienced staff moving into them rather than being filled by external recruiting.
That led to some hard discussions as to what we should do: should we go back to top-down direction to “force” people to fill the open roles? Rather than fall back directly to our old, problematic behaviour we took people’s reluctance as a sign that maybe we as a management team were doing something wrong. People were giving us feedback and we would be better to act on it than try and ignore and soldiering on.
Incentivising rather than directing
The first thing we did is look at how we had explained the problematic roles. If we thought they were important to the future of that organisation then had we conveyed that to the rest of the engineering team? Did people have the right context for the work that was being proposed?
By reworking the description and having some of the managers describe the roles and the importance of the work in group meetings we managed to resolve a few more of the positions. Rather than slipping back into direction we had improved our communication and had some valuable insight into how we were managing, or failing to manage perceptions of our work.
Better communication wasn’t the answer to everything though. Some roles are definitely less popular than others and people have a natural tendency to be more invested in the work they are currently doing than a new unknown task. Therefore we needed to reward people who took a risk and tried doing something different and with a higher potential impact to the organisation rather than those people who were just iterating over their current work.
The simplest way to reward the right behaviour is in our review process. We use an informal stack ranking system to ensure that managerial assessments of people are comparable and that people with the same job title and grade are having the same kind of impact on the Guardian.
Therefore in a situation where two people’s work has been very similar we can use the fact that one of them chose to take an internal position that other people were wary of as a “tie-breaker” in the ranking.
We can also use our institutional memory as mangers to allow someone who took on a difficult or unpopular piece of work that was important to the organisation to have “first pick” of any future rule or allow them to do some self-directed work.
In short, we have a lot of informal ways of rewarding the kind of volunteering behaviour that we want to see. We have also tried to be clear that we will use those informal rewards for people so that no-one feels it is unfair after the fact.
Enabling migration
With these final changes we have reached a situation where, and perhaps again it is just for the moment, we are able to match our internal positions to people who are interested in doing the work.
More importantly we have given developers a sense of ownership and direction in their work and careers.