The Silo-d Approach

In my experience, one of the biggest challenges organizations face is the issue of silos. Teams and departments naturally pull in different directions, which can make collaboration difficult. Bridging silos requires understanding the relationships between them. For instance:

  • IT and Accounting: Bridging silos between fundamentally different functions is inherently challenging.
  • Engineering and Operations: These silos, being closer in scope and purpose, are easier to connect.
  • Intra-team silos: Resolving silos within the same team should be straightforward and non-negotiable.

A Lesson from the Past: Show a Willingness to Help or A Little Gas Money goes a Long Way

Here’s a story from my time at GTE Data Services (the technical division of GTE in Temple Terrace, FL). I was promoted to Technical Lead and Manager, supporting the commercial side of GTE, headquartered in Tampa.

One of the first things I did was take my team on a short 30-minute drive to meet our clients face-to-face. We didn’t discuss technical details; instead, we simply asked how we could better assist them and understand their challenges.

When we returned, the director of the data center met us at the door, thrilled. He told us, “They just called and said they’d never seen anything like that.”

What stood out wasn’t any technical solution but our willingness to connect and help. That small gesture of driving over to meet them had far more value than spending hours solving a technical issue.

The Challenge: Recognizing Workable Boundaries

To break down silos, it’s essential to recognize the nature of the boundaries:

  • IT and Accounting: These silos are difficult to bridge and require significant effort and empathy.
  • Engineering and Operations: These are easier to resolve due to shared goals and overlap in workflows.
  • Team-level silos: These must be resolved immediately, as collaboration within a team is foundational.

Resolving Team-Level Silos

The primary issue with team-level silos is that work continuity is disrupted when a siloed team member is unavailable. This creates delays and inefficiencies that can impact the entire team’s productivity.

Challenges

  1. “We’re too busy to share knowledge.”
    Teams often feel they lack the time to document processes or cross-train because of immediate demands.
  2. “If I share my knowledge, I lose my value.”
    Some team members fear losing their importance or unique expertise by sharing information.

Solution

To address these challenges:

  • Mandatory Documentation: Require team members to document fundamental tasks and resolutions for recurring issues. This ensures critical work can continue smoothly in their absence.
  • Define Roles Clearly: While documentation covers routine work, the original team member retains ownership of resolving more complex, technical problems.

Resolving Silos Between IT and Accounting, Engineering and Operations

For bridging silos between distinct functions or departments, I apply a consistent approach to foster collaboration:

  1. Listen First: When contacted by someone outside my team, I focus on understanding their issue. I respond in the same way they reached out, whether through email or a call, to ensure clarity and connection.
  2. Provide Initial Help: If the issue persists, I offer simple, actionable technical documentation to address their need. In most cases, this resolves the problem.
  3. Gauge Commitment: If they reach out again with the same issue, I refer them to the original documentation. At this point, I observe whether they are making a reciprocal effort to solve the problem.
    • If they show progress and commitment to solving the issue, I match their effort by dedicating time to collaborate further.
    • If they repeatedly ask the same questions without demonstrating effort, I step back, as the process requires mutual commitment.

By fostering a willingness to help while expecting accountability, this approach ensures that collaboration is efficient and constructive.

Leadership from Behind

With over 25 years in technology, I’ve managed multiple teams across Fortune 500 companies. While I wasn’t always in an official leadership role, my breadth of experience often positioned me as a subject matter expert across various technical domains.

Navigating corporate environments can be challenging, especially in cultures that emphasize competition over collaboration. Yet, true, sustainable success relies on cooperation. I remember a senior leader once thanked me for always helping my team, but then added, “All you have to do to succeed here is to be better than your peers.” She quickly climbed the corporate ladder, yet the department continued to struggle with the same issues. This led me to adopt a different approach: Leadership from Behind.

My strategy isn’t just about my expertise; it’s also about sharing it. Experience naturally leads to knowledge, but in companies where collaboration is undervalued, fostering this knowledge can be difficult. Nevertheless, I’ve seen my approach yield positive results, even leading to official leadership opportunities.

I aim not only to help colleagues but also to educate them through my experience. Here’s a typical scenario:

“Garland, I was told to reach out to you regarding such and such.”

“How can I help?”

I don’t just troubleshoot or resolve the issue; I document the solution if I haven’t already done so. I believe the most vital skill for an engineer is a commitment to the written word. In today’s world, where texting often replaces in-depth communication, few people take the time to read. Frequently, colleagues return with the same questions, hoping I’ll fix the problem again, but I refer them back to the documentation. (Teach a person to fish, and they’ll eat for a lifetime.)

When I join a new environment, I establish a central repository for all technical documentation, if one doesn’t exist already.


Technical Leadership

In formal leadership roles, I believe a technical leader’s purpose is to educate and empower their team. I begin by setting up communication protocols that define how the team operates. I encourage team members to be versatile, ensuring everyone is familiar with the full spectrum of responsibilities rather than working in silos. This way, the team’s progress doesn’t depend on the availability of a single individual.

By fostering knowledge-sharing and collaboration, I believe we can create resilient teams that are both innovative and prepared to handle any challenge.

Here’s a Good One: Empowering Your Team

While working at IBM, I managed a team of AIX System Administrators with diverse skills and personalities. One standout member was a self-taught programmer—confident, resourceful, and passionate about solving problems. He’d spend his days at work troubleshooting and likely spent many nights honing his skills at home. He was, without a doubt, talented.

Often, he would come into my office to report an issue with the system. I’d typically resolve the problem in about five minutes. This became a routine.

One day, I noticed him walking toward my office, but then he stopped, turned around, and left without saying anything. A few hours later, he returned with a smile on his face and said, “I figured it out.”

Curious, I asked, “What did you figure out?” He showed me the solution and then added, “I wasn’t about to walk in here and have you figure it out in five minutes again.”

That moment was pivotal. It showed he was motivated to stretch his abilities, solve problems independently, and take ownership of his growth. This was precisely the mindset I wanted to cultivate within the team—confidence, persistence, and self-reliance.

Empowering team members doesn’t always require formal training or instruction. Sometimes, giving them the space to rise to challenges is enough to inspire growth and innovation.