The Engineering Manager

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?

Not how it was supposed to be

Alice could vividly remember how she felt a year ago when she was promoted. It was her first managerial role, and for years she had been visualizing what life was going to be like when she had her own team. She would feel powerful, confident, and an integral part of her company. When she received the news, her partner was so proud. She remembers their celebration dinner together. They went to her favourite restaurant, the one they always visited on special occasions. Her mother and father were ecstatic. “Our daughter has always been going up in the world!”, her mother exclaimed over a trans-atlantic Skype call. Life was good.

Now we fast-forward to the present moment. Alice is sitting at her desk, her head slumped into her right hand, unable to face the pile of end of year reviews that are due tomorrow. The production environment is on fire and it was the latest push from her team that caused it. Her project is still late, and she can’t face reading the reply from the CTO to her latest update email. She feels scattershot, out of control, over-socialized, and her partner drove the final nail home during a conversation last night: when was the last time she felt fulfillment in something creative now that she wasn’t coding?

This wasn’t how it was supposed to be.

She can’t work out whether it’s the job that’s the problem, or whether it’s her. She also can’t work out whether she’s not good at it, or whether it’s an expectation mismatch with how she had imagined it. Thoroughly depressed, she opens up LinkedIn and starts browsing the job listings for senior developers at other companies in her town. “There’s no way I could go back to my old role,” she thinks. “I would look like such a failure.”

Two tracks

As we’ve touched upon before, there are typically two tracks in software engineering:

• Individual contributor (IC): Beginning with little experience producing software in industry, a person on the IC track progresses to become ever more senior at creating software. Their increasing experience allows them to become a key stakeholder in technical decisions, a continually better mentor, and to harness deep expertise in their domain.
• Management: Often after a bit of experience, an engineer makes the conscious choice to take ownership of a team, most often through being accountable for their performance via line management of their staff. Over time, a manager can increase their influence and impact on the business by growing their team, and by being promoted to manage other managers, and therefore run bigger organizations.

A stereotype has always existed that the move from being an IC to a manager is a progression upward, in the same way that it is a move upwards in the org chart. Does this mean that the move from management to IC is considered the reverse: a regression downward? Left undiscussed, I would posit that many feel this way. However: it really shouldn’t be. Both career tracks contain individuals contributing in vastly different ways, but each track cannot exist without the other.

You can’t have a visionary CEO without a CTO who can make that vision a reality. You can’t have an amazing middle manager who ensures all of the trains run on time without fantastic engineers that, given that space, thrive and build great things. Yin and yang. So if both tracks contain essential staff, why is there stigma about transferring to IC after being in management? I would argue that there shouldn’t be. We all contribute in different ways.

Often one doesn’t get to experience what management is like without actually doing it. This is why it is important for our organizations to be supportive of those who want to give it a go, and offer ways for them to switch out if it’s not right for them, or if they crave a change after some time.

New managers: a safety net

When promoting new managers, the process can be made smoother and less risky by offering them a safety net if it turns out that the role isn’t right for them. One way of doing this is by using a 30-60-90 day plan that is mutually agreed upon beforehand.

In the plan you’ll set out goals and milestones for the first 3 months. At 30, 60 and 90 days you will have a check-in where you review progress against these goals. At the end of the period a decision will be made as to whether they continue in their new managerial role or revert to their old role with no hard feelings. The decision to revert can come from both sides; you may not feel like they have performed well enough, but equally importantly, they may not feel that the change to the management track is right for them at this time.

An example of a 30-60-90 day plan could be as follows, written from the standpoint of the new manager’s own manager:

• 30 days: Begin 1 to 1s with the team and report back on how they are progressing. Identify areas that the team need to improve upon and, if necessary, begin implementing some change. Continue with the delivery of the current project and re-estimate if necessary. Have the first check-in meeting at 30 days.
• 60 days: Revisit the current product roadmap with the product owner. Suggest ways in which the team could deliver faster or in smaller, cheaper increments. Challenge any items you are uncertain or lack confidence about and discuss them with me. Highlight areas you will focus on in the team’s mid-year reviews. Deliver the current project on time. Have a second check-in meeting at 60 days.
• 90 days: Feedback to be gathered from the team on how you are doing. Have the final check-in meeting at 90 days. Both of us to mutually agree whether you should continue in the new role. If so, discuss our current view of the coming quarter and areas to focus on. If not, begin advertising for the role and begin your transition back to your previous role. Review the last 90 days and see what went well and what didn’t (for both of us).

Using a plan like this can provide a safety rail to initial exposure to managerial work, which can be more unstructured than a new manager may be used to. Additionally, the team can openly know that their new manager is also operating a 90-day trial, which empowers them to give their feedback and support during this period, rather than feeling that they are stuck with a new boss with little say in the matter.

There’s no shame in switching tracks

It’s all well and good having a way of allowing new managers to test the water, but how many people in your organization have gone from the managerial track to the IC track and have done so happily and openly? Technology moves exceptionally quickly, yet instead of observing from afar as a manager and being wracked with anxiety that the world is passing you by, why not find hope in the possibility of creating software again?

Smart engineers who become good managers can still be smart engineers in the future. It’s not shameful; it’s exciting. If you manage a manager, make sure that part of their ongoing career conversation contains the possibility of returning to the IC track. Doing so may help you retain that member of staff for a longer period if they know that there are many different routes that they can take within your company. If you are a manager yourself, remember that this always on the cards. With the increasing breadth of specialisms in technology, it could be a great chance to try something new: from JavaScript to Java, from API to data ingest, from UX to data science. We all have talents and interests which can ebb and flow with time, and riding the wave of interest makes for satisfying work.

But what should switching tracks mean for compensation? A long-tenured manager with a good compensation package should be open to reducing their pay, if deemed necessary, when switching to the IC track and knowingly being less impactful than they are in current role. But that’s a conversation that is different for each individual. Allowing a manager to change to IC and keep most (or all) of their compensation package can be a great gift to reward hard-working and long-tenured employees.

In summary

Allowing staff the option to freely move between the managerial track and IC track can create more career opportunity for those that you employ and therefore help retain them much longer, which is tough challenge in our industry. If you’re a manager, what would make you go back to being an IC again? What’s stopping you?