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.

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.

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.

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?