Tag Archives: leadership

Developing a social media policy for your enterprise? Use bottom-up design principles

In response to the explosion of use of social media and collaboration tools over the past 12 months, many organization leaders (e.g., CIOs, CPOs, etc.) are developing formal Social Media Polices to guide their staff in approved use of these tools inside the enterprise. Their challenge is to ensure staff use social media in ways that comply with both the enterprise’s mission and general policies—without overly inhibiting the benefits of open collaboration. By starting from bottom-up design principles, leaders can create Social Media Policies that productively encourage creativitywithout risking their enterprise’s mission and reputation.

Enterprises routinely start with a top-down approach

HierarchyEnterprises traditionally employ top-down approaches when defining standards, policies and procedures. This is natural and unsurprising as the majority of enterprises are hierarchical entities.

Top-down approaches are great at driving compliance

Top-down approaches are very effective when the goal is to prevent outliers and discrepancies. Their use is ideal when you want to drive adherence to things like plans and regulatory compliance.

However, top-down approaches are counter-productive to encouraging creativity

Creativity is not something you can drive on demand, from the top downward. Have you ever tried to order a team to be creative according to a plan? If so, did this produce the results you desired? Likely not. Creativity needs to be encouraged, not driven.

Social media requires a bottom-up approach

Social media is inherently non-hierarchical. It creates a “flat” network that enables all members to participate in the same way, regardless of level, time or location.

Social media results develop along embryonic lines

nautilusSocial media-based creativity follows a rather organic approach. Members initially join social media networks and share information about topics of personal concern or interest. Members with similar interests then link together to collaboratively develop initial thoughts into fleshed-out Ideas. These more complete Ideas then compete with the Ideas of others for attention and support. Those that “rise to the top” attract increased interest and collaboration, resulting in fully-vetted solutions to problems or unmet needs. While the social media community has coined worlds like “crowdsourcing” and “wikification” to describe this process, it is essentially embryology at work (albeit embryology of Ideas).

Embryology works from the bottom-up, following local rules

Embryology forms rich, complex works from simple beginnings by following a bottom-up process. Richard Dawkins, elegantly described the power of this on page 220 of his latest book, The Greatest Show on Earth:

“The key point is that there is no choreographer and no leader. Order, organization, structure—these all emerge as by-products of rules which are obeyed locally and many times over… That is how embryology works…this kind of programming is self-assembly.
… [I]t seems impossible to believe that the genes that program their development don’t function as a blueprint, a design, a master plan. But no: … it is all done by individual cells obeying local rules. The beautifully ‘designed’ body emerges as consequence of rules being locally obeyed by individual cells, with no reference to … an overall global plan.”

Dawkin’s major point is that you will obtain richer, more robust results by defining bottom-up, local rules for the evolution of Ideas (instead of driving them top-down from a master plan or policy).

Many examples of this exist throughout the technology world

Bottom-up self-assembly of robust, complex systems through use of local rules is not simply confined to the biological world. Some of the most successful expansions of technological change were built on the same approach. Just take a look at everything from Internet routing and open source technologies to Google’s Page Rank algorithm and Apple’s iPhone application development model.

Creating a social media policy based on bottom-up principles

Using bottom-up, locally followed rules to develop a Social Media Policy looks very different in structure than a traditional top-down policy.

Below is an outline of sample rules (and how they would locally execute throughout a social media ideation process) that I would initially consider to develop an effective Social Media Policy. For simplicity’s sake my unit is an Idea. An Idea could be a plan, policy, design, rule, product or anything else you can imagine.

A) Define the stages of ideation

Define what stages a collaborative idea should pass through from a root concept to completion. This is the skeleton for all other local rules. An example:

  1. Brainstorming of Ideas to consider
  2. Competition of Ideas to see which should be elaborate upon
  3. Elaboration of Winning Ideas into a critical level of detail
  4. Editing of Elaborated Ideas to a Released State

Once Ideas are Releases they become subject for further Brainstorming efforts to adapt them to changing business conditions (evolution at work).

B) Define the allowed actions at each stage

Define what staff can do to an Idea at each Stage. For example, staff can—

  • Create or delete Ideas during Brainstorming
  • Vote, share (internally) or comment on them during Competition
  • Add or remove whole Idea Components during Elaboration
  • Refine existing Idea Components (only) during Editing

Limiting what can be done at each stage provides just enough organization to reduce chaos and encourage productive collaboration. Brainstorming is all done in one place. You do not waste time fleshing out Ideas until they proceed through the Competition Stage. Similarly you focus on Elaborating upon and Editing late-stage Ideas (instead of chaotically replacing them with an unexplored, pre-Brainstormed half-Idea).

C) Define the transitions between each stage

Define what conditions triggers movement of an Idea from one stage to another (forward or backward). By defining the conditions you let the network act without requiring extensive oversight. Samples for movement out of Competition could include the following:

  • When an Idea gets enough votes it moves into Elaboration
  • When an Idea gets flagged as offensive or disruptive enough times it moves back to Brainstorming

D) Define who can see what at each stage

For example, only I would be able to see my Idea until I advance it for Competition. Once this occurs, only My Organization would be able to see and vote on it until it reaches a particular threshold (or is approved by the Organization Leader)

This type of rule set encourages two things. First, it enables edge-condition “long tail” idea creators to participate. Second, it makes department heads feel safer encouraging their employees to ideate and collaborate.

E) Define who can do what to an idea at each stage

For example—

  • Only I may be able to edit my Idea in Brainstorming
  • Only my department Colleagues (i.e., my friends) may be able to add or remove Components of an Idea in Elaboration
  • While everyone can refine Idea Components in Editing

The first rule protects the individual and encourages Ideation. The second protects the Department, encouraging the Department Head to allow social media-based Ideation. The third protects the mission or the enterprise (and can even ensure regulatory compliance).

These rules are just a brainstorm to start

These Rules are only Ideas at the Brainstorming stage. They require a full cycle of collaboration to see which win out and which do not. (After all, defining these as the rules for social media and collaboration would be Top-Down thinking.)

What Joe Shea, program manager of NASA’s Apollo program, taught me

Who was Joe Shea?

Joe Shea was the original Program Manager of NASA’s Apollo Program. Kevin Pollack portrayed him on HBO’s excellent series, “From the Earth to the Moon.” Contrary to what that series depicted, it was Joe who came up with concept of splitting the Apollo Program into missions that achieved never-before-achieved technology marvels.

He is also considered by some a founder of the Systems Engineering profession (many consider him the greatest systems engineer who ever lived). He was also an Adjunct Professor at MIT who taught those of us in Course XVI Systems Engineering. Every year, he would get a project from NASA and have us develop the Preliminary Design, Critical Design, Program Plan and Critical Path and present them to the Administrator of NASA.

Under Joe, I got to work on something called “Project Phoenix,” returning to the moon—but now with a re-usable capsule and landing four astronauts at the pole and keeping there for 30 days (a much harder prospect). In this project I learned about everything from active risk management to critical path costing to lifting bodies to Class-E solar flares. (How cool was that for a 20-year-old?)

Talk about the “Ultimate Definition of Scope Creep”

Yes, we have all seen “Scope Creep” our projects. We all tell “war stories” of the times scope doubled and time was cut in half. However, imagine this scenario:

You are listening to the State of the Union address and the President announces that the country is going to put a man on the Moon by the end of the decade. Keep in mind that no one is ever even escaped low earth orbit (let alone escaped Earth’s gravity, executed Holman transfers and navigated to another body). Now you have to implement the largest engineering project in history, while inventing not only technologies, but also whole fields of study. All under the watch of the press—and completed within one decade.

This is inconceivable to most of us. It hammers home how much the men and women of Apollo achieved. It is inspirational.

600px-Aldrin_Apollo_111

It also taught me that any “Scope Creep” I deal with is likely to be much easier than this!

What I learned from Joe

The technical things I learned from Joe got me my first job at Lockheed Martin (then GE Aerospace). It was great to be able to say that I had worked on a NASA program, helped create both a PDR (Preliminary Design Review) and CDR (Critical Design Review) and present elements of them to the Administrator of NASA in Washington.

However, I learned five much more important lessons — independent of aerospace or any other technology – that I have used in the eighteen years since:

  1. Break Big Challenges into Small Parts. Any obstacle can be achieved if you break it down to smaller items. If these are too large, break them down again. Eventually you will get to things that have clear, straightforward paths for success. Essentially this is the engineer’s version of “a journey of a thousand miles begins with a single step”
  2. Know Your System (or Program) Inside and Out. You cannot be a technology leader who only manages from above. You must understand how the components work. This is the only way you will see problems before they happen. Remember, you are the leader who is the only one positioned to connect the “Big Picture” to the execution details.
  3. Stuff Happens. Things break. Schedules are late. People leave the project. Plan for this. Ask yourself every week what can go wrong. Put contingency plans together to address the biggest or most likely of these. Today, this is called Risk-based Project Management (now all of the PMs who have worked for me understand my Risk Registers and Weekly Register Reviews)
  4. There is No Such Thing as Partial Credit. Yes, unlike a rocket, you can “back out” (essentially un-launch) software. However, the costs of this type of failure are enormous: not only does it cost 3-5x more to back-out, fix and regression test changes, it also frequently results in lost revenue and customers. Get things right in development – then certify them in testing (not the other way around). Don’t count on being able to “back-out” after a failed launch. Joe hammered a lesson into our heads with a chilling story: when people forgot this and rushed three astronauts died during a basic systems test on the Apollo 1.
  5. Take Ownership. If you are the leader, you are responsible for the team’s or program’s success. If you are the module or work stream leader, you are not only responsible for your area but are being relied upon by your peers for success. If you are a hands-on analyst or engineer you are actually delivering the work that leads to success. In all cases, ensure you do your job right, ask for help when you need it and never lie or hide anything.

Five really important lessons. I am grateful I had the opportunity to learn them before I entered the full-time career work force. I try to “pay this back” by teaching these lessons and concepts everywhere I go.

Before I forget…

Thank you to the men and women of Apollo. You achieved miracles on a daily basis and inspired whole generations of scientists and engineers.

PS – I am writing this on Wi-Fi at 35,000-ft. What a great coincidence given the anniversary.