Building the Future in 2013: Why I Pushed for SharePoint Before It Was Ready

In the summer of 2014, I recommended that Crisis Response Force teams adopt a SharePoint portal for real-time collaboration and intelligence sharing. The technology had launched two years earlier but was still rough around the edges. People thought I was pushing for a solution to a problem we didn't have, using technology that wasn't ready.

Three years later, in 2017, they built it. A decade later, it's still how they operate.

This is a story about seeing around corners, pushing for solutions before organizations are ready to adopt them, and planting seeds that bear fruit long after you've moved on.

The Problem: Fragmented Intelligence in High-Stakes Decisions

From December 2013 to December 2016, I served as an instructor at EOD Training and Evaluation Unit One in San Diego, specializing in training Crisis Response Force teams. These elite units were designed to be regional commanders' first eyes on potential weapons of mass destruction, determining whether Tier 1 assets needed to be deployed.

When a CRF team responded to a potential WMD event, the stakes were extraordinary. Their reports would be read by the President and every level of leadership in between. Decisions about resource deployment, diplomatic engagement, and threat assessment would be made based on the intelligence these teams provided.

But there was a fundamental problem with how that intelligence was being shared and consumed.

Three Clients, Three Standards, Zero Alignment

The CRF capability served three distinct Tier 1 units: one specialized team within the FBI and two Department of Defense units. I can't name them specifically, but each was among the most elite operational forces in the U.S. government.

Each unit had its own reporting preferences. They wanted information in different formats, different sequences, with different levels of detail. Each believed their approach was superior, shaped by their unique operational requirements and organizational culture.

Worse, individual teams within each unit wanted their own variations. It wasn't just three different standards. It was three standards plus multiple sub-variations, all competing for primacy.

For CRF teams in the field, this created an impossible situation. Which format do you use when multiple stakeholders are waiting for your assessment? How do you satisfy competing requirements without spending hours on report formatting instead of threat analysis?

For strategic decision-makers, the fragmentation made it difficult to quickly assess situations or compare responses across different incidents. There was no standardized baseline they could rely on.

Solution Part 1: The 30/60-Minute Framework

Working with stakeholders from all three Tier 1 units, I facilitated a series of conversations to identify common ground. What information did everyone need? When did they need it? What could be standardized without forcing everyone into an identical process?

We analyzed the overlapping requirements and discovered something valuable. Despite their different preferences, all three units needed approximately the same baseline information to make initial assessments. The differences emerged in the follow-up details and presentation format.

We created a tiered reporting structure:

30-minute mark: Baseline critical information delivered in a standardized format. Location, threat type, immediate hazard assessment, and recommended actions. Enough for strategic leadership to understand the situation and begin coordinating resources.

60-minute mark: An expanded report providing 80% of what all three Tier 1 units required. This included more detailed technical analysis, environmental factors, and operational considerations.

Beyond 60 minutes: Units could request additional specific information tailored to their unique requirements.

This wasn't about forcing uniformity. It was about creating a foundation that satisfied the majority of requirements quickly, then allowing flexibility for specialized needs. The 30/60-minute framework became the standard for CRF reporting.

But as we implemented this system, I recognized a deeper problem.

Solution Part 2: Real-Time Collaboration for Distributed Teams

Even with standardized reports, the distribution mechanism was broken. Teams were sending information via email. Updates required new email threads. Clarifying questions spawned additional messages. Strategic decision-makers were trying to assemble a complete picture by reading through email chains while the situation evolved.

There was no centralized location where all stakeholders could see the latest information simultaneously. No efficient way for distributed teams to collaborate in real time. No clear record of what information had been shared, when, and to whom.

In 2013, I had recently learned about SharePoint Online. Microsoft had launched it in 2011 as part of Office 365, positioning it as a cloud-based collaboration platform. The concept was compelling: a centralized portal where teams could share documents, track versions, maintain real-time updates, and collaborate without endless email threads.

But the technology was still immature. The interface was clunky. Performance was inconsistent. Integration with other systems was limited. Most importantly, the military and intelligence communities were deeply skeptical of cloud-based platforms for sensitive information.

I recommended building a dedicated SharePoint portal anyway.

The Vision: Before the Technology Was Ready

The recommendation was straightforward: create a secure SharePoint environment where CRF teams could upload reports, intelligence updates, and situational assessments. All key stakeholders from the three Tier 1 units, strategic leadership, and supporting agencies would have appropriate access levels to view, comment, and collaborate in real time.

Instead of emailing reports to distribution lists, teams would update the portal. Instead of reading email threads to find the latest information, decision-makers would log into a single location. Instead of wondering whether everyone had the same information, there would be one authoritative source.

The resistance was immediate and multifaceted.

Technical concerns: How would we ensure reliable bandwidth in deployed environments where connectivity could be limited or intermittent? SharePoint required constant internet access. What happens when teams are operating in areas with poor infrastructure?

Usability concerns: How would we make the interface intuitive enough for operators under stress? SharePoint's learning curve was steep even in ideal conditions. Asking someone to navigate a complex platform while managing a potential WMD incident seemed unrealistic.

Security concerns: Could we trust a cloud-based platform with sensitive intelligence? What were the risks of centralized data storage? How would we manage access controls and prevent unauthorized disclosure?

Cultural concerns: People were comfortable with email. It worked. Why introduce complexity and risk to solve a problem that didn't feel urgent?

These weren't unreasonable objections. The technology genuinely wasn't ready for the use case I was proposing. I was advocating for a solution before the infrastructure, usability, and security frameworks had matured to support it.

Planting Seeds for Future Harvest

I couldn't force the issue. I had no authority over the CRF program at the strategic level. My role was as an instructor focused on training delivery, not technology infrastructure.

But I kept advocating. I documented the collaboration problems we were experiencing. I showed examples of how distributed teams were struggling to maintain shared situational awareness. I pointed to emerging commercial uses of SharePoint and similar platforms as evidence that the technology would mature and become more viable.

I wrote the recommendation into after-action reports. I raised it in stakeholder meetings. I made it part of the conversation even when I knew immediate implementation was unlikely.

Then I moved on to other duties and other assignments. The recommendation sat in the institutional knowledge base, neither approved nor rejected, waiting for conditions to change.

Three Years Later: The Future Arrived

In 2016, after I had left instructor duty, the SharePoint portal was implemented. The technology had matured. Security frameworks had evolved to address cloud-based collaboration in sensitive environments. Usability had improved. Most importantly, the organization had experienced enough pain from fragmented communication that the need became undeniable.

The portal became the standard mechanism for CRF intelligence sharing and collaboration. It wasn't exactly what I had envisioned in 2013, shaped by three years of technological advancement and organizational learning. But the core concept was the same: a centralized, real-time collaboration platform replacing fragmented email distribution.

Nearly a decade later, it's still how they operate. The specifics have evolved with technology, but the fundamental shift from email-based distribution to centralized collaboration platforms has become embedded in the operational culture.

The Broader Lesson: Leading from the Future

There's a particular kind of leadership that doesn't get much recognition: advocating for solutions before the organization is ready to adopt them.

It's not the same as being visionary. Visionaries imagine entirely new possibilities. I wasn't imagining anything radical. SharePoint existed. Other organizations were using collaboration platforms. I was simply recognizing that a commercially available technology could solve a specific problem we were experiencing.

The leadership challenge was timing. The technology existed but wasn't mature enough. The problem existed but wasn't painful enough. The organization knew change would eventually be necessary but wasn't ready to prioritize it.

In that gap between "this will matter eventually" and "this matters now," most people stay silent. Why spend political capital advocating for something that won't be implemented? Why risk being seen as pushing impractical ideas?

But someone has to plant the seeds. Someone has to introduce the concept, document the need, and keep it in the conversation so that when conditions change, the organization doesn't have to start from zero.

Civilian Translation

Every organization has a version of this story: someone who recommended a technology, a process, or a structural change years before it was adopted — and who received no credit when it was finally implemented.

The difference between "ahead of your time" and "a poor communicator" is usually documentation and persistence. I documented the recommendation, built the case, kept it in the conversation through multiple leadership cycles, and moved on without ownership. Three years later, it was built by people who may not have known I was involved.

In business, this looks like: advocating for a platform migration before the pain is bad enough to justify it. Recommending a market move before the data fully supports it. Pushing for an organizational structure change before the current structure has visibly broken. In each case, the timing is wrong but the direction is right.

The skill isn't prediction. It's persistence with documentation. Recommend it, record it, revisit it. The organizations where that kind of long-horizon thinking is valued — and credited — are the ones that actually build institutional capability rather than just institutional inertia.

The Takeaway: Your Timeline Isn't the Organization's Timeline

I recommended SharePoint in 2013. It was implemented in 2016. I had moved on by then and received no credit for the implementation. The people who built the portal probably didn't know I had advocated for it years earlier.

That's exactly how it should work.

Organizational change rarely happens on the timeline of the person who first proposes it. The gap between recognizing a need and implementing a solution can span years. Technologies mature. Leadership changes. Budgets fluctuate. Pain points intensify.

If you're only willing to advocate for changes you'll personally implement and receive credit for, you'll miss most opportunities to drive lasting impact.

The question isn't "Will I get credit?" It's "Will this make the organization more effective?" If the answer is yes, plant the seed. Document the recommendation. Make the case even if implementation is years away.

Some of your best work will bear fruit long after you've moved on, benefiting people who will never know your name. That's not a failure of leadership. That's the ultimate expression of it.

In my next role, I'm looking for organizations that value this kind of forward thinking: identifying future needs before they become crises, advocating for solutions before they're convenient, and building institutional capabilities that outlast individual tenures.