Overlapping
- Rule 6 - Cooperation is a powerful force.
- Rule 31 - Innovation happens when the people with the need meet the people with the how and can speak the same language.
In your career, should you specialize or be a generalist? Phrases like “jack of all trades and master of none” tend to make it sound like we should specialize and certainly the tendency in most organizations is to favor specialization. I do not think the question specialization versus generalization is the right question. What we should be asking is “how much we should overlap with the people around us?” The answer? A lot.
Lately I have been using variations of this phrase a lot:
Most of us do not fit inside our role and most roles do not exactly fit the person.
That is, we have more skills than our job title requires. On the other side of the coin, our job title requires more skills than we have. Is that a bad thing? No. We are people and that is to be expected and even encouraged. Uniqueness is a strength, not a weakness. The only world where uniqueness is a weakness is one where people are “fungible resources” to be exploited rather than embraced. That attitude of fungibility leads to weak organizations. Even when an organization does not act like people are swappable, we can run into the weakness that looking at people as specialists who fit neatly in a role creates.
When we fit people neatly in a role, we create gaps between roles. Everybody lines up next to one another and we hope nothing falls through the gaps between us. business analyst does not understand the development approach, the developer does not understand the business need, and the QA understands none of the above. We then wonder why the tester missed test cases that were “obvious.” Of course they missed the obvious cases, they were not obvious to them at all! Low quality, slow delivery, and general failure are almost certain when Acronym Soup and other jargon causes communication between team members to break down.
When the business analyst learns something about the software architecture and practices, when the developer and QA learn not just the terminology of the business, but how it works, then we start to see some overlap. It is like a group of people standing in line holding hands. Something may start to get through, but they can help one another stop it. They are only as strong as the weakest link and that weakest link is tenuous because it is still relying mostly on the strength (capabilities) of the individual.
As the team starts to learn more of the roles next to theirs, they build a stronger chain. They can lean into the problems coming their way and can rely more on one another for support. It is like they have locked arms together. They are standing close and are relying on arm strength instead of just hand strength.
As the team members learn more about the roles next to theirs, they start to be able to perform some of the duties. Sometimes I call this “adjacency”, but “overlapping” is a simpler term, so I will use that. We do want to be careful how much we actually do of the role next to ours(and it depends), but that overlap means we are covered when someone is out of office, there are fewer gaps that pop up because of misunderstandings, and the team is not just relying on one another - they are actively helping one another. For example: the user interface developer is not just handing a problem off to the business logic developer, they are providing information about what is wrong and possibly even how to fix it. Without the UI developer understanding the business logic at some level, all too often we see bugs and other problems bouncing back and forth between team members as each one has to investigate and communicate. They are not really speaking the same language, and so communication is poor and resolution takes far more time. Conflict among team members increases as each claims “it is not in my area” until finally someone figures out the root problem. When each team member can actually do some of the duties of the people in the roles next to theirs, it is like they are standing with arms interlocked in multiple ranks, one behind the other. Like a brick foundation where each course is staggered, this creates a strong foundation for the team to work together.
Creating opportunities to overlap is why I love requirements gathering workshops. Put a large group of people from different departments in a room to talk about the organization’s processes and it is usually a matter of time before you hear comments like “you still do that? We have not needed that for years” or “you do that too? We do it before we send the thing over to you, we can sent it with the thing.” Without breaking bread and building common understanding, we miss those chances. I often think the real success of a new systems initiative comes from those lessons and not from the new system itself.
Do not let the desire for specialization create isolation. Get people talking together, understanding what one another does everyday, and I promise you will get a much better result at less cost. As an added bonus, your team is going to be much happier working together. Will overlapping hurt your career? No! Choosing to overlap will help your career. From my first software development job, I spent the time to understand the industry I was in, the company I was in, the users, and everything I could about the development process. I do not try to master those adjacent roles, and certainly do not try to be the jack of all trades, but I do want to understand the people I am working with and be sure my solutions are good solutions. It has worked for me so far!
For 2024, I’m aiming for shorter articles and here we are at 1000 words or so. There is much more to go into with creating shared understanding, but I’ll leave it for another time. I hope this has been a smidge useful and, as always, reach out on LinkedIn or Mastodon if you’ve got any feedback or questions.