There are many ways to build engineering teams. However, a few factors repeatedly play into how teams function and operate. Group dynamism is a huge contributor to the efficacy of a team. Knowledge of the domain, the technology are other key driving factors.
For a team to be high performing, it needs to have all the functions that contribute to the end goal or the object they are building be part of the team. While this sounds obvious, many teams in organizations are not set up in a structure that comprises of all the necessary contributors. Some of the key contributors would be external and be available on a time-share or limited basis.
Let's take an engineering ( software development) team as an example. Ideal engineering teams would have all the necessary roles as part of the team. This would include Business Analysts, User Experience Designers, Architects, Software Developers, Quality Assurance, Automation Test Developers, and Site Reliability engineers being part of the same team. However, given some of the natural organizational boundaries, this may not be totally possible.
What are the Issues that arise with teams or management that are structured around functions?
There are many reasons that could contribute to the low performance of a team that is structured by function. Before we look at the negative impacts, let's consider the positive impacts of such a team :
1. The team will be specialized in that function - engineering, quality assurance, UX or whatever the specialization is - they will be very much specialized in that area.
2. Detail Oriented - The specialization can result in the solutions that the team builds to be very detail-oriented. While this can be a good thing, the Pareto principle could come into play here - where the team could ( note the could ) end up spending 80% of their time on a solution that is needed by only 20% or less of the users.
3. High Quality - Obviously a specialized team can build products and solutions that are very specialized.
Now let's look at the countering arguments:
1. The dependencies within the team - Due to each function reporting in from different leadership, each member will be a dependency for the success of the project. Considering that software engineering is like a production pipeline, where each function contributes to a different area and is time-boxed, the availability of each of the functional roles could play a significant role in the speed of execution of the project.
2. Communication gaps - An all too common scenario that emerges with this type of segregation is what I call the idea of "throwing the stuff over the wall". One functional group, after their work, is done , eager to move on to the next big thing ( and in many cases challenged by productivity KPI's and commitments) , will handover the work to be continued over to the next functional group, without the focus and commitment to get the transition completed in a smooth and efficient way. The idea, though taken from automobile manufacturing assembly lines, is not a good fit as the nature of software development is empirical. No two solutions are alike ( except in a very few cases) and each solution needs its own context and reasoning and in most cases a verbal explanation and walkthrough is necessary).
3. Differing alignment - Conway’s law, though an adage, should be mentioned here. It states that ‘Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. What does really mean in a function structure team? Well, we will see that each of the functional teams ( engineering, QA, architecture) is focused on what the leadership of each of the teams is focused on ( communication structure), instead of the end goal which is to release a wholesome product for the customer. Each team is likely to get 'lost in the weeds', and lose the vision of the bigger picture. Of course, this can be offset by having visionary and dynamic leaders, but lacking such a person on the team can cause significant shortsightedness in the team.
So how do we fix this? Is it possible to build a lean yet efficient team?
I wish the answer was simple. But I am afraid, it is more complicated. Agile and hybrid teams are a great and brave attempt to fix the above-said problems. They are called hybrid because the team comprises of all the functional roles needed to complete the project. The team should have all the roles necessary to take a project or feature all the way from inception to deployment. While this team could be very effective, given that the decisions will be taken by the entire team , this could also lead to the teams being expensive. To be continued....
Comments
Post a Comment