This post is about Wikileaks, without being about Wikileaks. We know the most recent Wikileaks release was an overwhelmingly large set of data, generated by a fairly low-ranking intelligence analyst, and contains potentially sensitive information. The aspects of the Wikileaks scandal that fascinate me, however, are the human and organizational factors affecting data security.
Why did Bradley Manning do it? He must have known he would be subject to a long prison sentence (at best), and made no efforts to hide his actions. Assuming he was acting rationally, the benefits he imagined from doing so outweighed the prospect of certain punishment. Manning must have evaluated the volume and nature of the data at his disposal – data owned by his organization, effectively the U.S. government – and chose to place his individual motivations above those of the organization to which he belonged.
His own Wikipedia page and various media reports describe Manning’s “disillusionment,” and some opinion pieces paint him as “disgruntled.”
Disgruntled at the age of 23?
This fact points to the causes of the leak: it’s a people problem, more than an information problem. This includes security clearances, i.e., how many eyes need to see the information, but the solution is not about security clearances. Safeguarding organizational data such as that shared in the Wikileaks event is ultimately a management issue, for the following reasons:
A change in employee behavior is a crucial signal to management. It would surprise me if Manning’s behavior changed overnight from unassuming analyst to data thief. A good manager should look for changes in employee behavior that signal a shift in attitude. Furthermore, a manager should ensure he has enough information to act on if restricting or revisiting information flows becomes necessary, particularly in the event that an employee’s risk profile changes.
Digital natives exhibit different workplace values than their older counterparts. At 23, Manning is a digital native. Individuals under the age of 30 have grown up with technology in a world where a sense of possession is poorly defined in digital terms. Digital natives have a different notion of right and wrong in sharing information than previous generations of workers, even when information is proprietary to their organizations. Generation Y is also less loyal to organizations, and expects authority figures to earn their respect, rather than commanding it automatically. (I realize the Army is a very special kind of organization; however, the military cannot claim to be modernizing for warfare in the Information Age and expect to preserve outdated management philosophies, particularly when recruiting overwhelmingly from the digital natives demographic.)
Technology itself distracts from the human issues. Security specialists discuss access protocols and authentication procedures, but focusing on such issues is like staring at the end of someone’s finger when she points to a mountain in the distance. Internal data leaks are a real threat, but they are also perpetrated by people. The Information Age is changing the relationship between people and organizations. Adding to the urgency of the problem, today’s technological capabilities allow people to share and act on information as quickly as they think to do so. When “think it – do it” is the norm, it is important for an organization’s management to communicate expectations about information use and dissemination and to assess and monitor, in an honest way, the risks associated with information flows.
The landscape of information behavior is undergoing a major shift, and technology is merely an enabler of behavior. An individual’s ability to act impulsively, and with powerful tools that can execute enormously impactful actions digitally, should prompt organizations to manage closely the human aspects of internal security threats. It takes one weak link in an organization – unmonitored, disillusioned – to commit a destructive act with sensitive data. Although individuals should be empowered to make ethical, informed decisions when acting on behalf of their organizations, management culture must continue to adapt to the new Information Age, and its digital natives.
One of my fond memories of working in Finance MIS was a short-lived tradition called “Nerd Lunch.” I and another analyst would log in to a net meeting and work through complicated SQL queries every few weeks. We would brainstorm solutions for ongoing information problems facing our department. I ask you: Has there ever been a more appropriate moniker for an event?
The analyst was my guru. With her help, I went from landing a job where I knew next to nothing about the software I would be using to finding solutions for decision makers in our organization.
I’m writing this blog post because it’s great to get excited about a job posting that sounds perfect in terms of industry, position, and advancement opportunities – but then it’s disappointing to worry about qualifying on ‘Preferred’ software experience. Worrying about software experience may even keep a job seeker from pursuing a position. What follows are tips I’ve found helpful to first get through an interview without perfect software experience, and then to get up to speed quickly in software skills once hired.
For an interview: Likely you will be facing a hiring manager when answering questions about software skills. Before the interview, it is possible you may be able to fully investigate the software – say, with a free trial for more common products. Barring that, prior to sitting down with the hiring manager, I suggest Googling the software listed in the job posting to find its specifications, as well as those of competing software products. This is a particularly helpful step with specialized software, such as enterprise management, accounting or asset management software.
Investigate the capabilities of the software to understand the functionality, and then come up with (intelligent!) questions related to the software’s application to itemized job responsibilities in the position listing. After all, once you get the job, that will be your contribution to the organization. It is most important in an interview with a hiring manager to demonstrate understanding of the role and to express critical thinking skills related to a position’s responsibilities.
Once hired, read a book: Find a beginner’s guidebook to the software if you can. Also, read it. (NOTE: No one really thinks you are a dummy when you read those Dummies books.) Rather than buying it new, I suggest checking out bookins.com, half.com, or posting an ad on Freecycle for a used copy. I’ve always found that starting with these books gives a good comfort level for tinkering in the software, at which point you are ready to sandbox.
Sandboxing: This is when you’ll start breaking existing tools in a calculated way. Set up a dev environment for this step, whatever that may be. For tools that use scripts, like VBA, or query language, like SQL, pretty much everyone learns by stealing snippets from existing tools and modifying for new applications. This is the sort of stuff you can do while waiting on a batch of project work or during down times in cyclical reporting periods. Please do not underestimate the “Help” tool in a software package; these tools tend to get more useful as your grasp on the software jargon strengthens (ironically). There’s no shame in using company resources to iterate and build on your technical skills, particularly if you are the type to check Facebook or text during working hours.
Find a guru: A guru is different than a mentor. This is a person whose geek runs deep, but who has enough patience and time to answer your technical questions. A guru will also have excellent problem-solving skills, in that she (or he) can help you find answers to existing problems by walking you through previously applied solutions in the software tool. Surprisingly, perhaps, a real guru won’t do things like grab your mouse and make a quick fix; that person will have a conversation with you, explore the scope of the issue, and explain in plain language what you need to do. You will learn to deepen the relationship with increasingly thoughtful questions about the work at hand, eventually adding value instinctively. In the long run, a guru’s approach will ideally make you a better thinker.
When this person helps you, be sure to recognize her. Buy her coffee. Send a thank-you email to her boss. Write a blog post about her. Someday, if you care to, you’ll be in the position to act as a guru.
I hope this makes learning new software (or becoming an expert in familiar software) more attractive and less painful. The software is just a tool for the tasks at hand. In the end, you are the element adding value in the position, first by applying software and later by sharing your knowledge.