Back to resources

Specialization vs. Wearing Many Hats

Internal Communication
Collaboration

23 November, 2021

William Bajzek
William Bajzek

Director of Engineering at Sapphire Digital

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Managing Different Timezones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

How Less Viable Solutions Solve Common Architectural Challenges

13 May

Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Architecture
Different Skillsets
Conflict Solving
Collaboration
Tom Hill

Tom Hill

Engineering Manager at Torii

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.