Debacle Prevention

Here’s a daunting question: 

Why do most technology projects end up as complete debacles?

It never starts out that way. A highly qualified expert firm or consultant is brought in. Staff and leadership get seated around the table. Budgets are allocated. Optimistic kickoff meetings are held, with reassuring powerpoints and timeline charts. Months of meetings are scheduled. Projects are managed.

Yet somehow, reliably, the result is disappointing if not disastrous. And it’s usually a catastrophic waste of time and money. Whether it’s an outright debacle or a mishmash of partial victories, it’s a tragic missed opportunity to harness the game-changing potential that was envisioned in the first place. 

This just isn’t right. You’re doing mission-oriented, heroic work. Technology should be supercharging you, not pulling you backwards.

So how can this be prevented? 

The answer is simple but profound. It’s about consistent, detailed, strategic ownership and leadership, inside the organization’s walls. That is the business of debacle prevention. 

And what does ownership really mean? It means someone who is paying attention to every single detail. Who is constantly making strategic and tactical adjustments. Who is seeing the project through from all angles, all day, every day. 

It means having access to, communication with, and mutual respect from leadership and staff around the organization. It means knowing what to outsource and what to insource. It means constantly prioritizing and re-prioritizing based on the most updated landscape. It’s knowing which deadlines are real, and when it makes sense to extend timeline or cost restrictions in exchange for a game-saving fix or a game-changing upgrade.

That kind of internal ownership and leadership is the real gamechanger. You can have the best external consultants in the world, and they won’t deliver on your project’s potential if no one at your organization is playing close, daily attention. How could an external firm ever possibly fill that role? 

You, as an organization, must have or develop people -- thoughtful, skillful people -- who are empowered to understand and guide the direction of development, and whose role it is to guide these processes persistently and patiently until they are completely landed. With massive amounts of flexibility, humility, and caring. 

It’s a serious endeavor and there’s no quick fix, but it is most certainly possible. It takes time, money, care, and a steadfast commitment to an entirely new way of doing things. One that refuses to accept further debacles as a given, or even an option.

Expect More

“Ugh, I hate technology.”

How often do we hear this? How often do we say this?

It’s almost a given, something we can share an eyeroll about at the coffee machine. Most of us almost expect to struggle with technology. 

Can we really afford that expectation? Technology is probably at the very center of how we effectively deliver, track, and measure our programs these days. 

Imagine being a race car driver with an engine that is malfunctioning and slowing you down. And imagine that you just accepted that as normal and kept trying to race.

We can no longer afford to expect -- and allow -- our technology to be subpar. The first step to building and managing an effective technology landscape is raising our expectations.

Consider this simple statement: 

Your organization’s technology should work, and it should provide you value.

Can you say that about your organization? It’s not too much to ask. Let’s stop viewing dysfunction as normal. Let’s start expecting more, and putting in the work to make it happen.

You Need a Product Team

We’ve reached an era where high-quality technology offers unprecedented ability to superpower work and increase overall effectiveness. But the only way for technology to thrive is with a specialized, holistic and ongoing focus. Without that, organizations predictably lurch from debacle to debacle, with technology as a hindrance to their effectiveness rather than a supercharger.

A product team uses methods of “product management” that have solidly emerged as best practices in the tech world. At its heart it recognizes two simple ideas: We now have a new layer of technology “products” to manage (such as website platforms and databases), and those products require a dedicated, internal team with the clear mission of strategically driving and guiding your investments in those products. 

Let’s take a common example. Say you engaged a firm to set up a new CRM for you. They gathered requirements, customized the database, and even did a couple trainings for your staff. They probably did a solid job of it. So as time goes on why does the system reliably get more frustrating instead of less?

It’s because platforms such as CRMs can go any direction you need them to. This is an incredible strength and a potential game-changer for your efficiency and overall workflow. But developing a roadmap for them requires careful, thoughtful, dedicated management and stewardship, inside your organization’s walls.

So when that new CRM is launched, a product team recognizes that moment not as the finish line, but as the starting line. Their job is to make sure everyone knows how to use that system, and to constantly be on the lookout for potential improvements, and to manage and resolve competing priorities, and to be generally in a never-ending quest for increased efficiency and improvement. They are your organization’s dream team of technology problem-solvers, turbochargers, and fairy godmothers, constantly swooping in to make everything better.

But getting there means admitting that it simply doesn’t work to ask other types of staff to manage technology off the sides of their desks. Nor does it work to just outsource everything tech-related, or to ignore our technology altogether because everyone is too busy trying to do their “other” jobs. We need skilled people in place whose job it is to ensure your technology is fully aligned with what you’re trying to accomplish and creates the high quality experience you want to deliver.

The good news is, the product team structure is actually not that complicated or that hard to implement, and it scales way up and way down. Perhaps counterintuitively, we’re not talking about hiring a bunch of highly skilled coders and developers. It’s much more about dedicated internal staff whose job is to deeply understand the business needs and the way the technology will meet those needs. 

So at its most basic, a product team consists of a “product manager” for each of your essential tech platforms, with clear processes and principles to guide their work. You also likely need a chief to help guide and direct, and to sit at the executive table to strategize, give real time assessments of what’s possible when, and help navigate priorities and capacity in harmony with the rest of the organization.

If you are larger, there will be more demands on your product team, and you are wise to invest further in product staff so they that can focus their energies on the force-multiplying effects of products that are well considered, well architected, well tested, and well explained throughout your staff. 

You likely even have some of the necessary talent inside of your organization already, whether you realize it or not. Notably, the product manager role is more of a tech strategy role than anything very technical, so you’re still working with external specialists when it comes to specialized work such as designing and developing. 

Fundamentally, the product team represents the acknowledgement that, among a landscape of many things that can be outsourced, you simply cannot afford to outsource the brains of your technology operation. Your technology backbone is too essential and too unique to your organization, and a cookie cutter approach won’t get the job done.

Of course, change can be hard. In many cases this is an entirely updated way of thinking and working, and it may cause some friction for people who are attached to the old way. But once an organization implements a product approach, it can be hard for them to understand how they ever survived without it. 

You Don't Want a Treasure Map

People often seem to wish that technology could be an afterthought. Isn’t there a pill they can take so the headache goes away? Or a consultant who can just take care of it? Can’t someone just give me a treasure map with an "X" showing where I should dig?

But in reality you don’t want a treasure map. You want your own team of ace treasure hunters.

Why? Because a treasure map assumes that the treasure will remain in a specific place, and the path to get there will look the same tomorrow as it does today. That may be the case for buried treasure. But in the case of technology, neither of those assumptions are true. Your treasure is constantly moving, and the landscape around it is constantly changing. So the treasure map you create today is almost guaranteed to miss the mark within even a few months. And if the map is all you've got, then you're stuck.

What you actually need is your own team of treasure hunters, strategic and skilled enough to assess and reassess the terrain as your journey evolves. A leader who can take in the landscape, your team's skills and supplies, your organization's restrictions and priorities along the way, and adjust those priorities and destinations appropriately. A skilled team that can communicate and manage and execute and delegate. That's how you'll reach your next destination safely, and the destination after that, and the one after that.

An over-simplified treasure map handed to you may seem like an attractive option, especially since the investment to get there is relatively limited. But in reality it's a cheap shortcut to the real work of building internal capacity and self reliance. And it's wildly inadequate insurance against the changes guaranteed to come. The only reliable insurance is skilled guidance and stewardship that you're confident can adjust to the ever-changing road ahead.

Continuous Investment and Smiley Faces

An organization decides it’s time for a new website. All of the stakeholders get involved, bring in a skilled external firm, and together they figure out the strategy, content, messaging, and style.

The site then launches to great fanfare, and everyone loves it. On day one it’s the bold new face of the organization.

But if you check back in one year later, the grumbling has started. By Year 3, everyone talks about how terrible the website is. And by Year 5 it’s universally considered a complete embarrassment. So it is torn down and rebuilt from scratch. 

And the cycle repeats itself.

The same could be said for almost any digital product. In fact, it's a cycle we’ve all gotten so accustomed to, it can be hard to remember how broken it is. 

We got to wondering why this kept happening. Why, in Year 3 or 5, did everyone hate the exact same website that they loved on day one? Why did everyone’s opinion change when nothing about the site had changed?

Of course, that's the very problem. Five years after it launched, nothing about the site had changed.

Meanwhile the entire world had changed around it. The organization changed and their needs for a website had changed. Website styles had changed, so a five year old ago site looked hopelessly dated. The technology underneath it had changed, from platforms to security and speed. The expectations of users and accepted standards of the internet had changed. 

And all the while the site was stuck in the ancient world it was created in, even just five years ago.

Consider what an atrociously bad return on investment this is, for something as essential in this day and age as your website. Notice how briefly you’re in the green smiley face zone. In other words, despite all of the money and effort spent, your site is delivering on its potential for a miniscule amount of its lifecycle. 

---

By contrast, what does a product-centered, ongoing-investment approach look like? 

Well, you still have to spend the time and money to build a site in the first place. But importantly, that becomes the starting line rather than the finish line. Once the product is built you continue paying attention and investing on an ongoing basis. You admit that the site needs to continue to evolve in order to stay relevant, useful, and effective. But with that cycle of continuous investment, you manage to keep everything in strong working order.

Behold the profusion of green smiley faces.

Yes, that cycle goes on forever. And yes, it costs money. But look at the comparative return on investment. You are devoting the focus and resources required for the product to deliver on its promise, to be effective for your staff, your constituency, and for delivering on your mission.

And what could possibly be a better investment than that.
 

You're a Tech Company

Lyft and Uber are tech companies. That's obvious, right?

But are they really? What do Lyft and Uber really do? They’re taxi services, shuttling people in cars from one location to another. What’s so tech about that?

The answer is that their entire business depends on the consistent, high-quality function of a technology product. If their apps and systems don’t function consistently, at a high level, the whole thing falls apart. If they’re not constantly paying attention to what is working well and what needs to be improved, they will fall behind.

We would argue the same is true nowadays for just about every organization or business of any kind. What modern-day mission can be realistically accomplished without the high quality function of a technology backbone?

And guess what tech companies do that we all need to be doing? They care enough about tech to resource it with a robust team of smart people. It doesn’t happen by itself. 

Whatever you do nowadays, you’re also a tech company. Let's admit that, and then put good people on delivering it.

Building Rocketships

If you’re harnessing the opportunities that technology truly offers, it's not just about barely surviving. It's about raising your game to new levels where your technology starts to enable your organization to transform itself on a regular basis. 

Your staff is spotting efficiencies, grasping unseen opportunities, testing new ideas, optimizing, experimenting, and learning. That’s the real north star. That is when your organization’s technology is no longer about trying to fix leaky pipes. 

When you build a culture of smart technology, you’re building your organization a rocketship.

Once you’ve seen this potential, you realize there are corners you should never cut.

What’s the purpose of a rocketship? To get you somewhere ambitious, to carry out your mission, and to come back alive. That’s true of your organization, too, isn’t it?

You don’t need gold plated gear shifters, you don’t need Corinthian leather seats, but you do need a thoughtfully architected, exactingly built ship, and every piece of essential functionality tested by highly capable staff for a thousand different conditions. 

If your systems and technology are really unimportant enough that you plan to outsource the whole thing, barely pay attention, cut budgets, limit staff time, or rush things that deserve careful attention, you might need to consider getting out of the space travel business. You won’t be able to compete. Maybe look into building a go-kart instead.

Otherwise, if you're looking to travel to grasp the unlimited opportunities of technology space travel, you need to invest seriously in the effort, and to pay serious attention at every step along the way. Be smart about your investments and leave those corners intact.

You Can't Delegate Caring

You’re an organizational leader. The demands are on you are high and the pace is fast. You simply must delegate things in order to survive, and for everything to get accomplished.

But one thing you cannot delegate is caring about your technology. Your organization, all the way to the top, has to care. It’s simply not good enough to say “I don’t really get technology, but you guys go ahead and take care of it.”

Why? Because your tuning out causes a ripple effect down through the organization that ultimately drains essential focus and resources from where it needs to be. Maintaining strong and high-quality technology is a detailed, never-ending process that demands constant vigilance and thoughtfulness, not to mention time and resources. If you communicate that you care about other priorities more, your organization will act accordingly.

But your technology has a fundamental, critical impact on your success. It’s what’s going to let your staff work faster and smarter. It’s going to offer you data on what’s working well and where improvements are needed. It’s going to be your arsenal for smart ways to engage your public. 

It’s your job to understand the strategy and knowledgeably help guide the possibilities. You need to understand the nature of your platforms enough to know -- at least on a high level -- what’s easy, what’s possible, what’s expensive, and what isn’t really viable right now. You simply have to understand where it stands and where it’s capable of going. You must care about it. 

You wouldn’t tune out when it comes to raising money, to strategic planning, to how your program is run, to selecting your board, to developing marketing campaigns, or to revising your branding and messaging. Of course not. Those things are too essential! 

If you stop to think about it, hopefully it becomes equally obvious that your technology is too essential to ignore as well. 

Organizations take on the character and priorities of their leadership. If you want your organization to care about technology in a detailed, robust enough way to be great at it, that level of caring starts at the top, and cannot be delegated.

Are We Too Small for This?

Does this product team model scale down for smaller organizations?

It's a fair question.

Here’s one way to look at it. Chances are that for an organization or company being founded today -- especially a startup run by younger entrepreneurs -- a technology leader is either a co-founder or the very first hire.

Why would that be? 

Because for people who have grown up around tech it’s intuitively obvious that technology will be an essential part of successfully delivering their impact or services. 

“Oh,” you say, “that doesn’t really apply to us. Our program happens entirely offline in the real world.” Are you sure it doesn’t apply? How do you track your program and constituents? Communicate with the public? Raise money? Evaluate your effectiveness?

When we talk about young entrepreneurs today, we’re not just talking about people who are creating apps. We’re talking about anyone in today’s landscape who is trying to do high quality work, optimize their effectiveness, and compete for hearts, minds, and eyeballs. 

So yes, the model scales down. All the way down to an org size of one or two.

If you look at your smaller-size organization with fresh eyes, what’s the maximum size of a team you can really justify before you include a skilled technology leader in the mix? 

Three? Maybe four? Seven? 

Are you sure about that?  
 

Clear the Haters

If you have one job as an organizational leader to ensure the success of your technology, it's to care about it. If you're allocating time and resources, the things you care about in your organization get focus, resources, oxygen, accountability, and the opportunity to thrive.

But if you have a second priority, it may just be to put capable people on the job, and then to clear the obstructions out of their path.

It's true, we've worked with several organizations where there weren’t people blocking forward progress, and it was great. When everyone is ready to be open-minded about new, more efficient and effective ways of working, ready to bring thoughtfulness and humility to the table in search of better adjustments every day… what a powerful culture can be quickly created.

But sometimes, for whatever combination of reasons both understandable and mysterious, you can encounter people who perceive certain types of progress as a threat and seem to devote themselves to undermining their colleagues who are working towards it.

All manner of efforts should be made to get such people on board and to hear out their concerns. In most cases, people come around when there is enough communication, or when they get some initial exposure to a better way of working and start to feel the benefits. Or when they realize the threat they initially perceived isn't coming to pass.

But sometimes such people don't come around. And here's the thing. As a leader of the organization it's not enough to simply chalk it up to a "disagreement" or a clash of personalities or styles. You're in your seat for a reason. You're the judge and jury, and the justice system only works if you play your role and give the situation a fair trial. It's up to you to dig in, hear the arguments, and put your finger on the scale in the direction that makes the most sense for the organization.

And when you do that, you'll be in a position to establish a clear mandate heard by all. You'll be able to make clear that it's time for people to get on board. That there is space for everyone who is focused on being part of productive solutions, but there is no place for people to cling to outdated and wasteful models of working that squander precious resources and opportunity. 

You're the leader. You want an organization that can compete in an ever-more demanding landscape. That functions a little bit better every day than it did the day before. Let reason win the day, and clear the path for the people on your team who are fighting for a better tomorrow.

There's a New Layer in Town

You might ask, “Why do we suddenly need new staff on hand to steer our ship of technology? We’ve been using software applications for years. Our IT people handle that.”

But in fact, we’re not talking about software applications anymore, nor traditional IT. There is a new layer of technology in play now -- the platform layer.

So what is the difference between an application and a platform? 

As you probably know from using applications on your phone or computer, an application is pre-built for a specific use. Listen to music. Scan your receipts. Edit your photos. Microsoft Word is an application. It does what it does. Pull it up, type up a document.

A platform, however, is a toolset that you can use to custom-build an application that fits you perfectly. It can do pretty much anything you want it to do, but you have to decide exactly what that is. It's kind of like a Lego set. You can build a house with it, or a boat, or a robot. You have to decide what you need, and then build it around those needs. Same goes for building your platforms around your organization’s unique processes.

Good examples of platforms in wide use these include a CMS (content management system) for a website such as WordPress or Drupal, or a CRM (constituent relationship management) database such as Salesforce.

These platforms give us amazing new potential to do things better, work more efficiently, be more in control of our communications, stop siloing information, get smarter analysis because all your data is in one place, and banish shadow systems that were a necessity before, removing constraints left and right. 

But with this new power comes a new responsibility. It requires a new core competence within your organization, a new type of management, in order to steer the development of those platforms. Developing, maintaining, and managing the product roadmap is the core responsibility of the product team in general, and of the product manager specifically.

Why? Because, a thoughtful, carefully considered roadmap is what brings sanity to the wild west of technology opportunity. Development of your platform could go any which way, but chances are you have limits on your capacity and resources. Meanwhile you have a mixture of urgent fixes, exciting opportunities, and new experiments that all need their oxygen and focus.

Without a roadmap -- and the entire ecosystem that goes into generating it -- you’re stuck in reactive mode, and you risk going everywhere and nowhere. You can end up wasting your resources on relatively lower priorities, or overlooking big opportunities, or confusing and frustrating staff who are waiting on essential fixes to get their work done smarter and better.

There is a new layer in town. A powerful, exciting new layer. Now it’s time to get yourself some new sheriffs in town who are up to the task of managing it.

A Stripe in Your Org Chart

A technology accelerator team should be its own department — its own stripe in the org chart. Critical problems get introduced when the team lives under a “service” oriented department like Operations, or a specific purpose-oriented team such as Fundraising, Communications, or Programs. And it must not be mixed with I.T., which is a separate area requiring separate skills and expertise.

That said, it’s common in many organizations to find technology platforms living under something like one of those other departments. 

This is typically for understandable reasons. Most often, an organization’s investments in technology platforms such as web or CRM were driven by a single department getting fed up enough with the dysfunctional state of their technology systems that they decide they’re going to just fix it themselves. A Communications department finds itself in daily pain from their lackluster, outdated website, or a fundraising team is driven to utter exasperation by their lack of a coherent CRM to track relationships. So they muster the internal political will, secure a major budget allocation, find a development firm, and go through a painstaking process to build a new site, or adopt a new platform. They probably weren’t thrilled to be the ones doing it, and the results may be mixed, but afterwards at least it’s not as bad as it was before.

Then, understandably, that department intently guards that system going forward, protecting their territory against all who they fear might mess everything up again. They become the de facto owners and guardians. “You have no idea what we went through to even get this far,” they explain. “If you need something, you can ask us.”

But this fundamentally requires these departments to hold a core competency that is substantially outside their area of expertise. It’s too much to ask that a communications department be able to do web product management at the level a modern organization needs, or that a fundraising team include specialized CRM product management skillsets. Rather, if the organization is set up right, everyone should get to focus on their areas of expertise.

In addition, in today’s world, your technology platforms need to serve every department well, not just the one department that got frustrated enough to initiate that platform’s temporary renewal. A successful website must provide critical daily value and address high priority needs for departments across the organization. A CRM’s transformational potential lies in its ability to connect and track different areas across the organization’s work.

Planning, building, and continuously maintaining that level of strategic focus and technical quality is an extremely advanced undertaking! It simply can’t be done from within one specific ‘purpose-built’ department. And even when attempted at a much lower level of ambition, it pulls that department farther out of position, and makes it extremely difficult to do the critical work of prioritizing needs accurately across the organization.

Set up right, your Technology Accelerator Team is a make-everything-better team with a voracious appetite for improving everything around it. Allocating an independent department gives this team of crack improvers and problem-solvers the ability to bring their specialized, focused, strategic and tactical skillsets to bear working with teams across the organization, unencumbered by common structural limitations that otherwise hold them back. It allows them to fairly and strategically prioritize positive impacts across every part of the organization, and help transition your organization to a new level of technology proficiency. 

This is Not Traditional I.T.

There is an important distinction between Products and I.T.

Remember that the Product Team is responsible for technology systems and tools -- such as the CRM and website -- that could potentially go any direction. Thus they require a smart, informed roadmap to ensure their development matches the organization's priorities.

By contrast, in our view I.T. is a more of an operations function. It focuses on technology systems that may be complex, but generally don't require the creation of a roadmap. As an oversimplification, your IT systems either work or they don't. 

Examples of internal I.T. functions include purchasing and setting up computers, networks and internet access, software and installation, email accounts administration (such as Google Apps for Work), password management, web domain registration and accounts, web hosting accounts, and all technology-related billing and payment.

The Product Team must not be pulled into I.T. roles, even if they seem to be more "tech savvy" than other people in the organization. Otherwise the I.T. workload will quickly overwhelm the product team's ability to do their primary jobs. Eyes will be taken off the ball, and crucial balls will be dropped. This defeats the entire purpose and mandate of the team!

Fortunately, a viable I.T. option for some organizations are external tech support providers, to whom you can outsource much of the basic I.T. support, such as issues involving computers, software, printers, networks, internet, and advanced tech support.

That way you keep your product team's eyes on the prize where it belongs.
 

Two Great Reasons Not to Combine Digital Products and IT Operations

Don’t combine IT and Digital Products. Don’t do it. They are not the same thing. They require different people. They pull in different directions. Everyone loses.

That said, we have seen enough times that this can be a hard separation to pull the trigger on. So here are a couple great reasons to help you marshal your courage and build your case:

1. They have different superpowers

2. They require different mindsets and skillsets (and therefore different people!)

1. They Have Different Superpowers

• IT people make things work as they are supposed to work. 

• Product people are always thinking of new ways to make things better.

• The IT superpower is technical proficiency. 

• The Product superpower is context.

On the digital products side, perhaps the greatest superpower of an excellent product manager is the ability to fully immerse themselves in the organization — to dig into organizational goals, needs, complexities and strategies, to open communication channels, to build trusted relationships, and to understand everything there is to know about what the organization is trying to accomplish as it relates to their product. It means gathering several metric tons of information and context. That level of context is the product manager’s superpower and guiding light, towards wise short and long term priorities and investments.

Traditional IT Operations also has plenty of complexity. However it generally does not require the same level of context. Certainly IT needs to understand what the organization is trying to accomplish, and many parameters relevant to the tool or service they are installing or implementing. What activities will we be using our computers for? What speed and redundancy of our internet connectivity do we need? What is the likely trajectory of our server storage needs? How are we going to deal with digital security threats? 

But very likely, IT problems that arise do not require months of conversations and understanding to answer. They need technology specific expertise. But you don’t need to know every single thing about the organization’s strategy, programs, and key players in order to, say, get the internet working again, or select an appropriate email provider service or file sharing system, or to fix it when it goes down.

In fact, an external expert or service provider might very capably be able to solve most IT problems without knowing every detail about your organization‘s complex intersecting strategies, needs, and dynamics. If something operational is broken, it’s not ambiguous. It’s not doing what it’s supposed to do, and the solution is likely extremely similar for your organization as it would be for another organization using the same tool. It’s also not ambiguous when it’s fixed. “Call the Director, the system is back online!” and everyone goes to bed.

That is an entirely different profile than the work of digital products, where context and understanding are the superpower enabling the creation of an ever-evolving strategic and tactical roadmap — building a product that supports and superpowers everyone’s work, a little bit better every single day.

2. Different Mindsets and Skillsets Require Different People

Given this wholesale difference in approach and mandate, it should be no surprise that Digital Products and IT Operations require entirely different mindsets, skillsets, proficiencies, and personalities. If you’re trying to combine them under the same person or even the same team, you’re asking for one or the other to come up short. Generally, IT people have very little interest in digital products, and digital product people have very little interest in IT issues. They’re both typically very happy to hand off duties at the border.

When these duties are combined, both sides suffer, and priorities get dropped. The most common example of this we see is when the crucial long-term oriented strategic work of digital products gets crowded out by IT’s near-term fires with high urgency and importance, but of little concern to long-term strategic outcomes. “The printer isn’t working!” or “our computers have a virus!” are crises that tend to crowd out questions like “Is our website on a path to support the game-changing organizational plans we have for next year?”

When we’re hiring for digital product managers, more than a deeply technical profile we’re looking for strategic orientation and an exceptional level of communication and interpersonal skill along with an adequate level of technical literacy. Naturally, this is a skillset that cannot and must not be outsourced.

When it comes to IT operations, some organizations decide they need internal staff support, but others seem to feel well serviced by a solid external IT provider, a choice which we’re seeing with increasing frequency. Yes, you will still need to put a strategic internal brain on solving IT issues. But if you have a strong external IT partner, the strategic piece can often be provided by a strong manager of Operations, or the leader of the department with the specific need being addressed.

Great digital products, specifically, require a unique type of person, along with access to expert internal and external resources, and a whole lot of time and energy and thoughtfulness. Your organization’s success depends on getting the right people in those roles, and giving them the mandate and the room to run. Cram together this sacred responsibility with traditional IT operations work — with its very different set of priorities, responsibilities, and personality profile — at your peril.  But give digital products its own space, and the right type of strategic and tactical magic-makers, and watch as your organization shifts into an entirely new technology orbit.

You Can't Outsource The Brains

There are some things you can -- and probably should -- outsource. In most cases that could include high-skill execution tasks such as visual design and coding/development. In fact there are several significant advantages to outsourcing those roles.

But what you can never outsource is the brains of your technology operation.

Because the most important role your internal technology staff has is not actually technical. It’s strategic. It’s about understanding the strategic, programmatic, and operational priorities of your organization on one side of the equation, and on the other side masterfully conducting the symphony of forces that must be brought together to execute on those priorities.

Doing that successfully requires making countless decisions on a daily basis -- large, small, simple, and complex. It requires weighing options, balancing priorities vs. cost and capacity. It requires constant communication with colleagues and external resources. And it requires creating and constantly adjusting a clear, coherent product roadmap. It’s a massively complex production.

Can you imagine outsourcing that to a consultant? How would that possibly work? 

The answer, of course, is that it wouldn’t. And it doesn’t. If you’re going to leverage technology’s potential to support and transform your organization, the brains of your technology landscape must live inside of your organization’s walls.

Dishwashers Don't Need Roadmaps

We use the analogy of a dishwasher to help explain technology that we see as belonging under the purview of traditional I.T., as opposed to digital products. Traditional I.T. products, we say, are like dishwashers.

That’s no knock on traditional I.T., of course. Dishwashers are complicated enough underneath the hood that most of us don’t want to mess with the innerworkings. When the time comes to assemble or fix a dishwasher, you clearly want a specialist with skill and experience doing the work.

However, we also all know the basics of what a dishwasher is supposed to do. You have a few options to choose from, you add soap, you hit start. The dishwasher needs no roadmap for future development. For the rest of the dishwasher’s life it will perform the same functions it did on day one.

Generally speaking, the same can be said for traditional I.T. products such as hardware (like printers, laptops, routers), and for most consumer software as well. Sure, hardware may require occasional maintenance and upgrades, and require skilled expertise to get the most out of them. But a router is a router, it does what it does. Similarly, software like Microsoft Excel or Adobe Photoshop surely require training, skill and experience to be used effectively. But that said, they are what they are the moment you buy them.

By contrast, your website isn’t like that. Your database isn’t like that. They start out in one state, and if they have any hope of staying useful and relevant, they have to evolve constantly, from day one until day last. And complicating matters more, the possibilities for that evolution are endless. That’s why you need a roadmap for them, managed by a highly capable, strategic, detailed product manager.

And that’s why your digital products are out of place if they get lumped in with traditional I.T. by an undifferentiated categorization of “digital”. Traditional I.T. is a core backbone function, but it most often falls into Operations, and for good reason. Whereas your digital products are evolving, unique platforms that need to managed strategically to support and keep pace with your evolving needs. They each demand different skillsets to manage and steward, different lifecycles and levels of resources, and different types of access to leadership and strategy. Asking a single department to manage both is a fundamental misalignment, and a sure-fire recipe for underperformance.
 

The Delicious Alignment of Distributed Ownership (The Blue/Gold Divide)

Photo by Sindy Süßengut

Technologists are often put in charge of programs that they don’t have background for, simply because those programs are online or digital in nature. “Hey, you’re the website person, so we’re putting you in charge of this online fundraising campaign.”

Conversely, many people in non-technology roles commonly find themselves in mind-numbing technical conversations that they aren’t prepared for or interested in. Fundraisers who need new features on the website, for instance, might find themselves in meetings with developers about website platforms and security models. 

This happens because we’re not acknowledging that there are multiple highly distinct skill-sets required to successfully develop a technology product. 

Specifically, you need a key partnership between the technology-driven product owner, and the content-driven product user. We call this the distributed ownership model. 

That phrase -- distributed ownership -- can make some people nervous. “You can’t have shared ownership,” they protest. "The boss needs one butt to kick!”

But if we’re honest, the one butt system doesn’t work anyway. No fundraiser or communications staffer has the time to get fully up to speed on the range of possibilities offered by technology. No technologist has time to keep pace with the ever evolving strategic requirements of fundraising, not to mention communications and programs at the same time.

So if you give one person the whole job, they’re destined to fall behind. You have baked-in a fundamental misalignment of goals which creates frustration on both fronts.

However, the distributed ownership model presents a far more functional setup, where everyone can deliver on the pieces of work that make the most sense for them. The digital product owner owns and focuses on the intelligence and smooth function of the architecture and the primary user owns and focuses on the informed prioritization of the functionality that will serve their needs.

So where you once had misaligned roles that created frustration on all sides, the distributed ownership model presents a far more functional setup, where everyone can deliver on the pieces of work that make the most sense for them.

In fact once it’s up and running, it can be hard for people to imagine they ever did it without these roles. An upcoming post ("Flight of the Bumblebee") shows a great example of this in action.

Everyone Likes to Geek Out On Something

There is a divide. We call it the gold/blue divide. And it’s really important. 

Some people (namely the product team, which we informally refer to as the blue team) love to geek out on building, improving, and optimizing the living stuffing out of a tool. Give them a problem or an issue with the system, and they love to dig into it, craft some options for how to solve it, compare money and timeline implications, and laser in on the strategic costs and benefits of the possible paths ahead.

Other people (the gold team, informally) would much prefer to spend their time using that tool in service of the strategic objectives of their work — be it programs, fundraising, communications, or anything else. They know the tools are critically important for them to deliver on their work. And they are the de facto experts in what is working with the tool, what needs to be fixed, and what new features might supercharge what they're trying to accomplish. But they have little to no interest in spending hours with developers and designers or working through detailed underlying complexities. They have ideas and strategic direction and they'd love for someone they trust to figure out the how of it.

It’s rare that the same person has the same appetite for both sides of the divide, but it’s excessively common for a person to be assigned to both sides. Management thinks, figure out how to email and then email, it makes sense to put those two things together! But does it? One is developing technology systems, and the other is writing compelling copy for a particular audience. What incredibly distinct skillsets they require.

These are both critically important roles and they must work together harmoniously in order for a product or system to be created and maintained at a high level. When we default to giving someone the full spectrum of both duties — which is the inevitable result without a defined distributed ownership structure — we're setting that person up to fail on one or both sides of the equation.

A great gold team tool user is passionate about the work being accomplished using the tool and constantly paying attention to ways it can be improved. A great blue team tool optimizer is driven to improve the tool to help her gold team counterparts grasp opportunities for greater efficiency or impact.

So that's the key underlying principle of the distributed ownership model: let people focus on their areas of interest and expertise. Let people geek out — productively — on the piece of the puzzle where they can make the most impact. And give people on both sides the trusted allies they need to move the ball forward.

When work is fun for the staff-person and productive for the organization, everyone benefits and you start to see the real superpowers emerge.
 

Flight of the Bumblebee

At a high level, this "Flight of the Bumblebee" diagram illustrates the beauty of the system working, when the blue team (tool optimizers) and the gold team (tool users) work in harmony:

View fullsize

Let's say the gold team person is a fundraiser, or a programs person. They're using the CRM or the website to accomplish parts of their work. Naturally this gold teamer periodically gets ideas about ways the tool can be improved in order to help them execute on their work more efficiently, strategically, or impactfully.

With the distributed ownership model in place, instead of this gold teamer having to try to figure out how to execute on this idea alone -- navigating the confusing world of developers and platforms and limitless technical options -- this gold teamer now knows exactly who to go to for help: the product manager on the product team. The blue teamer.

They sit down and have a conversation. Questions are asked, clarifications are sought, objectives are explained. And then the real beauty of this system happens. The product manager heads off onto the various complex and looping paths required to work through technology complexities, and the gold teamers go back to their work!!! They go back to fundraising, or communications, or programs. Which is exactly what they want to be doing, and what the organization wants them to do. They're spending their time working in their area of expertise.

At some point the parties come back together and discuss options. "Well," says the product manager, "we have three options. Let me explain the costs and benefits and let's figure out the best path from here." They have another productive meeting and decide on next steps. And then more magic: everyone goes back to focusing on their own area of expertise. The blue teamer problem geeks out on solving the technology problem and the gold teamer goes back to fundraising or communications or programs. 

The blue teamer, of course, continues to pull in the gold team colleague throughout the process, at each point where their subject matter domain knowledge is needed, and together they move the project forward hitting its strategic mark, each playing their essential part in the opera.

It's such a simple concept, but so profoundly helpful in practice. It's about putting everyone in a position where they know exactly where to go, can work together in service of the organization's objectives, and can spend their time focused on their areas of interest and expertise.
 

Alignment Dissolves Resistance

Concern about turf wars is natural, especially when you're accustomed to pervasive technology dysfunction. Often, turf around tech systems like the website CMS or the CRM database has been grabbed because of the frustration of systems working poorly and making people's jobs harder. Someone gets fed up, leads a temporary reclamation project, and thereafter holds onto their new turf for dear life. 

And yet, the frustrations persist. Why? Because it takes real expertise to do more than create stopgap solutions. Yes, you may ensure your contact list isn’t used by another team, but you don’t have the time to build a robust solution that gives you a 360 degree understanding of your contacts. So your contact is safe, but your understanding is incomplete. That would require coordination, collaboration, and trust, as well as an in depth understanding of the different technical options out there in the world and someone to wrangle all the data together. Who’s going to do all of that? Someone who’s already busy with another full-time job? Some external IT consultant clocking in every day with limited understanding and context about your organization?

When roles are well defined — when people get the support they need and digital products like the website and CMS start to hit a new trajectory of quality and utility — turfiness starts to dissipate. Give people a real ally who sits down and really listens to their key concerns… who understands their importance, and dedicates themselves protecting their data and their mission… who helps deliver better products for them to work with and improved processes for their team’s everyday use…. In that scenario people tend to happily come on board. Who wouldn't.

Better alignment is what the entire distributed ownership model is about, and what the entire product team approach is about. How can we find both larger structures and smaller interventions every day, where we can better align the structures and roles so that everyone has excitement and incentive about rowing in the same direction and making each other more effective?