Like a lot of people in the tech world, I try to read a variety of publications (both online and physical versions) to keep up with what is going on in the dizzying world of technology. Recently, I read a great article in a recent issue of Wired entitled Accept Defeat: The Neuroscience of Screwing Up. This article explains in some detail, with examples, the problem of 'failure blindness' in scientific research.
This phenomenon causes scientists and researchers to ignore anomalies in their results they didn't expect, which are therefore categorized as 'failures'. The article goes on to state that one of the best ways of overcoming this bias is to involve other people from outside of your immediate speciality in discussions about your results.
For me, this triggered the thought process of why it's important to encourage participation in your communities (Open Source or internal) from folks on the periphery of your project - non-specialists who have something to contribute that could be the key to solving a problem or advancing the state of the art. Being an effective community leader/shepherd/guide/manager is as much about how you enable 'outsiders' to contribute as it is allowing the core group to work effectively together.
The Wired article has a great example of how two different groups of scientists went about solving a thorny issue in their research efforts. The story centered around two different labs studying E. coli, and a problem they had with keeping proteins they were measuring from sticking to a filter.
“One of the labs was full of people from different backgrounds. They had biochemists and molecular biologists and geneticists and students in medical school. The other lab, in contrast, was made up of E. coli experts. They knew more about E. coli than anyone else, but that was what they knew..."
"The E. coli group took a brute-force approach, spending several weeks methodically testing various fixes. It was extremely inefficient, and they eventually solved it, but they wasted a lot of valuable time..."
"The diverse lab, in contrast, mulled the problem at a group meeting. None of the scientists were protein experts, so they began a wide-ranging discussion of possible solutions. At first, the conversation seemed rather useless. But then, as the chemists traded ideas with the biologists and the biologists bounced ideas off the med students, potential answers began to emerge. After another 10 minutes of talking, the protein problem was solved..."
Open Source has long had a maxim that 'with many eyes, all bugs are shallow'. I think it's time we extend that idea to include general problem solving and new features/directions in both internal and external Open Source efforts. To that end, remember to encourage and nurture that 'outsider' mentality in your project - don't be afraid to step back and see things from a different perspective. Note that this kind of paradigm shift can happen in closed 'internal' projects, but given the open and dynamic nature of the way Open Source projects/communities function, it should be easier to implement this culture there.
A big part of the power of the Open Source ethos is meritocracy, and checking of egos at the door (as much as possible). Embracing the 'periphery' of contributors can push innovation and productivity to new levels, establishing a positive feedback loop which encourages more collaboration and ultimately, better software.
Monday, February 8, 2010
Monday, October 19, 2009
Putting the 'Social' Back in Social Media
I've seen a lot of information recently in social media spaces and RSS feeds I follow that portends a bit of a change in the way people approach social media, and the inevitable 'information overload' we've all heard so much about. A lot of people compare today's information environment to a stream, and I think that's a very apt analogy. There are two primary ways that people seem to be reacting to this glut of information: more filtering or scaling back who they attempt to have 'relationships' with online.
I honestly believe the answer to this dilemma is to incorporate both approaches. In a nutshell, the way I've always approached 'social media' is to remember first and foremost, it's about people and relationships, not about how high you can drive your Twitter, LinkedIn, FriendFeed, or Facebook follower count. It's also important to utilize tools to help you filter out the most important pieces of information.
One of the most important tools is the network of contacts you build. My colleague (and I do consider him a colleague, though I've never met him in person) Steffan Antonas wrote a great blog post recently about his 'social media reboot' on Twitter. He had a lot of great content in the post, but this is by far my favorite part:
"The bottom line is, chasing numbers doesn’t matter in the long run. It’s just a waste of time. The only networking that matters is consistently taking an active interest in others, helping people achieve their goals, writing and sharing great content."
I agree with this 100%, and I find it interesting that this 'counter-culture' trend in social media is now starting to bubble to the surface. Maybe all of this is easier for me, as I'm not really trying to 'monetize the Guy Martin brand.' It's a good thing, too, as I think the Guy Martin Group (cool music BTW) would most likely be the beneficiary, not me. :) I participate in social media & write in this and other blogs as a creative outlet, and to keep my skills and knowledge current. It's true I'm not being completely altruistic here, but I also don't plan to sell 'MashedPotatoTech.com' t-shirts or even become the next Chris Brogan (though I admire the business he's built). I'm content to build up a network of trusted individuals (differing degrees of trust is ok) whom I can use as a sounding board for ideas, and on whom I can rely to separate the wheat from the chaff in terms of information out there. The value of social media isn't so much about the technology involved; it's about creating relationships that you can count on to help you navigate the stream successfully.
I think people in the know are starting to realize that by successfully navigating the information stream, you are not only more productive and less stressed, but business opportunities come more naturally to you. I know I've harped on the early days of Usenet news groups as an example of this phenomenon, but I have distinct memories of the communities built up in that era, and, for my money, they were as productive (if not more so) as some of the social media we have today. I suppose you could say that they were the original 'social media,' where social was the focus, and the systems were a set of tools to get the job of information transfer done. I think it behooves us to start treating our current crop of social media systems a lot more like those tools of a bygone era.
I honestly believe the answer to this dilemma is to incorporate both approaches. In a nutshell, the way I've always approached 'social media' is to remember first and foremost, it's about people and relationships, not about how high you can drive your Twitter, LinkedIn, FriendFeed, or Facebook follower count. It's also important to utilize tools to help you filter out the most important pieces of information.
One of the most important tools is the network of contacts you build. My colleague (and I do consider him a colleague, though I've never met him in person) Steffan Antonas wrote a great blog post recently about his 'social media reboot' on Twitter. He had a lot of great content in the post, but this is by far my favorite part:
"The bottom line is, chasing numbers doesn’t matter in the long run. It’s just a waste of time. The only networking that matters is consistently taking an active interest in others, helping people achieve their goals, writing and sharing great content."
I agree with this 100%, and I find it interesting that this 'counter-culture' trend in social media is now starting to bubble to the surface. Maybe all of this is easier for me, as I'm not really trying to 'monetize the Guy Martin brand.' It's a good thing, too, as I think the Guy Martin Group (cool music BTW) would most likely be the beneficiary, not me. :) I participate in social media & write in this and other blogs as a creative outlet, and to keep my skills and knowledge current. It's true I'm not being completely altruistic here, but I also don't plan to sell 'MashedPotatoTech.com' t-shirts or even become the next Chris Brogan (though I admire the business he's built). I'm content to build up a network of trusted individuals (differing degrees of trust is ok) whom I can use as a sounding board for ideas, and on whom I can rely to separate the wheat from the chaff in terms of information out there. The value of social media isn't so much about the technology involved; it's about creating relationships that you can count on to help you navigate the stream successfully.
I think people in the know are starting to realize that by successfully navigating the information stream, you are not only more productive and less stressed, but business opportunities come more naturally to you. I know I've harped on the early days of Usenet news groups as an example of this phenomenon, but I have distinct memories of the communities built up in that era, and, for my money, they were as productive (if not more so) as some of the social media we have today. I suppose you could say that they were the original 'social media,' where social was the focus, and the systems were a set of tools to get the job of information transfer done. I think it behooves us to start treating our current crop of social media systems a lot more like those tools of a bygone era.
Thursday, August 20, 2009
Community Management is a Career, Not a Job
'Community Management' is a hot topic, & a hot job field, but I think it's important to articulate that it's not a role which should be approached as a 'job'. What do I mean by that? Community Management should NOT be:
I've talked in the past about what kinds of skill sets I believe are necessary to be an effective community manager, and as I thought about my own career path, I realized that early on in my community management career, I considered myself an engineer doing community management, whereas I now think of myself as a community manager with an engineering background. It is a subtle, yet hugely important difference - one that allows me to draw on a breadth of engineering experience to help me steer groups of developers in the right direction, while also considering the needs and requirements of the business and management communities that tend to drive the formation of communities.
One thing that is common between my engineering hat and my community hat is the need to constantly seek to improve not only the knowledge of my craft through reading blogs, Twitter, and other RSS feeds of community news, but also to give back to those same communities. From my earliest days in computer science at Cal Poly, San Luis Obispo, I remember learning what community was (without even realizing it at the time) through things like Usenet News Groups (wow, I'm getting old! :)). The closest thing we had to community 'managers' may have been a wiser, older member of the 'tribe' who kept things on a reasonably even keel (including privately emailing yours truly when I got a bit out of line), but the lessons of cooperation I learned in those formative years of my education have stuck with me. Some of the community management/social media professionals whose writings I try to read regularly are:
You don't have to read the same resources as I do, but I'd encourage you to find your own 'community of community pros' to draw from, as I've found reading what other people are doing in the field stimulates my creativity and gives me new insight into areas I could be better addressing in my own communities.
It is tremendously exciting to see how community management has evolved, and grown into myriad different directions, but all with the core of cooperation and collaboration to meet the common needs of the group. To continue moving the practice of community forward, it is critical that those of us in the field truly work toward making it a profession - something that we can proudly point to and say 'yes, I'm a community manager, and I try to make a difference every day with my constituents'. I know, it sounds a bit cliched, but the notion of 'community' has been a powerful force in human history for a long, long time. What we are doing now is just formalizing its practice to harness it for productivity. I firmly believe that to be successful at anything, you need to treat the pursuit of it with the respect it deserves, so if you want to make community management your career focus, make sure you give it your full attention and skill.
- A role you 'settle' for because you can't do other things
- Something you do as an ancillary part of your 'real job'
- Something you get into 'because it's hot right now'
- A position that you can perform in isolation, without constant upgrading of your skills/knowledge
I've talked in the past about what kinds of skill sets I believe are necessary to be an effective community manager, and as I thought about my own career path, I realized that early on in my community management career, I considered myself an engineer doing community management, whereas I now think of myself as a community manager with an engineering background. It is a subtle, yet hugely important difference - one that allows me to draw on a breadth of engineering experience to help me steer groups of developers in the right direction, while also considering the needs and requirements of the business and management communities that tend to drive the formation of communities.
One thing that is common between my engineering hat and my community hat is the need to constantly seek to improve not only the knowledge of my craft through reading blogs, Twitter, and other RSS feeds of community news, but also to give back to those same communities. From my earliest days in computer science at Cal Poly, San Luis Obispo, I remember learning what community was (without even realizing it at the time) through things like Usenet News Groups (wow, I'm getting old! :)). The closest thing we had to community 'managers' may have been a wiser, older member of the 'tribe' who kept things on a reasonably even keel (including privately emailing yours truly when I got a bit out of line), but the lessons of cooperation I learned in those formative years of my education have stuck with me. Some of the community management/social media professionals whose writings I try to read regularly are:
- Chris Brogan
- Jono Bacon (check out his new book "Art of Community" - highly recommended)
- Amber Naslund
- Rachel Happe/Jim Storer (Community RoundTable)
- Martin Reed
You don't have to read the same resources as I do, but I'd encourage you to find your own 'community of community pros' to draw from, as I've found reading what other people are doing in the field stimulates my creativity and gives me new insight into areas I could be better addressing in my own communities.
It is tremendously exciting to see how community management has evolved, and grown into myriad different directions, but all with the core of cooperation and collaboration to meet the common needs of the group. To continue moving the practice of community forward, it is critical that those of us in the field truly work toward making it a profession - something that we can proudly point to and say 'yes, I'm a community manager, and I try to make a difference every day with my constituents'. I know, it sounds a bit cliched, but the notion of 'community' has been a powerful force in human history for a long, long time. What we are doing now is just formalizing its practice to harness it for productivity. I firmly believe that to be successful at anything, you need to treat the pursuit of it with the respect it deserves, so if you want to make community management your career focus, make sure you give it your full attention and skill.
Monday, July 6, 2009
The Red Herring of Open Source Licensing
There has been a lot of drum beating of late on the topic of the increasing irrelevance of Open Source licensing, & the loudest drummers seem to be Tim O'Reilly & Matt Asay. Matt's recent blog post touches on some great points in this discussion, not the least of which is:
"The real value in open-source software is no longer the software, but rather the resultant services that are delivered over the Web"
This is spot on, and we (the industry) need to move beyond the 'licensing hiccup' that seems to permeate every conversation we have around Open Source (especially in government & enterprise). While I'll preface my statements with the standard disclaimer of 'IANAL', for 'community source', or 'innersourcing' discussions, I think that everyone gets way too wound around the axle on what the license is, and the relative merits of each possible alternative.
I completely agree with Matt's point about the licenses being irrelevant because of the delivery mechanism, however, I'd also add another area where they are less critical is in internal projects behind corporate firewalls. You might be saying, 'Wow, that's a pretty strong statement'. Yes it is, but I think it gets us down to what I hope the really important discussion is - using the collaborative practices of Open Source (the 'Open Community Approach') regardless of whether the license is BSD, GPL, LGPL, or even a custom internal distribution rights clause.
When your application is going to be used for internal purposes (such as what my team at CollabNet is enabling in Forge.mil within the DoD), you should be focusing on how to take advantage of the unique capabilities enabled by the community approach. Before anyone objects too strongly, of course you need to pass all of this by your legal team, but we all need to be advocates for harnessing the key aspects of Open Source, and quite frankly, licensing is not a key differentiator anymore, especially for internally developed & fielded code.
If your system will only ever be delivered within your own firewall, I say, relax, and focus on using the approaches of Open Source (transparent development, open collaboration, meritocratic contribution model) in your projects. The value of innersourcing lies in the ability for project teams to tap into the same kinds of best practices that made projects such as Linux and Apache successful. Increasing the transparency of what is being developed internally also helps break down silos (or at least identifies them so that senior leaders can make informed decisions).
At the end of the day, using Open Source effectively within your organization should be your primary motivator, and if your focus is strictly on risk management or licensing, you are missing the larger, richer part of the Open Source ecosystem.
"The real value in open-source software is no longer the software, but rather the resultant services that are delivered over the Web"
This is spot on, and we (the industry) need to move beyond the 'licensing hiccup' that seems to permeate every conversation we have around Open Source (especially in government & enterprise). While I'll preface my statements with the standard disclaimer of 'IANAL', for 'community source', or 'innersourcing' discussions, I think that everyone gets way too wound around the axle on what the license is, and the relative merits of each possible alternative.
I completely agree with Matt's point about the licenses being irrelevant because of the delivery mechanism, however, I'd also add another area where they are less critical is in internal projects behind corporate firewalls. You might be saying, 'Wow, that's a pretty strong statement'. Yes it is, but I think it gets us down to what I hope the really important discussion is - using the collaborative practices of Open Source (the 'Open Community Approach') regardless of whether the license is BSD, GPL, LGPL, or even a custom internal distribution rights clause.
When your application is going to be used for internal purposes (such as what my team at CollabNet is enabling in Forge.mil within the DoD), you should be focusing on how to take advantage of the unique capabilities enabled by the community approach. Before anyone objects too strongly, of course you need to pass all of this by your legal team, but we all need to be advocates for harnessing the key aspects of Open Source, and quite frankly, licensing is not a key differentiator anymore, especially for internally developed & fielded code.
If your system will only ever be delivered within your own firewall, I say, relax, and focus on using the approaches of Open Source (transparent development, open collaboration, meritocratic contribution model) in your projects. The value of innersourcing lies in the ability for project teams to tap into the same kinds of best practices that made projects such as Linux and Apache successful. Increasing the transparency of what is being developed internally also helps break down silos (or at least identifies them so that senior leaders can make informed decisions).
At the end of the day, using Open Source effectively within your organization should be your primary motivator, and if your focus is strictly on risk management or licensing, you are missing the larger, richer part of the Open Source ecosystem.
Monday, May 25, 2009
Memorial Day Musings
Like many Americans, I tried to keep today, Memorial Day 2009, focused on those who have served (and continue to serve) in our armed forces. Whatever your political leanings, I think we can all agree that we owe a huge debt of gratitude to those brave men and women to put their lives (and their family's livelihoods) on the line everyday.
So, what does this have to do with technology, Open Source, and social media? Given that I'm helping create a new initiative (Forge.mil) to enable those building technology for our troops do so in a more efficient manner, I think there is a strong connection. It should go without saying that our armed forces deserve the absolute best technology to help accomplish their mission and keep them safe.
I'm heartened by the fact that technologies and methodologies that we in the consumer space take for granted are now starting to be accepted in the Department of Defense as the most expedient way to help build out the tech that our warfighters need. The whole concept of cross-department collaboration (especially using Open Source development models) enabled by Forge.mil is a pretty large departure from the traditional 'silo-ed' approach of doing things. I can attest to the fact that while progress has been made, we need to continue to push those with leadership roles to really embrace this effort to give those who serve us the best capabilities, in the shortest amount of time, and at the most efficient price point.
I struggle most days with figuring out how to bring things like Social Media and Open Source methodologies into the DoD and the community I'm helping to build in the development space. Thankfully, there are several initiatives being worked on within the department today, including A-Space ('Facebook for Intel Analysts'), and other social site experiments like Synchronicity @ DISA (for use by folks inside of the Defense Information Systems Agency). I believe there is good momentum in this space that will hopefully continue forward.
While all of these efforts are currently 'internal public' within the department, at least they are starting down the path of opening up the lines of communication and collaboration within a very traditional organization. At some point, we are going to have to get to a critical mass or tipping point where these tools are the accepted norm, and aren't feared. I also believe we are going to need a bit of a 'renaissance' from government contractors who need to start thinking not just in terms of money/contracts, but also about truly serving those who work hard every day to serve and protect us. Learning to successfully adapt to the new ways of building software and systems would be a great first step!
Personally, I'm honored and humbled every single day that I get to help (albeit in a very small way) give our service members the technology they need to accomplish their mission. Words cannot truly express how grateful I am for all that they do!
So, what does this have to do with technology, Open Source, and social media? Given that I'm helping create a new initiative (Forge.mil) to enable those building technology for our troops do so in a more efficient manner, I think there is a strong connection. It should go without saying that our armed forces deserve the absolute best technology to help accomplish their mission and keep them safe.
I'm heartened by the fact that technologies and methodologies that we in the consumer space take for granted are now starting to be accepted in the Department of Defense as the most expedient way to help build out the tech that our warfighters need. The whole concept of cross-department collaboration (especially using Open Source development models) enabled by Forge.mil is a pretty large departure from the traditional 'silo-ed' approach of doing things. I can attest to the fact that while progress has been made, we need to continue to push those with leadership roles to really embrace this effort to give those who serve us the best capabilities, in the shortest amount of time, and at the most efficient price point.
I struggle most days with figuring out how to bring things like Social Media and Open Source methodologies into the DoD and the community I'm helping to build in the development space. Thankfully, there are several initiatives being worked on within the department today, including A-Space ('Facebook for Intel Analysts'), and other social site experiments like Synchronicity @ DISA (for use by folks inside of the Defense Information Systems Agency). I believe there is good momentum in this space that will hopefully continue forward.
While all of these efforts are currently 'internal public' within the department, at least they are starting down the path of opening up the lines of communication and collaboration within a very traditional organization. At some point, we are going to have to get to a critical mass or tipping point where these tools are the accepted norm, and aren't feared. I also believe we are going to need a bit of a 'renaissance' from government contractors who need to start thinking not just in terms of money/contracts, but also about truly serving those who work hard every day to serve and protect us. Learning to successfully adapt to the new ways of building software and systems would be a great first step!
Personally, I'm honored and humbled every single day that I get to help (albeit in a very small way) give our service members the technology they need to accomplish their mission. Words cannot truly express how grateful I am for all that they do!
Wednesday, April 15, 2009
The Day The Phones Went Down in Cali...
There is nothing quite like the sound of a very insistent police officer knocking on your door/ringing your doorbell at 5 am on a Thursday. No, for those of your wondering, they weren't there to serve a warrant or arrest me. :) As it turns out, we had a MAJOR outage of communications service in the South County area of the California Bay Area. Specifically, the towns of Morgan Hill (where I live), Gilroy, and part of South San Jose were all completely isolated from a communications perspective. No E911 services, no long distance (calls within the local telephone central office would go through sporadically), and no cell phones. Basically, back to the 'good old days' (or at least the simpler times). The friendly police officer was at my door to fetch me as one of the leaders of our volunteer emergency response team since there was literally no other way to activate our team. I serve on both the Amateur Radio Emergency Services team (ARES) and the Community Emergency Response Team (CERT).
I was in the field for the better part of the day, took a short break, then was back out again in the evening. I'd like to take a look at the technology aspects of this incident, what worked well (Amateur Radio), and what did not (all of the modern infrastructure that we rely on).
The Good:
Amateur Radio Response - I have a sticker on my car from the Amateur Radio Relay League that reads 'When all else fails, Amateur Radio'. There was never a truer statement spoken on 4/9/09. Other than the public safety radios of the police and fire departments, the ARES team I help lead provided the only reliable communications link that citizens had to contact emergency services, and that the Office of Emergency services had to contact neighboring Emergency Operations Centers. As a matter of fact, at one point, Gilroy Fire and Santa Clara County fire personnel were using our radio equipment to coordinate their response from within the respective EOC rooms in Morgan Hill and Gilroy.
However, the most awesome thing I saw during the entire incident was the response from the MAC (Mutual Aid Communicator) system that the Santa Clara County ARES/RACES organization has worked hard to put into place. All told, we had 42 extremely capable amateur radio operators from many unaffected cities in the county descending upon the incident to help us staff key positions. We had communicators in the field at schools, fire stations, community centers, and major intersections to provide a 'safety net' for citizens to report problems and get updated information. We also served as extra 'eyes and ears', freeing up police personnel to focus on more critical tasks. I've never been prouder to be associated with a group of volunteers as I was that day.
Remember, the 'amateur' in amateur radio simply refers to the fact that we can't take money for our services. This group has consistently shown an outstanding level of professionalism and dedication in providing communications support to the South Bay in times of crisis. The city management of both Morgan Hill and Gilroy, and the associated professional responders were very pleased with the efforts of the volunteer groups, and we were glad to be able to put all of our training to good use in support of the stellar job they did. This isn't the 'Ham Radio' that sometimes gets unjustly made fun of ('crazy people with tube radios in their garage talking to China') - this was a professional response by dedicated individuals who were ready and able to be used as a 'force multiplier' to augment the regular first responders.
The Bad:
This incident highlighted all too well how dependent as a society we have become on technology. Now, I'm as much of a technology guy as the next geek, but this incident clearly showed a need to keep 'alternate tech' like ham radio alive and vibrant. Also, this was probably a wakeup call to citizens who spent the day with no ATMs, no POS machines (gas pumps, credit/debit cards, etc.), no Internet, and no E911 services.
Besides the obvious steps that need to be taken to harden and protect the infrastructure we rely on, it's incumbent upon citizens to be prepared for these kinds of incidents. Know your 7-digit police/fire dispatch numbers, have extra cash on hand, make sure your gas tanks are always filled when you hit half empty, & keep enough food, water, etc. on hand to last 72 hours.
The major point to take away from this incident is that it really isn't about the tech, it is about how it's applied. There is a reason that 'old-tech' like two-way radios are still used by police and fire agencies, however, the professionalism of that community, coupled with a dedicated and prepared group of volunteer communicators who know how to work in concert with them is what made the difference in this crisis.
So, go out and make sure you are prepared if the technological underpinnings of our society go haywire again... and, remember to thank a ham radio operator the next time you see them responding to a crisis in your community... :)
I was in the field for the better part of the day, took a short break, then was back out again in the evening. I'd like to take a look at the technology aspects of this incident, what worked well (Amateur Radio), and what did not (all of the modern infrastructure that we rely on).
The Good:
Amateur Radio Response - I have a sticker on my car from the Amateur Radio Relay League that reads 'When all else fails, Amateur Radio'. There was never a truer statement spoken on 4/9/09. Other than the public safety radios of the police and fire departments, the ARES team I help lead provided the only reliable communications link that citizens had to contact emergency services, and that the Office of Emergency services had to contact neighboring Emergency Operations Centers. As a matter of fact, at one point, Gilroy Fire and Santa Clara County fire personnel were using our radio equipment to coordinate their response from within the respective EOC rooms in Morgan Hill and Gilroy.
However, the most awesome thing I saw during the entire incident was the response from the MAC (Mutual Aid Communicator) system that the Santa Clara County ARES/RACES organization has worked hard to put into place. All told, we had 42 extremely capable amateur radio operators from many unaffected cities in the county descending upon the incident to help us staff key positions. We had communicators in the field at schools, fire stations, community centers, and major intersections to provide a 'safety net' for citizens to report problems and get updated information. We also served as extra 'eyes and ears', freeing up police personnel to focus on more critical tasks. I've never been prouder to be associated with a group of volunteers as I was that day.
Remember, the 'amateur' in amateur radio simply refers to the fact that we can't take money for our services. This group has consistently shown an outstanding level of professionalism and dedication in providing communications support to the South Bay in times of crisis. The city management of both Morgan Hill and Gilroy, and the associated professional responders were very pleased with the efforts of the volunteer groups, and we were glad to be able to put all of our training to good use in support of the stellar job they did. This isn't the 'Ham Radio' that sometimes gets unjustly made fun of ('crazy people with tube radios in their garage talking to China') - this was a professional response by dedicated individuals who were ready and able to be used as a 'force multiplier' to augment the regular first responders.
The Bad:
This incident highlighted all too well how dependent as a society we have become on technology. Now, I'm as much of a technology guy as the next geek, but this incident clearly showed a need to keep 'alternate tech' like ham radio alive and vibrant. Also, this was probably a wakeup call to citizens who spent the day with no ATMs, no POS machines (gas pumps, credit/debit cards, etc.), no Internet, and no E911 services.
Besides the obvious steps that need to be taken to harden and protect the infrastructure we rely on, it's incumbent upon citizens to be prepared for these kinds of incidents. Know your 7-digit police/fire dispatch numbers, have extra cash on hand, make sure your gas tanks are always filled when you hit half empty, & keep enough food, water, etc. on hand to last 72 hours.
The major point to take away from this incident is that it really isn't about the tech, it is about how it's applied. There is a reason that 'old-tech' like two-way radios are still used by police and fire agencies, however, the professionalism of that community, coupled with a dedicated and prepared group of volunteer communicators who know how to work in concert with them is what made the difference in this crisis.
So, go out and make sure you are prepared if the technological underpinnings of our society go haywire again... and, remember to thank a ham radio operator the next time you see them responding to a crisis in your community... :)
Monday, March 2, 2009
Don't Ignore The 'Back-Channel'
The concept of a 'back-channel' during presentations, meetings, classes and similar events has been around for a while (the analog version was called 'passing notes', and who knows, maybe even the cavemen did that during boring recitations on hunting/gathering strategy :)).
The modern equivalents started with email, but now even that quaint old service is derided as 'too slow' in the world of instant messaging, and more recently, Twitter. There are two types of back-channel - private (usually in instant messaging), and public (Twitter). I know very few people who don't utilize the former during long conference calls (especially if they are with clients, and you need to address something that came up during the call privately with a colleague). This can be a huge advantage if someone can go off and get an answer/research an issue while the call continues. I can easily see a role for junior-level associates to perform this function, as I think it makes good business sense, and shows a commitment to your customers to serve them in the most efficient manner. It also lets the 'creative juices' flow between members of your team and gives them all a sense of engagement in helping to quickly find the answer for your customer. Of course, you do need to guard against everyone abandoning the actual call, so it's good to have one or two folks whose job it is to do this.
The public back-channel, as implemented in Twitter, is starting to gain more prevalence in conferences and other public presentations/events. Olivia Mitchell recently penned a great guest blog post at the Pistachio Consulting site on this very topic, with great information from the perspective of both the audience and the presenter. You should definitely read the post, but the key takeaways for me were:
What's interesting to me (as a community manager) in this recent usage of the back-channel is how short-lived communities are formed during this time, take on a life of their own, and are then disbanded immediately afterward. I am heartened by the fact, though, that, unlike private IM sessions, the content is automatically archived and easily searchable (especially if using Twitter 'hashtags'), allowing people who didn't attend the presentation to benefit from the community long after it has gone away, and also make potential contacts that can help them with the ideas presented.
I've long used the private back-channel for my own benefit, but I'll be interested to see how my next public presentation goes with all of the Twitterati tapping away - or, at least I *hope* I'll have something interesting enough to say for them to tweet. :)
The modern equivalents started with email, but now even that quaint old service is derided as 'too slow' in the world of instant messaging, and more recently, Twitter. There are two types of back-channel - private (usually in instant messaging), and public (Twitter). I know very few people who don't utilize the former during long conference calls (especially if they are with clients, and you need to address something that came up during the call privately with a colleague). This can be a huge advantage if someone can go off and get an answer/research an issue while the call continues. I can easily see a role for junior-level associates to perform this function, as I think it makes good business sense, and shows a commitment to your customers to serve them in the most efficient manner. It also lets the 'creative juices' flow between members of your team and gives them all a sense of engagement in helping to quickly find the answer for your customer. Of course, you do need to guard against everyone abandoning the actual call, so it's good to have one or two folks whose job it is to do this.
The public back-channel, as implemented in Twitter, is starting to gain more prevalence in conferences and other public presentations/events. Olivia Mitchell recently penned a great guest blog post at the Pistachio Consulting site on this very topic, with great information from the perspective of both the audience and the presenter. You should definitely read the post, but the key takeaways for me were:
- Audience gets more out of presentation & is more engaged when participating in Twitter back-channel
- Smart presenters learn to harness this back-channel, and tailor their content accordingly
What's interesting to me (as a community manager) in this recent usage of the back-channel is how short-lived communities are formed during this time, take on a life of their own, and are then disbanded immediately afterward. I am heartened by the fact, though, that, unlike private IM sessions, the content is automatically archived and easily searchable (especially if using Twitter 'hashtags'), allowing people who didn't attend the presentation to benefit from the community long after it has gone away, and also make potential contacts that can help them with the ideas presented.
I've long used the private back-channel for my own benefit, but I'll be interested to see how my next public presentation goes with all of the Twitterati tapping away - or, at least I *hope* I'll have something interesting enough to say for them to tweet. :)
Subscribe to:
Posts (Atom)
