The Costs of Ignoring Your Problems
I get a bit antsy when I’m asked how much something will cost. It’s an important question, it deserves a solid answer. But somehow the question seems to frame things up in a misleading way….
Photo by Josh Appel
Formerly titled “It Costs More Than That”
Written by Chris Zezza
I get a bit antsy when I’m asked how much something will cost. It’s an important question, it deserves a solid answer. But somehow the question seems to frame things up in a misleading way.
The main problem is defining the “it” in how much will “it” cost.
It’s not that it’s hard to put on a cost on any given “it”. You want a website that can sell these products. You need a CRM to keep track of your donors. No problem. Those can be priced and built for the set price. Firms do it all the time. But it becomes precisely the problem.
What we think “it” is today, knowing what we know today, will change quite a bit by the time “it” is built. And “it” will reveal that you’re just scratching the surface of the potential to run your business better.
Stephen Covey talks about the difference between “Production” and “Production Capacity” (P vs. PC) and advocates a balance between the two. P is the golden egg, PC is the goose.
When most people talk about a website or a CRM or an app for their program, they’re thinking about a nice, shiny golden egg. When we hear someone needs one of these, if the organization is sufficiently complex and unique, we think: you need a goose.
Three Costs
There are three costs to consider when making the decision of how to go about your digital products or platform management.
The cost to do it right - finding geese capable of laying golden eggs, and giving them the environment and resources they need to consistently lay those eggs.
The cost of doing it wrong - getting the wrong kind of goose, depriving it of necessary nutrients, or distracting it with other duties.
The cost of not doing anything - letting inertia set your course.
The fact is, if you’ve been under-investing in stewarding your technology, you will likely underestimate the cost of doing it right. You will likely be surprised at what it might cost to get a team onboard that can get you on a path to continuous improvement and compounding benefits. But in almost every case, the cost of doing it right is far less than the cost of doing nothing or the cost of doing it wrong. These costs can show up in any number of ways:
Constituent Experience
What do your online interactions say about you? Are you confusing people? Does it garner trust or the opposite?
Are you losing attention of potentially interested people?
Are you maximizing the potential of volunteers, customers, and funders? Or are you leaving a ton of potential on the table?
Staff work
How much time is lost to inefficiency?
How much talent of non-technical people is wasted on time spent wrestling with systems?
How many errors are getting into your data?
Are staff resorting to shadow systems to keep track of essential work?
Leadership needs
How confident are you in your data?
Is your data telling you how well your strategic bets are paying off?
Are your technology deficiencies wasting your staff’s time and energy or helping them make the most of their talent and skills?
If you are happy with the answers to these questions, I would bet you are investing in your technology. It doesn’t happen by itself. Whereas if you are not happy with your answers, how much would it be worth to get happy about them?
If you know exactly what you want to get built, you can get a reasonable estimate for that. But will it deliver for you into the future, or be another half-realized disappointment?
We focus on building the capacity you need to steer your technology platforms, not just for that first project, but for every related need that is sure to arise thereafter.
It costs more than you think. But it will cost a lot less than doing it wrong.
Coverage
If a baseball team doesn’t have anyone in left field, they will consistently lose. Sure, they may handle long balls to center exceptionally, they may pitch great games, handle everything in the infield just fine. But if no one is covering left field, those fly balls will go unfielded and end up giving a significant advantage to the other team.
If a baseball team doesn’t have anyone in left field, they will consistently lose. Sure, they may handle long balls to center exceptionally, they may pitch great games, handle everything in the infield just fine. But if no one is covering left field, those fly balls will go unfielded, runs will be given up, and games lost.
The same applies to technology teams, but holes in coverage there aren't always as easy to spot. As technologists we have to map an invisible world that needs to be covered. It’s not always obvious, until it’s too late, that we’ve been neglecting an entire part of the field. All we know is that we’ve been losing, and scratching our heads wondering why someone else didn’t scoop up that play.
Many times people misinterpret a coverage problem as a problem with a specific person — a bad apple — when more likely expectations were set too broadly (you cover the outfield!) for any one person to be able to cover.
This might sound as simple as getting the right number of people to handle a load, but more often it’s about realistically figuring out the distinct skillsets required to cover the necessary ground, and making sure those skillsets are represented on your team. The skills represented on a healthy technology team will be extremely varied, and no one will have them all.
This is true for internal staff as well as external support. It's common to hear organizations complaining about their implementation firms, but on further inspection it often appears the firm delivered what was asked for, but delivered it to no one. The staff wasn’t set up to take it from there. The firm threw the ball back to first, and no one was there to catch it.
With proper coverage, we find ourselves surprised how many balls get fielded. But getting there requires paying close attention to where the balls are actually being hit. That takes real time and focus. If repeated training is needed to ensure successful adoption of a system, you have to get that covered. If data needs to be carefully monitored and cleaned in order to remain trustworthy, get someone on it. If a leader is needed (and one always is) to make strategic technology decisions, create and manage a roadmap, communicate with fellow executives, and advocate for budgets, how can we expect the product to be successful without a skilled individual playing that role?
With proper coverage, we also may be surprised how many people reveal themselves to be smart, conscientious, and hard working. A blaming culture can be replaced with an all-hands-on-deck, problem-solving culture. Instead of everyone’s priority being avoiding responsibility for the debacle, people can focus on the never-ending cycle of continuous improvement, in service of ultimately increasing the entire team's effectiveness, satisfaction, and impact.
Develop Slow, Respond Fast
If you want your product to succeed, don't think the road to that is by putting every bell or whistle you could imagine. Think first of making sure the people using your product are helped every step of the way to remove roadblocks to their use. No more arms crossed disappointed looks when they're not doing it right, despite "having got the training, twice!" We have to move to a support mentality that recognizes that if the product isn't used, it's useless.
Yes, being a product teamer involves a lot of geeking out on fixing and developing your product. Diving into new requirements and adding elegant new features to meet them. In constant development mode, expanding your system’s capabilities.
That work is important, to be sure. But it’s also easy to get carried away focusing on the next big thing you’re adding, at the cost of something even more important.
That's why we say develop slow, respond fast.
Because there's another piece of the puzzle that is implicit to how this whole thing works, and that is the healthy and robust use of the system as it exists today. Specifically support and training, bug-fixing, and a general guiding philosophy over overwhelming helpfulness.
If you want your product to succeed, the road to success is not by putting every bell or whistle you could imagine onto the machine. Think first of making sure the people using your product are helped every step of the way to remove roadblocks to their use. No more arms crossed disappointed looks when they're not doing it right, despite "having got the training, twice!" We have to move to a support mentality that recognizes that if the product isn't used, it's useless. And that people need a ton of support to get to a highly effective level of adoption.
No question, there is also a critical role to be played by new features and larger expansion/integration projects. But even still, develop slow still applies. You aren't always jumping in adding a feature at someone's request. Rather, get things on the roadmap, prioritize them by leverage and lift. And execute them thoughtfully and strategically.
So build an essential function, yes, and then do everything in your power to help the people using it succeed. Everything in your power. Sit with them, be a wide open door to their frustrations and struggles, listen, see what you can do. Questions and requests may take time to handle but they are not a burden. They are a necessary and healthy symptom of success.
Changing Your Mind is a Feature, Not a Bug
It’s true, changing your mind might alter budget and timelines. It may vex project managers. But the truth is that understanding evolves, and changing your mind based on the latest landscape is not a sign of negligence. It’s a sign of careful attention and thoughtfulness.
There should be zero shame in reversing field when the evidence demands it.
However it’s common to encounter resistance to changing your mind during the course of a project. This is especially true when your project is structured using the flawed “waterfall” model, where a firm does discovery, has everyone sign off on requirements, and then delivers something based on that agreement that doesn’t quite work the way it needs to. Predictably, everybody loses.
It’s true, changing your mind might alter budget and timelines. It may vex project managers whose job it is to keep everything as predictable and on-track as possible, or executives who are understandably focused on cost.
But the truth is that understanding evolves. It evolves as you solve related problems, as you work through the specifics of implementations and migrations, and as people start testing and using the damn thing you’re building.
What’s the alternative? Recognizing a flaw or spotting an improvement and keeping your mouth shut? Why are we building this boat in the first place if we’re going to ignore the leaks that are springing up?
Changing your mind based on the latest landscape is not a sign of negligence. It’s a sign of careful attention and thoughtfulness.
It’s ok to change your mind.
Your Timeline is a Lie
In the realm of technology builds, timelines are most helpful if we can all admit that they are, by nature, an initial best guess.
There are all kinds of reasons it’s useful to create a project timeline. It forces you to think carefully through each step and clarify dependencies, and it gives everyone a shared goal to work towards. You may need a timeline to get budgets approved and staff allocated, and it helps get the right people ready to pay attention at the right time.
But in the realm of technology builds, timelines are most helpful if we can all admit that they are, by nature, an initial best guess.
Why? Because at the outset of the project you don’t actually know exactly where you’re going, even if you think you do, (a well established principle of lean development). Nor do you know what your priorities will end up being at the end, nor what you will encounter along the way.
You also probably don’t know who are the specific human beings assigned to each task and their particular availability, skill sets, and challenges (the idea that all human “resources” with a certain job title are interchangeable in terms of skills and effects on timeline is a particularly ludicrous notion, to be elaborated on in an upcoming post.) Neither do you know what other competing priorities your organization will grapple with during that time.
And you certainly don’t know the feedback and ideas that will emerge once people start using the thing you’re building. Once you can lay your hands and eyes on the product, new questions, puzzles, and ideas arise daily. And that’s exactly how it is supposed to work. That’s where all of the juicy stuff is that makes the difference between mediocre and great.
Sure, you could plug your ears, ignore everything you’re seeing, and stick to the pre-set plan. But is that really worth it, if it means ending up with something mediocre? That is, in fact, the predictable result of the widely-discredited system of “waterfall” planning.
If you want to build something great, each puzzle along the way requires careful problem-solving, scenario planning, and sometimes even all-hands-on-deck solutioning. Sometimes it means choosing the lesser of two non-ideal options, other times going with an entirely unforeseen new option to address the challenge. But the benefit of all of this work is a much stronger, more effective product in the end.
This doesn't mean that a well-run project is devoid of urgency. Some projects may even demand countless high-urgency sprints strung together, in order to hit a series of sequenced goals.
Many people think the solution is to pad the timeline, but that's the wrong medicine. When the project is drained of realistic, meaningful urgency, people tend to pay only partial attention, and generally relax when they need to be putting their backs into the work.
So by all means, let’s establish a realistic timeline that we can all look at together and use as a strong, guiding light.
But when choices arise that threaten the timeline, let’s not be so focused on timeline that we lose sight of the whole point of what we’re building. You need to be constantly making choices that weigh the tradeoffs of timeline (and level of investment) versus functionality and fixes. That’s simply a cost of doing business in this world of limitless complexity, limitless options, and game-changing improvements out there waiting to be made.
We just have to be ok with the uncertainty of the journey that gets us there.
Nobody Cares About Your Website Launch
Don’t send out an announcement about your new website. Nobody cares about your website launch. Unless…
Don’t send out an announcement about your new website. Nobody cares about your website launch.
You’ve worked hard on it, you’ve probably spent a good amount of time and money on it. It was a huge project and you want to recognize your staff’s efforts! But that’s not a good enough reason. Don’t send a press release about how much time you spend making your hair look great. Unless your business is making hair look great.
Photo by Nathan Bingle
Why? Because chances are your new website is about you, it’s not about them.
“Come read pages of text about our different programs” might sound interesting to you. “Come peruse our annual report” might seem like your idea of a good time. “Come click through every staff member’s bio and read about their quirky choice of favorite food” might be how you’d spend your next half hour.
But it’s probably a yawner to most people, even those who love your organization.
Don’t get me wrong, a great new website will be more engaging, and the proof will be in the pudding! Definitely improve your website! Check the analytics. Is it performing better? Are people navigating around more intuitively? Are they staying on the site for longer? Are they seeing more content you want them to see? That’s great!
But just the fact that you have a new website? That probably won’t get anyone’s pulse racing.
UNLESS!
Unless you are letting your constituents know: Now you can...
If you’ve added a new capability that people will be interested in or excited about using, then that’s real news. Use the “Now you can” test.
As in: “Now you can watch first-person videos from people we serve and sponsor them directly.” How cool!
Or: “Now you can manage your own recurring donation on our website.” Great, that used to be a pain.
Or: “Now you can sign up for and manage your own volunteer shifts, and see your entire volunteer history and award levels.” Let’s check it out.
If you don’t have a really solid “Now you can” that will bring value to the people receiving the email, then just don’t send your launch announcement. Instead, let people discover your beautiful new website next time they go to check you out. They’ll think this is just how you operate. (Or if you must, mention it in a p.s. on another email that actually is bringing them real value.) Be a pro, and act like you’ve been in the end zone before.
And most importantly, for the love of Pete, treat your new website as the starting line, not the finish line. Turn it from a one time event to a new level of commitment to constantly improve everything about how you reach people, interact with them, and deliver ever-increasing value to them as they help you have greater impact in the world.
Detangling Digital
If you ask five or ten different digital directors what their scope/remit is, the answers will be all over the map. You see completely different meanings of a Digital department from organization to organization. In some cases it refers to digital campaigning and organizing. In others it means writing and sending email. Some digital departments are made up of social media specialists. Still others feature traditional IT functions, and/or ownership of digital platforms like the CRM or website CMS.
If there is a clear singular function to the Digital department, then we’ve got no quarrel with it. If your Digital department is clearly focused on digital campaigning, for instance, you can call it whatever you like.
The problems creep in when a Digital department becomes an excuse to mash together multiple disparate functions into a single home that strains to support them. In the most extreme cases, the Digital department may even be asked to include all of the above functions at once, with the reasoning that they all involve digital technology in some way.
We liken that to the idea of having a “Department of Paper”, and insisting that all work involving paper must go through that single department. That concept is obviously absurd, but not too much more absurd than saying that all things digital nowadays go through a single digital team. How could that possibly work? How could anyone coherently manage communications, fundraising, social media, traditional IT, and tech platform development all together? How could you effectively prioritize, or manage such a complex combination of workflows?
For some this may sound sacrilegious, since over the last decade or so the creation of a separate “digital” department often represented a hard-fought victory, wresting the control and management of all things digital away from staff who were masters of legacy systems and media but who were unfamiliar with how to harness the power of newer digital tools effectively.
But in today’s rapidly evolving world, we should admit that the big-D “Digital” umbrella has outlived its usefulness.
Smushing together digital has real, problematic consequences. It distracts people from their core work, undermines priorities, misaligns incentives, and causes core functions to slip through the cracks. You’re left with a team that is usually overwhelmed, constantly being asked to do things outside their areas of expertise, and frustratedly rowing in different directions -- from each other and from others in the organization.
These days damn near everything is digital in some way, so we need more useful distinctions. When it comes time to untangle the undifferentiated digital mess, here’s a simple guiding principle: everyone should get to focus on their areas of expertise. Campaigners should spend their time campaigning. Communicators should spend their time communicating. Fundraisers should spend their time fundraising. IT staff should spend their time doing IT. Digital product managers should be evolving their digital products (such as CRM and CMS platforms).
Each of these areas is a complex area of expertise that requires focus and care, and should be supported in a department that supports and enhances its mission. And each should be able use the tools of their trade, which these days, include digital tools and mediums.
If you’re a campaigner who needs to send an email, you should be able to work through and negotiate your content and sending schedule with your campaigning and communications colleagues. Then between those teams, someone should be able to pull up a template on the email system, populate your content, and schedule the message. And this should be able to happen without having to compete for priority and attention with people who are developing your CRM system, or A/B testing website donation page copy, or fixing your office printers. The workflows and skillsets for each are entirely distinct.
So at this point, we most commonly find ourselves recommending the integration of digital skillsets back into every department according to the area of expertise.
For some organizations, this might only require a slight tweak -- a few meaningful adjustments to job descriptions. For others, it could take a radical re-organization, and those should never be undertaken lightly. But the appropriate structure for today’s organization should reflect the reality that a basic level of digital fluency can no longer ever be “someone else’s” responsibility, it must be everyone’s.
And of course we’re not talking about every staff-member learning highly technical configuration and development skills! Those should remain specialized. We’re just saying every department needs to include people who know how to use the digital tools that are part of their trade.
~
So once you get each of these other functions back to their home planets, is there still a need for any kind of digital specialization? Yes! Very much so! In fact, sorting those functions back out leaves a clearer focus on the key gap that remains, which is the critical work of managing your core digital platforms (such as your CRM and CMS). Give these responsibilities to people who are focused, talented, and aspiring to become masters of that work. That’s the heart of a digital product team.
So if you’re in charge of a Digital team and are finding yourself in the business of herding cats and balancing unreasonable expectations, take a moment to think about what is at the core of your remit, and perhaps more importantly the core of your interest and talent. What do you think success looks like? Whatever it is, could that become the clear focus of your team? And could the other functions of digital be moved to the spot in the organization where they can really thrive?
Everyone likes to geek out on something. Wouldn’t it be great, both in terms of staff happiness and organizational effectiveness, if people spent their time focused on the areas where they bring the most energy and talent to the table?