Seniority: the role of flying hours and the personal upgrade in a technology team's evolution
Starting to fulfill my promise — made in my article on scaling engineering teams in a healthy way, I want to talk about a subject that is very important and also controversial — the team’s maturity metric.
As I have mentioned in my previous article, this metric is comprised basically by two factors: the seniority of the team members and if the people on the team have developed an efficient team dynamic
This article is about the first factor: the seniority of the members and how we should balance it in a team.
On this topic — in this article — I will speak a little about how to look at experience and, after that, give you some tools so you can grow your team in a sustainable way looking from an experience perspective.
But — before going to the usual pragmatism — let’s play the philosopher for a bit…
There is a lot of anxiety in today’s world and — eager to change the world — I see many leaders putting the cart before the horse and not letting some things mature as needed.
Don’t get me wrong, I think it is very important to change the world for better. As Steve Jobs used to say, we have to “poke life” and “make a little dent in the universe”. However, how to do it is very important.
Now you can say:
“Bernardo, we are done with philosophy! What time has to do with seniority in a team ?”
Well, going straight to the point, everything!
Time has to do with experience. And, the experience from the people we hire and how we train our team is essential for our company’s success. And, to give good training to our team, we need experient “mentors”. Hence, experience is key in order to create a virtuous cycle of growth.
Flying hours and the “personal upgrade”
First — as I always like to do — I think it is important to illustrate a little why experience is important and how it relates directly with time.
To do that I think it is important to introduce a concept — that I learned for the first time in Malcolm Gladwell’s book Outliers — known as the 10.000-hour rule. In this book — one of my favourites — Malcolm teaches that in order to achieve mastery in a complex task — like leading a team or writing software — one needs to have at least a certain numbers of practice hours
The magic number of 10.000 hours — what would be the equivalent of training, around three hours per day, or twenty hours per week, during ten years — is what studies show that is the minimum necessary to achieve the level of mastery that would be the equivalent of an international expert.
And, surprise, surprise! That works for many areas of knowledge: from skiing to master’s in crime. You would be even more surprised to know that this applies even to people that the world considers prodigies. The book remembers us that Mozart, for instance, is famous to start composing at the age of six, but to do that with help — which is impressive anyway — and he would only achieve his best — composing his masterpieces — following the 10.000-hour rule.
I hope the 10.000-hour rule has heightened your curiosity — as it had mine — and I strongly recommend that you read Outliers and, in special, the chapter “The 10.000-hour rule”.
One thing that it is very important to have clear is the distinction of an international expert and what the market calls a specialist. An international expert in software is someone that operates at an international level of excellency and — in my opinion — follows a very different model from the specialist. I wrote about that in my last article about the PaintDrip profile for those that want to know more about this subject
But, let’s get back to the main topic: now that we know about the 10.000-hour rule it should be very clear that “flying hours” — which is the nickname I gave to the number of hours of experience someone has — are important to any professional and you should look at this carefully when building your team.
After I got to know the concept of the 10.000 hours one thing that has always intrigued me — and something that people asked me often as well — was if they were enough. The number of hours alone did not seem intuitive to me. How to do things always seemed fundamental as well.
The “formal answer” only came to me years later when I met Morten Hansen in a training session he gave to the leadership at OLX about his book Great at Work.
This is another of my favorite books — I guess you have already noticed that I am the kind of person that takes my Kindle with me everywhere. Luckily for my back,I do not imitate Bill Gates who takes a bag full of books everywhere 😉
Morten published his study from several years — studying 5000 people — trying to identify what differentiates people with exceptional performance from regular ones.
His conclusion: there are “7 practices” — that he called “work smart practices’’ — that are responsible for the major part of the people’s performance, as shown in the picture below — taken from his book.
I recommend you to go deep on all seven practices so you can use them in your work. My favorite is the one he called “Do Less, Then Obsess” — it has to do with prioritization — you certainly are going to see more of that in future articles. However, for our conversation today, the practice that I want to talk about is number four — that Morten named, Don’t Just learn, Loop.
In his study, Morten tells the story of Dan McLaughlin. Dan — with the rule of 10.000 hours in his mind — dropped his successful career as a photographer and — after 5.200 hours training — starting from scratch became one of the top 5% golf players in the United States. In a nation with 24 million golf players — and in only 4 years — that is an extraordinary feat. However, one of the most interesting things in Dan’s story is that it was not only a repetition game over time.
Reading the book — and I strongly encourage you to do the same — I realized that my intuition was not wrong. It is not only a brute force game. “Flying hours” are very important, as it is shown by Dan’s story — and many more in the book. Nevertheless, it is very important that during our journey we create — what Morten called — a learning loop — as pictured in the image below.
The learning loop enables us to learn and do what I call the “personal upgrade”. Easy in words, but in real life you know how hard doing this “upgrade” is.
In Great at Work, Morten explains the Learning Loop technique in detail. He also gave some tips on how to implement it. An example is the technique he calls “the power of one” which helps in our own “upgrade” focusing 15 minutes daily in enhancing a new skill. A quick example of this: during the pandemic I learned touch typing — to save my cervical spine — using this technique and the platform keybr. Well, now I’m deviating from this article’s main topic, but — definitely — I recommend the reading.
So far what I wanted to show you were two important aspects that you have to consider when you are: building, participating or — even — considering to become part of a team.
- It is very important to look if people have the desired experience considering “flying hours”, in other words, the number of hours the person has worked in that position before.
- It is very important to look if over time the person can demonstrate that she got better at doing whatever she does — AKA — do she do her “personal upgrade”.
Structuring the team
Now that you already know that flying hours and the personal upgrade are very important — and also — why, let’s start to look on how to use them while building our teams.
First, I would like to remember that the model for building teams that I recommend and use for many years now is the one that Marty Cagan calls empowered product teams. I have talked about that model in the first article from this series — on building teams powered by technology — and if you are not familiar with it I would deeply recommend that you take a look at it first.
First of all, I would like to present some structures and proportions — besides the empowered product teams model mentioned before — that I find important and use in my model for building teams.
The first structure I would like to talk about is the engineering leadership team. Essential to make the engineering team work smoothly and efficiently, this structure is where the direct report lines lie within engineering and it is orthogonal to the multifunctional teams — or empowered product teams.
The proportion I like to use between people managers and individual contributors is one to eight — at most — depending on the leader’s maturity, the level she is in the hierarchy and the maturity of the individual contributors under her responsibility. Hence, the leader can give quality time to her people.
The idea here is not to get too deep on the role of an engineering leader — an excellent source for that is the site rework from google and its oxygen project. The important for this article is remembering that this layer is fundamental as an enabler to create the environment where we are always recruiting the talent we need and training our team — so, it is always doing its “personal upgrade”. In other words, this layer is the one that is responsible for keeping the team balanced in terms of experience.
It is also important to remember that depending on the team’s size the report tree has one or more levels.
Typically in a team with up to eight developers, the leader — or manager , for the purpose of this article I will use both interchangeably — is the CTO and everyone reports to her. When the time start to grow the CTO — or the most senior leadership role in engineering — starts to recruit other managers to help her. As a consequence, a layer that we call engineering leadership is born.
The second structure that the engineering leadership — together with the people department — has to build is a very well structured Y career — where we have a clear path for both managers and ICs — the latter are also essential for a company powered by technology.
The image above shows an example of a Y career with well structured roles — if you need other examples the site levels.fyi has many, including most of the Bigtechs such as Amazon, Microsoft and Facebook.
Of course we should be careful and not over-engineer our career ladder before we need it. A career like the one above does not make sense in a startup with ten people. However, it is important from the beginning at any company that the leadership have conversations about the future and how to develop their people — systematically coaching them thus enabling the team’s “personal update” along the way.
I also think it is very important — from the beginning — that the company has a vision for both career paths: managing people and technical individual contributors. It is important to understand that those are two different types of work, both extremely necessary so we can attract, train and keep the necessary talent in an effective way.
Another common mistake that many professionals face is looking at the people managing path as a promotion. That is not the case, again, both paths are essential to build a solid technology powered company — the difference is the nature of the work and set of skills that need to be developed.
A proportion — that I mentioned in my article about how to scale an engineering team in a healthy way — which I think is important to look here is the seniority of the ICs in a squad. As I told in the article — in my experience — a good proportion would be 25% more senior devs, 50% in the intermediate levels and 25% beginners. To illustrate that we can use the Y career from the previous image:
- senior devs — would be developer V and above
- intermediate level devs — would be developer IV
- beginners devs — would be developer IV and below
It is also important to balance the leadership using proportions. I ended up not talking before about how to look at proportions regarding seniority of people managers. However, very similar to how we should look at this from an IC perspective, we have to do the same exercise with managers.
Let’s also use the same Y career to illustrate the proportions I use in general:
- Engineering Manager I — responsible for one squad — remember that an average squad in my model in general has from 4 to 6 people. Hence, this manager would have from four to six direct reports.
- Engineering Manager II — responsible in general for 2 squads.
- Senior Engineering Manager — it is already a leader of leaders — in general has under his responsibility a group of managers and — eventually — some ICs — normally more senior ones.
- Engineering Director — it is a seasoned leader of leaders and typically is responsible for a bigger engineering team division.
The important here is that — in general — the leader should not have more than eight direct reports, otherwise — as I have mentioned before — she will not be able to have quality that to dedicate to her people.
Team Strategy
With all these artifacts and proportions in hand we are able to create the last artifact I would like to present in this article, that I call: the team map.
This map is the representation of the team’s people strategy and starts with the forecast of the number of squads that you are going to have based on the company strategy and the derived product strategy.
if you do not know exactly what a product strategy is and how using it is very different than using traditional roadmaps — I suggest you take a look at Marcelo Quintella’s article about that.
In the map we must have:
- Team’s topology.
- Squads and its components(people and roles).
- Squads that you want to create — based on the strategy — and who you have to hire and train.
- List of leaders responsible for the squads.
Those items are the partial diagnosis on the current state of your team and which are the “gaps” you have in terms of people and roles.
Looking at it, the engineering leadership team can propose recruitment and training policies so the team will be balanced and look at its growth strategically.
This map is also a key communication tool to use with the company’s senior leadership and with all the tech team.
Well, I hope this article has helped you to understand the role played by experience in a technology team and how to use that to balance seniority in your team.
One thing you might be asking yourself is: in an incipient, very hot, with less talent than openings, technology market, how to do it?
This is the subject for my next article, where I will show how training is fundamental and how to create incentives in your culture so your team is always doing “its personal upgrade” organically. See you soon!
