Tag Archives: organizational culture

Creating A Tech-Savvy Nonprofit Culture

This article was originally published in NTEN Change Magazine in June of 2015.

TechSavvy

What kind of challenge does your organization have supporting technology? Below are several scenarios to choose from:

  • Little or no tech staff or tech leadership: We buy inexpensive computers and software and rely on consultants to set it up.
  • Our IT support is outsourced: there is no technology plan or any staff training.
  • We have a tech on staff who does their best to keep things running: no staff training, no technology planning.
  • We have a tech on staff and an IT Director, but no technology plan: IT is swamped and not very helpful.
  • We have staff and IT leadership, but strategic plans are often trumped by budget crises. Training is minimal.
  • IT Staff, Leadership, budget, and a technology plan, but executive support is minimal. IT projects succeed or fail based on the willingness of the departmental managers to work with IT.

What do all of these scenarios have in common? A lack of a functional technology plan, little or no staff training, and/or no shared accountability for technology in the organization. While it’s likely that the technical skills required in order to successfully perform a job are listed in the job descriptions, the successful integration of technology literacy into organizational culture requires much more than that. Here are some key enabling steps:

Technology Planning: If you have a technology plan, it might not do more than identify the key software and hardware projects planned. Technology planning is about much more than what you want to do. A thorough plan addresses the “who,” the “why,” and the “how” you’re going to do things:

  • A mission statement for the technology plan that ties directly to your organizational mission. For a workforce development agency, the tech mission might be to “deploy technology that streamlines the processes involved in training, tracking, and placing clients while strategically supporting administration, development, and communications”.
  • A RACI matrix outlining who supports what technology. This isn’t just a list of IT staff duties, but a roadmap of where expertise lies throughout the organization and how staff are expected to share it.
  • A “Where we are” assessment that points out the strengths, weaknesses, threats, and opportunities in your current technology environment.
  • A “Where we need to go” section that outlines your three to five year technology vision. This section should be focused on what the technology is intended to accomplish, as opposed to which particular applications you plan to buy. For example, moving to internal social media for intra-organization communication and knowledge management” is more informational than “purchase Yammer.
  • Finally, a more technical outline of what you plan to deploy and when, with a big disclaimer saying that this plan will change as needs are reassessed and opportunities arise.

Training: Training staff is critical to recouping your investments in technology. If you do a big implementation of a CRM or ERP system, then you want your staff to make full use of that technology. If you’re large enough to warrant it (50+ staff), hire an in-house trainer, who also plays a key role in implementing new systems. This investment will offset significant productivity losses.

Smaller orgs can make use of online resources like Khan Academy and Lynda.com, as well as the consultants and vendors who install new systems. And technology training should be part of the onboarding process for new hires, even if the trainers are just knowledgeable staff.

In resource-strapped environments, training can be a hard sell. Everybody likes the idea, but nobody wants to prioritize it. It’s up to the CEO and management to lead by policy and example – promote the training, show up at the training, and set the expectation that training is a valued use of staff time.

Organizational Buy-in: Don’t make critical technology decisions in a vacuum. When evaluating new software, invite everyone to the demos and include staff in every step of the decision-making process, from surveying them on their needs before you start defining your requirements to including staff who will be using the systems in the evaluation group. When staff have input into the decision, they are naturally more open to, and accountable for, healthy use of the system.

Executive Sponsorship: With technology clearly prioritized and planned for, the last barrier is technophobia, and that’s more widespread than the common cold in nonprofits. Truly changing the culture means changing deep-rooted attitudes. This type of change has to start at the top and be modeled by the executives.

True story: At Salesforce.com, every new employee is shown the “Chatter” messaging tool and told to set up a profile. If a new user neglects to upload a photo, they will shortly find a comment in their Chatter feed fromMarc Benioff, the CEO of Salesforce, saying, simply, “Nice Photo”. That’s the CEO’s way of letting new staff know that use of Chatter is expected, and the CEO uses it, too.

Play! One more thing will contribute to a tech-savvy culture: permission to play. We want to let staff try out new web tools and applications that will assist them. The ones that are useful can be reviewed and formally adopted. But locking users down and tightly controlling resources – a common default for techies, who can trend toward the control-freakish side – will do nothing to help establish an open-minded, tech-friendly atmosphere.

Overcoming Tech Aversion: We all know, now, that technology is not an optional investment. It’s infrastructure, supplementing and/or taking the place of fax machines, printers, photocopiers, telephones, and in more and more cases, physical offices. In the case of most nonprofits, there isn’t an employee in the company that doesn’t use office technology.

But there are still many nonprofits that operate with a pointed aversion to technology. Many executives aren’t comfortable with tech. They don’t trust it, and they don’t trust the people who know what to do with it. A whole lot depends on getting tech right, so enabling the office technologist – be it the IT Director or the accidental techie – is kind of like giving your teenager the keys to the car. You know that you have to trust them, but you can’t predict what they’re going to do.

Building that trust is simply a matter of getting more comfortable with technology. It doesn’t mean that management and staff all have to become hardcore techies. They just have to understand what technology is supposed to do for them and embrace its use. How do you build that comfort?

  • Have a trusted consulting firm do a technology audit.
  • Visit tech-savvy peers and see how they use technology.
  • Go to a NTEN conference.
  • Buy an iPad!

Building a tech-savvy culture is about making everyone more engaged, accountable, and comfortable with the tools that we use to accomplish our missions. Don’t let your organization be hamstrung by a resistance to the things that can propel you forward.

13 Lessons On Building Your Nonprofit Technology Culture

This article originally appeared on the Exponent Partners blog on December 19th, 2014. It was written by Kerry Vineburg, based on a phone interview with me.

EXPONENT PARTNERS SERIES: SMART PRACTICES

Is your nonprofit thinking about implementing a large database project like Salesforce? Nonprofit and technology veteran Peter Campbell, CIO at Legal Services Corporation, recently shared his valuable insights on how to prepare your team and culture for long-term success. His organization, the top funder of civil legal aid for low-income Americans in the country, is developing Salesforce as a data warehouse for their grantee information and document management. 

We asked Peter to tell us more about what practices he uses to help ensure a successful technology implementation. As you’ll see, it’s just as much about working with people! 

Embarking On Your Project

1. When beginning a technology project, agree on the problem you’re solving, that all staff can relate to. Organizational readiness is critical. I’ve worked at organizations that didn’t recognize that their casual approach to data management was a problem, and they weren’t looking for a solution. If your staff don’t understand why they need an application, then you’re in danger of installing something that won’t be utilized. When starting a new organizational project, I identify 2-3 core bullet points that will explain the goals of the project, and repeat them often. For example: “The new system will provide one-step access to all information and documents related to a grantee.” That’s the high-level goal. It should be something where the product users all agree, “Yes, I need that!”
2. When planning technology upgrades and projects, schedule the changes. Plan for gradual change. Early in my career, I had to deal with the Y2K bug and replace every system at a mid-sized law firm in a short period. It led me to this philosophy: replace only one major system each year. It’s a myth that people hate change — people hate disruption. Change is good, but needs to be managed at steady level. If you’re doing regular implementations every year, people can get used to that pace. If you do nothing for 3 years, then switch out everything: 1) you’re putting too much of a burden on your implementers to achieve everything at once and 2) you’re making too big of an imposition on staff. Suddenly, everything they know is gone and replaced.

Getting Buy-In

3. Gain full executive sponsorship. There’s a common misconception that a new system will just work for you once it’s installed. To fully realize the benefits of a CRM requires cultural change. Every level of the organization needs to buy into the project. You’ll need to harness a lot of attention and energy from your team to develop requirements, manage the project, learn the new system and adapt processes. Otherwise, you’ll invest in a big database implementation and only one or two people will use it.
The importance of a major system upgrade should be set by the executive director and/or board. Everyone should know that the system is a priority. At nonprofits, our executive directors are often better at fundraising than managing a business, and many are somewhat technophobic. They don’t need to be technology gurus, but they do need to understand what the technology should be doing for them, and to take ownership of those goals. The last thing that I want to hear from my boss is, “Here’s a budget — go do what you think is best.” Without their interest in my projects, I’m bound to fail.
4. If one buy-in approach needs help, try a combo. If you can’t convince your executive director or other leadership to be regular active participants, power users can sometimes help convince your team. I’m not recommending an either/or approach, there should be some of both, but power users can engage staff in cases where management isn’t setting clear expectations. For any project that impacts staff, I will invite key users to be on our evaluation team, help with product selection, and potentially be on our advisory committee during the project. For example, we have a grants department liaison, who is charged with getting the right people in the room when we need input from the staff that know much better than we do what the system should ultimately do for them.
5. Incorporate perspectives from around the table. In addition to power users, I also want feedback from “standard” users. Maybe they don’t love technology so much, and maybe they wouldn’t volunteer for this. But they have an important perspective: you need to understand their reactions and what they’re going to find difficult. As the IT director and CIO, I know important things about managing a project. The users know important things that I don’t. If we don’t have views from multiple sides of the table, the project will fail.

Working With Good People

6. Look for partners (vendors and consultants) who understand your mission, not just the technology. In the ideal situation, you want people who not only get database and programming work, but also really understand your mission and business priorities. I’m blessed to have developers on my team who not only understand grants management but are also sympathetic to what the people coming to them are trying to accomplish. When they get a request, they can prioritize with a good understanding of our organization’s requirements. They’re able to answer, “How can I make the most out of what this person needs with my available time?” while being skilled enough to capably choose between the technical options. Getting people that have a broader mindset than just technology is really important.
7. Vary your team and role strategy with your size. At nonprofits, we don’t usually have big internal teams. Someone becomes our accidental techie/database guru. Even large nonprofits are hurting for staff. It’s always been less “here’s the best practice and ideal way to staff this,” and more “let’s see what budget and people I have, and make it work as well as I can.” Not many nonprofits have developers on staff. Hiring can be challenging. It’s a popular skillset, and won’t be cheap. If you’re tiny, you probably won’t hire full-time, you’ll outsource to consultants. But if you have 30 people or more using the CRM, you might benefit from in-house expertise, even if it’s a half-time role.
If you already have developers on staff, that’s great. If they don’t have experience with, say, Salesforce, but they do know database design and a programming language or two, it’s not hard to pick up the concepts. You’re modeling a database, designing it, and then scripting on top of it in a similar language. They can probably adapt.
8. Practice good compensation and retention strategies for your technically savvy (and/or newly trained) staff. I’ve seen a trend over the past 10 years. A nonprofit decides to use a solution like Salesforce and they charge their accidental techie with the task of implementing. The accidental techie gets the implementation done, becomes a guru on it, trains all the users, and then because the organization is paying them an entry-level salary, they leave and go get a much higher paying job as a consultant! It’s a valuable skillset, so don’t be short-sighted about compensating them for what they do for you. You need to be careful and invest properly. Give them raises along with the skillset, to make sure they are fully motivated to stick with you.

Project Management

9. Avoid surprises with good communication. My rule of IT management now is: “No one should ever be surprised by anything I do.” From experience with good mentors, I learned important lessons about communication: if you’re going to make a change, communication is critical. Say it 3 times in 3 different mediums (in email, on the internet, on flyers on the wall on every floor!). Be sure staff know how the technology contributes to the well-being of the organization, rather than being a time-waster, so they are motivated to keep working with it. Communicate well.
10. If possible, hold out for the right team. I put off projects to have the right people in place, rather than hold tight to a project deadline with the wrong people in place. See above for how to find and keep the right people.

Training and Baking The Technology Into Your Culture

11. Don’t reinvent the wheel; take advantage of the ecosystem. It can be really common for staff not to reach out for help. They may feel like their job is to learn the technology on their own. They should know there are many resources available to them! For example, with Salesforce, I recommend making use of peer support in the community, the Power of Us Hub, and local user groups. When they do seasonal updates, they do a lot of webinars and are good about providing information about how the app is growing. Salesforce also offers training (the Salesforce Foundation discounts by half) and every consultant I’ve spoken with is capable of doing some customized training. I know that other technologies offer resources like this also. It also behooves anybody on staff to know the specific implementation that you’ve done.
12. Allocate a training budget. I always push to have a staff training budget. For my organization, we even hired for a role of training and implementation specialist. We wanted to have a person on staff whose full-time job was training and strategizing how users use software and how to involve them in the implementation process. This should be part of your budget. I can’t emphasize enough how important it is to have people in your organization who know how to train on your applications.
13. Engage staff and help them understand the big picture of the technology. It’s good to get your team working with the database early on in the process, learning what it’s capable of and what it looks like. Engage your users: get people involved in every step of the process, from selecting products to implementation to training and rollout. Make the product demos big group activities, so that everyone can envision how similar systems work and what they might do with the product beyond what they’re doing today. Beta-test your implementations, giving staff lots of opportunities to provide input. Take an Agile approach of regularly showing what you’re developing to the people who will be using it, and adjusting your development per their feedback.
With a committed team that understands your mission, great communication, well-allocated resources, and gradual change, your organization can lay the foundations for a successful solution that will actually be adopted!
Thanks to Peter Campbell for these great insights. Peter also blogs at techcafeteria.com
For even more strategies on ensuring that your culture is ready for your system, check out our free report Nonprofit Technology Adoption: Why It Matters and How to Be Successful.

– See more at: http://www.exponentpartners.com/building-your-nonprofit-technology-culture#sthash.QPFll78h.dpuf

Telecommuting Is About More Than Just The Technology

We’ve hit the golden age of telework, with myriad options to work remotely from a broadband-connected home, a hotel, or a cafe on a mobile device. The explosion of cloud and mobile technologies makes our actual location the least important aspect of connecting with our applications and data. And there are more and more reasons to support working remotely. Per Reuters, the state of commuting is a “virtual horror show”, with the average commute costing the working poor six percent of their income. It’s three percent for more wealthy Americans. And long commutes have negative impacts on health and stress levels. Add to this the potential cost savings if your headquarters doesn’t require an office or cubicle for every employee. For small NPOs, do you even really need an office? Plus, we can now hire people based on their absolute suitability to the job without requiring them to relocate. It’s all good, right?

Well, yes, if it’s done correctly.  And a good remote work culture requires more than seamless technology. Supervisors need to know how to engage with remote employees, management needs to know how to be inclusive, and the workers themselves need to know how to maintain relationships without the day to day exposure to their colleagues.  Moving to a telework culture requires planning and insight.  Here are a few things to consider.

Remote Workers Need To Be Engaged

I do my best to follow the rule of communicating with people in the medium that they prefer. I trade a lot of email with the people who, like me, are always on it; I pick up the phone for the people who aren’t; I text message with the staff that live on their smartphones. But, with a remote employee, I break that rule and communicate, primarily, by voice and video.  Emoticons don’t do much to actually communicate how you feel about what your discussing.  Your voice and mannerisms are much better suited for it.  And having an employee, or teammate, that you don’t see on a regular basis proves the old adage of “out of sight, out of mind”.

 In Person Appearances Are Required

For the remote worker to truly be a part of the organization, they have to have relationships with their co-workers.  Accordingly, just hiring someone who lives far away and getting them started as a remote worker might be the worst thing that you can do for them.  At a minimum, requiring that they work for two to four weeks at the main office as part of their orientation is quite justified.  For staff who have highly interactive roles, you might require a year at the office before the telework can commence.

Once the position is remote, in-person attendance at company events (such as all staff meetings and retreats) should be required. When on-site isn’t possible, include them via video or phone (preferably video). On-site staff need to remember them, and not forget to include them on invites. Staff should make sure that they’re in virtual attendance once the event occurs.

Technical Literacy Requirements Must Be High

It’s great that the remote access tech is now so prevalent, but the remote worker still needs to be comfortable and adept with technology.  If they need a lot of hand-holding, virtual hands won’t be sufficient.  Alternatively, the company might require (and/or assist with) obtaining local tech support.  But, with nonprofit IT staffing a tight resource, remote technophobes can make for very time-consuming customers. Establishing a computer-literacy test and making it a requirement for remote work is well-advised; it will ease a lot of headaches down the road.

Get The Policies In Place First

Here’s what you don’t want: numerous teleworkers with different arrangements.  Some have a company-supplied computer, some don’t.  The company pays for one person’s broadband account, but not another’s. One person has a company-supplied VOIP phone, the other uses their personal lines. I’ve worked at companies where this was all subject to hiring negotiations, and IT wasn’t consulted. What a nightmare! As with the office technology, IT will be much more productive if the remote setups are consistent, and the remote staff will be happier if they don’t feel like others get special treatment.

Go Forth And Telecommute

Don’t let any of this stop you — the workforce of the future is not nearly as geography bound as we’ve been in the past, and the benefits are compelling.  But understand that company culture is a thing that needs to be managed, and managed all the more actively when the company is more virtual.

Why I Hate Help Desk Metrics

image
Photo: birgerking

Tech support, as many of you know, can be a grueling job.  There are a huge variety of problems, from frozen screens to document formatting issues to malware infestations to video display madness.  There are days when you are swamped with tickets.  And there are customers that continually broaden the scale from tech-averse to think-they-know-it-all. I’ve done tech support and I’ve managed tech support for most of my career, and providing good support isn’t the biggest challenge.  Rather, it’s keeping the tech support staff from going over the edge.

In our nptech circles, it would be natural to assume that having good metrics on everything help desk would assist me in solving these problems. Good metrics might inform me regarding the proper staffing levels, the types of expertise needed, the gaps in our application suites, all that good stuff that can support my budgeting and strategy. But once I start collecting them I open myself up to that imminent threat that someone else in management (my boss, the board, or whomever) might want to see the metric, too. They want to see are metrics like:

  • Average tickets and calls per day
  • Number of open tickets
  • Average time to resolve a ticket

Their idea is that these numbers will tell them how productive the tech support staff are, how efficient, and how successful they are at resolving problems.

Every one of these is a unreliable metric.  Alone or together, they don’t tell a meaningful story. Let’s take them one by one:

Average daily tickets: This is a number that is allegedly meaningful as it rises and falls.  If we have 30 tickets a day in January, and 50 a day in February, it means something.  But what?  Does it mean that IT is being more productive?  Does it imply that there are more issues popping up? Is it because more people are feeling comfortable about calling the help desk?  If we drop to 15 in February, what does that mean?  That IT has stabilized a lot of problems, or that the users have figured out that others in the org are more helpful than IT?

Number of open tickets: The standard assumption is that fewer is better.  And while that is generally true, it can be deceiving, because the nature of tickets varies dramatically.  Some require budget approvals and other time-consuming delays.  An assumption that tickets are open because the technician hasn’t gotten around to resolving them is often wrong.

Average time to resolve a ticket:  This one is deadly. Because it is commonly used as a performance metric, and that’s based on the assumption that the quicker all tickets are closed, the better service IT is providing.  The common scenario I’ve encountered where this metric is shared with management is that the tech support staff grow so pressured to close tickets that they regularly close them before the issue is truly resolved.  It creates tension with staff, as the real power of a help desk ticketing system is in the communication that it enables, not the communication that it cuts off when staff are not geared toward taking a communicative approach to issue resolution.

Worse, it takes away the technician’s ability to prioritize.  Every ticket must be closed quickly in order to look efficient, so every ticket is a priority.  But, in fact, many tickets aren’t high priority at all.  People often want to report computer problems that they aren’t in a hurry to get resolved.  When every ticket is treated like a fire to be put out, staff, naturally, start getting resistant to shouting “fire”, and stop reporting that annoying pop-up error that they get every time they log in.  They start living with all of the little things that they have inconvenient but bearable workarounds for, and as these pile up, they grow more and more annoyed with their computers — and tech support.

So what might useful metrics to assess the effectiveness of tech support entail? Here’s what I look for:

  • Evidence that the techs are prioritizing tickets correctly. They’re jumping when work stoppage issues are reported and taking their time on very low priority matters.
  • Tickets in the system are well-documented. We’re capturing complex solutions and noting issues that could be reduced with training, fine-tuning or a software upgrade.
  • Shirts are tucked in, hair isn’t mussed, nobody is on the verge of tears. High stress on support techs is usually plain to see.

The type of person that gravitates to a tech support job is a person that likes to help. There are egos involved, and an accompanying love of solving puzzles, but the job satisfaction comes from solving problems, and that’s exactly what we want our support staff to do. Creating an environment where the pressure is higher to close tickets than it is to resolve them is a lose-lose scenario for everyone.

The Nonprofit Management Gap

I owe someone an apology. Last night, a nice woman that I’ve never met sent me an email relaying (not proposing) an idea that others had pitched. Colleagues of mine who serve in communications roles in the nonprofit sector were suggesting a talk on “Why CIOs/CTOs should be transitioned into Chief Digital and Data Officers”.  And, man, did that line get me going.

Now, I’m with them on a few points: Organizations that rely on public opinion and support to accomplish their mission, which includes the majority of nonprofits, need to hire marketers that get technology, particularly the web.  And those people need to be integrated into upper management, not reporting to the Development VP or COO.  It’s the exact same case I make for the lead technologist role.

Let’s look at a few of these acronyms and titles:

COO – Chief Operating Officer.  In most NPOs that have one, this role oversees operations while the CEO oversees strategy and advances the mission with the public.

CIO – Chief Information Officer.  CIOs are highly placed technologists whose core job is to align technology to mission-effectiveness.  In most cases, because we can’t afford large staffs, CIOs also manage the IT Department, but their main value lies in the business planning and collaboration that they foster in order to integrate technology.

Some companies hire CTOs: Chief Technology Officers.  This is in product-focused environments where, again, you need a highly placed technologist who can manage the communication and expectations between the product experts and the technical staff designing and developing the products for them.

IT Director – An IT Director is a middle manager who oversees technology planning, budgeting, staff and projects. In (rare) cases, they report to a CIO or CTO.  In the nonprofit world, they are often the lead technologists, but they report up to a COO or VP Admin, not the CEO.

CMO – Chief Marketing Officer.  This is a new role which, similar to CIO, elevates the person charged with constituent engagement to the executive level.

This is how many nonprofit CEOs think about technology:

Public Domain Image

Say you, at home, have a leaky faucet.  It’s wasting water and the drip is driving you crazy.  You can’t just tear out the sink — you need that.  So you hire a plumber.  Or, if you have the opportunity, you get your accidental te– I mean, acne-dented teenager to read up on it and fix the leak for you.  So now you have a plumber, and your sink is no longer dripping. Great!
Now you want to remodel your house.  You want to move the master bath downstairs and the kitchen to the east side.  That’s going to require planning. Risk assessment. Structural engineering. You could hire a contractor — someone with the knowledge and the skill to not only oversee plumbing changes, but project management, vendor coordination, and, most important, needs assessment. Someone who knows how to ask you what you want and then coordinate the effort so that that’s what you get.  So, what should you do?
Have the plumber do it.  He did a good job on the leak, right?
Every job that I’ve had since 1990 has, at the onset, been to fix the damage that a plumber did while they were charged with building a house.  Sometimes I’ve worked for people who got it, saw that they needed my communication skills as much or more than they needed my technical expertise.  At those jobs, I was on a peer level with the other department heads, not one lower.  Other times, they expected me to be just like the plumber that I replaced. They were surprised and annoyed when I tried to tell them that what they really needed was to work with me, not delegate to me.  At those jobs, I was mostly a highly-functional pain in the ass.

Some of those jobs got bad, but here’s how bad it can get when management just doesn’t get technology.

So, back to my rant, here’s my question: why would we increase the strategic role of marketing at the expense of strategic technology integration?  Is that a conscious desire to move just as far backward as we’re moving forward?  Is this suggestion out of a frustration that people who manage technology aren’t exclusively supporting communications in our resource-strapped environments? In any case, it’s a sad day for the sector if we’re going to pitch turf wars instead of overall competence.  There is no question: we need high level technologists looking after our infrastructure, data strategy, and constituent engagement. But we can’t address critical needs by crippling other areas.

Balancing Act

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.

Keys to the Kingdom

This post was originally posted on the Idealware Blog in December of 2008.

Being a career nonprofit IT type, I’ve repeatedly had the unpleasant experience of walking into a new job, only to find that critical information, such as software licenses and server passwords, are nowhere to be found. So before I can start to manage a new network, I have to hack it. This sort of thing happens in other industries as well, but it strikes me as something that plagues nonprofits. On one extreme, we might have staff who become bitter and malicious as they depart, destroying records and withholding passwords. But even if the situation isn’t that dramatic, keeping track of sensitive, critical data is a bit tedious, and concerns about security and confidentiality make it additionally complex. Protecting and keeping this information available to the staff that need it can save a lot of time, money and frustration. Here are some suggestions:

Follow procedures: in tight budget and staffing conditions, the approach to IT management is often reactive and chaotic. Many key NPO IT Managers came into the role as “accidental techies”, which implies that many nonprofits only support technology by accident. In an environment where the Office Manager, Donations Clerk or a volunteer ends up deploying the servers and installing applications, it’s a safe assumption that there aren’t well-crafted IT policies in place. In this environment, losing critical passwords — or even failing to ever write them down — can be a regular occurrence.

Involve all stakeholders:Don’t assume that your It staff – who are already struggling to juggle the big projects with user support — are keeping good records. Audit them, assist them and back them up. Finance can take a role in tracking license keys along with purchase records. And far too many nonprofit executives don’t even ask for the system passwords. There is no good reason – no matter how many a tech might come up with – why the CEO or head of security shouldn’t keep an updated, sealed envelope with key passwords in the safe in case of sudden turnover or emergency. I’ve worked with a lot of techies who would scream about this. “The CEO can’t have the password! They’ll delete files! They’ll mess it all up!” Well, the CEO shouldn’t use the password. But they should definitely have it.

Foster a culture that allows technology staff to succeed: in two of my personal cases, the staff before me had left en masse and bitterly. They took the main network password with them and wiped out a lot of the IT records. Clearly, this is immature and unprofessional behavior. I wouldn’t think to defend it. But the circumstances that lead some immature techs to be resentful and abusive can be fostered by certain work conditions. If you are a nonprofit executive, there are some things that you can do to create an environment that is less conducive to bitterness and abuse.

  • Have realistic expectations for IT. If you don’t know how easy or hard it is to, say, upgrade a server or roll out a CRM system, don’t make assumptions. Hire a consultant, get a sense of what’s required, and adjust your expectations accordingly.
  • Participate. Have all staff participate in technology planning and adoption. There are people who install systems and there are people who use them. The installation has to be a joint process. Techs can not be held accountable for determining user’s needs, and users can not be solely responsible for evaluating technology. Whenever IT buys the system without user input, or users pick a system without technical oversight, the relationship between IT and staff becomes strained. Joint responsibility and accountability for system choices is required for a healthy environment.
  • Be appreciative. Tech support can be a very thankless job, and the smaller the staff and budget, the less rewarding. When your computer stalls or malfunctions, it can be frustrating. Even if you, personally, don’t take that frustration out on the tech who comes to fix it, are the rest of your co-workers that patient?
  • Don’t hire extremes. When hiring technical staff, assess their people skills. Make sure that their focus is on how technology supports the org, not strictly on the technology. At the same time, assess the non-IT staff for their technical skills, and hire people who are competent and appreciative of technology. We are long, long past the day when all computer support and expertise could be delegated to the IT Department.

It boils down to organizational culture and priorities. The hectic, resource-strained environments that many of us work in aren’t conducive to good record-keeping habits. This problem is bolstered by the general case where upper management is, for various reasons, ranging from misplaced faith to technophobia, not thinking of IT as a keeper of critical organizational records. But the truth is that a failure to keep it all written down is inevitably going to cost you, in dollars and productivity. The best solutions are holistic – create a culture where accountability for organizational assets is clear to all and shared by all, and, in particular, understand enough about the technical demands put on your IT staff – accidental and otherwise – to allow them to prioritize the small stuff along with all of the big projects and constant fires they put out.