Ever since I started to work in this field, I have seen a transformation in the way companies shape their teams.
Of course, the nature of the business is the one dictating the form and the need of the teams towards a common goal. And we can iterate this into many different levels so let's move from macro to micro.
To close the scope, I will only focus on product companies. Companies that offer and develop a product to different customers, whether they are BTC (business to customer) or BTB (business to business).
Shaping the teams
The first factor that I would like to analyze is the size of the company, in the sense of when a role becomes a need over something the rest of the team can absorb.
It can also be considered as the timing where a company is in terms of its maturation and growth.
In startups, as the main goal is to validate if the product or hypothesis the company is building has a future or not, the common pattern is for people to wear multiple hats, as long as the team is productive enough.
In the beginning, this approach can look disorganized or a bit chaotic, but this is only because the focus is on delivery and nothing else. This for sure has side effects like growing the technical debt, lack of process, overlapping of responsibilities, etc.
In this particular environment, you might not specialize in a particular role, but you will learn about many other areas across the development cycle.
So, again, generally speaking, it's more common to see full-stack developers in startups, and the role of QA, just to name an example, is embedded in the team as a shared responsibility.
None of those embedded roles will be fully proficient, but as I said before, the focus is on delivering as fast as possible. So in case, we fail, we can re-adapt faster.
As the company starts growing, either by getting new customers, investments, or acquisitions, among other possibilities, the need for particular roles becomes crucial to the success of the company.
And here is when the situation starts to become a puzzle.
I guess this is growing up
There is a video from Steve Jobs, that sums up what I feel most companies suffer when growing in size.
The video is about the difference between process and content, process as the set of actions and rituals that took us to where we are today, and content as the output we have produced.
From his own words:
"You know what it is? People get confused. Companies get confused. When they start getting bigger they want to replicate their original success. And they start to think that somehow there is some magic in the process of how that success was created. So they start to institutionalize the process across the company"
Itโs not easy anyway, but the less we focus on standardizing or institutionalizing the process, the closer we will get to our final goal.
As the company goes from a start-up to a scale-up, defining a structure becomes a necessary evil. Scaling teams is difficult from every aspect we can think of.
Culture
Hypergrowth, sometimes used as an argument to convince people to join a company, is in my experience something that I, as an employer, will try to avoid.
I am not a fan because this usually ends up with a lot of people entering at once, with no proper onboarding and focus; with a lot of new managers having to take on new roles and promotions due to the new vacancies being opened, a consequence of this growth.
Keeping the culture of what has made a company successful as a startup or scale-up is difficult, and doubling the size in months makes it even harder.
As a newcomer, getting used to a way of working takes time.
Splitting the teams
As the company continues growing there's a need to start dividing and conquering different aspects of the product, in order to reduce the scope and define bounded contexts.
Having that in place, teams can feel more empowered to deliver impact, by getting a better understanding of its specific context.
Splitting responsibilities and defining what's generally known as domains (mainly due to the book written by Eric Evans called โDomain-Driven Design: Tackling Complexity in the Heart of Softwareโ) has become one of the most common patterns to promote what's called subject matter experts.
Whether you call it domains, areas, verticals, chapters, or even products, keeping the structure in sync slowly becomes an issue.
But, how does this affect delivery? The more people and teams we have, the more difficult the communication will be. There is a lot of try and error in this regard, as there is no framework that solves all the issues. So understanding the context and the tools is key.
The benefit of going in this direction is that we develop expertise in a particular subject, which in the end will help to develop more accurate and well-thought features and initiatives. Mainly because we are reducing the focus on the things we have to take care of, in other words scoping the knowledge, and responsibilities.
Similarly, we can think of the analogy when we try to split a monolith into microservices, sorry for the technical reference, but one of the drawbacks is how to balance autonomy and not create silos.
As a side note, I think when people say that every team has a startup feel, would potentially lead to misunderstanding as there is a lot of alignment that needs to be kept in order to fight for a common goal.
Creating unintentional silos
Once we have done the split, things start to get more complicated, and this is when for me the aim for autonomy can have a side effect on creating silos.
Teams will start looking down their own priorities and roadmaps. An aspect that has a magnificent benefit, but if we take alignment and general guidelines for granted this can end up in chaos.
Empowering the teams, and making them believe their impact matters is good, but it doesn't come for free. Having roles to keep those teams synchronized to reduce dependencies, to coordinate common problems with a holistic view of the product, ends up being something mandatory.
No matter how we based the split of the teams, business, or infrastructure, the necessity of standardizing and building the foundations (so we can align and speak the same language) will always be there.
One example of what foundations mean to me can be decided on the agile methodology, or the tracking and communication tools, we will use in every team.
At a certain level, delegating decisions and providing freedom to teams is good, but it all has to be aligned in a way in terms of direction towards the future. Clear communication and easy-to-understand guidelines can be a good starting point. The misinterpretation of these factors is a huge risk in big organizations.
Be cautious when making new steps, and move pieces incrementally and organically, rather than going for revolutionary changes, which are naturally hard to digest. Otherwise, you will spend most of the time organizing the structure of your system to shape it towards pre-defined domains.
Having a business purpose in sync and connected, usually helps to have control and guidelines for the teams. On one hand, they will have the autonomy to take their own decisions based on these key results, and on the other hand, they will avoid falling into silos as there is a common goal in every person's mindset.
Generally, itโs not a matter of only having the process but the people with higher overviews, taking care of cross teams initiatives that can spot where things are misleading, or when we see teams that are supposed to support each other running in different directions.
When things don't flow as expected, we might probably need to go over a re-organization of the team, towards a better setup that will make us work in an organized and meaningful way.
Re-orgs sometimes seen as a bad pattern, are a natural process that companies go for when changing directions or dealing with changes. Obviously, the overuse of this process will make people get tired.
Closing up this is just my view based on how things are seen from my perspective, my experience in the different places I have worked, the responsibilities I have had along with my career, and how these types of processes could affect motivation.
Top comments (0)