Sammi Sinno

Development - Off The Beaten Path

A development blog that explores everything and puts an emphasis on lesser known community driven projects.


Be a Generalist Not a Specialist

Monday, March 9, 2020

I see specialization on so many different levels. Specialization in a framework, a capability, a product. A specialist becomes the domain expert in that area and feels comfortable going into any engagement knowing that their knowledge won't be challenged on that front. But is that necessarily a good thing? In a world full of specialists things like collaboration and team innovation vanish. People and teams become territorial and any attempt to introduce a new way of doing things is seen as a challenge as apposed to teamwork.

Moors Law

I'm sure it is no surprise to anyone that technology changes, rapidly. So when thinking about specialization in technology, it does allows you to get up and running quickly when asked to work with what you are specialized in, but what happens when support for that product or framework is gone? In most cases companies tend not to move on or migrate from it because their employees are "specialized" and can't pick up new ideas or ways of doing things quickly.

I tend to see this more often in larger companies where the mentality is that the more people you hire the more you can get done (which is never the case). Due to the size of the company and the amount of projects going on, there is an attempt to create some sort of reuse in areas like authentication and content management. Years later new employees and teams come in who are expected to get work done fast and efficiently, but find out that they have dependencies on teams and products that follow different methodologies and are reliant on older technologies. Whenever an update is needed to accommodate the product you are working on you have to wait for another department to make updates. With specialists there is always an attempt to draw teams into their domain like the sounds of a siren and companies that put a focus on specialization have a organizational structure that looks a lot like this:

Now teams three through six are dependent on teams one and two in order to have a complete product. Lets say team one controls the CMS used by the company and there are constant updates needed in order to make progress to their goals. Every communication to update a common dev environment tends to take time and can break other teams environments. Now if you put a focus on generalization, it will allow teams to work more autonomously, and you'll have a team structure that looks more like this:

Lines of communication are kept open for mostly sharing ideas on workflows as well as new releases. Generally in a microservice pattern the idea is that each team can work with the frameworks that make the most sense for them. There aren't any standards or technologies forced on any teams, because in the tech world they can easily be outdated by the time a new team rolls on.

Team Dynamic

Having specialized teams is one thing, but there is also the idea of forcing specialization on individuals within a team. You have your front end developers, backend developers, DevOps ect.. The same philosophy applies, you can get up and running a little bit quicker, but then you tend to see certain aspects of the software being handled in strange ways. For instance, I've seen front end engineers chain a multitude of API calls together to get the aggregated content that they needed instead of just adding a single call to the backend that would be much more efficient. I've also seen DevOps engineers work in a silo for a very long time and come back with something that the developers either can't run or don't know how to. When something goes wrong with the pipelines everyone just throws their hands in the air and point figures at each other.

The same goes for issues with the software, front end developers point to backend developers, DBAs point to dev ops and the cycle never ends. The only way to avoid an environment like this is to avoid pigeon holding your engineers and make them responsible for all facets of the program. Ultimately it is much more difficult to hire in this manner, but with the right leadership and support it is easy to convert most engineers to be full stack engineers.