Friday, November 18, 2011

On Fatherhood, Technology & Community

Today, November 18th, 2011 is a very special day for my family - it's the day we 'officially' welcomed our newest addition (Rachel Elizabeth Martin) into our lives! Her adoption was finalized today, and it marks the culmination of one journey, and the beginning of a bigger one. Our family is incredibly lucky to have 'one in college (my son Mathew), and one in diapers.' :)

So, readers of this blog might now be wondering 'Ok Guy, where's the technology and community in this news?' Of course, you knew I was going to tell you, right? :) Simply put, technology helped save my daughter's life when she was just 9 days old, and it was also at the heart of our journey to her. As far as community goes, well, that was what helped her get through her first month of life in a NICU (Neo-natal Intensive Care Unit), and it also helped my wife and me navigate the sometimes maddening road to adoption.

Let's start with the technology and community that helped Rachel survive and thrive despite early challenges in her life. If you've never been in a NICU at a major hospital before, it can be a bit daunting. Depending on the individual child's situation, they can possibly be hooked up to a dizzying array of machines that breathe for them, pump blood, or just monitor their vital signs - and that's just the beginning. Rachel faced early challenges in her life that caused her lungs to have trouble developing, and the various breathing systems she was on, as well as deep intravenous lines, are what kept her body going as it healed itself.

However, these miracles of technology were only half of the story. Rachel was lucky enough to have incredible doctors, nurses, respiratory therapists, and other specialists who came together with each other (and our family) to help chart the best course for Rachel's recovery. This was a powerful reminder to me that technology is only ever one half of the equation. Technology without a human element to direct it, guide it, and use it judiciously, is no more useful than a blunt cutting tool. The community of experts who attended Rachel went beyond just applying the technology of medicine - they were there for us during what seemed like an interminable amount of time in the hospital, patiently answering our questions, and making us feel like part of Rachel's community, long before a court order recognized us as her parents.

As prospective adoptive parents, we relied heavily on a network of our friends, family, co-workers, social workers, church family and others. In today's age, it goes without saying that technology played a huge role in helping us communicate and share information with that network. This ran the gamut from simple things (email) to technology that wasn't even envisioned when I was growing up (Facebook, et al.). However, the heart of all of this was community - people who came alongside us through various means to help us navigate what can be a daunting and sometimes disheartening process.

Today, on this very special occasion, I'm reminded again that the human/community element of our lives is the most important aspect of our existence. Technology is a wonderful enabler to augment the human condition, but it cannot bring about the kinds of blessings we've experienced as a family without people joining together in community. My fervent hope and prayer for my daughter is that she'll take that lesson to heart when she grows up and says; 'Oh Daddy, it was so quaint when you used to post about me on Facebook!' :)

Tuesday, June 28, 2011

Is Bruce Bochy a Community Manager?

As an avid baseball fan, I love to go root on my beloved SF Giants (and a World Series victory last year was just an awesome gift to go along with my new baby daughter!) One of the things you hear at a major league ballpark is vendors hawking programs or in-stadium magazines with line up cards: 'Get your program, program here, can't tell the players without a program!' All of this got me thinking about the different roles in successful tech development communities.

These kinds of communities, not unlike your baseball line up of 'lead off hitter,' 'cleanup hitter,' etc., have important players as well. So, with that in mind, I'd like to build out a 'Technology Development Community Lineup,' complete with players, their respective roles and a brief 'scouting report' on each of them. So, let's play ball!

Leading off - Product Visionary: This person's role, like a leadoff hitter, is to get on base with an idea or a vision of how to do things better, build an awesome product, etc. They sometimes strike out while doing this, but they function best when they can 'get on base' with a compelling idea or business case.

Batting second: Technical Architect: This individual is a solid contributor who has the technical chops to move the product visionary's idea along by hitting the ball through the infield (with the occasional 'home run').

Hitting third: Product Manager: This can be a thankless job, because the PM does a lot of the dirty work on schedule, keeping everything humming along and setting the table for the cleanup hitter...

Our cleanup hitter: Engineer/developer: As a former engineer myself, having this person hit cleanup shouldn't be a surprise. This person has to produce runs (product/code) on a consistent basis, or they will be relegated to the scrap heap pretty quickly. This is where the rubber meets the road in tech dev communities - without a solid cleanup hitter (or hitters), it's hard to build successful communities in this space.

Next up: QA/Testers: These are unsung heroes that often fill the same role in the middle of the lineup. They are the 'utility infielders' that aren't exciting, but their work is critical to keeping a tech dev community strong and producing a great product.

Rounding out the lineup we have:

Users: Despite batting in the lower half of the order, don't discount these individuals, as they provide the impetus needed to field a successful product, and their contributions help you move the product direction forward. They are critical members of your collaborative team and community.

Batting last we have: Detractors - yes, they exist in every community, but they have a role to play (albeit at the end of the lineup). They can provide a productive counterpoint to make sure that decisions are evaluated in terms of what is going to drive the community forward. However, these, and all of the lineup needs to be 'managed' (maybe 'guided' is a better word) by... [wait for it]....

Community Managers - Good community managers build a strong lineup and then provide the right amount of leadership throughout the season (of product development). While they may make some tactical day-to-day decisions, they also need to be aware of the overall morale and 'vibe' of the community. Indeed, some of the most valuable things a community manager does may not be related to tactics at all - putting two groups of users together with appropriate product managers/visionaries, removing roadblocks for the cleanup hitters to get their jobs done, or bolstering the confidence of the utility players (QA) to contribute.

Not all of us can win a World Series like Giants manager Bruce Bochy did last year, but we can certainly think critically in not only putting together our 'community lineup,' but in how we guide and lead our players to deliver great technology.

Tuesday, April 5, 2011

Community Perspective

[Originally posted 11/17/09 in my work blog, but it still rings true today]

It’s amazing how restricting the amount of space you have to express a concept crystalizes what is truly important about that idea. Recently, in my ‘community’ Twitter list, Holly Seddon asked a very good question which helped give me one of those ‘A-ha’ moments:

‘In one word, what should using an online community feel like or give you?’

I loved the challenge of coming up with a single word to describe a key benefit to participating in community. After some reflection, the word that popped into my head was ‘perspective’. When communities are functioning at their peak (and I think this is true even of ‘development’ communities), one of the most powerful things you can glean from your participation is the perspective of one or more of the other community members.

Being able to look at business problems, source code issues, or any other medium within a community from a different angle is incredibly powerful. As an engineer, I used to get some of my most inspired ideas from listening and reading what others in discussion forums were posting. If you have a specific problem, a direct approach to soliciting help from your community gives you (sometimes) multiple different ideas & perspectives on your issue. Throwing these thoughts into the mix as you work toward a solution can be an invaluable step in the problem solving process.

There are a lot of reasons why people or companies start communities, but I believe a large portion of those reasons can be traced back to the need to get additional different perspectives – developers looking for ideas, companies looking for consumer input, social groups looking to connect with other like-minded individuals. I’ll admit that not everyone in the corporate world always understands this – mainly because asking for and reflecting on a different perspective requires the kind of humility that some companies (and even some governments) don’t always possess.

We’ve all participated in groups where we’ve felt our opinions didn’t matter, and I’m willing to bet you probably disengaged pretty quickly if that’s the experience you encountered. I urge companies and their individual employees to strongly consider this when setting up your own internal or external communities. Ask yourself the question: ‘Is this a place where I’d want to participate – is my perspective going to be welcomed and celebrated?’. If the answer is ‘no’, it’s time to go back to the drawing board in the plans for building out that community. If you are already participating in a well-oiled community, remember to appreciate the different perspectives you get – even the ones you might not necessarily agree with.

Monday, March 21, 2011

Salespeople are from Mars - Consultants are from Venus

I hope that title caught your eye because it is a great jumping off point for something that has become readily apparent to me in the last several years of my career. Now that I'm in a consulting role (services) as opposed to previous internal development roles, I've begun to get a new appreciation for just how different the sales and services/consulting camps are. In addition, I've seen how Dr. John Gray's provocative metaphor, first brought to light in his book 'Men are from Mars, Women are from Venus,' also applies to what many perceive are diametrically opposed groups in any community.


Venus-vs-Mars.gif


Now, don't get me wrong, there usually is (by necessity) a LOT of synergy between any of these two camps, but there is also a fundamental mindset difference that can easily throw an unproductive wedge between the two groups. I'll admit that I'm as guilty as the next person for not always recognizing this, and I'm sure it doesn't help that as a former software engineer, I still believe I can control most (if not all) of the variables in any problem. While I picked on sales folks and services people for my title, I'll try to generalize this to make it applicable to any community of people with whom you are trying to collaborate better.

At the end of the day, I think the fundamental difference between any two groups is in how they are incentivized, as well as how they approach problem solving. There is a tools aspect to solving this, but only at a very high level. To effectively take advantage of collaboration and management tools, you'll need to understand both your own mindset, and that of your planetary counterpart in this example.

Let's use the two groups from our title to illustrate:

Motivations

  • Sales people are primarily motivated by $$

  • Consultants are primarily motivated by customer success

Problem Solving Approaches

  • Sales people are 'big picture' thinkers - details are worked out later

  • Consultants think about the big picture - but need details to implement

I'm sure if we sat down, we could think up similar statements for other groups in a community such as 'Project Managers' and 'Developers.' The point here is both groups need to understand each other's differing approaches, and, to quote Wikipedia's assessment of Gray's work:

"...monitor the amount of give and take in a relationship and if the balance becomes off and one person feels they have given more than they have been given, beware of resentment developing ... this is a time when communication is very important to help bring the relationship back into balance."

Yes, this sounds very 'touchy/feely,' and some reading this will think it isn't germane to a discussion about collaboration in a business setting. To those people I would say: 'Don't business relationships matter too?' Businesses invest a ton of time in marketing efforts, and in trying to be more 'human' (see my friend and colleague Emily Salus's blog for examples). Shouldn't you as a professional (in whatever role you find yourself) be investing the same amount of effort to be successful in your company, project, or team?

All of the tooling in the world does you no good if you cannot recognize the differences in how you think compared to others, and then formulate a plan to overcome those differences and put them to work for you. At the end of the day, communication really is the key - and that means both talking and listening.

I plan on putting this into practice in my own world as a consultant and community manager - I invite you to join me in this endeavor, and I'd love to hear about your challenges and successes in the comments section here...

Tuesday, February 1, 2011

When Do You Weed Your Community Garden?

Anyone who has ever grown anything in their home garden knows that at some point or another, the onerous task of weeding will become a part of your reality. The question usually becomes when to take on the task that most of us don’t look forward to.


weeds.jpg


In recent discussions with colleagues and customers, I’ve revisited my list of traits that a good community manager should have – and I’d like to amend the list to include ‘community gardener.’ The gist of these discussions has been how much influence a community manager should exert and where in the process of the community workflow that needs to happen.

Let’s face it – to have an effective community (one that provides value for both the producers and consumers of content), there is a certain amount of ‘weeding’ that has to happen, whether by the community itself, or by the community manager. This task can either be relatively painless or a pain-filled experience, depending on where in the process it occurs.

In general, I see weeding happening in one of two places (and please excuse the engineering mentality here): on the front end or on the back end. On the front end, this means putting a lightweight governance model in place to prevent a raft of ‘test,’ ‘me too,’ or duplicate content (or in the case of communities I usually run, projects). While possibly stifling the producers, this allows for a better experience for consumers who come to your community looking for content that is valuable to them. The converse is to allow a Wild West mentality of ‘anything goes’ on the front end, and then attempt to weed out the unproductive content on the back end through community voting/affinity, or active pruning by the community itself or by their community manager.

My personal belief is that, for most productive development communities, you should perform this weeding activity on the front end of the process. While this can be seen as a bit too restrictive by people looking to produce good content quickly, I think it tends to work better for early-stage communities where you don’t have a critical mass of valuable content. Perception is huge in communities, especially newly formed ones where you’ll tend to have more consumers than producers. If you’ve chosen to do the weeding on the back end, you run the risk that your community will appear very chaotic and unorganized to those coming to it in an attempt to consume knowledge, code, etc. Given that, in my career, I’ve primarily run communities in enterprise & government settings, I realize the importance of first impressions for people who may not be as intimately involved or passionate about a particular piece of technology. If these people come to a site where the weeding is put off until the back end, the likelihood is they’ll go away with a bad taste in their mouth from this particular community effort, since they’ll primarily see duplicate or ‘I’m testing this’ kinds of content.

Additionally, weeding on the front end lets you identify the issues mentioned above with the content/projects while they are still small. If you wait until the back end of the process, you’re more than likely dealing with a greater quantity of larger weeds, and I don’t know about you, but I’ve always preferred to nip problems and weeds in the bud, as it at least makes the task manageable. Choosing an up-front approach also lets you create a fairly lightweight governance model where you can quickly vet new content and then let producers go on their way to helping you build a great community.

I’ve stated my personal preference here, but I’m curious as to what readers of this blog think. Does anyone out there have ‘war stories’ about how (and where in the process) you weeded your community garden?

Hey, Your Community Peanut Butter Is in My Agile Chocolate!


Ever since my first introduction to Agile software development (at the beginning of the Forge.mil project nearly two years ago), I've been noodling with the notion of how my primary role (Community Management) interfaces with and informs Agile. At first, it almost seemed like the beginning of the old Reese's ® Peanut Butter Cup commercial ('Hey, your community is in my Agile!'), but as I've had time to consider it, I think that community has a lot to do with the successful application of Agile methodologies.


cups.jpg


The culmination of this came when I was asked to speak on a panel at the recent AFEI DoD Agile conference, and the panel moderator asked us in our pre-show meeting to consider a 'lead-in' question he could give each of us in case the audience didn't have ready-made questions. I chose to have him ask me, 'How does the notion of community inform Agile software development?' In preparing my answer, I thought of three specific areas where I think this occurs:


  • Meritocracy

  • Peer Review/Customer Involvement

  • 'Fast Failure'



Meritocracy, most evident in successful Open Source projects such as Linux, Apache, and Subversion is the notion that your standing in the project has everything to do with the quality of your contributions. This is the engine that keeps innovation happening in these kinds of projects, and its application to Agile is often a tough lesson that can have huge human resources implications. People used to having their ideas heard in a traditional project setting are sometimes upset by the notion that 'junior' members of the team are on the same footing in terms of their contributions. This is especially true in more conservative and 'command & control' cultures like government; however, if your project can get past the initial hurdles presented here (and you have good HR people to smooth over any rough spots), group productivity can increase dramatically.

A core tenet of good development communities is also the notion of customer involvement and peer review. This is really one of the most obvious fits between community and Agile, where the notion of a 'Product Owner' as an involved part of the Agile team is a key component of the methodology. In good Open Source development efforts (even ones that aren't Agile), peer review helps find problems before they become large issues - the same function as it serves in an Agile project. Concepts in Agile & Scrum such as the retrospective meeting at the end of a sprint mirror the more informal peer review that happens on open source projects' community mailing lists.

Open Source communities live by the adage, 'Release early, release often.' This leads to an ability for 'fast failure,' which is also present in the Agile model. Because of the continuous feedback loops built into both systems, there is less of a paralyzing fear of something going wrong. To be sure, due diligence has to occur during release cycles, but with the knowledge that a quickly forthcoming future release can fix any issue comes the freedom to think outside of the box and try innovative approaches.

So, what does all this mean in the long run for your business and development efforts? Quite simply, don't ignore the community component of Agile development when your organization starts down the Agile path. Do your project members think the transition to Agile is the latest fad, or do they feel empowered to help improve the development process (meritocracy)? Have you gotten buy-in from your customer (internal or external) to support making this a community-focused effort (customer involvement)? Have you truly communicated to your teams that 'failure' in one release cycle is ok as long as future releases address the issue?

If you think about incorporating true community aspects into your transition to Agile, then, like peanut butter and chocolate in a peanut butter cup, your efforts will come together to provide a unique whole that is greater than the sum of the parts.

[Photo credit: Candycritic.org]