Transitioning from being a manager to an individual contributor
Nine months ago, I was presented with a choice. My job responsibilities had grown beyond the ability of one person to manage the role. Even though I thought I was OK, my management was concerned about me burning out. The first question they asked me was, would I be interested in splitting my job into two pieces? A choice followed that question:
Behind the door, number 1 was the choice of keeping the management part of my accessibility job.
Door number 2 consisted of an individual contributor role focused on accessibility strategy, outreach, and innovation with no managerial responsibilities.
Which piece of the job did I want to fill going forward?
So the answer was yes, and I decided to go with the IC innovation and outreach role, which was announced in August— though I had been telling people it was coming for weeks. Here are some interesting challenges I’ve personally experienced during this transition and how I’ve overcome them. Sometimes, overcoming the issues requires help from the person who took on my former role's managerial side. I decided to write an article about it after finding little guidance online to make this career change since I know others have undertaken a similar shift.
While these examples pertain to my accessibility career, the points are generic enough that they apply to the transition from a managerial role to an architect/individual contributor role in any field.
You have to learn how to let go of your baby.
Giving up a program that you built or have run for a long time is similar to sending your child out of state for college, which, ironically, I was also doing at the same time as this work transition. Building any program from scratch is a little bit like having a child.
You nurture your program.
You protect your program.
You fight for your program.
You don’t want anything bad to happen to your program.
But children turn into young adults, and you have to let go of them. If you choose to move from a management role to an individual contributor role in the same group, you have to do something similar. Someone ELSE is managing your program now, and you have to get used to it.
It helps if, for starters, you stop thinking of it as “your” program. It is a program that you now contribute to; you no longer run it. Also, you should unsubscribe to all the email lists, slack channels, and meetings that are for “managers only.” Disconnecting from your previous status forces your brain to re-orient to the new role. I didn’t do that soon enough, and once I did, it helped me see the line more clearly between “what I used to do” and “what I do now.”
You must redirect people to the new manager when appropriate — even when you know the answer
VMware is an enormous company, and it usually takes a while (sometimes up to 9–12 months) for word about personnel changes to get around, especially outside my home “business unit” (VMware-ese for division). People who are unaware of the transition continued to come to me for status, help, and advice because mine was the name they have heard in the past. Even if you know the answer to the query facing you after you transition to an IC role, the correct actions are:
Reply to the email introducing the new manager (you will need to do this as a forward if there are attachments to make sure those attachments go with the email), and;
CC the new manager
This approach is the only way:
the new manager will be able to build the collaborative relationships that are at the core of any good program, and;
the original sender will break the habit of reaching out to you for updates on areas that the new manager now controls.
Failure to do this sends the message that you don’t trust the new manager. That is not a positive way to start your relationship with them.
You must coordinate projects that require input from both people.
Sometimes my work has implications for the manager who has taken over my past role. One example (of many) includes a strategic initiative I’ve started on the consistency of our Skip to Main links (aka “Bypass Blocks”) across products — I’m defining the strategy and making sure the information is absorbed and acted on by the product teams. The new manager provides me with input, and then his team is responsible for testing the agreed-to standard.
It’s helpful to have a project tracker (like Trello) and RACI diagrams for projects that overlap like these. Then, everyone knows who is doing what and what their role is.
You must coordinate on subjects where you may disagree and decide on a single approach.
The WCAG guidelines are not prescriptive. For example, they require “a mechanism” to stop motion. That mechanism could be a toggle, a slide bar, or a pause button. There are plenty of accessibility areas where decisions must be made where you and the manager who took over from you may disagree. It doesn’t set a good example for the team if the manager goes out into new territory, you disagree with them, and they end up changing their mind. Coordinating these types of decisions regardless of who is initiating the decision is important to the program's continued smooth operation.
Meet frequently!
Note that the headlines for the last two items included the word “coordinate”? The best way to do the necessary coordination is to meet frequently. The manager and I have weekly 30-minute “connect” meetings early Monday to discuss anything we feel might impact the other person and many daily Slack conversations. I expect these coordination meetings to drop off over time, but they are important to keep things going smoothly for now.
Consider filling in your need to help people grow by expanding your mentoring circle.
The hardest part of giving up managerial responsibilities was no longer being partially responsible for giving people growth opportunities. Once you reach a more senior level in any field, mentoring someone either formally or informally is one of the best things you can do. This is especially true in accessibility, where people with disabilities may have been discriminated against in educational and occupational opportunities, directly impacting their growth. If you have spent years managing people, helping people grow outside of your organization when you don’t have any management responsibilities may satisfy that need.
I’ve also taken on a reverse mentoring role where I will have regular meetings with a VMware executive to discuss things like what it’s like to be a person with a visible disability in tech. I will write about that relationship in a future article.
The one thing I most feared in choosing a managerial vs. contributor role is “What if I hate it and want to go back?” It worried me enough that I waited several weeks and talked to many people I respect who know me well before I made the decision. For the record, I love my new role and have no second thoughts about the decision I made. I now have more time to spend on important, long-term projects like helping establish future accessibility standards. In turn, this work will benefit the individual who has taken over the managerial, testing, and remediation side of my former role and will benefit our mutual employer.
Individual contributor accessibility roles that do not involve testing are fairly rare. Most accessibility activity focus typically on compliance and remediation.
ICs are almost always testers.
Managers are usually a lead of testers, a manager of testers, or a manager/director of the entire program.
I am very fortunate that VMware’s accessibility program has matured to the point that our management sees value in my work as an individual contributor in a non-testing role.