I believe experience or seniority is about your repertoire of solutions for well-known and broadly present problems. You have built and established a personal toolkit that nobody can take away from you.
One problem I keep coming across in my career is facing bottlenecks or bus factors limiting an organization to fulfill its potential.
One of the prime questions I ask is: „Are the teams and critical processes depending on single individuals?“
It is not complicated to learn where these bottlenecks are. Be super-alert when you hear statements like these:
„We cannot do this because Brett is sick or vacationing.“
„We cannot do this project because Brett is the only one who has this expertise and he is fully committed to other projects.“
„I’m waiting for the completion of the backend to start doing the UI.“
„We cannot release because the tester is still testing.“
I haven’t chosen the name Brett randomly. Brett is one essential character from the excellent book „The Phoenix Project: A Novel about IR, DevOps and Helping Your Business Win“ by Gene Kim, Kevin Behr, George Spafford.
Brett represents people who are bottlenecks due to their unique skills or knowledge about manual processes that are neither documented nor automated.
Let me explain the problem in more detail using a cross-functional team developing Software as this is the field where I have my expertise.
Let’s start with a Team with a PO, two backend engineers, two frontend engineers, and a tester:
If everybody is healthy and present, this engineering power materializes as follows: 40% backend, 40% frontend, and 20% testing.
Let us assume this team starts working on a new product from scratch. First of all, this team will focus on some groundwork like Infrastructure, Architecture, and Boilerplate Code.
In this phase, testers and frontend engineers tend to be under-utilized as they pretty much depend on backend and infrastructure colleagues‘ work. I’m not going to focus on how to integrate infrastructure because I intend to write about DevOps in another post.
At a later stage, the backend engineers are writing APIs that the frontend engineers consume, and the testers test everything.
A very sequential workflow. Such workflows are prone to bottlenecks, context switches, and an „It is not my business“ attitude. Furthermore, you cannot have a demand that precisely corresponds to the specialization of your team members.
Please take a look at the picture below. It shows the changing demand depending on which product phase the team is working on.
While team members are waiting for the colleagues to complete their tasks, a typical situation is to use their time productively by starting to work on tasks and projects that haven’t been prioritized yet, thus increasing the teams‘ WIP and defocusing the team.
So how can we solve this dilemma? I have learned that promoting a culture based on collaboration and T-Shaped engineers is a viable solution to this.
So, what’s a T Shape then?
When people have one particular area of knowledge, they are called I-Shaped because they have one specialization, which becomes deeper and deeper over time. The difference between a junior and a senior UI engineer is the depth of their knowledge in the particular area of knowledge in frontend development.
If people start learning in areas other than their specialization, they automatically broaden their knowledge. They gradually become more T-Shaped, as the picture below illustrates.
So, what do you need to foster „T-Shape“ in your organization, you may ask yourself? Here are the answers:
Sense of Urgency
First of all, people should be aware of the problem they are facing. Otherwise, they are not going to understand what you are proposing.
Each time when you see a bottleneck or teams working in a waterfall mode within their agile framework, speak it up!
Ask questions: „Who can take care of this system if Brett is away?“, „Who is automating tests?“, „How can you be sure that your release will be fine if the tester is sick?“.
Accept no excuses like „I don’t have time to teach somebody,“ „I have a lot of urgent tasks,“ „We can start doing this Knowledge Transfer after closing this project,“ „I’m going to write tests for this feature later.“
After a while, people will get the point. It is essential to bring everybody to the same page. All the pictures you see in this post were part of a presentation called „DevOps and T-Shape – Silo Breaking!“. (A very warm thank you to my colleague Matthias Kohrs for these beautiful pictures)
I used this presentation to run Workshops with all development teams in early 2018. From these days on, we got buy-in from our staff to T-Shape, and the time was ripe for a few changes!
Everyone is an engineer
We changed the titles of all developers and testers. Now they are all Engineers instead of Backend Developer, Tester, or Frontend Programmer.
If they want to, they can put their specialization within parenthesis like Engineer (UI). Most of our engineers opted to skip their specialization in their titles.
Everybody is both a master and an apprentice
Sharing knowledge is a duty, not a nice to have.
Learning from others and being interested in all aspects of the product is a primary aspect of teamwork and ownership.
Another very positive aspect of allowing people to grow broader is giving the people a vast field to develop themselves, instead of limiting their development to a single discipline.
Quality is everybody’s concern
All the team members are responsible for delivering a high-quality product, and not only the Engineers whose expertise is the Quality Assurance.
The commitment to Quality is the reason why I believe all Engineers should automate Tests.
Automate everything
Working Code is the best documentation that a team can have, especially when the team developed it.
Avoid manual steps and knowledge that is only present in individuals‘ heads.
Value the contributions over individual activities
Seniority is not about what you can do but what you enable your organization and teammates to achieve.
Value long term performance over quick wins
Investing in T-Shape is a long-term endeavor, and you will need the patience to collect its fruits. Otherwise, you will avoid pair programming, knowledge sharing, and other activities required to put T-Shape in place.
Summing up
T-Shaping is about avoiding bottlenecks within a Team, sharing knowledge, fostering collaboration, among other measures that will increase team cohesion, focus, and performance in the long run.
You cannot order a T-Shape culture like a Pizza, you and your team have to work hard to have this in your DNA, but the benefits are worth it!