Structuring a better organization model
If there’s one thing that I always fight for in a company, is a career ladder. It may seem weird, but for the last four years, I’ve had roles that usually sits on the gray area of a company structure: Agile Coach and Product Manager.
But first, some context.
The 2013 tech boom
Those are new roles in tech. One might argue that PMs have been around for years now and that almost 20 years have passed since the Agile Manifesto. Well, look at these Google Trends charts:
From those, we can see that something happened around 2013. But what? Well, tech exploded. Things that, in the 90s would be thought of as impossible, came to life:
- A Social Network movie released at the end of 2010
- The same social network buys another social network (Instagram) in 2012, for 1 billion dollars
- Just two years later, it acquires another tech company for 19.4 billion dollars
So, is it Facebook boom the cause of it? No… it is just a consequence of the same “techy” virus (in a good way?) that spread in the business world. People started to see that technology is really, and I mean really, profitable. What more? The words Digital Transformation and Spotify Model started popping:
The first turned every company, even if it was a centenary one, into a tech organization. Everyone needs an Agile Coach now. Especially after the advent of the Spotify Model, in which ACs (or SMs) and PMs (or POs) are almost mandatory.
And I think this squad model is excellent. It gives autonomy to teams and, at the same time, it keeps all the tribes aligned. However, the flat structure makes the career ladder steps too high. Above the PM you usually have a Director of Product. You go from managing a product, which most of the time isn’t even the whole product, to handling all the products’ decisions. Meanwhile, the Agile Coach has even a more undefined path. Sometimes there isn’t even a path.
The problems I want to solve
There’s no way to build a silver-bullet solution, in which you have no trade-offs. The model I was looking for was something that would give everyone a smooth career ladder whilst maintaining the Spotify model’s alignment and autonomy.
Based on that, I maintained the squad model, but included “levels” to it, which reminded me of fractals. Thus the name, “Fractal Model.”
The Fractal Organization Model
First, what is a fractal?
“A fractal is a detailed, recursive, and infinitely self-similar mathematical set whose Hausdorff dimension strictly exceeds its topological dimension and which is encountered ubiquitously in nature “ — Wikipedia.
Clear, right? I know. It is not. But, simplifying it, a fractal is a pattern that repeats itself in different scales. Kind of like the movie Inception (which I highly recommend), which can be interpreted as a reality fractal. Let me be more graphical and explain what it means.
Example
Imagine that the pattern I will apply to a starting drawing is:
“For each line segment in the image, draw a triangle in the middle of it and erase the base segment.”
Based on that, take a look at this image:
Imagine that you start with just a line, like in 0. The next step is to draw a triangle on that line and remove the base segment, which gives us the image 1. Next, imagine that, for each of the four line segments in the picture, you’ll do the same. You’ll have image 2. Then you repeat it, and repeat it and repeat it…
The only difference between the above fractal and real-life applications is that the aforementioned is infinite. Therefore, we’ll have to define a limit to it in order to apply it in real life. Otherwise, it will not make sense. I’ll better illustrate what I mean.
The Fractal Model
Now that we are aligned on what I mean by fractal let’s dive into the organization model. Just like the example, we’ll start with the pattern that we need to apply. Our rule is:
“Each pattern needs to have a business head, a technical head, and a product head person.”
Level 1
Now imagine that the initial structure of your company, as a startup, is something like this:
Usually, at this time, you don’t need squads yet. The company is small enough to auto-organize itself. But you can already see the pattern in which we’ll apply the fractal rule as soon as the organization starts to grow.
Now, when do I grow to the next level? It depends on your business, your company, and your structure. As soon as you feel you lack alignment, your team is unorganized, and that people start to leave the company because they want higher positions, it may be time to evolve.
Level 2
In the next level, you create managers to take care of different areas inside a squad. Therefore, you’ll have Product, Business and Technical managers that will respond to the corresponding C-levels.
Take a look at how our imaginary company is divided now:
Each squad has a manager that is accountable for a specific area. It will:
- Facilitate alignment, since fewer people will be involved in decisive meetings
- Build a natural career path
- Keep each squad autonomous
Still related to the career path, this model increases the employees’ desire to make their squad thrive since, with its growth, new roles will emerge. An example of that happens again in the next fractal level.
Level 3
Imagine that the orange squad grew a lot. It started to give more and more profit, and they were already too many to few managers. Thus, we can apply the same fractal rationale to their pattern level 2, creating two new patterns level 3.
Now, the ones that were managers, are directors (the PM becomes a Group Product Manager) and everything stabilizes again.
Meanwhile, the purple team didn’t grow at the same rate. Hence, it stays with the same structure. The important takeaway here is that this fractal model doesn’t need to be always complete, i.e., it doesn’t need all the levels to coexist in all the squads.
Important notes
The model we saw above is a simplistic one:
- I didn’t consider the Y-career ladder. But you can, for instance, define that at every two levels of fractal, you’ll have a technical architect. The same goes for the Agile Coach ladder.
- The Business, Technical and Product pattern was an example. You can build rules according to your needs.
- The seniority of each role can still exist.
Conclusion
This model isn’t for every company. Not even for all tech companies. It is for companies that see themselves in the situations I described above, and that can relate themselves to the structural change that I propose here.
Moreover, I’m still working on tuning it to become better and more general. But, as a PM, I feel that in a structure like that I would have more control over my future, and would know that growing would depend on expanding my product to a point at which I’d become a GPM and then a CPO.
What do you think? Does it make sense? Is your company a candidate to change its structure? Tell me in the comments below!
