Generalist vs. Specialist engineer

I just had a short call with a friend of mine about whether QA should be doing so many different activities. I saw some organization that drops on QA laps quite a lot of activities that are out of their scope (as an example — some parts of release management, some system configuration, etc.)

I just had a short call with a friend of mine about whether QA should be doing so many different activities. I saw some organization that drops on QA laps quite a lot of activities that are out of their scope (as an example — some parts of release management, some system configuration, etc.)

And thinking about it, there has been a tendency to significantly increase the scope of ownership of both software engineers and QA engineers over the last decade. There were quite strict boundaries before between software development, testing, operations, release management, etc. And the boundaries are all blurred now.

First of all, the main reason for these boundaries being blurred is the Agile movement. It emphasizes cross-functionality teams (which can take on product ownership from the beginning to the end). And I totally agree that it’s (from a business perspective) a way more efficient way. Deciding on something within a team takes immensely less time than if you have to run around four different teams to agree on what needs to be done (and trying to squeeze it in their schedule).

That being said, it puts an additional burden (to have broader knowledge). For example, two decades ago, a QA person could have an engineering mind and knowledge of how to click buttons. Back then, this was enough for a junior QA (and often enough to do the job well). And now, you need to know programming, how to create efficient test plans, work with gazillion different tools, and so on. BTW. The same is valid for software engineers, who often need to understand how to develop, test, run, monitor, and so on.

I would recommend engineers to do three things:

• You need to have a good generalist background

I am sorry, the time when you can learn one thing and don’t worry about anything else has passed. Instead, you need constantly pick up new emerging technologies/trends.

You don’t need to predict things and catch them at the beginning of the hype cycle. However, it’s essential to learn something that has become widely popular (for example, if you don’t know how git works by now, it would raise my brow).

BTW. This is especially critical, taking into account that everything constantly changes. For example, I was once writing backend in ColdFusion. If I only did that, I would have painted myself in the corner by now.

• Be a specialist in at least one thing at a time.

It sounds opposite to the previous item. However, it’s not. Having general knowledge about a wide area of topics is helpful for you to dive into one specific area.

You want to know something well (way better than others). This opens a lot of doors for you. Of course, a good generalist is already valuable, but being a generalist with some specialization is a killer combo.

BTW. I just realized that the last two items are an expansion of It’s not that hard to be in the top 10% of your field article, which I wrote a couple of months ago.

The thing which I said there is “Be curious” and “Do what others won’t do” is equivalent to being a generalist, and “Go extra steps” is equivalent to being a specialist.

• Don’t do a shitty job.

As an area of responsibility grows, there is a tendency to make the smallest effort possible for secondary areas to get to the primary one. All of us have this feeling. Let’s just close this ticket to get it out of the way. It’s completely ok if this secondary area is not critical. The problems happen when you try to do a lousy job for something important.

To give you an example, somebody asks you to go and configure an (important) system. You have never seen it. You just go there, read half a page of documentation, and google three commands. Boom. You are done. Just to find out in half a day, that you didn’t do this well. So you come back, do googling, execute some random commands again which you don’t understand. Rinse and repeat.

Firstly, it’s essential to distinguish between critical things and just one-off tasks that need to be done.

However, if you stumble on something critical where your knowledge (and expected time frame) doesn’t match criticality, this is a perfect time to talk to a manager.

I would recommend coming to this conversation from a risk management and prioritization angle. Explain the risks of doing it fast (without good knowledge) and talk about things on your plate (how critical these tasks are in relation to others).

And the summary. Be a generalist with some specialization and talk to your manager if you see a mismatch between a task criticality and knowledge/timeframe. This will both let you handle much broader areas of responsibility. And also, it will bring you a pretty penny.