Hello?

Max has been working at his current company for about 9 months now. On the whole, he’s been having a really good time there: he’s building an interesting piece of infrastructure that will be a big deal for the upcoming product roadmap, he gets on swimmingly with his team, and he’s learning a lot. He’s even been convinced to change his IDE.

However, there are a bunch of things that have been bugging him recently. Firstly, he finds it really hard to find information; notably the documentation for the broad architecture of the platform doesn’t seem to exist, nor do any notes on best practice for the area he works on. How does he know if he’s building things the right way? Secondly, he’s been taking part in job interviews and he feels that the process is too drawn out compared to the speed at which he feels you need to secure good candidates before they accept offers elsewhere. Lastly, he has a feeling that the communication between the commercial side of the business and the engineering department could be a lot better. In fact, there have been a number of miscommunications recently which have made projects appear like they were late when they weren’t.

The problem that Max has is that he doesn’t really know where to raise these issues. He’s mentioned them a number of times to his line manager, but the department is pretty big; for these concerns to get up to the CTO requires four steps in the org chart. Is his message being relayed all of the way to the top where action can happen? He would go to the CTO directly, as he would in his previous job at a smaller company, but he doesn’t know her particularly well, and he can see how busy she seems to be all of the time. He’s nervous of being too pushy.

This feeling of inability to affect change is not something that is unique to Max. Most engineers in his department are smart folks, and they can see that a multitude of things could be a lot better, but they are not sure how they can make them happen. What can they do?

Management bugs

The idea

Last year at Brandwatch we rolled out a “management bugs” initiative, which was a slight adaptation of the concept written about in Radical Candor, a book that comes highly recommended. Kim Scott tells the story of a similar scheme that was implemented at eBay.

The idea was that as the company was growing via rapid expansion, the leadership were becoming increasingly distant from the staff on the ground. The CEO wanted to rectify this problem, and therefore installed a suggestion box in a busy area of the office. Anyone could drop a note into the box and at the all-hands meeting the box would be emptied. All questions and suggestions would be read out and answered in front of the whole company. This was a neat way of breaking down the typical barrier to leadership: all input is treated equally, no matter who it is from.

Our version

We really liked the suggestion box idea, however, there were some flaws:

• Box location: We’ve grown to the point that we have offices in a number of countries, so a physical suggestion box in HQ is only going to be seen and used by those that work in that location. Having a box in each office just makes the whole thing a bit of a pain to manage as well.
• Presence at at the meeting: Those that happen to be on vacation, ill, or visiting clients miss out on the Q&A.
• Tracking issues: Not all of the issues raised are going to be solved instantly. Some may require a lot of discussion, or may spin off into a working group before a solution is found. How can staff know the ongoing status of everything that’s been raised?

We had a think about how we could do this. Was there already a system that allows people to raise issues, to specific people if required, non-confrontationally? Does this system enable these issues to contain discussion and be tracked through different workflow stages? Well, actually, it turns out we were already using one: JIRA.

Set up

We thought that we’d give our management bugs initiative a go for two weeks to see whether it gained any traction. Our pitch to the department was this: it’s fairly commonplace to have bug-fixing weeks in technology companies, where everyone downs their tools and attacks outstanding bugs that haven’t been prioritized. It tends to be fun as everyone can stop their regular work for a while and make a significant impact by their focussed effort elsewhere. Given it works for software bugs, why shouldn’t we try something like this for process and management issues?

We wanted to make sure that if anyone felt that there was something bugging them about the way that the department was being run, then they could create a ticket in the backlog, and the senior management would follow the following process:

1. The ticket would be picked up by one of us, which meant acknowledging it and dragging it into the “ready” column of a public kanban board.
2. Comments would then be solicited from anyone who was interested and actions would be decided.
3. When the ticket was eventually completed, a summary would be written of the issue and the actions that were taken and emailed out to the whole department.
4. The ticket would be moved to “done” and an archive of the summary email would also be created publicly in our company Google Drive.

We created a new JIRA project called “Management Bugs” and gave administrator access to the senior managers in our department. In our case this was the CTO and VPs. The premise is that anyone would be able to raise their bugs into the backlog where they would be seen, tracked, and worked on, out in the open for all to see. We also gave people the option to raise a bug anonymously if they wished by having one of the senior management submit it on their behalf.

After setting this up and announcing that the initiative existed, how did we do?

Reflections

We were initially concerned that nobody would engage so publicly, and after the first day there was only one fairly uncontroversial ticket raised. However, given time, and after others saw that the tone of discussion was friendly and constructive, many others took part. We’ve now been running the initiative for 6 months and we’ve had 37 management bugs raised from people in a multitude of roles in the department, and we’ve solved 29 of them. The subject of the bugs has been incredibly varied, and we’ve been impressed with how open and honest everyone has been in defining, discussing and solving issues.

Here are some example management bugs that were raised and their resolutions:

• The surprising difficulty of booking Airbnb instead of hotel rooms through the travel system, even though they’re usually much cheaper and more interesting to stay in (plus you can cook your own food!). It’s now really easy to do so. Our Finance team helped us out a lot here.
• Clarification on how perceived performance links to salary increases at the end of the year. The algorithm for how salary increases are calculated according to performance and budget is now documented and available for all to see.
• Interesting discussion about the perceived speed that we get work done and how that has changed over time as we’ve grown our headcount. The perception that more engineers and a larger company means faster work isn’t always true.
• Concerns about teams switching to new projects too quickly after their completed project has shipped, thus not getting the chance to iterate, bug fix and address technical debt. As well as being mindful of the issue, we now try to give each new feature defined time to soak in production before context-switching on to new endeavors.
• Observations on the current quality of communication between the engineering department and commercial teams. We now have weekly newsletters and our CTO has regular open Q&A sessions with those in the US since our HQ is in Brighton, UK.
• Whether our existing take-home technical task is still useful in hiring new engineers, and if so, whether we can make them better for candidates to complete and easier for us to review. Broadly speaking it’s OK, but could do with some improvements, and we also don’t need to give it to everyone if they have enough demonstrable proof of their programming skill (e.g. an active Github account).
• New roles in teams were being advertised externally on the company website, but people who already work for us sometimes didn’t realize that there exists an opportunity to apply for them. We now make sure we advertise internally too.
• Ensuring it’s clear on our careers page that part-time applicants are welcome for most positions.

In summary

We’ve been really surprised by how well the management bugs initiative has been received here, and I would definitely recommend giving it a try. Feedback from our staff has been positive, and we’ve been appreciative at how open and honest everyone has been in discussions. This is the culture we’re aiming for, after all.

If you do decide to give this a go, do make sure that there is enough engagement from those who are running the initiative to keep it active. Seeing bugs stagnate may make people think that management doesn’t care, so do set aside time every week to work on it.

What bugs do you reckon your staff would raise?