Let's talk about T-shaped specialists. What does the term mean? The idea is that as a professional, you can either go deep or you can go wide.
I-shaped and dash-shaped growth
Say you're a junior working on the backend, and you can do some simple stuff like writing controllers or writing from JSON into a database. As you accumulate experience and learn in your field, your knowledge profile will deepen, and you will learn more about architecture, different design principles, databases, scaling, etc. We can dub this person a "scientist", someone who digs deep into their own field, an I-shaped specialist.
Another direction for your professional growth is understanding more about the field of other people on your team. If you are a backender, you'll probably have a frontend developer and a tester beside you. You could learn basic stuff about forms and requests or how to write simple tests. Here, you go for width, not depth; you become a "sage", a dash-shaped specialist.
T-shaped growth
A functioning enterprise will require people to develop in both directions. Understanding SOLID principles is important for a developer, but so is writing unit tests, and the two are related. Going both deep and wide means you'll be T-shaped, which is valuable today.
The direction of width helps with communication and understanding the general goals of the enterprise - which is why it is vital for business owners. However, they aren't the only ones that need it.
If people from different teams have trouble talking to each other, the cost of communicating will be extremely high, especially when communicating goals. Everyone will hear things their own way and have a different definition of done.
This problem can be countered by going into so much detail that tests requiring 30 minutes of work will have a specification that takes testers 3 hours to go through. Of course, the cost of not communicating goals would be even higher.
Silos
It's about the problem of silos. People either work in the context of business needs or the more narrow focus of their own fields; the distribution of effort is different in either case (you can see it in the metrics they use).
Of course, if each team is holed up in its own domain, all the communication will go through the manager, who will be constantly swamped.
The three amigos approach is trying to solve the silo problem by simply getting people to bloody talk to each other once in a while. And it works: there is research showing that transdisciplinary teams have an advantage when tackling "wicked problems" - problems that lack precise definitions, stopping rules, or opportunities for trial and error.
Building communication APIs
So, how do you get there? It would help if you worked on communication APIs - your shared boundaries with other specialists. There are many ways to share your expertise: meetings, code reviews, or just having a beer with colleagues. However, one of the most effective ways is a report.
If we go with the metaphor, what does an API do? It tells a person from the outside what a complicated system will spit out from its insides. This is exactly what a report does!
A report is a shared context for the inside and the outside. It condenses knowledge so that people with different backgrounds can talk about it. It's a universal tool for creating common ground.
And reports are easy to build - for instance, using Swagger. With language-independent documentation for APIs, it provides the kind of shared context we're talking about. You could create a report to compare two swaggers, one for tests and one for APIs. That would tell you your test coverage - and provide great common ground for testers and backend developers.
Allure Report
Another great base for reports is an automated test. For the three amigos concept, automated acceptance tests provide a common expression of what we want from the system. But test reports also create shared contexts for different developers.
Today, a multilanguage tech stack is very common - for instance, Go, Python, and Java on the backend, with a frontend written in JavaScript. In this situation, it can be tough to figure out the causes of failures - you need to dig into different reports for different languages, and it all becomes a tangled mess in your head.
Here's where Allure Report shines because it integrates with pretty much anything you can think of. Tests from every framework in every language all get transformed into the same data format. This base is used to display your test results in various neat ways.
Every test gets a representation in plain natural language, which doesn't depend on the framework:
This has everything you need to analyze the cause of failure - steps you can read without knowing the programming language, screenshots, and an HTML of the page under test. Failed tests also include stack traces:
And there are also graphs based on aggregated data from your test results:
This allows people with different tools to see the same picture and understand each other.
Conclusion
If you want effective lines of communication across professional boundaries, you need common ground, something for people to talk about. Reports are great for this - they condense complex information so that anyone can read and understand it. And as people get the horizontal part of their T shape stronger, the costs of communication fall and organizational goals become much clearer for everybody.
