Management bugs

Leave a comment
Growth

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?

There’s no shame in going back

comments 4
Growth

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?

Coaching

Leave a comment
Growth

A universal tool

When you become a manager, you may find yourself wondering how you can have a tangible impact on the performance of all of your staff. After all, they are at different levels of experience and have very different skills.

For staff that you share a similar skill set with, such as JavaScript development, you may still be able to offer mentorship for technical problems. But what about for those that you don’t have a common skills background with, such as UX or Data Science? You will also potentially find yourself managing staff who are older and have much more experience than you. How can you get the best out of them when you might not have any direct advice to offer?

A relationship with your staff based purely on directive interactions (e.g. “Do this in this way”, “Have you done that?”, “When will that be done?”) quickly becomes shallow. That should only be part of the relationship, and with time, should become an increasingly smaller part of it. Your top performers probably don’t need this kind of input at all; they’ll have a keen sense of what’s important and will just get on with it.

The skill that can help you increase the performance of your staff and open up a number of other opportunities for you is coaching, and it’s actually a lot easier than you think. We’ll take a look at some techniques in this article.

Coaching

So what is coaching? At an abstract level, it’s a technique for helping your staff improve their performance. But that sentence is so lofty it almost means nothing. My own take on coaching is that it is a framework for interactions with your colleagues that makes them more likely to have tangible positive effects on their work.

I learned about the techniques from Effective Modern Coaching, which I’d recommend if you’d like to explore the details. There are three main concepts that really stuck with me when reading it, and these are the tips that I would like to share here.

Before we dive in, let’s get this clear: coaching doesn’t require special planning, skills, performance, or, well, anything really. It’s just a bunch of tools that you can use when having a conversation with someone. You can use these tools in formal settings such as your 1 to 1s with your staff, or you could use them while having a chat about work in the kitchen. Equally, they can be used whilst in conversation with one person, or they can be used to steer a group discussion. If you try them out, you’ll be surprised at how useful they are.

Mode

So if coaching is effectively just having a structured conversation, how should you be talking to the person being coached? You’ll need to work out which mode you’re going to be in at different parts of the conversation. There are two mutually exclusive modes:

  • Directive: This is where you’re instructing someone on what they should do. This is considered to be a “push” action, i.e. you are solving their problem for them.
  • Following interest: Here you’re predominantly listening to understand, reflecting on what they are saying and summarizing. This is a “pull” action, i.e. you are helping them solve their own problems.

In-between these modes are questions, suggestions, and summaries that you can give to steer the conversation.

  • “What’s the difficulty with doing it in that way?”
  • “Why did you pick that method?”
  • “What’s up with Bill this week?”
  • “Why’s that?”
  • “Tell me more about that API.”
  • “Walk me through your thought process.”
  • “Can you draw me a diagram on the whiteboard?”
  • “So what you’re saying is…”
  • “So am I right in thinking that…”

As the conversation progresses, you’ll work out whether you need to be directive or continue to follow their interest until they work it out on their own. You may find that less experienced staff require you to be more directive than their more experienced colleagues. This is normal. With time, as your staff become more experienced, you will find yourself following their interests much more than you will find yourself directing them. The positive side-effect of this is that as you become more experienced yourself as a coach, you realize that you can help anyone out with pretty much any problem, as you’ll be mostly listening!

At each point of the conversation, be conscious as to whether they are honing in on the answer, and keep listening and suggesting until they do. If you think they’ll never get there, be more directive.

Keep the thought bubble over their head

Unless being explicitly directive, in order to help your staff develop their skills, both in technical and abstract problem solving, it’s to keep the thought bubble over their head. Here’s a little example.

You: “So how’s progress been this week?”
Them: “Not great. The backend is much harder than we expected, and we’re not sure how to approach it.”

Even if you are the world’s most expert engineer, don’t tell them what to do, especially if you know what the solution is. Instead, every time that you feel that you would naturally jump in and solve a problem, imagine yourself pushing a big cartoon thought bubble away from your own head and putting it over theirs.

You: “OK, so what’s hard about it?”
Them: “We were going to store it in MySQL, but there’s way too much data and it’ll be slow when we access it.”

Now, at this point, you may know exactly how to solve this problem. But you shouldn’t. Push the thought bubble back to them.

You: “Interesting. Have we solved any storage problems like this before?”
Them: “Hmm. When Alice’s team were storing alerts a few years ago, I remember they couldn’t use a relational database either.”
You: “That project was quite successful. Do you know what they used?”
Them: “I don’t. But I’m going to go and grab her for a chat after this meeting and find out.”

Note that all you did was ask some fairly open, leading questions. Not only does this solve the problem for them, it coaches an approach to thinking about problems that your staff can reuse in the future. Additionally, it encourages thinking through problems in the open, together, collaboratively.

Now, if they were totally stuck, you could be more directive, but in a way that still lets them figure it out on their own. Let’s replay that last exchange. Rewind…

You: “Interesting. Have we solved any storage problems like this before?”
Them: “I don’t know. I’m stuck.”
You: “I’ve got a feeling that Alice’s team did something similar. I think you should have a chat with her.”
Them: “OK. I’ll try and find her after this.”

The GROW model

For more structured coaching sessions, i.e. those centred around solving a specific problem, it can be useful to frame the exchange in a sequence of stages to ensure that it stays on course. This is called the GROW model, and the letters stand for the following. For a given topic or problem, you’ll want to iterate through:

  • Goal: What’s the goal of this session? What problem are we trying to solve?
  • Reality: What’s the situation like now? Who, what, where, and how much?
  • Options: What are all of the different ways in which we can tackle this issue?
  • Wrap-up: Become clear on a choice, commit to it, and discuss what support is needed.

This might seem exceedingly obvious, but it helps keep conversations from deviating. Let’s think about the above example using this model.

  • Goal: We need to work out how to store the data in some way that’s fast enough to support our use case.
  • Reality: We know a lot about relational databases, but they won’t be fast enough for this problem. We have a hard deadline and we need to get some support.
  • Options: We could get an external consultant, but that’s very expensive and they might not be available immediately. We could try out some different databases ourselves, but we are not expert enough to make an informed decision about what to use in production. We could see whether anyone else in the company has had to solve a similar problem and seek their advice.
  • Wrap-up: We’ve decided to seek advice from Alice’s team because they may have implemented a similar solution in the past. We are meeting with her later, and we’ll loop back with a decision on how we’re going to proceed. Then we’ll make a call on what to do.

Honestly, this seems so obvious when it’s written down. Yet, it works every time and prevents conversation from deviating, which is a regular occurrence when exploring technical matters.

Giving coaching elsewhere in the business

Directing your conversations using a coaching framework will greatly improve the quality of your interactions with your own staff. You’ll notice that with time you’ll get better at doing it, and similar to driving a car or riding a bike, you’ll just do it naturally.

If you get really good at it, you’ll notice that you can pretty much talk about any problem with anyone, and assist them in thinking it through. This can open up an opportunity for you to increase your influence in your department and company: you can coach others that don’t report to you. If you have demonstrated to your peers and your manager that you are a good coach, why not ask if there is anyone that they would recommend starting a regular coaching session with you?

Being a neutral third-party in the coaching relationship, rather than someone’s line manager, means that you can form a close connection with the person that you coach, without the worry that you ultimately need to judge their performance. It also allows you to have a positive impact on other parts of the business without feeling that you are meddling in their affairs. Instead, you are enabling others to solve problems for themselves by working them through with you. It’s very rewarding.

Receiving coaching

The higher up in the org chart that you go, the tricker it may be to receive the coaching support that you need. Your line manager may already be very busy, frequently traveling or based in a different country. Additionally, if you are quite senior and managerial, you may be wanting help working through problems that could be too sensitive to share with your peers or your direct reports.

It may be beneficial to ask whether the company could set you up with an external coach, who you can meet with regularly in order to unpick the knots around issues in your brain using the same techniques that we’ve described in this article. Prices vary and can potentially be quite expensive, but there is the possibility that the executive team may have connections that could offer some coaching services for free or at heavily discounted prices.

In summary

Coaching is a framework that you can use to have much more impactful and rewarding conversations with others in your organizations. Some simple techniques can dramatically improve interactions and make them more focussed, useful and impactful.

If you’d like to dive more deeply into tools and techniques then I would recommend Effective Modern Coaching as a good place to start.