Leave your team for a year and build your career capital

For more content like this subscribe to the ShiftMag newsletter.

One sunny day, my manager came to me and said, “Marina, you have two options”:

1. Stay in your Home team and work on integrating the company we just bought with Infobip authorization systems.
2. Go and help another team refactor an application for deploying our microservices (let’s call the application DeployMaestro).

Choose safety or embrace the challenge?

It was a tough decision – the toughest I had to make in my professional life. The atmosphere in my team was cozy; everything was in its place. But then I tried to look at it from a professional angle.

One thing was clear: accepting the DeployMaestro refactor would expand my influence within the company. In a large company, solving other people’s problems becomes inevitable – it is best to embrace it. And since DeployMaestro had many issues, *I could learn what NOT to do in future applications we will build from scratch. * Amid IT industry layoffs, it’s crucial to aim for such growth.

I hesitated at first but chose to take on the challenge of refactoring DeployMaestro. Once we’ve refactored the 150,000 lines of code (you call that a microservice), I’ll return to my Home team.

Breaking stuff is the only way you learn

You probably heard Michael Hopf’s quote:

Hard times create strong men, strong men create good times, good times create weak men, and weak men create hard times.

Well, the times were hard, and I was about to become a strong woman. Refactoring an old application is a challenging task. You must understand the legacy code, rewrite it with better architecture while retaining all the functionalities, and still not break anything for other 750+ engineers in a company.

When you are buried with all these classes you see for the first time, you don’t know how they are connected. You have to untwist it and make it clean, easy to read, and easy to maintain – it’s a daunting task.

It was almost too complex to add or remove something without breaking something else. So, I took the matter into my own hands and started breaking stuff – it’s the only way you can learn what not to do in your applications.

A lot of classes were crisscrossed with warnings and errors in IntelliJ. I didn’t know much about the source code of that application, but I knew that it could be simpler. You should get your hands dirty to make something great. It was a steep learning curve that went on as long as the refactor itself because every task was related to some other part of the application. Finally, we got rid of that ridiculous frontend error: “Error: no error“. ** **

Increasing your career capital

The good stuff I got from this experience was well worth the refactoring pain.

I now have much more technical experience than I did before. Also, I now understand DeployMaestro in-depth; I learned from its owners, and I can troubleshoot issues with it on my own. I can teach my Home team about the architecture and the cool features and improvements we added – I can teach them how to be a power user of the application.

As DeployMaestro relies on microservices that my Home team maintains, I was able to explain in detail to my Adoptive team what these microservices can offer. Now, they are less dependent on my Home team and don’t need to ping us to troubleshoot our services each time they run into a problem. Or at least they know what information to provide us with so we can troubleshoot more efficiently.

Moreover, since I refactored the authentication and authorization code in DeployMaestro, I saw what the usage of our microservices looks like from a client perspective, so I could suggest changes to make them better. Also, since I was among those with the most domain knowledge in my Home team, my leaving eventually gave them autonomy in decisions and a chance to go up the role ladder faster.

The best thing about switching teams is that I had a chance to gain a deeper understanding of the architecture of my company and, therefore, feel more empowered to suggest further improvements in the architecture.

Basically, everything that I experienced is going towards increasing career capital. In his book “So Good They Can’t Ignore You”, Cal Newport writes about “ *career capital” * that you acquire over time in your career. The basic idea is that you should gain rare and valuable skills through deliberate practice, which should be hard.

If it is not hard , that means *it will not increase your career capital, * and you will slowly begin to stagnate. Career capital makes you a domain expert, and only then can you gain new opportunities, more flexibility, and autonomy in your career.

From the manager’s point of view

If you are a team lead or manager, you might wonder why you should mix teams at all since it introduces many complications. Why would you allow lateral movements if the teams are functioning properly?

Yes, ** efficiency will suffer somewhat at first** , but the long-term benefits are well worth it.

Imagine a seamless business environment where every employee can handle basic bug fixes, testing, and troubleshooting various applications independently, resulting in a Slack/Teams devoid of basic questions. That is what LeSS is aiming for. And my hypothesis is that lateral movements are the way to go.

It may also be beneficial to have someone impartial on the team. This lateral movement was great for my manager. H e had an outsider in the team who could objectively evaluate team members and give honest feedback which some team members found hard to do.

Team switching is not for everybody

Keep in mind that lateral movement is not for everybody *. * If you work in a small company, you might not even have somewhere to go.

Also, if you are not fully onboarded to your team’s applications, services, microservices, libraries, etc., moving laterally doesn’t make much sense because you still have so much to learn from your team.

But, if you meet the requirements, then it is time to choose your destination team. ** Here are three questions to ask yourself** (or your manager):

• Where can I bring value?
• What can bring me value?
• What can bring value to my team when I come back?

These questions should align for a win-win-win situation. If they don’t, either your company will suffer from reduced productivity while you gain knowledge, or you’ll gain nothing and be a code monkey while the company benefits from your efforts.

If you have come this far…

My advice to you is: Go! Go be proactive and ask your team lead or engineering manager about temporarily transferring you to another team. It will open many new possibilities, some of which you are not even aware of.

The post Leave your team for a year and build your career capital appeared first on ShiftMag.