In my previous post, I talked about why I think the technical interview process is totally broken. In this post, I want to talk about yet another broken process in software industry: how teams are assembled (or more like misassembled!) for a software project.
In a typical software company, a person is hired by a team to work on a particular project within that team. This makes total sense. However, after some time, things change. The actual time frame varies from place to place, it could be as soon as 1 month or something longer like 1 year or more. Either way, change is inevitable, the project either ends or completely changes or the team gets a completely new assignment. This is the point where it gets really weird. Now, the person who was hired to work on a particular project is asked to work on a completely new project. The hired person is basically stuck with the team he/she was hired into to work on a completely different project that he/she did not sign up for.
If the project and the team sound interesting, he/she can carry on and all is good. However, the problem arises when either the project is not interesting or does not align with the person’s goals or the team is not what the person hoped to be. At this point, the hired person has a few choices but none of them are good. He/she can try to get out of the project/team but that means he/she needs to find something else to do within the company. In big companies, there’s a lot bureaucracy around switching to a new group. You usually need to get your manager’s approval (which is quite awkward as it is) and then go through the process of making yourself accepted in the new group. It’s just not straightforward as it should be.
The other choice is to quit the company and join to some other company which is even a bigger deal with more interviews and process. Either way, you end up spending a lot of time not doing any real work. So, what usually happens is that, many people go on, accept their faith and continue working on uninteresting projects with uninspiring people because it’s easier for the time being. This naturally results in uninspired mediocre work and it goes on until either the company or the person realizes how ridiculous the whole situation is. The person either quits or gets fired.
I’ve seen this happen a few times to solid people and it is quite sad. It does not happen because person is incompetent but it rather happens because there is a misalignment between the person’s abilities and his/her place in the company. And there isn’t a good and open process to fix that alignment within the company. This is especially true in big companies.
I think the solution is not that difficult though. In big companies, there should not be strict hierarchies with solid lines between managers and developers. The weird notion that a single manager effectively owning a software engineer within a particular group should change. Instead, software engineers should be treated more like free agents. They should be assigned to projects for a period of time and when that time elapses, there should be an opportunity for an open discussion among the employee, manager and possibly someone from HR to figure out what makes sense as the next step. Software engineers should be presented with project choices within the company at that point in time and they should have the real option of staying in the current group with the current project or move to another project with little or no process. The company hierarchy should not dictate what people do and where. Rather, the business needs should dictate what the projects should be and then people should be able to gather around those projects freely, kind of like open source project model but within an organization.
Big companies will tell you that they already encourage people to move around within the company but in reality, this is far from true. First, the amount of process and bureaucracy involved is so high that many people do not even bother. Second, the culture at these companies does not encourage moving around. The very existence of a strict hierarchy dictates the boundaries that an engineer needs to adhere to and it is quite difficult to get out of those boundaries. Third, a software engineer is not presented with other choices once he/she is hired into a role and there is hardly ever an open communication about the employee’s next step. Employees end up sneaking around the company hierarchy to find the right alignment and it just should not be like that.
Open source software is so successful mainly due to people involved in those projects. Most of open source people put time and effort into those projects because they really care about them, not because of a random hierarchy. The same should happen in software companies as well. The company that figures out a way to let people gather around projects they care about voluntarily will create the winning innovative culture that is so lacking in big companies nowadays.