Once upon a time things were fairly simple, we were a company that specialised in providing a UK-specific comprehensive technology service that allowed casting agents to run their entire business online.
Back then our team was between three to five developers and our development process looked a lot like Scrum with two-week sprints with a planning session at the start of the sprint and a product-facilitated retrospective at the end of the sprint.
Fast-forward three years and we now have a team of around fifteen developers, four related but different business lines across two continents and a code base that is fast becoming bigger than anyone can keep in their head even at a conceptual level.
So how have we changed?
Giving teams autonomy and accountability
This year I wanted to very consciously make a change to the way we worked as a development organisation. Senior leaders were very involved in the management of projects, in my view too involved. The effort required to provide enough information "up" the chain to allow effective decisions to come "down" meant that project bureaucracy was starting to take up as much time as the actual delivery work. Management was in danger of becoming a friction instead of facilitating work.
New projects now started with a few key people being assigned who understood the problem and do an initial investigation. That work would then lead to a proposal about what the team was that was required to deliver a project in terms of skills and number of people.
For management the goal was then to get the right mix and number of people working on the project or to be brave and cancel the project because it was beyond our capabilities.
Giving up on potentially rewarding projects because of the ability to fully commit to them is a hard and useful constraint. I'd like to say we always made the hard choices but that wouldn't be true. Instead I'd say that when it came to hard choices we made far more hard choices in 2019 than we did the year before. Improving is important if we want to get to a more ideal situation.
Governing work, not leading it
Once the right team is in place the next challenge is answer "How should we work?". The answer to this question lies with the team. The right way of working for a three week project of opportunity is not the same as a six-month infrastructure migration where system stability is at risk.
I firmly believe that self-organisation is important to create an appropriate amount of process. The minute someone outside the project attempts to define the process you run the risk of under or over-specifying what needs to happen with risks on either side.
Instead of trying to define process we have been trying to define governance. At the start of the project there was an outcome, often defined by leadership; a plan for achieving the outcome, defined by the team pioneers and then there is the feedback from trying to execute the plan.
This feedback is really the heart of governance. Is our outcome realistic and achievable? Is our plan the most likely way to achieve that plan? What feedback to do we have that supports our outcome happening and the way our plan works? What feedback implies problems with these?
We have set a weekly or fortnightly cadence of governance meetings that review the work of the team and how successful the team's work has been at achieving the outcome we have been seeking.
The team knows the governance meetings will happen. Anyone is free to attend but generally the pioneers tend to be the people who spend most time in them as the people who have most context and originally proposed the plan. This governance is the key to accountability, the team knows they need to demonstrate that they are getting feedback and acting on it to improve their chances of success.
The governance meetings also allow the company leadership to provide feedback on things happening outside of the project that might help or hinder it. For example, early warning of a partnership that might provide new opportunities or a key sale that could be influenced by the work the team is doing.
It is also a chance for the team to talk about what they need to deal with negative feedback. Commonly this will be about skills the team needs or how sensitive timelines are. If a team is asking for help and the request is reasonable then governance is also where leadership is held to account. No team can be successful if they don't have what they need to succeed.
The team should also be in position to challenge the idea that the team should exist or the problem they are working is the right one to address. The possibility of an internal pivot to a new problem or opportunity should always exist instead of forcing the team to just follow orders.
What has stayed the same?
We still have a fortnightly retrospective, this is attended by all developers and topics can be from anything that anyone is doing. We use the cloud service Retrium to facilitate and record our retrospectives and anyone from the team can volunteer to facilitate the session in the room.
We also still have a daily standup at 10am with all the developers with optional attendance from product and design. People can listen remotely but post their update to Slack ahead of the standup so that we're only trying to get the audio to work one way. Resolving issues for people working away from the office is handled via Slack.
We've had to adjust the reporting format several times this year to make the standup happen at pace and in truth I'm not sure it will be able to survive an increase in the size of the team.
Has it worked?
Well from a selfish point of view I am working significantly less this year than I did last year. That means I've been able to take on a whole different kind of work and focus more on strategy.
General feedback from the teams has been good. Some people feel that there should be more structure and that there should be some common structures between projects. In the development team we definitely have some standard practices and technology that cuts across teams so it makes sense that some of the process should be standard as well.
The most common feedback is that people feel that they are free to get on with their work the way they think is best. However sometimes they feel uncertain about how to do that and they wonder if they are doing too much or too little work.
Addressing this feedback feels like an issue of mentoring and supporting people to me. Remembering to tell people when they are doing okay and giving them some space and time to talk about their doubts (although in general the best people to discuss this with are your team members, which brings up back to team culture).
In terms of delivery output we did much more and grew more in 2019 than any previous years. In just one example we went from a team not existing to it generating £500K of annually recurring revenue in the year. We've not done that before.
If we can keep that empowerment of people to respond to their immediate situation effectively while feeling supported by the people around them I think we'll have a great workplace.
What's next?
POP as a whole is still under the crucial Dunbar's number so in many ways our culture can continue to be face to face and with a reliance on immediate communication to resolve issues.
As our US business grows however we will not be able to rely on this and we will have to start to evolve a more sophisticate mixture of asynchronous communications and principles of action.
I'm honestly not sure what the best solution is but I think we will probably look at loosely collaborating units which themselves have strong internal relationships and communication.
We'll have to look at who does this well and what we can learn from them. If you think you have something to share on this, please do. It's a tough challenge that I think a lot about when I think about where we are going next.
Oldest comments (0)