The T model

“Being deeply learned and skilled, being well trained and using well-spoken words: this is good luck.” ― The Buddha

Recently I visited the Craft meetup where

Gergely Orosz

talked about the evolution of the software engineering career. His thoughts were very rational, and eye-opening in some ways. He explained that with the recent changes in the industry, a software engineer’s chances of getting better jobs (or any job at all!) are way better if their field of expertise is broader. In other words, the star of the generalists is on the rise again.

When interviewing, one of my favorite questions to ask from the candidate is if they’re the type of person who knows everything about nothing, or rather the one who knows nothing about everything. This can evolve into an interesting conversation about the T-model - not the one Mr. Ford built a long time ago. Most developers feel that besides having stable and deep expertise in a narrower field (stem of the T), it’s beneficial for them to tap into the neighboring fields as well (the T-bar). The difference is only the shape and the ratios between these two components. I understand that this is a personal preference, but let’s take a look at why having a broad T expertise can be beneficial for you.

I’ve been working in the startup world for almost a decade now, and here, generalists were always more welcome and successful than specialists. In a small company, there are often areas and activities that aren’t big enough to fill up a 40-hour workweek. But those tasks have to get done in some ways. The company has mainly two options: either outsource the activities or have a generalist at hand who is interested in this area and they can pick these activities up. This could be a win-win situation for both parties.

Let’s see how AI defines a specialist:

In the context of software engineering, a specialist is someone who has a deep understanding and expertise in a specific area of software development. They are like highly skilled players in a particular position on a software development team.

Short and sweet, and in the context of big companies, there are certainly areas where you need specialists, since there are several similar issues across teams, and you can encounter problems that cannot be solved with some Stack Overflow reading but require the knowledge and the experience of a top-notch specialist.

But when looking at the big scheme of things, most companies and the most common development projects are not like this. If you’re working for a small to medium-sized company, or on an outsourced development project, chances are that such challenges are as rare as a white raven.

In software engineering, a generalist is someone with a broad range of skills and knowledge across different areas of software development. They're like the utility players on a team, adaptable and capable of contributing in various aspects of the project.

Being a generalist in the team can be a win-win. The company can count on you for critical projects and will involve you in these, where one or more aspects of your expertise come in handy. On the other hand, you can get ample opportunity to grow both horizontally and vertically and work on exciting projects and problems. Here are a couple of examples from my experience.

You build it, you run it

I’ve been hearing this for a while now, but it’s coming up more and more often. In bigger companies, software is developed by software engineers and then passed on to operations to put it out for the users. In smaller companies, operations is certainly not a full-time job, not even a part-time job. Especially since cloud and infrastructure-as-a-code are a thing, you can construct your ecosystem in a way that goes a long way with a couple of hours of work per week. In these cases, developers can gain the required knowledge to operate and tweak the system as needed - which is a cool add-on to every backend, frontend, full-stack, or data engineer’s toolkit.

Can you speak business?

One of the hardest problems in software development is understanding what needs to be built and then building it. Do you know the tree swing analogy? It demonstrates perfectly how this can go wrong. If you’re “just a rest API developer”, then the road to a successful product will be way longer than if you “speak business” and you can understand the feature you’re supposed to work on.

What’s the system and how is it used? What’s the specific feature’s goal and its audience? How will it be used? What are the connection points with other existing features? The usage of the product can greatly influence your design changes and the PM might not automatically consider everything when focusing on a single feature. Your design might be different for an API-only approach than if you own the UX as well. You might need to take internationalization into account from day one, but why bother with it if you’re only serving the US market?

Identifying and answering these questions will drive you to the right implementation quicker. This means learning a product mindset even though you won’t work as a Product Manager per se.

Heavyweight data job

If your system is data-heavy, then it’s not only the data engineer’s job to understand what’s coming in, and how you have to clean and enrich the data to make it ready for further usage. Applying a developer mindset to data engineering can help to increase both productivity and quality. Collaboration between data engineers and backend engineers can improve many areas: the data flow will become more automated, visible, and reliable, and it will become easier to democratize the data across the whole company.

I’m also sure that for every product, there is at least one database in the back office. Determining what database, and what data structure to use needs a lot of considerations. How are you going to structure the data? Does it require frequent access at high speed? Do you constantly rework half of the dataset? Will you perform costly calculations? What amount of data will you handle? SQL or noSQL? How much will it cost to operate and maintain it? … just to name a few. Of course, a database expert’s job is to answer all these questions and come up with the best solution, implement it, and then operate it. But how often do you do such an exercise? Similarly to infrastructure and operations, in most cases, this isn’t a full-time job - hence, developers who have experience dealing with such debates come in handy.

Learning Machine

Traditionally, the R&D team’s job ended with figuring out an algorithm, making a POC, and documenting it. The whole package was then passed on to software engineers for productization. Now, with the rise of ML, the game has changed, and ML engineers are now responsible for not only creating an algorithm, but also putting it into production, maintaining, and god-forbid operating it. This requires a whole different mindset and introduces the need for collaboration between data, backend, and ML engineers. The strict borders between these disciplines are now dissolving, and the ideal skillset moves from black or white to myriad shades of grey.

To me, all these examples prove that if you’re not a specialist but open your boundaries to some neighboring areas of software development so that your T of expertise gets narrower, you can greatly benefit from it. You still need to dig deep in one or two key areas, but clearly, that’s not enough. At smaller companies, this was already bread-and-butter, but based on the latest gossip, bigger companies are moving in this direction, too. It’s in their interest to get efficient, and demolishing these artificial walls between the different disciplines is one way to do it. It seems that the era of narrow-mindedness is coming to an end and this is your chance to stand out of the crowd with a well-established T-bar.

Food for thought: What other areas do you see such diffusion of disciplines? Do you consider yourself a specialist or rather a generalist? Do these changes where the flag is flying for generalists work in your favor? What new disciplines did you learn recently that are not part of your core skillset? How does this trend influence the role of the managers? I would love to hear from your personal experiences.