A few years ago, I took on the role of a security white hat in my previous job. It took 20% of my time, about one day per week. It was up to me to get organized. Sometimes working one full day per week on a security project made more sense, sometimes I would have rather spent those 8 hours spreading over several days. I prepared a simple spreadsheet to track my time so that I didn’t spend more time on one activity than was allocated.
Later, after a promotion, I had even more hats to wear. I had various tasks such as more mentoring, reviewing internal training materials, and reviewing internal coding standards… That spreadsheet became one of my most important productivity tools along with a simple timer.
I loved my job.
Better to say, my jobs. I didn’t have one job! I had a portfolio of them!
I learned the term “portfolio job” from Jeff Goins’s book called The Art of Work. Jeff Goins doesn’t only write books and articles, he also speaks at events, coaches aspiring writers, etc. He has a portfolio of responsibilities. He has several different projects, none is taking up his whole time, probably wouldn’t want to do only one of them all the time, but the combination is great.
It was great to be able to spend time on different projects. If I got stuck and needed some fresh air or I needed to wait for someone else, I could just easily switch to another project. The cost of context switching was cheap to me.
In my current job, when a few months ago I got the opportunity to divide myself between two projects I keenly took on it.
It didn’t work out very well.
By now, I have realized that a portfolio job has a very important limit that we cannot neglect. That limit is a combination of understanding and motivation.
After some reorgs, I found myself working in a team responsible for continuous integration. Something I find extremely important, but at the same time it’s something I don’t know that much about and sadly I don’t even want to. But hey, work must be done. Even if it’s not about C++. Even if it’s not directly about writing code.
At the same time, I was looking for an opportunity to get out of this situation and my manager helped me. So I got a part-time project to work on tidying up an internal (C++) API.
Does that sound great?
On paper, yes.
In the beginning, I was happy with it.
But while I managed to properly track and divide my time, I excelled in only one project and suffered in the other.
The reason?
Obviously, I cared more about one than the other.
Besides, I didn’t force myself to be deeply immersed in my main role. As it was a newly formed team group of individuals and a topic that I didn’t know well, it didn’t work out that well.
Before, when I had a portfolio job,
- I liked the central part of it
- the rest was still revolving around writing software and/or communication.
By now I think that a portfolio job can only work well if you’re confident and interested in your core role. Probably it’s not a problem if some of your tasks are related to different domains such as development and operations. Probably you need some knowledge of both. Probably it’s not a problem if you have no knowledge, but you have strong motivation to learn that domain. But don’t expect a portfolio job to work out properly for you if you have to spend a big chunk of your time on something you don’t know and you don’t care about.
I’m not saying that you must love all your tasks, but I do think that out of the three requirements of business need, skills and interest, at least two should be met. If only one is fulfilled, it’s not going to work out well.
By the time I published this article, I got into a role that I like and where I contribute to the success of my team as much as I expect from myself. A big thanks to my management who helped me through this situation.
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
