Non-coding roles or something you like?

This is an excerpt from by book called The Seniority Trap. I'm sharing some parts from each chapter. Check out the #thesenioritytrap for more parts.

Have you ever heard about the Peter Principle?

It states that if you perform well in your job, you will likely be promoted to the next level of your organization's hierarchy. You will continue to climb the ladder until you reach the point where you can no longer perform well.

This means that if you're a good developer you'll likely be offered a non-coding role sooner or later.

What should you do if that happens?

Should you accept it or not?

As we discussed in the previous chapter, it's important that you take your career into your hand. You should understand that the driver of your career is not your manager, but you. It's your responsibility where you end up.

Your manager can express her wish on which project you should work on. It's probably already set into stone which language or framework you will have to use. Still, it's your responsibility to accept that assignment or say no. Maybe you will even have to look for another job if you cannot turn the proposition down.

It's your responsibility that you don't get trapped in a situation that you don't like. You don't get trapped into a senior developer position where your daily activities consist of things that don't motivate, don't satisfy you.

But what if you were officially offered a non-coding role for a better salary?

It could be a dev manager position or it might even be the position of an architect!

Being an architect can be a real honour and you might be tempted to accept it. You might not understand in the beginning its implications, you might not realize that it can easily be a non-coding role. (I don't state that the role of an architect is never hands-on, but it's often the case.)

Exactly that happened to my mentor and good friend, Matthew. He always enjoyed teaching people, he enjoyed looking at the bigger picture and to give recommendations on how systems should be built. Besides, he was one of the most capable coder wranglers in each of his teams.

He didn't only enjoy these activities, but he had a good knowledge of how to create the blueprint of big distributed systems or on how to design an API.

Soon, he found himself not just being a senior developer, but being on the official architect track in the tech giant we were working for.

His enthusiasm started to fade soon.

Even as a senior developer he was somewhat trapped and found it difficult to find time for coding, but as an architect, he lost even that small time that was left for him.

He wrote mostly documentations. Documentations of existing undocumented systems, documentations of non-existing new systems, and guess what, he was also documenting his new role. He was documenting what an architect should do, what his accountabilities should be. We could even say he wrote meta-documentation.

He got fed up.

Even though this new role was the key to advancing on the non-managerial ladder both in ranks and salary, after pondering over it for a few weeks, he decided to look for another position. He took on a developer position so that he could stay in touch with real code...

Money is important and I already expressed how much I despise when management acts like it's not one of the most important motivating factors. Yet, according to studies, after you reached a certain salary, money will not make you happier.

In other words, it's not worth chasing just money, once you have a fair salary. You have to consider other aspects of your job as well.

Just because in a certain position you'll earn more money, you shouldn't take it. The extra money will make you happier only for a short period of time. But the daily crap you have to deal with will stay with you for every day you have to work.

You'll not be able to write the amount of code you want to - or maybe you won't write code at all. Not a single day. You'll only write studies and documentation. Every. Single. Damn. Day.

Keep in mind that most probably, you'll continue working for long decades. You have to stand your job. It's very difficult to lead a happy life if you don't like what you do 8 - or more - hours a day.

You'd better take a job you like.

Create your own portfolio job

In the next section, I'm going to explain a job structure I learned about from the author Jeff Goins. Something that I love, I follow, and there is a fair chance that it would work for you too. Let's explore the concept of portfolio jobs.

What is a portfolio job?

Matthew went back to becoming a developer. While it is true that due to his seniority he still didn't write so much code, but at least he was right there where the action happened. He started to give advice to developers and eventually to write important fixes.

He is happy with his job.

He has a portfolio of responsibilities. It's similar to what Jeff Goins presented in his book, The Art of Work. Jeff doesn't only write books and articles, he also speaks at events, coaches aspiring writers, etc.

Matthew has been following a similar path in IT.

He doesn't only write code, but creates systems designs, plans activities, coaches less experienced engineers and sometimes writes documentation.

Writing documentation is not bad, it's just something he would not like to do all the time.

He found it easier to enrich a lower-level job than making a higher level more versatile. Having such a portfolio was more important to him than a bit more money.

How to create a portfolio

I'm going to share my personal story of creating a portfolio job while I obviously kept only one at a corporation. One job, one team, one paycheck. The road will be different for you, but probably you can pick up the main ideas and implement them.

In the beginning, I was only performing my core tasks. I think it will be the same for most of the junior developers and it's good like that. I needed quite some time to learn the basics of software development, I needed more time to focus on the core activities and improve the quality of my deliverables.

Once that quality was in place, I became an advocate for software craftsmanship and I started organizing coding dojos. There I didn't only improve my technical skills but also my soft skills. I lost quite a bit of shyness and speaking spontaneously became easier for me. These improvements were something acknowledged by my manager.

Still, I did spend most of my time on my core activities, honing my coding skills.

When I joined my next team, I started to act very independently. With a couple of years of experience in the bag, I had a lot of ideas on how to improve the application, the coding practices, the processes.

While these were not the core activities expected from me, I really wanted to change the way things were going. I simply took the liberty to write processes, present them, and to facilitate knowledge sharing sessions.

Later, I was offered the side role of being a white hat and I started to coordinate security-related activities in the department which took about a day per week. It was definitely not something I would have been keen to do in 100 per cent of my time, but I started to enjoy the different kinds of activities I was asked to do. It also gave me more liberty to find more time for transversal activities and I could help the department with more tools, more coaching.

Thanks to my blog, I also started to become better in writing, better in my basic C++ skills and I built up a more and more important written knowledge base. Articles, that I could refer to in code reviews, or when I was asked about something. Now obviously it would have been very snobbish to just post my articles in code reviews or send them as answers when asked about a concept, but after giving the main idea it was perfectly fine to say that for more details, please refer to this and that article.

Soon, I started to organize more knowledge sharing sessions and I became a coach and helped with company-wide C++ related initiatives like reorganizing some trainings or revamping our hiring questionnaire.

I found that no more than half of my time (sometimes significantly less) was spent on software development actually.

As long as I could keep C++ backend development as part of my portfolio, I was happy and whenever management wanted to move me out of that core task in the name of versatility (a.k.a being an expert beginner) I fought hard and reminded them about my portfolio job and versatility.

A portfolio job lets you not get bored in one position even for a long time and also to improve yourself in different dimensions.

What about the money?

You might argue that the extra money you'd get if you became an architect or a manager would end up quite a considerable sum over the course of a few years, or decades.

That's true. Yet, you must not forget that it's not guaranteed that you would be able to keep a position that you despise.

There is actually a fair chance that you will get more and more frustrated, you'll not be able to deliver such a performance that you and your managers are used to and your bonus will go down over the course of the years. There is also a fair chance that you will grow frustrated and eventually burn out. Or maybe you won't wait for it, you just quit and go to some Caribbean islands selling mojitos or renting surf decks. Who of us hasn't dreamed about it yet?

All that just for and just because of some extra bucks.

It's not worth it unless you have a special condition that makes that extra money vital for you. You might have a plan to pursue the managerial ladder until you can get out of it and go back to something that you like. Even in such a situation probably you'd be better of working on what you like and doing some freelancing besides your full-time job.

I also know some people who went for the managerial ranks to get some soft skills, to get exposed to project management to build a network, only to come back into a principal engineer or architect position. That can be a plan. But we have to see that they didn't take on the managerial job because of the extra money it paid.

Are you interested? Check out The Seniority Trap on Leanpub!

Connect deeper

If you resonated with this chapter, if you want to get udpates, please subscribe to my personal blog and let's connect on Twitter!