Suppose that there is work to be done always.
Some developers are continuously working to get those things done. There are some developers who get some of those things done, and then spend some time learning - new stuff or old stuff.
There is no clear demarcation about when to do each of them - working & learning. From what I know, most companies, if not all, expect people to learn on their own time. Below I am going to try to explain why this is ultimately not beneficial to a company.
When there is always work to be done, it falls on the judgement of each developer to take the call on when to do work and when to learn.
Like everything, when something is left to the judgment of each individual, you will find that different individuals take vastly different decisions (as to when to work and when to learn).
Sometimes, the decision is taken out of their hands too. This happens when there is a lot of work always, which is mostly the case with software companies.
The logical conclusion to the above line of thinking would be - if left to their own judgement, in an environment where there is always work of some kind or the other to be done, developers will tend to just keep working all the time and will tend to postpone learning, waiting for the time when the workload would become less, which almost never happens.
Can we attribute fault to the people who do the above?
In a corporate world, the answer would be Yes.
In the engineering world, where a team is working for years together on building/maintaining one single product, I feel the answer is more complicated.
Irrespective of who is to blame, in a product-company, it is in the best-interests of the company to not allow the above to happen (as I will describe below).
If developers work in a company in the above fashion, then after a few years, the following will happen:
Note: Above, I have not mentioned the monetary aspect, which I do think, plays a huge role in a person's decision whether to stay or move. But I think as developers tend to become more senior (in experience and age), their salaries tend to stabilize, people start to have a family of their own, and the family's needs get tied to a location and a routine, and hence this factor almost ceases to have any impact many times.
Some developers are continuously working to get those things done. There are some developers who get some of those things done, and then spend some time learning - new stuff or old stuff.
There is no clear demarcation about when to do each of them - working & learning. From what I know, most companies, if not all, expect people to learn on their own time. Below I am going to try to explain why this is ultimately not beneficial to a company.
When there is always work to be done, it falls on the judgement of each developer to take the call on when to do work and when to learn.
Like everything, when something is left to the judgment of each individual, you will find that different individuals take vastly different decisions (as to when to work and when to learn).
Sometimes, the decision is taken out of their hands too. This happens when there is a lot of work always, which is mostly the case with software companies.
The logical conclusion to the above line of thinking would be - if left to their own judgement, in an environment where there is always work of some kind or the other to be done, developers will tend to just keep working all the time and will tend to postpone learning, waiting for the time when the workload would become less, which almost never happens.
Can we attribute fault to the people who do the above?
In a corporate world, the answer would be Yes.
In the engineering world, where a team is working for years together on building/maintaining one single product, I feel the answer is more complicated.
Irrespective of who is to blame, in a product-company, it is in the best-interests of the company to not allow the above to happen (as I will describe below).
If developers work in a company in the above fashion, then after a few years, the following will happen:
- developers get bored with the work i.e. motivation starts to decrease
- developers start to feel insecure if the skills that they are using daily are not what are in demand anymore (outside the company), and new skills are being sought after in the market
- the software industry is an extremely fast-changing industry and today's-in-demand-skills go out-of-demand in a few years time
- there is increased pressure to be successful in the current company due to the above insecurity; and this increased pressure tends to manifest itself in negative ways - people losing their cool with each other over minor things, office-politics, etc.
I think above are the reasons why most developers don't stay at any given company for more than a few years.
When people leave, they take with them a wealth of knowledge - informal training received over word-of-mouth, experience specific to company's problems, history of decisions made to get the product to where it is, etc, and not to mention, cause a loss in morale of the remaining team-members.
So what if people leave? Can't we hire new ones?
In the corporate world, I have heard this statement multiple times - "no one...no one is irreplaceable". That is how it is structured.
However in the engineering world, I feel there are 2 categories:
- A few brilliant Lead engineers form the backbone of the entire company. Such people are considered irreplaceable and that is straight-forward logic.
- the Rest
What about 'the Rest' ? Are they replaceable or not?
In my opinion, the ideal team is a set of brilliant Lead engineers who are supported by an ever-improving team of senior/mid-level/junior engineers. If there is churn within the team of senior/mid-level/junior engineers, the Lead engineers will have to take the time to train the new hires, and you can tell that if it happens a lot, it is not good.
In the above sense, every team-member is important.
So my opinion is - a small product-company, should not have its hiring/retaining policy built similar to a corporate-company. People do leave due to one reason or another, but the core policy should be to try super-hard to retain everyone it hires and trains.
Super-hard? How?
As outlined in a different post (http://psjp-learn.blogspot.in/2017/06/building-machine-that-makes-machine.html), I think, unless a company considers that continuous-training of each developer is an integral part of its philosophy (and somehow incorporates continuous-training in its software-engineering-process), the above negative phenomenon cannot be stopped.
When people leave, they take with them a wealth of knowledge - informal training received over word-of-mouth, experience specific to company's problems, history of decisions made to get the product to where it is, etc, and not to mention, cause a loss in morale of the remaining team-members.
So what if people leave? Can't we hire new ones?
In the corporate world, I have heard this statement multiple times - "no one...no one is irreplaceable". That is how it is structured.
However in the engineering world, I feel there are 2 categories:
- A few brilliant Lead engineers form the backbone of the entire company. Such people are considered irreplaceable and that is straight-forward logic.
- the Rest
What about 'the Rest' ? Are they replaceable or not?
In my opinion, the ideal team is a set of brilliant Lead engineers who are supported by an ever-improving team of senior/mid-level/junior engineers. If there is churn within the team of senior/mid-level/junior engineers, the Lead engineers will have to take the time to train the new hires, and you can tell that if it happens a lot, it is not good.
In the above sense, every team-member is important.
So my opinion is - a small product-company, should not have its hiring/retaining policy built similar to a corporate-company. People do leave due to one reason or another, but the core policy should be to try super-hard to retain everyone it hires and trains.
Super-hard? How?
As outlined in a different post (http://psjp-learn.blogspot.in/2017/06/building-machine-that-makes-machine.html), I think, unless a company considers that continuous-training of each developer is an integral part of its philosophy (and somehow incorporates continuous-training in its software-engineering-process), the above negative phenomenon cannot be stopped.
Note: Above, I have not mentioned the monetary aspect, which I do think, plays a huge role in a person's decision whether to stay or move. But I think as developers tend to become more senior (in experience and age), their salaries tend to stabilize, people start to have a family of their own, and the family's needs get tied to a location and a routine, and hence this factor almost ceases to have any impact many times.
No comments:
Post a Comment