The Filing Cabinet Analogy

Your office is cluttered – you have documents all over the place.  The paperless office of the future has not yet arrived, will never arrive, and your hardcopy papers are necessary, important, and accumulating.  You must get them filed for safekeeping, but you also need a system of storage and access:  You require ready reference of the content. 

You call up your supply department and order a filing cabinet.  A few days later, a supply clerk rolls your cabinet in, asking where you would like it. 

In exiting, the clerk wheels his empty dolly toward your door… you say, “Wait!  You’re not finished…”  Bewildered, the clerk asks you what you mean.  You politely gesture to all the stacks of paper on your desk, your table, your office floor.  You tell him that he needs to label the drawers.  He needs to create folders with tabs for various subjects, projects and tasks.  He needs to alphabetize and categorize your paper documentation and file it in the appropriate place in the new cabinet. 

Hmmm… what is wrong here?  Simply this:  You, the recipient of the filing cabinet, expect the supply clerk to do your filing – which is not the supply clerk’s job.  The supply clerk has delivered a system for filing – the recipient must file, or delegate that to relevant department staff.  But realize too:  the cabinet’s recipient must not only use and administer the “system,” – the cabinet, drawers, folders, and setup of information storage – the recipient must do some initial configuring and setup of that system.  After all, it is the recipient who best understands the business requirement of that system (the labeling, categorization, etc. that is necessary).

Now, we know that no one would ask the supply clerk above to do that filing – or configuring – yet IT finds itself in that very position as it delivers its “filing cabinets.”  Often times business systems are delivered, and IT is expected to set up such things as finance codes – and to maintain them.  Why?  Business uses those codes, and should have an intimate knowledge for best codes:  syntax, how many, subcodes, inter-relations… and on and on.

We’ll examine this example in the next days, but it is business’ “filing cabinet” of codes to maintain – not IT’s.  IT can assist with suggestions for entering and structuring the codes as necessary, but IT should not determine the business-mechanics of the codes and their fit and inter-relationship to business.  Further, this is just a sliver of an example:  IT is frequently bled across lines of diminishing returns; maintaining all sorts of business structures, rules and updates – that are squarely within any reasonable person’s definition of business responsibility.

Yet IT is often tasked precisely the wrong way, taking time away from the rush of security challenges, best progressions, and vision to the horizon of accelerating challenges…

Stay tuned…

On this day (August 13^th):  In 1907, the first taxicab begins operation in New York City.

Many of us have seen situations where a person of considerable general competence accumulates duties – like a magnet.  They attract responsibilities that in some cases go far afield from that which they’re supposed to be doing.  Why does this occur? 

It is often expedient – and perhaps even necessary – in an environment where other people are not held to appropriate standards of performance.  Many times conscientious people volunteer to get the job done – whether it’s in their sphere or not – and deliver on whatever the task, whatever the assignment. 

Neither Business nor IT should skew work that way.  Don’t build up a position as a reaction to ‘negatives’ – and inadvertently create a hybrid position that is difficult to maintain in the longer term.  A “Frankenstein” job position:  Particularly for small-to-medium business (SMB) environments; take heed.  Particularly as you grow, be absolutely certain that leadership and HR begin to put formal, tried-and-true (longstanding, effective, efficient) Position Descriptions and definitions in place.

Too frequently in the SMB environment, a position is cobbled together from many “parts” (disciplines, requirements and exigencies) without regard to best practice, known IT definitions, or long-term consequences.  Many times Business goes right along – the ultimate stakeholders.   For their part, HR often does not dictate adherence to appropriate definitions and distribution of duties.  Nor does IT’s ultimate executive management do this.  Frankly, oftentimes no one knows any better – or the organization deliberately ignores deviations in trying to soothe the pain of the moment. 

Today’s Expediency – Tomorrow’s Emergency

Why would any organization or leader create positions of this nature?  Organizations create hybrid, Frankenstein, positions in order to keep their staff small.  The problem that arises is that, as the particular disciplines’ sophistications increase within the umbrella of the Frankenstein position, more and more time to manage those disparate disciplines is required.  It becomes difficult to train up for the changes – akin to having a foot in two different boats, each beginning to diverge.  It’s one thing to track the requirements and attend a schedule of training in remaining current in a particular field of endeavor, or fields closely related and supporting; it’s quite another challenge to remain current in a variety of disciplines – too often training is ignored or missed due to the sheer challenge in covering disparate environments.  A point of diminishing return is quickly reached. 

Consider too that when a Frankenstein is removed from the environment for one area of training, you are removing your support to the broader range of disciplines supported within that position.  This is inefficient.  You may put the entire gamut of disciplines at some measure of risk (whether this person is absent through training, or other loss). 

Not everyone has to be a specialist, and there are always degrees of exception to everything.  However, if you have extremely disparate disciplines under one job position, they will become increasingly difficult to straddle, the job will become increasingly difficult to do, increasingly difficult to populate, and there will be increasing difficulty in maintaining currency.

Where possible, and as work increases in your IT department, or as certain disciplines start to require more time, you’re better off creating a new, entry level position and hiring a relatively junior member to populate it.  Step that person up over time as the position demands an increase in capability and responsibility.  Alternatively, you can “hire up” slightly when there is turnover, and boost the position description to reflect new realities. 

You not only risk stretching people too thin, and putting coverage at risk:  Good people can become frustrated.  When good people tire of covering too many disparate bases – or worse, other people’s bases – they’ll seek greener pastures where they can concentrate on an appropriate contribution on a better functioning team. 

On this day:  July 30, 1928 – George Eastman demonstrates the first color movie.     

If you’ll bear with me, I may have a rather novel use for a Content Management System.

I had a question from someone recently:  “What is a Content Management System?” (CMS).  Great question -  further, what can a CMS become?

I was presenting a rather high-level view of The Business-Technology Weave, so I mentioned briefly that a Content Management System enables the efficient control and use of information in the organization:  setting triggers for archive, destruct, filing… sometimes just the removal of data from the “active environment” to preclude a glut of information.

It’s so much more of course:  It’s the assignation of metadata (simply:  data about data), tags, “handles,” for the ready “pull” of data into whatever reporting you need.  It sets classifications for data.   A CMS can cough up abstracts for larger information elements:  pointing to papers, reports, related volumes of information – independent of whether reinforcing-content is a document, spreadsheet, presentation, record in a database… info in your finance and accounting system – that is, independent of where content resides (system, building, desk… electronic or paper).  CMS manages the content contained within large, sophisticated, data repositories.  (CMS is a very large subject:  There’s an entire chapter on content and its management in I.T. Wars).

Therefore, CMS grants the ability to leverage dispersed and formerly hidden content, in bringing together scattered information assets that may be silo’d in diverse systems, repositories, departments, and so on.  A good CMS even documents the location of content that exists solely on physical paper assets.

In looking at the Social Security Administration (SSA), and related problems with their new data facilitiy and allied project, I wonder if CMS was being employed in any way? 

Most folks assume CMS is for the tracking, leveraging, reporting, and managing of information – for sole purpose of delivering to the “outside” mission.  That mission can be educating students, selling widgets to customers, providing legal services to clients, manufacturing cars, surveying labs for regulatory compliancies…  managing and dispensing payments to social security recipients…   the mission can be anything.  The “doing” of whatever it is you “do.”  Most folks employ CMS largely for what I’ve mentioned above.

But CMS can do something that may be a rather novel application:  You can register and track assets – an inventory (nothing new there), but one with “tethers” – the metadata to note any asset’s relationship, support to, and vulnerability within other supports, against all other inventoried assets – “CMS’d” assets.  I wonder if anyone is utilizing CMS in this manner?

Once all assets are “CMS’d”, keeping up-to-date is fairly easy:  Upon procurement of any resource, it is a fairly rapid and efficient task to create a record in a CMS for it.  Populated are key metadata fields with the date of procurement, purpose, class of employees supported, some history regarding the vendor (years in business, size, market presence…etc. – yielding anticipated longevity), and all associated assets and systems with dependencies and supports.  A general notes section adds to the metadata, all searchable within CMS, blooming any and all of the organization’s critical infrastructure and systems supports and dependencies; anticipated dates of major updates; anticipated dates of obsolescence, or consideration thereof.  As to that consideration, remember BIT anyone?  Ah… it all weaves together…

This does a couple things:  You don’t get surprised by antiquated, incompetently produced, cabling schemes that grew over the years as different people procured new systems, stuffed more cables under a raised computer room floor, cramming them in until it’s a snake pit.  A snake pit with no accompanying documentation or possibility of anything resembling this millennium’s best-practice-discipline of Wire/Cable Management.

Critical power sources are not located near water.  If they are, a plan for the relocation of power (or water) is at least considered.  It goes somewhere on the Five Year Plan (hopefully more near-term than far), and gets budgeted and scheduled according to the other priorities and initiatives in the organization.

It may seem a burden to administer this – but you have someone, or a whole department, inventorying already:  This is an inventory with relationships; the who, what, when, where and why for each asset, its intentions, and its relationships.  It can be done; with efficiency and accuracy.  Then turn the CMS wheel in updating, retiring, acquiring, and blending all assets for maximum gains vis-à-vis ROI, TtV, and TCO.

The Weave; it serves.

Thought for today:   

Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment.  Most people are even incapable of forming such opinions.   - Albert Einstein

In the wake of my two-part article earlier this month, Systems Security – Service, Success and Longevity; and its follow-on, Systems Security, Part II:  Social Security Administration meets the real world, comes word of another government project with lessons for us all.

I truly don’t mean to pick on the Federal Government (they’re bigger than me).  However, Government projects provide nice lessons for several reasons:  The projects are projected on the maximum screen of national import, reporting, and observation.  Further, they are projects that affect us all. 

And being that we pay for them, we should benefit from them – we should demand benefit – that is our rightful expectation.  However, even in the event of failures, we can perhaps yet realize a benefit:  We can learn what to avoid from their mistake(s), and look to the legitimate paths for forward progressions and true solutions.

Just within the past few days, the Department of Homeland Security (DHS) announced that it is abandoning the present project to emplace a virtual security fence along our border with Mexico.  The Secure Border Initiative (SBINet) is now a $3 billion program failure, and that is the huge, and sad, milestone.  Homeland Security Secretary Janet Napolitano announced, “SBINet cannot meet its original objective of providing a single, integrated, border security technology solution.”

This specific virtual fence was to seal our nation’s border through use of cameras and sensors.  As being crafted by Boeing, the system was to alert the U.S. Border Patrol as well as law enforcement authorities.

The project ran into technical difficulties.  As the timeline stretched and technical problems increased, it was discovered that other companies had viable technology that was already available on the commercial market. 

The conditions represented a failure of the Government’s to know exactly where it was.  We’ve said before:  Before plotting any project’s path and destination (it’s activities, deliveries and solutions), you must know where you are.  You cannot possibly plot a destination – a solution – without a true begin-point.

Tell me how to get to Chicago; right now, in the Comments section to this blog.  What is your ultimate question before advising me?  “Where are you now?”  In other words, from where am I departing?

Amazingly, the Federal Government could not have known, could not have surveyed effectively, “where it was.”  If it did, it would have planned a project that leveraged readily available products and solutions, in supporting the ultimate solution.

At present, the plan is to use commercially available drones, thermal imaging devices, mobile surveillance systems, tower-based surveillance, and a measure of Boeing’s elements from the original project.

It’s interesting to note that the Chairman of the Senate Homeland Security and Governmental Affairs Committee, Sen. Joe Lieberman (I-Conn.), said that he hoped the “new route” chosen by DHS will be an improvement.  Me too.

But consider “new route” – yes, this phrase reinforces our take on reaching a project destination:  it involves a route, comprising a valid starting point, and a realistic destination.  Properly mounted and managed projects have valid, known, beginning points, routes to destination, and the final arrival of a go-live:  A  serving solution.  All, hopefully, done according to empirical measures, timely milestones, and monitored progression within an agreed budget.

Before mounting any major initiative in your organization, be certain to know:

Where You Are:  Includes buy-in from all stakeholders; survey of what’s available in supporting solutions, what’s needed, what’s affordable, and what will be supported by governance.

Where You’re Going and How:  An agreed project progression, with empirical measures, supported by tools and systems, along with the sanctioned “who” for doing “what.”  All done with appropriate exposure and total agreements. 

The Destination:  Ensure the project delivers what is truly needed.  Pin down stakeholders, Business and IT.  Understand governance, and guidance, thoroughly.  Reach the destination in a timely way:  according to the project management plan; hit the go-live date. 

Doing that requires a true project, true management of it, and the originating understanding of exactly where you were, and thorough understanding of where you’re going (where you need to go, according  to the organization’s needs and aims).

DHS didn’t know where it was (by virtue alone of failing to make robust use of existing products – survey where you are by understanding the total swim you’re in).  DHS didn’t craft a valid route to destination, and this particular version of the project will never arrive.  DHS has started over.

Learn.  In the next days, I’ll further outline some “Where We Are” factors, and more considerations in “Where We’re Going” when mounting projects.

NP:  Herbie Hancock, Sextant.  Original LP.  Weird album.

What is the most critical element, or factor, in any system’s security? 

In other words, what most influences its strength against breach, its level of invulnerability to corruption, its flexibility and scalability for new business circumstances and progressions? 

That critical element is human beings.

Occasionally when I consult, I hear groans:  Oh no – please tell us it isn’t so…  human beings?  That most volatile, transient, and intractable resource?  Sure:  Everything begins, proceeds, and ends with the employees – from CXO to intern. 

Like it or not, people are our greatest challenge – and, I sincerely hope too, our greatest reward.  We all love working with great people.

Whether procuring new systems, planning and changing existing ones, or just exercising a system’s day-to-day production, it all has to be done within the surety of best business/technology practices.  And, in the vast majority of organizations, during the vast majority of time, things are done that way.  But what of human error when it leads to poor business decisions?  Or poor IT outcomes, and resultant poor deliveries or service to business?

What of harmful actions delivered by malfeasance?  What do we need to consider in preventing bad outcomes, and in recovering from them once occurring – and what do we do to improve, and guard against recurrences?

When considering people and their vulnerabilities – and thus, vulnerabilities in and to systems – the leader must consider three things that can “breach” a person’s solid, stable, performance:

Internal state:  Evaluate employees on their fit to the job; on their happiness in it; on their goals and aspirations; their overall morale…

Practices (that is, their ways of working):  Naturally you must ensure the organization does its part in orienting and training employees.  Also, measure individual employees general work ethic, standards of quality, adherence to care, attention to detail, etc. as to how effectively individual human practices fit to and support your organization’s best practices.

Surrounding environment:  I doubt you’d work on your car on a frozen pond wearing ice skates.  The proper environment, tools, and teamwork is crucial.  Ensure people’s best chances for success – and therefore your org’s – by instituting knowledge-shares and ready access to the best tools; whether that’s programming tools, backup systems, content management, policy & procedures, planning, etc., be certain you’re up-to-spec in all functional areas.

Ensure you’re supporting your people through regularized education, training, and counseling.  Then, stop looking at your people as human resources:  It’s gonna be 5 o’clock – buy ‘em a dinner and be sure to tell them it’s from me.

NP:  Bessie Smith, Empress of the Blues, original Columbia 4-disc 78 RPM set in original binder:   C-31.  Nice.

Three Plan Types

IT’s general support to the Business-Technology Weave can be effectively planned and managed through three major plan types.  These are the high-level, across-the-board support plans – which acknowledge and mark the upcoming projects. 

We’ll refer to these IT-Business support plans as the Five-Year Plan, the One-Year Plan, and the Individual Action Plan.  You may wish to label these plans differently in your organization; you may need to look further into the future with a ten-year plan – or more.  But here we’ll use these generic names for ease.  Let’s take a brief look at each plan type, how it relates to the other plan types, and how together they help maintain your directed change, and adjustment to outside, impacting, change. 

The Five-Year Plan

The Five-Year Plan begins with the upcoming (next) calendar year, and extends through each of the upcoming five years.  The upcoming first year becomes the organization’s detailed One-Year Plan, upon the turn of that new year.  Therefore, the first year of the Five-Year Plan should contain everything you intend to do in the upcoming year.  Since the One-Year Plan is the near-term focus for what needs doing, it should be as detailed as necessary – it is executable in that it has been vetted and sanctioned, is budgeted, has been announced, and all preparatory steps have been taken for each element of the plan.  It matches the organization’s business expectations, needs, and overall business plan for the year.  Also, the One-Year Plan spawns all of the detailed project plans and individual action plans as necessary for the organization’s various managed projects and changes.  The organization’s overall project management benefits from the coordinated tracking on the Five and One-Year plans; supports, dependencies and competition for resources can be adjusted in maintaining optimal results.

The Plan’s Progression:  Years Two, Three, Four and Five are progressively less detailed, respectively, as you consider periods of time that are further out from “now.”  Looking out to Year Five, we can see that in a year’s time, its detail and plan moves into the Year Four slot; the former Year Four is now Year Three, and so on.  At each turn-of-year, a new Year Five is added to the back of the plan.  As each year of the Five-Year Plan marches toward you, it is massaged into better focus; adjusted according to changing business priorities or objectives; availability of resources; advancing technology; changing environment; and new methods and practices.  There is an ongoing maintenance for the organization’s alignment of business and technology.  Eventually, our original Year Five clicks forward, having evolved and focused according to needs, until it moves into position as the One-Year Plan.  In this manner, we find that a properly maintained Five-Year Plan can efficiently generate a comprehensive, executable, sanctioned, and aligned One Year Plan.  This means that an organization’s staff is fully informed and qualified to tackle the forthcoming changes, and changes align with business needs in fulfilling expectations accurately, comprehensively, and efficiently.  

At any given time, we can expect that Year-Two doesn’t have quite the focus or detail as Year-One – however, most major initiatives are known and a fair amount of detail is present.  The more distant years will have large bullet items without a lot of detail, because technology and business factors change, sometimes radically, over a period of years.  Your Years-Four and Five may even contain rather whimsical “wish-list” type of items, just to keep them on the radar.  Your organization may have potential mergers or acquisitions under consideration, which will require different technology and business practices – these considerations can call for placeholders on the plan, ensuring some exploratory discussion and gathering of pertinent information.  These efforts establish and define a ‘where we are,’ also project a ‘where we’re going,’ and ensure the start of a bona-fide, progressive, route for future actualization. 

The Plan’s Direction and Flexibility:  Planned items can go one of two ways:  Some things become certified as bona-fide objectives, and additional detail is accumulated and added to the plan.  Just as importantly, other things may be dropped due to a change in business priorities.  Likewise, other things may pop on as completely new items.  The flexibility of the plan means that you may “bump back” certain items over the course of a couple months, or even years – maintaining them as placeholders – perhaps until a return-on-investment threshold is reached.  Other things may “heat up” and slide forward. 

At the same time, the Five-Year Plan cannot simply be a receptacle for every crazy brainstorm or trendy practice that comes along.  It must represent a managed plan that adheres to the true needs of the organization, as best as you can determine them at any given time. 

The Five-Year Plan (or any long range plan) also does something else that’s very important:  it should not only expose dependencies, but should also show vulnerabilities and strengths.  For example, if your plan is to implement a new content management system in the course of the next few years, you may need to consider an upgrade to your hardware platform and infrastructure.  Your plan may have to accommodate new fileservers and workstations, for example.  You’ll have a significant training and support burden.  Once that decision is made, it may be evident that another project that was waiting for these upgrades can now move forward.  The preparation and timing for implementation of many things will coordinate nicely through the plan. 

Remember:  As the first year of the Five-Year Plan becomes the current year, that part becomes the new year’s One-Year Plan.  The Five-Year Plan adds a year at the end of its range, is populated as necessary over the course of time, and all years are updated and tuned accordingly.  A properly maintained Five-Year Plan not only means that you know where you are, and where you’re going, but also means that you’ll always have your One-Year Plan ready at the beginning of each year.  In fact, you’ll have one-year plans under development for each of the next five years.  That is managing change as a continuum.  Also keep in mind that you can project further if you feel you need to.  Just remember to match your time and effort to the likelihood that a particular plan objective will actually be undertaken.

Coming:  The One Year Plan, and the Individual Action Plan.

October 31^st:On this day in 1956 Brooklyn, NY ended streetcar service.

Wow.  I was reading an article in InformationWeek magazine:  The Top 10 Security Challenges for 2010.  I guess I’m slowing down:  The article is from January 2^nd.  Ahem, however -

There’s a great, great, line in the article – I wish I’d written it, but I’m happy to source it:  Speed may be Google’s most cherished goal, but it also increases the velocity of risk.

The “velocity of risk”!  That is an incredible concept:  Velocity’s definition comprises speed paired with direction.  In other words, 35mph is an indication of speed.  35mph due North is velocity.

But, what is Velocity of Risk in an IT/business sense? 

Well – risk now arises quickly, and comes from many directions:  The cloud (internet apps and services), social networking sites such as facebook and MySpace (just recently suffering its own breach), business sites such as LinkedIn, real-time enablements like Twitter and chat agents… and on and on and on….   you get the idea.

So, we can see that risks stream toward us from many directions (sources), and risk speeds toward us (opens quickly) – in both the unmanaged (or poorly managed) environment; but also too often in the best, most carefully managed, environments.  Unmanaged risk opens, and will ultimately deliver, incidents of directed harm in the form of malware, hacks, etc.,  and incidents of inadvertent harm (lack of centralized data/nightly backups, as one example).

A tenet from The Weave that we’ve hammered many times:  In the realm of risk, unmanaged possibilities become probabilities.  And quite naturally, an ongoing situation of probability will deliver in the course of time  - it’s a guarantee:  data breach, identity theft, corrupted data, applications crash… followed by costly recoveries… or – loss of business reputation and customer-faith.

When IT and Business converse across the table, be sure to discuss risk management, associated costs, and delivery of protections (ROI) in a specific context.

That context is Velocity of Risk.

NP:  Rolling Stones:  Metamorphisis.  The opening track - the alternate take of “Out of Time” - is worth the price of admission.  On vinyl.  Next week, some NPs involving hardcore Blues on original 78 rpm.

We’ve discussed WorkOns and WorkWiths – let’s wrap this series up with the WorkFors class. 

These are the folks who “work on” you – the IT leader – and include any entity or individual who has sway over IT-business matters.  These are your direct supervision, senior management, your governance committee members, your board, and other senior players who have influence.  It also includes clients, members, and customers.  For your organization, it may include regulatory bodies or government agencies.  But the steadiest and most influential WorkFor interactions will be with those superiors in the organization itself.

For the IT leader, you must embrace the fact that many, if not most, of these people are not particularly interested in information technology.  Even when they are, they don’t have time for a lot of details.  They are not oriented to details – at least in a situational sense.  They don’t have time for details – they have people working for them that attend to those.  You for instance. 

WorkFors are big-picture players, and are focused on results.  They’ll want to hear about solutions, not problems.  They want to hear about progress.  They want to hear about productivity and efficiency.  They want to hear about success.  Keep in mind that anyone you speak to in this group, no matter how highly placed, has to report to someone too.  Their burden for delivering success is in an arena of stress that is likely greater than yours. 

In order for you to succeed, you must align your resources and methods so that you deliver consistent success to this group.  If you’re escalating problems to the WorkFors, you have not done your job effectively at the WorkWith and WorkOn levels.  You have not established your sanctions, sponsorships, and you likely have failed to make the sale (in terms of cooperation, teamplay, etc.).  Perhaps you’ve exceeded the limits of your lead.  Remember this:  If you start to sense yourself as tipping toward a “problem reporting” stance when engaging with the WorkFors, as opposed to a “success reporting” and summary style of communication, you must make immediate adjustment.  A qualified exception is your interaction with your direct supervision.  Here, you’ll iron out problems and strategies.  But even here, you must present solutions – you must have a positive answer for moving business forward. 

As you may suspect, TechnoShines can be rare in this group.  There is an overwhelming majority of TechoFinds here, and a sizable proportion of TechnoBinds.  The heavy proportion of TechnoFinds in this group works to an IT leader’s advantage, and also to any Business manager when interacting and discussing the Weave.  That’s because WorkFors rely on your knowledge and the strength of your position to pilot the organization into the future.  Once you’ve established a sound reputation with this group based on solid performance and trust, you should find very rewarding relationships.

It should be a rare situation where you go to this group to lobby for relief – but if you feel you must, or if you have a special relationship at this level whereby someone specifically wants to be kept apprised in a more detailed fashion than is usual, you must yet remember your audience.  Keep things very focused, very positive (even when reporting problems), and make certain you pose valid solutions to problems in a positive way.  Your reputation should be such that you are seen as the facilitator to progress.  Nothing is personal, everything is business.  Nothing is personal, everything is business.  It matters not how some others engage – this is your engagement, and this will be your reputation’s enhancement of your credibility. 

Those that facilitate progress will ultimately cook to the top, regardless of temporary setbacks or small, inconsequential, battles lost.  Keep that larger picture in mind when talking to the big-picture people.

You will find three kinds of people in the WorkWith group.  (Indeed this next examination of people in the Weave can be applied with equal vigor to WorkOns, WorkWiths, and WorkFors.  But there is the most significant representation and impact inside the WorkWith group). 

The three kinds of WorkWiths are: 

     1) TechnoShines:  Those who like technology, embrace it and look for ways to leverage it.  These people partner well with IT.  They go out of their way to cultivate good relations with the IT staff.  They appear happy, well adjusted, participatory, and understand technology quite well – therefore, they use technology very well.  They are generally pleasurable to work with for these reasons. 

     2) TechnoFinds:  There is then that kind of person who is ambivalent about technology.  The “just show me what to do” types.  Give them a computer, keep it running, and you won’t hear too much from them.  They go with the flow.  They “find” that there’s a change coming, and roll with it.  We can think of them as having a sort of benign “whatever” attitude, and they deal with whatever comes down the pike.  These folks can’t be counted on for any groundbreaking suggestions, but they are generally positive – at their worst they won’t actively inhibit progress.  As they find that they’re in a Business-Technology Weave, they can be counted on to do what is necessary. 

     3) TechnoBinds:  The third kind of person is someone who seems unable to appreciate technology.  They may view it as a necessary evil – and worse for them, it is constantly evolving.  I hesitate to use the word techno-phobe here, although there are those.  But most of the people we’re considering in this category are able to use technology, and many very effectively. We know that within the Weave they pose a problem because they generally don’t treat IT matters well, and they don’t treat the people in IT very well.  Whether through extreme criticism or negative attitude, at best they slow progress and at worst they may halt it; they bind things up. 

Having defined these folks, let’s examine them closer.  It should be easy to slot the WorkWiths in your organization into one of these three groups.  Recognizing them and their corresponding behavior helps to work with them as effectively as possible. 

TechnoShines, TechnoFinds, and TechnoBinds in Detail

The TechnoShine:  The TechnoShine is a satisfying, even fun, person to work with.  Don’t underestimate the power of fun.  People are going to be a whole lot more creative, resistant to negative effects of stress, and much more productive if they feel they’re having fun and working with fun people.  This person is always looking for “the better way” and is enthusiastic regarding improvements – thus they bring enthusiasm and energy to change.  They work well with others, in and out of their department, and this carries over into their appreciation for what others do.  So how do we manage this WorkWith person?  What is the leverage in maximizing this person’s potential, contribution, and influence?

This person is an obvious candidate for the BIT team.  They will not only represent their department well, but they’ll have an overall appreciation for the organization’s business.  This kind of person tends to build time in an organization.  They’re well connected politically.  They don’t “job hop.”  They have important institutional knowledge.  They give credit where credit is due.  They will make suggestions regarding best-practice with appreciation for how it will affect, and enhance, other departments.  In fact, they make suggestions regarding other departments in a way that is not intrusive, but helpful and acceptable.  They also accept suggestions and criticisms very well. 

In addition to soliciting this kind of person’s participation on the BIT team, you can employ them to serve as a liaison.  Often they’ll become an informal liaison between their department and IT anyway.  However, the IT leader should push this kind of arrangement.  During large-scale implementations, someone in each business department needs to take the lead anyway in collecting business requirements and helping to translate those into effective solutions.  No less important, the TechnoShine can help buffer IT from some of the more difficult people in their area.  TechnoShines by nature are informal sponsors for initiatives, and IT in general, by virtue of their positivity.

TechnoShines are necessary to BIT endeavors.  However, don’t load the BIT team with TechnoShines to the exclusion of other valuable people who may not rise to this level.  You will have to have representation by virtue of position and influence, as well as ability. 

The TechnoFind:  The TechnoFind is a person who adjusts to the temperature around them.  They “find” that technology is permeating everything.  It is an increasing influence on the part of their daily lives, both in the professional environment and the personal arena.  They adjust. 

TecnoFinds do what is necessary, and little more.  They don’t like sticking their necks out.  Therefore they don’t make waves – which in itself can be valued in many circumstances.  They’re safe and practical people – they avoid risk.  So, how can we leverage this kind of person?  Should we merely be satisfied that they, at least, won’t “muck things up?” 

Actually, this kind of person is very useful.  TechnoFinds tend to be very honest about system performances and deliverables.  They are not idle complainers, therefore a criticism usually has value.  Nor do they “inflate” technology’s contribution.  They don’t seek to hang every bell and whistle on a system to the point of a diminished return.  Theirs is usually a very balanced, informed opinion.  They want to know how to get their job done – they’re not fooled by the “sizzle” and want the steak.  Most of the people in any organization will be TechnoFinds – therefore, you must satisfy this important majority.  This person is invaluable for feedback – how’s the new software performing?  How is your remote-access working?  Are you satisfied with HelpDesk support?  Since TechnoFinds will likely make up the majority of an organization’s staff, surveying them and exercising improvements in service to them is a winning combination.

But don’t look to this kind of person for a leadership role.  You don’t want to select this person to oversee their department’s implementation of a business software application module, for example – unless there is no other choice.  This person may or may not be a good choice for participation on the BIT team.  Remember, the BIT team’s seats are valuable.  The people who occupy them should be those who are informed enough to contribute, who desire to contribute, and who have the institutional knowledge and the good judgment to occupy one of these important seats.  A TechoFind person simply may not qualify. 

However, in an instance where you must have a department’s representation on BIT, and the department is populated by TechnoFinds, you must choose the best person by virtue of position and influence.  Too, a TechnoFind may outclass certain TechnoShines by virtue of deep business-knowledge and sheer know-how in other areas.  Choose that person who best meets the diverse qualifications necessary to moving business forward.

We can’t afford to imply here that TechnoFinds are unlikely to make a contribution or deliver anything of value in contributing to the Weave’s momentum.  For example, solicit this person’s contribution when conducting requirements-analysis.  For the reasons stated above, this person will know the practical side for getting work done, and will be very matter of fact about what a new system needs to do.  They’ll have high expectations in meeting and beating what the old system did, as you can usually rely on them for the pragmatic view. 

The TechnoBind:  Uh-oh.  The time has come to discuss that kind of person that we’d all rather avoid, but that we must, alas, deal with.  We must try to discuss TechnoBinds in keeping with the overall positive tone of our discussions, but there are some simple realities that we need to examine if we hope to overcome the obstacles that TechnoBinds can impose.  Let’s define the TechnoBind in plain language – then we’ll discuss methods to blunt their influence, and where possible to neutralize them.  We’ll also note that TechnoBinds are frequently correct, and can contribute on occasion.  However, it is necessary here to recognize their contribution to inefficiency.  We’ll need to know how to identify them, and how to best handle them.

TechnoBinds can be very negative people – and frequently are complainers.  Therefore, when they’re in a Business-Technology Weave, IT represents a fat target.  So, too, does work in general.  Because TechnoBinds aren’t interested in acclimating and moving forward at an efficient pace, they contribute to their own, self-reinforcing, “complaint-ready” environment.  Be aware that TechnoBinds are a counter-productive influence on everything they come into contact with: their department, group projects, other’s attitudes, and so on.  They may not drive things backward, necessarily, but they create enough of a drag on events that they s-l-o-w things significantly, if not carefully managed.

Next and last in this series:  We’ll look at the WorkFor group – those folks we report to.

I think we all believe that IT professionals have unique challenges within support and betterment of business.  In understanding all of the people around us, we can come to better interactions.  Better interactions will yield success, promotion and achievement of your career goals – in addition to furtherance of business’s aims and success – no small thing!

Let’s pick up our discussion by examining the class of employee I call the “WorkWith.”  Remember, this second group is IT’s fellow managers and business staff – co-workers with whom IT has no direct formal control from a management standpoint.  They also comprise middle managers, controllers of business process, and are neither too senior nor too junior.

The WorkWith group helps to select and plan the future courses of business.  Many WorkWiths will be on the Business Implementation Team (BIT – see post of Mar. 8)  Here there can be a compounding of risk for change in behavior.  This is because (as with WorkOns) WorkWiths are frequently required to assume greater responsibilities within the scope of their present responsibilities – but the compounding factor is that they also have to manage and direct change.  This group is especially active in the preservation of order amid change, and the preservation of change amid order.  In planning and managing change, those involved have to stick their necks out.  Simultaneously, they have to cover the bases.  WorkWiths have to deal with consequences and are on the hook to report what’s going on and why.  They have to answer for things.

Too, the WorkWiths are likely in the middle – situated between the WorkOns and the WorkFors.  There is a special challenge to this group, because they’re not only communicating within the Weave – speaking with special care to Business and Technology – but they also have to communicate up and down the organizational hierarchy.  Theirs is a special balance.  For IT, let’s examine how this person may appear to you when changing groups.

Essentially, any WorkWith shifts and becomes someone you WorkFor when you’re dealing with him or her as a customer (as does anyone, in any group, for that matter).  Whether you’re updating the WorkWith’s department’s PCs, implementing new software solutions, or addressing general support concerns, you’re working for this person and you have to provide service to their satisfaction.  In these cases, the WorkWith can become demanding, even unreasonable, as the power tilts their way.  They have to get the job done and you have to deliver.  In this case, it helps to understand the pressures a particular WorkWith may be under.    

Next, we’ll examine three kinds of WorkWiths (TechnoShines, TechnoFinds and TechnoBinds) before wrapping up with WorFors.