Recently, I had an opportunity to meet many test engineers from a large IT services company. These were 0-5 years experienced engineers. Here are a few comments I heard multiple times:
“I am in performance testing and I don’t know about manual testing”
“I only write automation scripts (execution and reporting is done by other roles) so I don’t know about how the system performed in final results”
I was at loss for words at times. I know that IT services companies need to drive down their costs (since they find it too hard to move up the value chain of IT projects) and slicing job roles is one way of doing this. But it was first time for me to talk to people who worked in such fine slices of roles.
Writing scripts, but not knowing about how the system performed? Calling yourself tester and not knowing manual testing? What kind of workforce are we creating? Where is the well-rounded test engineer who is supposed to be the customer advocate in the engineering team? Where is the omniscient test engineer who is supposed to be the go-to person even for the dev team regarding all the functionality of the system?
To be clear, this is not only test team within an engineering team. Similar role slicing is happening within development, project management and other teams. This reduces cost in the same way assembly lines reduced cost of production in manufacturing sector – put all the intelligence in the line (process design) and reduce the dependency on the quality of personnel (or as Henry Ford is alleged to have said “Why is it every time I ask for a pair of hands, they come with a brain attached?”). Resources become eminently replaceable, don’t require training, and hence wages can be reduced.
I pity those who get slotted in these slices of roles and think they are making a career by sticking to a well-known company. They don’t realize that they have stopped learning, that too so early in their career. At least in 0-5 years of a career, the goal must be to try out as many career opportunities as you can, learning a lot on the way, before taking a role which puts you in a silo (read climbing the wrong hill for a great analogy from computer science).
I also pity the companies – it is very hard to take this bunch of employees and develop them into next set of leaders and managers. While I am sure many companies are trying to give their employees enough knowledge through training, interactions etc., there is really no substitute to on-the-job learning. While this approach to software delivery is laudable from cost cutting perspective, it can’t build long term success.
If you are in one of these roles, reflect on your career path carefully: you may be hurting your career growth much more than you think. If you are not sure, ask yourself 3 questions:
- Have I learned new skills (other than maybe new domain because of new project) over last 3-6 months?
- Do I understand a lot about various aspects of the software I am working on?
- Do I know enough about the work being done by those who depend on my work, as well as whose work I depend on?
Career Bloom 