techcafeteria

In 2000, after spending 15 years at corporate law firms, I made a personal choice to start working for organizations that promote social good by reducing poverty and protecting our planet. I understood that this career move would put some serious brakes on what was a fairly spiraling rise in compensation – my salary tripled from 1993 to 2000. And that was fine, because, as I see it, the privilege of being compensated for doing meaningful work is compensation in it’s own right.

We all know that we make less in this industry than we might in the commercial world, and we’re all pretty okay with that.  But how much, or how little, the discrepancy between “real world” and nonprofit salaries should be is a metric with little established thought behind it.  We don’t base our pay scales on any rationale other than what we determine others are paying and what we can afford. My concern is that, by not taking a strategic, reasoned approach to compensation, nonprofits are incurring far more unnecessary expense than they might, particularly when it comes to technology support, although these thoughts apply across the org chart.

The problem is that, when it comes to determining the market value of a nonprofit employee, we often go to nonprofit salary surveys, such as the one put out by NTEN and the Nonprofit times. But job seekers don’t read those surveys.  In San Francisco or New York, a good System Administrator can make $70-80k a year at a for-profit.  Even if they come in to your org understanding that they aren’t going to be offered the market pay ($75k), they have an expectation that they’ll either be on the low end of it ($70k), or within 10% of it ($67.5k).  The recent NTEN Staffing Survey puts the average nonprofit Sysadmin salary at $52k, which is about 75% of that market. So, given this scenario, here are my questions:

• How many excellent candidates are eliminated from consideration because they can’t afford to take a 25% pay cut?
• Of the ones who can afford that pay, how many can afford it because they aren’t qualified for the work required?
• How many can afford it because they have other primary income sources, and therefore can take a low paying job and not feel very committed to it?
• If a good Sysadmin takes a job at that rate, how long will it be before they decide that they need more money and leave?
• What is the impact of having a heavy rotation among the staff that maintain and upgrade your technology?
• What is the impact of having of having often empty critical IT positions?

But, let’s get really into this. Unless the IT people that are hired at the 75% rate are extremely mature, then they might have some of the common failings of immature Sysadmins:

• Many are often controlling and secretive. I’ve been in multiple situations where I’ve come into an organization and learned that the prior IT staff left with the key system passwords.  I’ve also seen numerous situations where the IT staff left en masse.
• Most Sysadmins are lousy about writing things down.  What is the ramp-up time for your new staff when they have to research and guess how everything works on arrival?
• The general instinct of a new IT person is to rip everything out and install their favorite things. Got Windows? They like Linux.  Got Word? They like Google Docs.  They don’t necessarily understand that one platform is much like another, but imposing massive change on an organization can be dangerously disruptive.

Technology candidates need to be assessed not only for their technical skills, but also for their attitude and maturity.  A very sharp tech, who can answer all of your Outlook questions, might have little patience for documenting his or her work or sharing knowledge with other technical staff. And those skills are the ones that will allow you to transition more smoothly when the tech leaves.

Mission is a motivator, and it has value that can be factored in to overall compensation, but not to the point where it’s so unattractive that it knocks the pool of candidates down to a pool of uncommitted or desperate ones.  The impact of paying poorly isn’t isolated to the salary bucket on the balance sheet.  In many cases, particularly with technology, it’s tied directly to the ability to operate.

I recently wrote about the potential for shared outcome reporting among nonprofits and the formidable challenges to getting there. This topic hits a chord for those of us who believe strongly that proper collection, sharing and analysis of the data that represents our work can significantly improve our performance and impact.

Shared outcome reporting allows an organization to both benchmark their effectiveness with peers, and learn from each others’ successful and failed strategies. If your most effective method of analyzing effectiveness is year to year comparisons, you’re only measuring a portion of the elephant. You don’t practice your work in a vacuum; why analyze it in one?

But, as I wrote, for many, the investment in sharing outcomes is a hard sell. Getting there requires committing scarce time, labor and resources to the development of the metrics, collection of data, and input; trust and competence in the technology; and partnering with our peers, who, in many cases, are also our competitors. And, in conditions where just keeping up with the established outcome reporting required for grant compliance is one of our greater challenges, envisioning diving into broader data collection, management and integration projects looks very hard to justify.

So let’s take a broader look this time at the justifications, rather than the challenges.

Success Measures is a social enterprise in DC that provides tools and consulting to organizations that want to evaluate their programs and services and use the resulting data. From their website:

Success Measures®, a social enterprise at NeighborWorks® America is an innovative participatory outcome evaluation approach that engages community stakeholders in the evaluation process and equips them with the tools they need to document outcomes, measure impact and inform change.

To accomplish this, in 2000, they set up an online repository of surveying and evaluation tools that can be customized by the participant to meet their needs. After determining what it is that they want to measure, participants work with their constituencies to gather baseline data. Acting on that data, they can refine their programs and address needs, then, a year or two later, use the same set of tools to re-survey and learn from the comparative data. Success Measures supplements the tools collection with training, coaching, and consulting to insure that their participants are fully capable of benefiting from their services. And, with permission, they provide cross-client metrics; the shared outcomes reporting that we’re talking about.

The tools work on sets of indicators, and they provide pre-defined sets of indicators as well as allowing for custom items. The existing sets cover common areas: Affordable housing; community building; economic development; race, class and community. Sets currently under development include green building/sustainable communities; community stabilization; measuring outcomes of asset programs; and measuring value of intermediary services.

Note that this resources nonprofits on both sides of the equation—they not only provide the shared metrics and accompanying insight into effective strategies for organizations that do what you do; they also provide the tools. This addresses one of the primary challenges, which is that most nonprofits don’t have the skills and staff required simply to create the surveying tools.

Once I understood what Success Measures was offering, my big question was, “how did you get any clients?” They had good answers. They actually engage more with the funders than the nonprofits, selling the foundations on the value of the data, and then sending them to their grantees with the recommendation. This does two important things:

• First, it provides a clear incentive to the nonprofits. The funders aren’t just saying “prove that you’re effective”; they’re saying “here’s a way that you can quantify your success. The funding will follow.


• Second, it provides a standardized reporting structure—with pre-developed tools and support—to the nonprofits. In my experience, having worked for an organization with multiple city, state and federal grants and funded programs, keeping up with the diverse requirements of each funding agency was an administrative nightmare.

So, if the value of comparative, cross-sector metrics isn’t reason enough to justify it, maybe the value of pre-built data collection tools is. Or, maybe the value of standardized reporting for multiple funding sources has a clear cost benefit attached. Or, maybe you’d appreciate a relationship with your funders that truly rewards you with grants based on your effectiveness. Success Measures has a model for all of the above.

At the recent Nonprofit Technology Conference, I attended a somewhat misleadingly titled session called “Cloud Computing: More than just IT plumbing in the sky“. The cloud computing issues discussed were nothing like the things we blog about here (see Michelle’s and my recent “SaaS Smackdown” posts). Instead, this session was really a dive into the challenges and benefits of publishing aggregated nonprofit metrics. Steve Wright of the Salesforce Foundation led the panel, along with Lucy Bernholz and Lalitha Vaidyanathan. The session was video-recorded; you can watch it here.

Steve, Lucy and Lalithia painted a pretty visionary picture of what it would be like if all nonprofits standardized and aggregated their outcome reporting on the web. Lalithia had a case study that hit on the key levels of engagement: shared measurement systems; comparative performance measurement and a baked in learning process. Steve made it clear that this is an iterative process that changes as it goes—we learn from each iteration and measure more effectively, or more appropriately for the climate, each time.

I’m blogging about this because I’m with them—this is an important topic, and one that gets lost amidst all of the social media and web site metrics focus in our nptech community. We’re big on measuring donations, engagement, and the effectiveness of our outreach channels, and I think that’s largely because there are ample tools and extra-community engagement with these metrics—every retailer wants to measure the effectiveness of their advertising and their product campaigns as well. Google has a whole suite of analytics available, as do other manufacturers. But outcomes measurement is more particular to our sector, and the tools live primarily in the reporting functionality of our case and client management systems. They aren’t nearly as ubiquitous as the web/marketing analysis tools, and they aren’t, for the most part, very flexible or sophisticated.

Now, I wholly subscribe to the notion that you will never get anywhere if you can’t see where you’re going, so I appreciate how Steve and crew articulated that this vision of shared outcomes is more than just a way to report to our funders; it’s also a tool that will help us learn and improve our strategies. Instead of seeing how your organization has done, and striving to improve upon your prior year’s performance, shared metrics will offer a window into other’s tactics, allowing us all to learn from each others’ successes and mistakes.

But I have to admit to being a bit overwhelmed by the obstacles standing between us and these goals. They were touched upon in the talk, but not heavily addressed.

• Outcome management is a nightmare for many nonprofits, particularly those who rely heavily on government and foundation funding. My brief forays into shared outcome reporting were always welcomed at first, then shot down completely, the minute it became clear that joint reporting would require standardization of systems and compromise on the definitions. Our case management software was robust enough to output whatever we needed, but many of our partners were in Excel or worse. Even if they’d had good systems, they didn’t have in-house staff that knew how to program them.


• Outcomes are seen by many nonprofit executives as competitive data. If we place ours in direct comparison with the similar NPO down the street, mightn’t we just be telling our funders that they’re backing the wrong horse?


• The technical challenges are huge—of the NPOs that actually have systems that tally this stuff, the data standards are all over the map, and the in-house skill, as well as time and availability to produce them, is generally thin. You can’t share metrics if you don’t have the means to produce them.

A particular concern is that all metrics are fairly subjective, as can happen when the metrics produced are determined more by the funding requirements than the NPO’s own standards. When I was at SF Goodwill, our funders were primarily concerned with job placements and wages as proof of our effectiveness. But our mission wasn’t one of getting people jobs; it was one of changing lives, so the metrics that we spent the most work on gathering were only partially reflective of our success – more outputs than outcomes. Putting those up against the metrics of an org with different funding, different objectives and different reporting tools and resources isn’t exactly apples to apples.

The benefits of shared metrics that Steve and crew held up is a worthwhile dream, but, to get there, we’re going to have to do more than hold up a beacon saying “This is the way”. We’re going to have to build and pave the road, working through all of the territorial disputes and diverse data standards in our path. Funders and CEOs are going to have to get together and agree that, in order to benefit from shared reporting, we’ll have to overcome the fact that these metrics are used as fodder in the battles for limited funding. Nonprofits and the ecosystem around them are going to have to build tools and support the art of data management required. These aren’t trivial challenges.

I walked into the session thinking that we’d be talking about cloud computing; the migration of our internal servers to the internet. Instead, I enjoyed an inspiring conversation that took place, as far as I’m concerned, in the clouds. We have a lot of work to do on the ground before we can get there.

The technology trend that defines this decade is the movement towards open, pervasive computing. The Internet is at our jobs, in our homes, on our phones, TVs, gaming devices. We email and message everyone from our partners to our clients to our vendors to our kids. For technology managers, the real challenges are less in deploying the systems and software than they are in managing the overlap, be it the security issues all of this openness engenders, or the limitations of our legacy systems that don’t interact well enough. But the toughest integration is not one between software or hardware systems, but, instead, the intersection of strategic computing and organizational culture.

There are two types of silos that I want to discuss: organizational silos, and siloed organizations.

An organizational silo, to be clear, is a group within an organization that acts independently of the rest of the organization, making their own decisions with little or no input from those outside of the group. This is not necessarily a bad thing; there are (although I can’t think of any) cases where giving a group that level of autonomy might serve a useful purpose. But, when the silo acts in an environment where their decisions impact others, they can create long-lived problems and rifts in critical relationships.

We all know that external decisions can disrupt our planning, be it a funders decision to revoke a grant that we anticipated or a legislature dropping funding for a critical program. So it’s all the more frustrating to have the rug pulled out from under us by people who are supposed to be on the same team. If you have an initiative underway to deploy a new email system, and HR lays off the organizational trainer, you’ve been victimized by a silo-ed decision. On the flip side, a fundraiser might undertake a big campaign, unaware that it will collide with a web site redesign that disables the functionality that they need to broadcast their appeal.

Silos thrive in organizations where the leadership is not good at management. Without a strong CEO and leadership team, departmental managers don’t naturally concern themselves with the needs of their peers. The expediency and simplicity of just calling the shots themselves is too appealing, particularly in environments where resources are thin and making overtures to others can result in those resources being gladly taken and never returned. In nonprofits, leaders are often more valued for their relationships and fundraising skills than their business management skills, making our sector more susceptible to this type of problem.

The most damaging result of operating in this environment is that, if you can’t successfully manage the silos in your organization, then you won’t be anything but a silo in the world at large.

We’ve witnessed a number of industries, from entertainment and newspapers to telephones and automobiles, as they allowed their culture to dictate their obsolescence. Instead of adapting their models to the changing needs of their constituents, they’ve clung to older models that aren’t relevant in the digital age, or appropriate for a global economy on a planet threatened by climate change. Since my focus is technology, I pay particular attention to the impacts that technological advancement, and the accompanying change in extra-organizational culture (e.g., the country, our constituents, the world) have on the work my organization does. Just in the past few years, we’ve seen some significant cultural changes that should be impacting nonprofit assumptions about how we use technology:

• Increased regulation on the handling of data. We’re wrestling with the HIPAA laws governing handling of medical data and PCI standards for financial data. If we have not prioritized firewalls, encryption, and the proper data handling procedures, we’re more and more likely to be out of step with new laws. Even the 990 form we fill out now asks if we have a document retention plan.


• Our donors are now quite used to telephone auto attendants, email, and the web. How many are now questioning why we use the dollars they donate to us to staff reception, hand write thank you notes, and send out paper newsletters and annual reports?


• Our funders are seeing more available data on the things that interest them everywhere, so they expect more data from us. The days of putting out the success stories without any numbers to quantify them are over.

Are we making changes in response to these continually evolving expectations? Or are we still struggling with our internal expectations, while the world keeps on turning outside of our walls? We, as a sector, need to learn what these industrial giants refused to, before we, too, are having massive layoffs and closing our doors due to an inability to adapt our strategies to a rapidly evolving cultural climate. And getting there means paying more attention to how we manage our people and operations; showing the leadership to head into this millennia by mastering our internal culture and rolling with the external changes. Look inward, look outward, lead and adapt.

Last week I had the thrill of visiting a normally closed-to-the-public Science Building at UC Berkeley, and getting a tour of the lab where they examine interstellar space dust collected from the far side of Mars. NASA spent five or six years, using some of the best minds on the planet and $300,000,000, to develop the probe that went out past Mars to zip (at 400 miles a second) through comet tails and whatever else is out there, gathering dust. The most likely result of the project was that the probe would crash into an asteroid and drift out there until it wasted away. But it didn’t, and the scientists that I met on Saturday are now using these samples to learn things about our universe that are only speculative fiction today.

So, what does NASA know that we don’t about the benefits of taking risks?

In my world of technology management, it seems to be primarily about minimizing risk. We do multiple backups of critical data to different media; we lock down the internet traffic that can go in and out of our network; we build redundancy into all of our servers and systems, and we treat technology as something that will surely fail if we aren’t vigilant in our efforts to secure it. Most of our favorite adages are about avoiding risk: “It it ain’t broke, don’t fix it!” and “Nobody was ever fired for buying IB.. er, MicroSoft.”

On Monday, I’ll be presenting on my chapter of NTEN’s Book “Managing Technology to Meet Your Mission” at the Nonprofit Technology Conference in San Francisco. My session, and chapter, is about mission-focused technology planning and the art of providing business-class systems on a nonprofit budget. That’s certainly about finding sustainable and dependable options, but my case is that nonprofits, in particular, need to identify the areas where they can send out those probes and gamble a bit. For many nonprofits, technology planning is a matter of figuring out which systems desperately need upgrading and living with a lot of systems and applications that are old and semi-functional. My case is that there’s a different approach: we should spend like a regular business on the critical systems, but be creative and take risks where we can afford to fail a bit, on the chance that we’ll get far more for less money than we would playing it “safe” with inadequate technology. It’s a tough sell, yes, but I frame it in my belief that, when your business is changing the world, your business plan has to be bold and creative. As I mention often, the web is, right now, a platform rife with opportunity. We will miss out on great chances to significantly advance our missions if we just treat it like another threat to our stability.

We need stable systems, and we often struggle with inadequate funding and the technical resources simply to maintain our computer systems. I say that, as hard as that is, we need to invest in exploration. It’s about maximizing potential at the same time as you minimize risk. And its all about the type of dust that you want to gather.

I had big plans for another insightful, deep, break-down-the-walls-of-the-corporate-culture-that-diminishes-use-of-technology post today, but I think I’m gonna save it for a rainy day and write something a bit more useful, instead.  I have a big nonprofit technology conference coming up this weekend, as you might, as well, and I think we should all be resting up for it.

The most important skill for any IT staff person to have is the ability to communicate.  All of the technical expertise in the world has little value without it, because, if you can’t tell people what you’re doing, what you’re doing won’t be well-received.  And there is an art, particularly with tech, to telling people what you’re doing, whether it’s taking the system down for maintenance of upgrading staff from Notepad to Office 2007.

Here are my five rules for crafting an technical email that even my most computer-phobic constituents will read:

1. Let no acronym go unexplained.

   The simplest, worst mistake that techies regularly make is to tell people that

   “The internet will be down while we reconfigure the DHCP server” or

   “The database will be unavailable while we replace the SCSI backplane”.

   Best practice is to avoid the technical details in the announcement, if possible.  But if it’s relevant, speak english: “In order to accommodate the growth of our staff, we need to reconfigure the server that assigns network resources to each system to allow for more connections.”

2. Be clear, concise and consistent in your subjects

   Technical messages should have easily recognizable subjects, so that staff can quickly determine relevance.  If your message is titled “Technical Information”, it might as well be titled “You are getting sleepy…”  But, if it’s titled “Network Availability” or “Database Maintenance Scheduled”, your staff will quickly figure out that these are warnings that are relevant to them. Don’t worry about the Orwellian aspect of announcing system downtime with a message about availability.  The point here is that using the consistent phrasing will grab staff’s attention far more effectively than bolding, underlining and adding red exclamation points to the email (see rule 4).

3. Keep it short and simple

   It’s about what the staff needs to know, not what you’d like to tell them.  So, the network maintenance email should not read:

   “The systems will be down from 4:30 to 9:00 tonight while we replace drives in the domain controllers and run a full defrag on the main document server”

   It should read:

   “The network will be unavailable from 4:30 pm until 9:00 pm while we perform critical maintenance”.

   If it’s only a portion of the network, but something useful will be up – as when the file servers are being repaired, but email is still available, make a note of that: “While the main servers will not be available, you will still be able to send and receive email”.

4. No ALL CAPS, no exclamation points and go sparingly on the bold

   System downtime might be urgent to you, but it’s never urgent to the staff.  It’s a fact of life.  A reply from the Director of Online Giving that the downtime will jettison a planned online campaign is urgent; not your routine announcement.

5. Tell the whole story

   ...even if this sounds like it conflicts with rule 3.  Because there are two types of people on your staff:

   • The majority, who want simple, non-techie messages as described above
   • The rest, who want the gory details, either so they can rest easy that you aren’t making anything up, or because they’re actually interested in what you’re up to.
   
   

   My approach is to do the simple message and, below it type, “Technical Details (optional reading)”.  In this section I might explain that we’re replacing the server that processes their network logins (I won’t use “DHCP” or “Domain Controller” if I can help it) or that we’re upgrading to the new version of Outlook.

The key concepts here are consistency, simplicity, and a focus on what impacts them regarding what you’re doing.  Stick to it and, miraculously, people might start reading your all staff emails.

Non Profit social media maven Beth Kanter blogged recently about starting up a residency at a large foundation, and finding herself in a stark transition from a consultant’s home office to a corporate network. This sounds like a great opportunity for corporate culture shock. When your job is to download many of the latest tools and try new things on the web that might inform your strategy or make a good topic for your blog, encountering locked-down desktops and web filtering can be, well, annoying is probably way to soft a word. Beth reports that the IT Team was ready for her, guessing that they’d be installing at least 72 things for her during her nine month stay. My question to Beth was, “That’s great – but are they just as accommodating to their full-time staff, or is flexibility reserved for visiting nptech dignitaries?”

The typical corporate desktop computer is restricted by group policies and filtering software. Management, along with the techs, justify these restrictions in all sorts of ways:

• Standardized systems are easier, more cost-effective to manage.


• Restricted systems are more secure.


• Web filtering maximizes available bandwidth.

This is all correct. In fact, without standardization, automation, group policies that control what can and can’t be done on a PC, and some protection from malicious web sites, any company with 15 to 20 desktops or more is really unmanageable. The question is, why do so many companies take this ability to manage by controlling functionality to extremes?

Because, in many/most cases, the restrictions put in place are far broader than is necessary to keep things manageable. Web filtering not only blocks pornography and spyware, but continues on to sports, entertainment, politics, and social networking. Group policies restrict users from changing their desktop colors or setting the system time. And the end result of using the standardization tools to intensively control computer usage results, most often, in IT working just as hard or harder to manage the exceptions to the rules (like Beth’s 72, above) than they would dealing with the tasks that the automation simplifies in the first place.

Restricting computer/internet use is driven by a management and/or IT assumption that the diverse, dynamic nature of computing is either a distraction or a problem. The opportunity to try something new is an opportunity to waste time or resources. By locking down the web; eliminating a user’s ability to install applications or even access settings, PC’s can be engineered back down to the limited functionality of the office equipment that they replaced, such as typewriters, calculators and mimeograph machines.

In this environment, technology is much more of a controlled, predictable tool. But what’s the cost of this predictability?

• Technology is not fully appreciated, and computer literacy is limited in an environment where users can’t experiment.


• Strategic opportunities that arise on the web are not noticed and factored into planning.


• IT is placed in the role of organizational nanny, responsible for curtailing computer use, as opposed to enabling it./

Cash and resource-strapped, mission-focused organizations only need look around to see the strategic opportunities inherent in the web. There are an astounding number of free, innovative tools for activism and research. Opportunities to monitor discussion of your organization and issues, and meaningfully engage your constituents are huge. And all of this is fairly useless if your staff are locked out of the web and discouraged from exploring it. Pioneers like Beth Kanter understand this. They seek out the new things and ask, how can this tool, this web site, this online community serve our sector’s goals to ease suffering and promote justice? More specifically, can you end hunger in a community with a widget? Or bring water to a parched village via Twitter? If our computing environment is geared to stifle innovation at the cost of security, are we truly supporting technology?

As the lead technologist at my organization, I want to be an enabler. I want to see our attorneys use the power of the web to balance the scales when we go to court against far better resourced corporate and government counsel. In this era of internet Davids taking down Goliaths from the RIAA the the mainstream media, I don’t want my co-workers to miss out on any opportunities to be effective. So I need the flexibility and perspective to understand that security is not something that you maintain with a really big mallet, lest you stamp out innovation and strategy along with the latest malware. And, frankly, cleaning a case of the conflickr worm off of the desktop of an attorney that just took down a set of high-paid corporate attorneys with data grabbed from some innovative mapping application that our web-filtering software would have mistakenly identified as a gaming site is well worth the effort.

Flexibility has it’s own Return on Investment (ROI), particularly at nonprofits, where we generally have a lot more innovative thinking and opportunistic attitude than available budget. IT has to be an enabler, and every nonprofit CIO or IT Director has to understand that security comes at a cost, and that cost could be the mission-effectiveness of our organizations.

Say you sign up for some great Web 2.0 service that allows you to bookmark web sites, annotate them, categorize them and share them. And, over a period of two or three years, you amass about 1500 links on the site with great details, cross-referencing—about a thesis paper’s worth of work. Then, one day, you log on to find the web site unavailable. News trickles out that they had a server crash. Finally, a painfully honest blog post by the site’s founder makes clear that the server crashed, the data was lost, and there were no backups. So much for your thesis, huh? Is the lesson, then, that the cloud is no place to store your work?

Well, consider this. Say you start up a Web 2.0 business that allows people to bookmark, share, categorize and annotate links on your site. And, over the years, you amass thousands of users, some solid funding, advertising revenue—things are great. Then, one day, the server crashes. You’re a talented programmer and designer, but system administration just wasn’t your strong suit. So you write a painful blog entry, letting your users know the extent of the disaster, and that the lesson you’ve learned is that you should have put your servers in the cloud.

My recent posts have advocated cloud computing, be it using web-based services like Gmail, or looking for infrastructure outsourcers who will provide you with virtualized desktops. And I’ve gotten some healthily skeptical comments, as cloud computing is new, and not without it’s risks, as made plain by the true story of the Magnolia bookmarking application, which recently went down in the flames as described above. The lessons that I walk away with from Magnolia’s experience are:

• You can run your own servers or outsource them, but you need assurances that they are properly maintained, backed up and supported. Cloud computing can be far more secure and affordable than local servers. But “the cloud”, in this case, should be a company with established technical resources, not some three person operation in a small office. Don’t be shy about requesting staffing information, resumes, and details about any potential off-site vendor’s infrastructure.
• You need local backups, no matter where your actual infrastructure lives. If you use Salesforce or Google, export your data nightly to a local data store in a usable format. Salesforce lets you export to Excel; Google supports numerous formats. Gmail now supports an Offline mode that stores your mail on the computer you access it from. If you go with a vendor who provides virtual desktop access (as I recommend here), get regular snapshots of the virtual machines. If this isn’t an over the air transfer, make sure that your vendors will provide DVDs of your data or other suitable medium.
• Don’t sign any contract that doesn’t give you full control over how you can access and manipulate your data, again, regardless of where that data resides. A lot of vendors try and protect themselves by adding contract language prohibiting mass updates and user access, even on locally-installed applications. But their need to simplify support should not be at the expense of you not having complete control over how you use your information.
• Focus on the data. Don’t bend on these requirements: Your data is fully accessible; It’s robustly backed up; and, in the case of any disaster, it’s recoverable.

Technology is a set of tools used to manage your critical information. Where that technology is housed is more of a feature set and financial choice than anything else. The most convenient and affordable place for your data to reside might well be in the cloud, but make sure that it’s the type of cloud that your data won’t fall through.

My friends at Blackbaud referred me to this excellent post by Jay Love, CEO of ETapestry, once a small donor database service, now a subsidiary of the mother of all donor database companies. Jay’s timely caution to nonprofits is that they be skeptical about all of the for-profit folk answering their employment ads in the face of the poor economy. People from that side of the dollar fence are generally unprepared for the culture of nonprofits. His story about vendors trying to break into our sector with no experience or research into our needs is fascinating. But I have a different take on hiring people from the for-profit world, and while Jay seems t be saying “don’t do it”, I’m on the “be sure to do it – in moderation” side.

Of course, the healthy disclaimer is that I never worked for a nonprofit, or knew all that much about the culture, before I took a job at Goodwill in late 2000. But I did have enough sense to pick an NPO that ran more like a traditional business than most, at least in some ways, and I took some time to adjust to the culture before I tried to push through any changes. Which isn’t to say that I blend all that well – I’m one of the people complaining that we move to slowly and that consensus is not a value, it’s a tool that, like most tools, is better suited for some tasks than others.

Any business (and nonprofits are businesses) benefits from diversity, just as any business benefits by retaining internal expertise. Businesses suffer when they lean too far in one direction or the other. If your hiring policy is to only hire people who are lifetime nonprofit workers, you run the risk of stifling innovation and you court stagnation. The world doesn’t sit still around us, so we have to dynamically adapt to it. A key tool for managing that adaption is to maintain a diversity of experience and skills in your organization.

Think about it: ten or fifteen years ago, non-profits were largely unregulated. There was no HIPAA. There was no Sarbanes-Oxley, which, while not designed for NPOs, is generally agreed to impose guidelines on us. There was no PCI compliance, the next wave of external oversight that will demand that we modify our processes and investments. Beyond the 990 and what we chose to disclose about our outcomes, there was little demand for detailed metrics. These are all circumstances that the for-profit world, with traditional government oversight and accountability to shareholders has dealt with for decades. We need some of that expertise.

Of course, it’s a scale, and just as we can suffer from cultural insulation, we can suffer by turning over too dramatically. While I would steadfastly debate that we need some of that for-profit perspective on board, I’ve seen a few examples of for-profit executives that take over as CEOs and—because the nonprofit style is so antithetical to the big business style—quickly replace everyone that, to them, looked like they weren’t up to the task of running “a business”. This type of culture change, in a nonprofit, is deadly, because it is a misconception to think that we can run like normal businesses. When that happens, the nonprofit runs the risk of losing all of the internal historical expertise, as the people who aren’t squeezed out don’t stick around for the cultural change, and the new execs face the budgeting challenges with no perspective to draw on.

So, a businessman like me – and I absolutely consider myself a businessman—gets frustrated with the slow pace at the nonprofits that I work for. And I beg, moan and try and shame my boss into adopting more business-like practices. But I don’t sweat it too much, because, at the end of the day, even if we don’t do things in the efficient and productive ways that I’m so stuck on adopting, we still do an amazing job of defending the planet, or, you can fill your mission in here. I’d hate to see it fall apart because we didn’t properly comply with regulations or we simply didn’t manage our resources well, and we have to staff to address that. So my shoutback to Jay Love is that the bunker mentality is a bit much. Let a few for-profit types in the door. But, until they understand and value our culture, don’t let them drive.

My big post contrasting full blown Microsoft Exchange Server with cloud-based Gmail drew a couple of comments from friends in Seattle. Jon Stahl of One/Northwest pointed out, helpfully, that MS sells it’s Small Business Server product to companies with a maximum of 50 employees, and that greatly simplifies and reduces cost for Exchange. After that, Patrick Shaw of NPower Seattle took it a step further, pointing out that MS Small Business Server, with a support arrangement from a great company like NPower (the “great” is my addition – I’m a big fan), can cost as little as $4000 a year and provide Windows Server, Email, Backup and other functions, simplifying a small office’s technology and outsourcing the support. This goes a long way towards making the chaos I described affordable and attainable for cash and resource strapped orgs.

What I assume Npower knows, though, and hope that other nonprofit technical support providers are aware of, is that this is the outdated approach. Nonprofits should be looking to simplify technology maintenance and reduce cost, and the cloud is a more effective platform for that. As ReadWriteWeb points out, most small businesses—and this can safely be assumed to include nonprofits—are completely unaware of the benefits of cloud computing and virtualization. If your support arrangement is for dedicated, outsourced management of technology that is housed at your offices, then you still have to purchase that hardware and pay someone to set it up. The benefits of virtualization and fast, ubiquitous Internet access offer a new model that is far more flexible and affordable.

One example of a company that gets this is MyGenii. They offer virtualized desktops to nonprofits and other small businesses. As I came close to explaining in my Lean, Green, Virtualized Machine post, virtualization is technology that allows you to, basically, run many computers on one computer. The environmental and financial benefits of doing what you used to do on multiple systems all on one system are obvious, but there are also huge gains in manageability. When a PC is a file that can be copied and modified, building new and customized PCs becomes a trivial function. Take that one step further – that this virtual PC is stored on someone else’s property, and you, as a user, can load it up and run it from your home PC, laptop, or (possibly) your smartphone, and you now have flexible, accessible computing without the servers to support.

For the tech support service, they either run large servers with virtualization software (there are many powerful commercial and open source systems available), or they use an outsourced storage platform like Amazon’s EC2 service. In addition to your servers, they also house your desktop operating systems. Running multiple servers and desktops on single servers is far more economical; it better utilizes the available server power, reducing electricity costs and helping the environment; and backups and maintenance are simplified. The cost savings of this approach should benefit both the provider and the client.

In your office, you still need networked PCs with internet access. But all you need on those computers is a basic operating system that can boot up and connect to the hosted, virtualized desktop. Once connected, that desktop will recognize your printers and USB devices. If you make changes, such as changing your desktop wallpaper or adding an Outlook plugin, those changes will be retained. The user experience is pretty standard. But here’s a key benefit—if you want to work from home, or a hotel, or a cafe, then you connect to the exact same desktop as the one at work. It’s like carrying your computer everywhere you go, only without the carrying part required.

So, it’s great that there are mission focused providers out there who will affordably support our servers. But they could be even more affordable, and more effective, as cloud providers, freeing us from having to own and manage any servers in the first place.