Historically, companies have followed quite a strict chain of command. This style comes from different management schools, such as Taylor’s, that wanted the operator to be as supervised as possible, so as to get their maximum performance level. With time, since certain tasks were highly mechanical, that structured working methodology proved very useful in certain production areas, such as factories or, later, fast food chains (I’m sure you’re already thinking about the famous golden arches).
I’m going to skip several important events to arrive to this day and age: times have changed and they’re much more dynamic. A great number of tasks these days are less mechanical, and require more creativity. Among these tasks, we can obviously find design and programming. Even though the latter has a reputation for being structured, the truth is that you need to be highly creative and connect different types of knowledge to make something work, follow standards and good practices, perform correctly and be safe, maintainable, reusable and scalable. This is why the Agile methodology was introduced in the programming department; this methodology seeks to break the paradigm of the boss that works as the head of the area and the operators, which would be his “hands”.
The Agile Methodology
The Agile paradigm starts from the premise that work teams must be self-directed: there is no such thing as the “supervising boss”; instead, the team manages itself. After all, ten heads are better than one. Apart from that, Agile brings about another key change: we no longer use job position labels that could resemble an assembly line (“Programmer”, “Functional Analyst”, “Tester”, “Security”, “Layout Designer”, “Implementation”, “SysAdmin”, “DBA”, and so on), but only three key figures, which are “Team Developer”, “Scrum Master” and “Product Owner”. If we analyze the labels used in traditional methodologies, we can easily see that everyone had a specific task that they couldn’t deviate from: someone’s job began where another one’s finished. In contrast, in Agile, nowadays it’s very common for the developer team to assume full responsibility for all the previously mentioned roles. How did we go about this change? The answer is a concept known as “T-Shape”.
“T-Shape” was a concept invented in 2009 by Tim Brown. It’s widely used in Agile and it depicts the idea that every team member should be able to take on different tasks, as well as specialize in one particular area. Take a look at the “T”: the vertical beam makes reference to the area in which every team member professionalizes, the one in which they are experts. The “roof” of the “T” would be the knowledge of other areas that they can use to cooperate with them.
In the developer team, all members must be able to carry out all the tasks. Nowadays, the “software engineer” or “developer” has more responsibility than ever: they must know how to program, test, layout, organize the work, assess other team members’ work, give feedback, deploy, talk to the client in order to understand their needs, document, and understand the business’ domain. The current dev team member is no longer an operator, but a person with different roles and who requires infinite soft and hard skills. Hence the reason why, in many companies, a programmer may earn more money that a director in other companies, or even more than their own boss. This is also why there is such a high demand for people to take that position, but so little offer to satisfy it. Because it’s difficult to hire people that might know it all or might be willing to learn. Not only is it a complicated task to find this type of profile, but also, once in place, it is difficult to motivate these people to keep on improving their skills or updating them.
There are two ways to look at this scenario: we can either see it as negative, or as an opportunity to take advantage of, if we take into account that we can go further than ever before and that it only takes the will to be self-taught, Internet access and a desire to constantly learn.