Table of Contents
In this article, Alexey Minkevich, a member of the SoftTeco’s board of directors, shares his thoughts on the direction in which modern software engineering is evolving and how tech specialists should develop their skills and knowledge to keep up with the accelerating industry requirements.
What is the main issue with modern software development approaches?
From the early days of Kanban methodology arriving at software development, there has been an issue with the Work In Progress limit. Ideally, you are supposed to limit the number of tasks on every step of the process. This approach is meant to help you avoid working on too many tasks at the same time and losing time on switching between the tasks. And if your column is full, other team members should come and help you fight the bottleneck. As an example: if the quality assurance engineers are overbooked with the tasks, developers should come and help them solve the issue. 10 years ago I could imagine how developers can help QA engineers. But what if the development team is overbooked by tasks? Should QA engineers come and help to write the code? Less likely.
The problem is getting bigger when we plan what to do. No matter what methodology is used (Scrum, Kanban or classic), every business wants high priority tasks to get to development first. Say, your server engineers are busy for the next 2 months. Most often, business owners decide to take only mobile/web stories into the sprint in this case. So we are not doing what is needed, but what we can. These dependencies negatively impact the overall working atmosphere and result in loss of trust between the business and R&D.
You can eliminate the issue by using one of several approaches available. Let’s take a closer look.
Functional teams
A functional team means you have a team of individuals with similar skills and expertise. In this way, you set up separate server, mobile, and web teams and manage the workload by the number of people in these teams. This option is very good for the professional growth of engineers and is more or less easy to scale till a certain point.
But dependency management can be a nightmare that you need to invest too much time in. And from a business point of view, it’s not great either: people care less about the overall impact and outcome, and focus on their part of the job only. So it becomes hard to find who is responsible for the feature and explain changing priorities to the teams.
Cross-functional team
In this case, you as a business owner try to build a team with the right balance of skills, aka hiring server, web, mobile and QA engineers, each with their own specific skills and knowledge. But it might be hard to find this balance, as the team scope is unpredictable (i.e., it’s hard to predict whom exactly you will need and how much). And when someone falls ill or goes on a vacation, the balance in the team is ruined.
A huge advantage of this approach, however, is how the team can own the business area(s) and share the responsibility. Scaling can be done by adding more teams and sharing the codebase ownership. But it’s hard to grow professionally in such teams, as usually there are only a few engineers of your technology stack in it. So you need to add some group events like mobile code days, so engineers can share their knowledge.
T-shaped engineering culture
This is where software engineering is going now. Imagine all your engineers being full-stack, so there is no difference in what task is coming in the future sprint. 90/10 Server/Web – fine! 15/85 Server/Web – no problem, as every engineer in the team can do both. This is a dream of every business, and engineering culture supporting T-Shaped people is helping a lot here.
You probably heard about this concept: the vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is one’s ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own. In our world, this means that an expert server engineer is able to understand how the front end (web or mobile) works and contribute to the development of mid/low complexity tasks.
This approach helps many expert engineers to move forward. Once you are proficient with one stack, you are ready and motivated to learn something new. So you go out there and learn another stack in your vertical T or start investing in horizontal T. For example, if you are an expert in .NET – learn Go or Python and then add WEB/Mobile on the top of it. And once you master your skills enough, it really adds up to the sense of accomplishment and one’s professional worth, “Hey, I don’t need to wait for the mobile team to fix it, I can do it on my own. Cool!”
In conclusion
Modern engineering culture is focused on encouraging the growth of full stack engineers. If you are a QA engineer, you can fix simple issues in the code on your own – why not? If you are proficient in server and need to make a change in the front end – go ahead. And if you need to add one more field to the screen – add it on the server as well. Why should you wait for someone else to do it? Such an approach speeds up things a lot and makes everyone happier and more satisfied with their work.
These days, businesses prioritize hiring engineers with several tech stacks or full-stack engineers. This is what FAANG (Facebook[Meta], Amazon, Apple, Netflix and Google) companies are doing. If you are a strong server engineer with few stacks in the background – the project tech stack becomes less important. You will learn it in 1–2 months, so no one is looking for a specific stack on the interviews – they look for good engineers. This approach allows companies to build strong cross-functional teams and work on what is important for business, not on what we can take to work based on team load. This strongly increases the chances to win the race, so join it!
Comments