Nearly a year ago, I wrote an article on an initiative called “management bugs” that I had introduced into our Engineering department at Brandwatch. If you’re not familiar with the concept, then I go into a fair amount of detail in the previous article.
However, in summary:
- The management of the engineering department have their own JIRA backlog that staff can raise “bugs” into if something isn’t working quite right.
- Anyone can raise bugs, regardless of role or tenure, and anyone can view or comment on them.
- There is a designated person (me) who receives, triages and dishes out bugs to the relevant people in order to solve the issues.
- Typically the bugs become part of the agenda at our management meetings, and are taken away as actions.
- Once resolved, a summary is written of the outcome and emailed around to the department mailing list.
This week, I was invited to give a talk about the management bugs initiative at The Lead Developer Meetup which was hosted at Intercom’s office in London. In my talk, I introduced the concept and walked through some of the things that had changed in our department as a result.
In preparation for the talk, I revisited the management bugs scheme by reviewing all of the bugs that had been raised and closed. We’ve been running the scheme since summer 2017.
Here’s what I learned:
- In 18 months, we’ve completed 48 management bugs, with 5 currently in progress. So that’s a new bug every week and a bit. Although, it has to be said that the average number of bugs is skewed by a deluge coming in at the beginning of the initiative, and it has lessened with time, hopefully because we’re getting things fixed!
- An overwhelming majority of bugs were opened by non-managers. This is great, as it shows that our staff feel empowered to raise their concerns openly with their names attached.
- The typical length of time that a bug was open for ranged from 5 minutes to 1 year! Some issues were extremely simple to solve, and some were not even necessarily solvable.
I sifted through the bugs to get some examples of issues of different sizes.
Here are some examples of small, quickly solved issues:
- What do the VPs do? As a VP, this one hit slightly close to home! However, it was a good example of us failing to regularly share the location of our career tracks document, which details the roles and responsibilities for the individual contributor and management tracks.
- New starters aren’t getting introduced! And indeed, they weren’t. We now make sure that every new member of staff has an introduction sent to the department from their manager detailing their name, what they’re working on, a picture of what they look like, and any self-declared interests and facts to help break the ice.
- Is there a budget for books and courses? Well, yes, there was, but we had never really documented it. So we did.
- New staff outside the UK aren’t getting dialed into induction meetings. Oops! That doesn’t happen any more, and all calendar invites now have proper video call links.
- New roles aren’t being advertised internally. Often opportunities would arise in teams and the outside world would know more than our internal staff who might be interested in working on something new. We make sure that we publicize roles internally now also.
How about some of the medium sized issues?
- Why aren’t we getting faster as we’re getting bigger? That classic debate. It had a whole bunch of fascinating input from people in a variety of roles in the department. I wrote up a fairly in-depth summary about productivity per head decreasing as you grow, including mention of the Mythical Man Month, speed of decision-making, and the Innovator’s Dilemma, and how we could keep this in mind as we go forward.
- Why do we not advertise roles as part-time? Well, after a bunch of discussions, we now do, and we have part-time staff that we have hired into our department. So that was a success.
- When are we going to rewrite the frontend? We’re not, but this did help instigate further discussion about architectural and technical debt work that we needed to tackle, and we now have a permanent stream of work to address it.
Lastly, what about some of the issues that took a very long time to resolve?
- What is our technical vision for the department? Tricky to define, as it cross-cuts so many different skill sets and areas, such as what our cloud strategy is (we run both cloud and hardware for different parts of the system), how we migrate towards Kubernetes everywhere, whether or not we should standardize the storage and deployment technologies in all teams, and so on. We made a fair bit of progress, but then we went through a merger, so this is all up for further debate again…
- Why don’t we sign up for StackOverflow for teams? We made the decision very quickly that we’d like to, and we ran a trial that was very well received. It just took a long time to secure the budget. Sometimes it isn’t always the consensus that takes the time.
All in all, I’ve been really happy with our management bugs initiative. I hope that it has made everyone empowered to make change, regardless of their seniority or tenure in the department. It’s also allowed myself and others to get involved in discussions with individuals that we otherwise would rarely talk to.
The challenge that I set the audience of the meetup was that they should go away and do something similar in their own Engineering department. Will you?
2 Comments