Tag Archives: policy

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.

The Softer Side Of Security

This article was first published on the NTEN Blog in April of 2010.

As the technical staff at our nonprofits, we wrestle with all sorts of complex security concepts: firewalls, encryption, network address translation.

But here are three quick questions:

  • Would you spend $10,000 on a security system for your building, and then set the access code to “12345”?
  • Would you set the administrative account name and password to your network to the same thing that five other companies in your building use?
  • Would you allow an outside vendor to manage your network without sharing the passwords with you or anyone else at your organizations?

I’ve seen all three of these situations occur, the first two at commercial law firms, the latter at a large nonprofit [disclaimer: not the one I work for now!]. There are some infamous and true stories of clever hacking that played on the human side of security, such as the teenagers who took a couple of clipboards and interviewed people in the lobby of a large office building under the guise of a school project, in the process collecting birthdays; kids, spouses and pets names; street addresses — all things people commonly use as the base for their network passwords.

But all of the sophisticated systems in the world offer little more than a swiss cheese defense if we don’t have good organizational policies to address the human side of security. And even that’s a little tricky, as policies that are too complex for staff to easily comply with will be subverted in ways that open more security holes.

A sustainable password policy requires that passwords be:

  • Of a decent length (7-15 characters);
  • Comprised of a mix of letters, numbers, and/or additional characters, preferably with mixed case; and
  • Not be based on data that can easily be associated with the user, such as kids names or the TV show that they often discuss online.
  • They should also n ot be so obscure (as in “6T5re#bb77l”) that they can’t be easily memorized — that’s a recipe for password post-its!

In addition to maintaining a secure password policy (and enforcing it with network policy automation), staff should be resourced with tools to manage passwords.

There are numerous free or inexpensive applications and services that offer encrypted, password-protected storage for the collection of passwords. Looking for the ones that synchronize to a mobile app will add additional convenience.

From the management level, a best practice is for the lead in IT to print all passwords, seal them in an envelope, and give it to the CEO or HR executive at the organization, repeating (with secure destruction of the outdated list) as passwords change. Twice in my career as a CIO/IT Director, I’ve walked into situations where my predecessors left mad, and took all of the system password information with them, leaving me, initially, unable to manage the networks that I’d been hired to oversee. Don’t put your nonprofits work at risk by omitting this type of failsafe.

All of the port blocking, proxy servers and point to point tunneling on earth won’t protect you from the person who clicks on a malicious link in an email. Only education, communication, and support will address those security holes, and no security plan can be considered valid if it doesn’t incorporate policies along with the technical protection.

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.

Small Footprints, Robotic and Otherwise

Here’s my 11/7/2008 Idealware post, originally published at http://www.idealware.org/blog/2008/11/small-footprints-robotic-and-otherwise.html

As the proud owner of a T-Mobile G1, the first phone out running Google’s Android Mobile Operating System (OS), I wanted to post a bit about the state of the Mobile OS market.  I’ve been using a smartphone since about 1999, when I picked up a proprietary Sprint phone that could sync with my Outlook Contacts and Calendar.  We’ve come a long way; we have a long way to go before the handheld devices in our pocket overcome the compromises and kludges that govern their functionality.  My personal experience/expertise is with Palm Treos, Windows Mobile, and now Android; but I have enough exposure to Blackberries and the iPhone to speak reasonably about them. My focus is a bit broader than “which is the best phone?”  I’m intrigued by which is the best handheld computing platform, and what does that mean to cash-strapped orgs who are wrestling with what and how they should be investing in them.

I wrote earlier on establishing Smartphone policies in your org.  The short advice there was that the key Smartphone application is email, and you should restrict your users to phones that offer the easiest, most stable integration with your office email system.  That’s still true.  But other considerations include, how compatible are these phones with other business applications, such as Salesforce or our donor database? How easy/difficult are they to use and support? How expensive are they?  What proprietary, marketing concerns on the part of the vendors will impact our use of them?

The big players in the Smartphone OS field are, in somewhat random order:

  • Palm: PalmOS
  • Nokia: Symbian*
  • RIM: Blackberry OS
  • Microsoft: Windows Mobile
  • Apple: iPhone
  • Google: Android

Palm is the granddaddy of Mobile OSes, and it shows.  The interface is functional and there are a lot of apps to support it, but there isn’t much recent development for the platform. Palm has been working on a major, ground -up rewrite for about two years, code-named Nova, but it has yet to come to light, and there’s a serious question now as to whether they’ve taken too long.  Whatever they come up with would have to be pretty compelling to grab the attention of customers and developers in light of Apple and Google’s offerings.

  • App Support: C (lots, but not much new; Treos do Activesync)
  • Ease of Use: C (functional, but not modern interface)
  • Cost: C (Not sure if there’s much more than Palm Treo’s available, $200-200 w/new contract)

Nokia’s Symbian platform is notable for being powerful and open source.  It’s more popular outside of the US, I’m not sure if there are any Symbian smartphones offered directly from US carriers, which makes them pretty expensive.  They do support Activesync, the Microsoft Exchange connector, and have a mature set of applications available.

  • App Support: B (Activesync, lots of apps, but missing some business apps, like Salesforce)
  • Ease of Use: B (Strong interface, great multimedia)
  • Cost: D (Over the roof in US, where contracts don’t subsidize expense).

The Blackberry was the first OS to do push email, and it gained a lot of market and product loyalty as a result.  But, to get there, they put up their own server that subscribes to your email system and then forwards the mail to your phone.  This was great before Microsoft and Google gave us opportunities to set up direct connections to the servers.  Now it’s a kludge, offering more opportunities for things to break.  They do, however, have a solid OS with strong business support – they are either on top or second to Microsoft (with Apple charging up behind them) in terms of number of business apps available for the platform.  So they’re not going anywhere, they’re widely available, and a good choice if email isn’t your primary smartphone application.

  • App Support: A- (lots of everything except Activesync)
  • Ease of Use: B (Solid OS that they keep improving)
  • Cost: B (Range of models at decent prices)

Windows Mobile has broad third party support and powerful administrative functions.  It comes with Activesync, of course.  There are tons of smartphones running it, more than any other OS. But the user interface, in this writer’s opinion (which I know isn’t all that pro-Microsoft, but I swear I’m objective), is miserable.  With Windows Mobile (WinMo) 5, they made a move to emulate the Windows Desktop OS, with a Start Menu and Programs folder.  This requires an excessive amount of work to navigate.  If you use more than the eight apps (or less, depending on model/carrier), you have your work cut out for you to run that ninth app. And the notification system treats every event — no matter how trivial — as something you need to be interrupted for and acknowledge.  It’s hard to imagine how Microsoft is going to compete with this clunker, and you have to wonder how the millions they spend on UI research allowed them to go this route.

  • App Support: A (tons of apps out there)
  • Ease of Use: D (the most clunky mobile OS.  Period.)
  • Cost: A (The variety of phones means you get a range of prices and hardware choices)

Apple’s iPhone represents a leap in UI design that instantly placed it on top of the pack.  Best smartphone ever, right out of the first box.  Apple clearly read the research they commissioned, unlike Microsoft, and thought about how one would interact with a small, restricted device in ways that make it capable and expansive.  The large, sensitive touch screen with multi-touch capabilities rocks.  The web browser is almost as good as the one you use on your desktop (and this is important – web browsers on the four systems above are all very disappointing – only Apple and Google get this right).  The iPhone really shines, of course, as a multimedia device.  It’s a full-fledged iPod and it plays videos as well as a handheld device could.  As a business phone, it’s adequate, not ideal.  While it supports Activesync and has great email and voicemail clients, it lacks a physical keyboard and cut+paste — features that all of their competitors provide (although the keyboard varies by phone model).  So if you do a lot of writing on your phone (as I do), this is a weak point on the iPhone.

  • App Support: A (it’s still pretty new, but development has been fast and furious)
  • Ease of Use: A- (Awesome, actually, except for text processing)
  • Cost: B (since they dropped it to $199).

Android is Google’s volley into the market, and it stands in a class with Apple that is far above the rest of the pack.  The user interface is remarkably functional and geared toward making all of the standard things simple to do, even with one hand.  The desktop is highly customizable, allowing you to put as many of the things you use a touch away.  This phone is in a class with the iPhone, but has made a few design choices that balance the two out.  The iPhone makes better use of the touch screen, with multi-touch features that Google left out.  But the iPhone is has far less customizable an interface.  And, of course, the first Android phone has a full keyboard and (limited) cut and paste.  It is, however, brand new, and I’ll discuss the future below, but right now the third party app market is nascent.  Today, this phone is best suited for early adopters.

  • App Support: C (it will be A in a year or so)
  • Ease of Use: A
  • Cost: A (G1’s are selling for as low as $150w/new plan)

The big question, if you’re investing in a platform, is where are these all going?  Smartphone operating systems are more plentiful and competitive than the desktop variety, where Windows is still the big winner with Apple and the Unix/Linux variants pushing to get in.  But the six systems listed above are all widely deployed.  Palm and Nokia have the least penetration and press these days, but they’re far from knocked out.  Nokia could make a big push to get Symbian into the market and Palm’s Nova could prove to be really compelling — at one point, Palm was king of these devices.  Today, the interesting battle is between the other four, Microsoft, RIM, Apple and Google.  Of these four, all but Android are commercial OSes; Android is fully open source.  RIM and Apple are hardware/software manufacturers, building their own devices and not licensing their OSes to others.  Windows Mobile and Android are available for any hardware manufacturer to deploy.  This suggests two things about the future:

Proprietary hardware/software combos have a tenuous lead.  RIM and Apple are at the top of the market right now.  Clearly, being able to design your OS and hardware in tandem makes for smoother devices and more reliability.  But this edge will wane as hardware standards develop (and they are developing).  At that point, the variety of phones sporting Windows and Google might overwhelm the proprietary vendors.  Apple is big now, but this strategy has always kept them in a niche in the PC market.  They dominate in the MP3 player world, but they got that right and made a killing before anyone could catch up; that edge doesn’t seem to be as strong in the mobile market.

Open Source development won’t be tied to the manufacturer’s profit margin. Android’s status as open source is a wild card (Nokia is Open Source, too, so some of this applies).  Apple and Microsoft have already alienated developers with some of their restrictive policies.  If Android gets wide adoption, which seems likely (Sprint, Motorola, HTC and T-Mobile are all part of Google’s Open Handset alliance, and both AT&T and Verizon are contemplating Android phones), the lack of restrictions on the platform and the Android market (Google’s Android software store, integrated with the OS) could grab a significant percentage of the developer’s market.  I’ve been pleased to see how quickly apps have been appearing in the first few weeks of the G1’s availability.

If I were Microsoft, I’d consider isolating the WinMo development team from the rest of the campus.  Trying to leverage our familiarity with their desktop software has resulted in a really poor UI, but their email/groupware integration is excellent.  They need to dramatically rethink what a smartphone is — it does a lot of the same things that a computer does, but it isn’t a laptop.  Apple should be wondering whether their “develop your app and we’ll decide whether you can distribute it when you’re finished” approach can stand up to the Android threat.  They need to review their restrictive policies.  RIM has to fight for relevance – as customer loyalty, which they built up with their early email superiority fades, well, didn’t you notice that Palm and RIM the only names in our list that don’t have huge additional businesses to leverage?  And we, the smartphone users, need to see whether supporting Android — which has lived up to a lot of its promise, so far — isn’t a better horse for us to run on, because it’s open and extendable without the oversight of any particular vendor.

* I have to own up that I’m least familiar with Symbian; a lot of my analysis is best guess in this case, based on what I do know.