Specialization vs. Wearing Many Hats

Problem

A lot of my company’s clients are much bigger organizations than we are; some are hundreds of times our size. A seemingly inevitable consequence of this is the way knowledge silos develop within them.

One client of ours is a great example of this; whenever we have to have a support call or other technical conversation with them, our point-of-contact does their best to ensure the right people are on the call, but more often than not, that person is not technical themselves and invites the wrong people. When the technical team realizes they are not the right ones to discuss the issue, they suggest who should be on the call, and time is wasted waiting for them to join. Often, this process repeats multiple times, resulting in meetings with dozens of people that are hours long and largely a waste of time and money.

In such a large organization, siloed departments like this can have some seemingly advantageous qualities. Even in vastly different industries, there can be common needs in specific areas, so it may be easier to recruit for teams with narrow responsibilities or to employ contractors with skills that are not specific to your business. A small, focused team may be able provide the same service to many departments within the company.

On the other hand, this kind of structure also risks creating organizational waste. When each department is responsible for a small piece of the overall picture, you usually need someone, perhaps the entire team whose responsibility is to design the big picture and coordinate the efforts to bring the pieces together effectively. When large systems are being built in pieces by different teams over long periods of time, it can lead to overdesigning and overengineering as people try to anticipate and account for all the situations that might arise when it all comes together.

Actions taken

In a small company like mine, we don’t even really have the option to work this way. We haven’t had the resources to hire enough people to have a team or even an individual for every part of the system. Our market-leading product, which is used by millions of people around the United States, is built and maintained by a team of about a dozen engineers. By working in a highly collaborative environment with our product managers and sometimes our clients directly, our engineers grow expertise not just with our product and our industry, but also with being more complete contributors to the company.

Virtually none of us came to this company with expertise in our industry, but by working closely with our product managers and our clients over time, we all have the opportunity to develop that expertise and I would argue that we do more so than if we were able to fully specialize in tiny slices of the product. While it is natural for each of them to develop preferences and specialties within our product, at the same time, they all grow expertise with the product as a whole and the industry in which we work. They develop value to the company beyond the boundaries of their job description. In my experience, it makes them happier and gives them an advantage as they progress in their careers. They have opportunities to stretch and carve out their own roles.

Lessons learned

• It’s important to expose people to unfamiliar things so they can develop new expertise. I try to make sure that peoples’ time is not being wasted, but they need an opportunity to learn, to let things sink in and make sense.
• As a company, we tend to hire entry-level developers out of boot camps. This gives them an opportunity for to grow and a chance for us to build them into the person that we really need. Engineers at that point in their career often have nothing on their resumes to distinguish themselves from each other, so I look for ones who value clear communication and thoughtful listening. Coding is, after all, a form of communication.