Entering the Free and Open Source emerging market

Originally published on opensource.com

In business speak, an “emerging market” is a market that is not yet well developed but on the rise and shows strong potential to be as robust as other developed markets. The Wikipedia definition focuses purely on countries, but this is a limited view of the meaning of “market.”

Whether a market is developed or emerging depends entirely on the product or service being offered and the receptiveness and awareness of a market to that product or service. For instance, Italy would not qualify as an emerging market by the Wikipedia definition. Yet, with an Internet penetration of only 58.5% of the country, it could be considered one for broadband Internet providers.

By this more inclusive definition, free and open source software (FOSS) is an emerging market for most of the corporate and business world. It’s a new land, abundant in resources and promise, and businesses are getting very excited about the possibilities. It’s also an entirely foreign culture, and many businesses are struggling to learn how to operate in this new land.

A new land

The place where business meets an emerging market is a liminal zone, which is space that is neither here (standard business practice) nor there (Wild West mentality), and where transformations are more likely to occur. In literature and mythology, all of the most exciting things occur in liminal zones. Operations in a liminal space, such as the meeting of an emerging market and a business, are not as constrained by a “business as usual” mentality; therefore, they are free to explore new solutions. The meeting of diverse approaches and philosophies can lead to incredible innovation in processes and products. With such potential, a growing number of businesses are looking to enter the FOSS emerging market, which is no surprise.

Entering a market is entering into a relationship, and like all relationships there is more than one perspective to consider. According to a study published in the MIT Sloan Management Review, this is where many organizations fail when attempting to enter emerging markets. Being very familiar with and confident in “how things are done,” organizations enter emerging markets with a business-as-usual attitude. They fail to do the necessary market research and don’t learn enough about the culture, the market needs, or even the communication norms and language. Unsurprisingly, their efforts lead to disappointment and a withdrawal from the market, usually to the benefit of local competitors.

This business-as-usual approach leads to expectation mismatch. Businesses expect that their usual go-to-market strategies will gain them entry, their usual processes will get things done, their usual messaging will gain them positive attention and brand recognition, and their usual language is appropriate for all communication. Some companies entering a FOSS community or project expect to mold them to their needs through force of numbers, either human or financial. This works about as well as you’d imagine. Companies expect Step 3: Profit will follow. Disappointed by unmet expectations, businesses decide that FOSS will never work for them. They withdraw from participation in FOSS and leave that emerging market to their competitors.

When businesses are unable to participate in FOSS, doors close for everyone. It deprives companies of the benefits of FOSS participation, including faster development and innovation, more efficient recruiting, word-of-mouth marketing, and lower total cost of ownership. The community or project becomes deprived of the benefits of corporate support, such as wages for maintainers, support for essential infrastructure, and sponsorship of events and participants.

How to step foot onto new land

As businesses set foot on the foreign land of FOSS participation, they should take care to treat it as they would any emerging market: with the respect and consideration due an unfamiliar culture. Businesses should tailor their entry to the market and not engage the autopilot to business as usual. Taking the time to pause, reflect, research, and listen can pay remarkable dividends and better ensure success. Part of this reflection should be confirming that the FOSS organization knows what it wants to get out of the relationship, and ensuring that this is a mutually beneficial arrangement. As with entering any new endeavor, you can reduce the time required to ramp up the team by hiring someone already familiar with this emerging market and its pitfalls.

While those of us on the management and business side of things learn how we enter the emerging market of FOSS, there’s no reason FOSS communities, projects, and supporters can’t do a little to help out our end. As with any relationship, meeting in the middle is the best way. For a successful entry into this emerging market, a business must learn the FOSS language, culture, and needs. The FOSS community can do its part to help a business do this, perhaps even by reaching out and offering to teach them. This may be one of the best approaches, because it also allows the FOSS community the opportunity to learn the language, culture, and needs of the business, making all communication more efficient and successful.

Most importantly, the FOSS community must try to be patient, non-judgmental, and empathetic when businesses inevitably stumble. Many people still retain an old-fashioned perception of emerging markets as savage or unsophisticated, although this is a view that has no place in technology or in business. The same can be said of business’ perceptions of FOSS. Many still see free and open source projects and practitioners as dogmatic, phlegmatic, and anarchic. Assisting businesses to enter the FOSS emerging market and picking them up should they fall will go a long way toward dispelling these misconceptions and we will all reap the benefits of broadening the scope of our collaborations.

Avoid failure when supporting free and open source communities

Originally published on opensource.com.

This is Part 3 in a series of articles three on community management best practices. Read Part 1, Practical business reasons to support open source communities, and Part 2, How your company can build and keep community trust.

Although supporting a community offers many benefits to an organization, to imply that there are no risks to the organization or community manager would be disingenuous. When handled poorly, engaging with a community can lead to major growing pains, raging headaches, and total meltdowns. In this article, I’ll discuss how to prevent the headaches before they happen.

If your organization decides to invest in and grow a community, not knowing why you are supporting a community and what results you expect are a huge problem. Humans—some more than others—are social creatures, so the appeal of being part of a community can be strong. However, that does not excuse your organization from responsible business practices. Undertaking any sort of large initiative without understanding the business reasons for doing so, or criteria and metrics for success, is irresponsible and not sustainable.

Defining ROI

Still, many organizations dive head first into community (and other) initiatives without having done basic due diligence from a business perspective. They fund the salaries of the community management team and sponsor community events without discussing assumptions, expectations, parameters, metrics, or anticipated ROI from the endeavor. Down the road, this inevitably leads to awkward conversations. And some of these conversations negatively impact the community, which can lead to serious blow-back and negative PR for the organization.

Another risk organizations face when initiating a community support program is mistaking the community for a market or for customers. Although community members may also fit these roles, and traditional marketing and sales outreach techniques can be helpful at times, treating the community like anything other than a community can lead to resentment and ill-will from its members. Remember: A community is a self-organized and self-identified collection of people. Identification is a powerful thing, and treating someone contrary to their selected identification is arrogant and disrespectful. When an organization begins to think of the community as merely a well-qualified market or as sales leads, it has lost connection with the community and risks losing members and public negative feedback.

Community value

Organizations that do not think through business aspects of their community support programs risk devaluing the community they support. Without considering the business case for supporting a community, the organization can fall into thinking that any community will do, and that this community is expendable or hot-swappable for another that the organization can simply support or build in parallel. Again, this line of thinking ignores community self-organization and identification. It dehumanizes the community members, treating them as interchangeable cogs turning in a machine cranked by the organization. This dehumanization creates a blind spot in the organization such that they are surprised when the community exercises its agency and independence, often with unfortunate results for the organization.

Organizations that decide to support a community and then, through neglect, allow the community to fall into disrepair are also at risk. Communities will self-manage; there is no requirement for an organization to swoop in and offer its support on that front. But a self-managing community is not always a healthy community. Through neglect, indifference, or political skulduggery a community can become a negative space that is unwelcoming to the new, the reasonable, the empathetic.

An organization that reneges on its promise to help manage and lead a community cannot walk away from the reputation it earns by being associated with a negative and toxic community environment. This is, of course, a worst-case scenario. More often, a community left in neglect withers and dies silently. But sometimes thriving and toxic weeds overrun it, and ignoring this possibility is a mistake that a supporting organization makes at its own peril.

Then there is the problem of expectations mismatch. The organization cannot simply decide to support a community, go stomping in there waving money and touting their principles, and then expect to be embraced as a conquering hero. Entering a community, as I mentioned in Part 2, takes time and deliberate effort. A large part of that effort is communicating why the organization has decided to become a part of the community, what they hope to gain, what the community will gain, and how the organization intends to operate both within and outside the community.

Communication is key. Both sides must openly outline expectations, otherwise they risk an expectations mismatch, which can sour the community to future support from the organization. If the organization supports and listens to a skillful community manager who understands the community and its members, the chance of an expectation mismatch goes down. The communication pipeline provided by the community manager ensures that all sides understand what is going on, when, why, and how everyone can contribute.

Enter the community manager

I’ve discussed the benefits and risks to organizations supporting communities, but there’s another piece of the equation that is often overlooked: risks to the community managers themselves.

Community manager (or a variant, such as developer relations) is a relatively new job title in the tech industry. As organizations began to recognize benefits of supporting a community, they also began to see the need to have one or more employees guiding, growing, and communicating with that community. But problems with this role can start early on, when organizations aren’t clear on expectations and requirements for measuring the community manager’s success.

Community managers are in curious and occasionally awkward positions. To succeed at their jobs, they must participate in their communities at a level that can appear to be disloyal to an employer and in favor of the community. In fact, a successful community manager plays the role of diplomat and translator between organization and community, representing the organization’s interests within the community, while transmitting the feedback and concerns of the community back to the organization. The community manager must understand the perspectives and motivations of each side and work to balance and achieve goals to benefit both.

This is a difficult task in the best of situations, but becomes particularly challenging when the organization misunderstands the diplomatic role of the community manager, and instead expects them to enforce organizational edicts without regard to effects on the community. This can be perceived as disloyalty to the organization rather than what it is: the community manager working to protect the reputation of the organization.

Community manager ROI

Community managers also have the challenge of proving their value to their organizations. The metrics required for such validation often are difficult to track, nebulous, or both. Proving the ROI of a community support program is hard enough; proving the impact of an individual community manager on that ROI is even more difficult. For the sake of community managers and of the community program, that organizations define metrics and criteria for success before beginning the undertaking is vital.

Community managers who are not armed with metrics and organizational expectations are unable to show the value they bring to an organization, and they become low-hanging fruit when budgets are cut, and they can be cut out of the picture. Often organizations that choose this option are those that failed to outline their motivations and expectations for supporting a community. And, having not thought things through from the start, these organizations rarely have considered the repercussions that losing a community manager can have on the community and how it views the organization.

Other risks to community managers are more personal in nature. For instance, embedding oneself within a single community can lead to difficult career mobility. Becoming a trusted member of a community takes a great deal of time, energy, and emotional investment, and although the relationships built and interpersonal skills learned are valuable and transferable, a community manager cannot simply jump from one community to another as easily as a programmer can move from one project to another. When an organization decides not to continue supporting a community, or if the community manager is no longer satisfied with their role or organization, finding a new position can be difficult.

How your company can build and keep community trust

Originally published on opensource.com.

This is Part 2 in a series of articles on community management best practices. Read Part 1: Practical business reasons to support open source communities.

If you are part of an organization looking to get into the community-support game, you would do well to tread carefully and deliberately. Communities, particularly at the start of your involvement in them, can be delicate and fragile things. Stomping in there with big words and big plans and big brand engagement will cause a lot of damage to the community and its ecosystem, often of the irreparable sort.

Before your organization sets forth on the community path, take the time to do research first. Learn who the members of the community are, and about the social dynamics between them. Learn the community’s jargon, but not in a “How do you do, fellow kids” sort of way. Listen to what the community members discuss, what concerns them, what they enjoy, what they’d like to change. A week or two of research can help prevent many otherwise non-obvious missteps once you start engaging with and participating in the community.

Once you finally do take the plunge into community support, being open and sincere about both your intentions and the role you will be playing in the community is vital. As this is a community coalesced around a project or product on which you rely, the community likely will welcome a representative from your organization into the fold. But dissembling and pretending not to be associated with the organization will inevitably be discovered and will cause ill-will on the part of the community members.

First build trust

When supporting a community, initially building trust in the members of that community is important. Without trust, you will never be able to guide, direct, or grow a community. It will not matter that the community formed around one of your organization’s projects or products. If community members do not trust you, you will not be allowed to participate in the community and you will lose all of the business benefits of that. Furthermore, the community may turn from your product/project entirely.

The actions that build trust within a community are the same ones that build trust between any people or organizations:

  • First listen. Listen, listen, listen. Listen more than you speak. The community has things to say and wants to be heard. Take the time to listen carefully.
  • Then speak. When you do speak, do so to make promises based upon what you have heard. Making the promises is not nearly enough; you also must deliver on them. If you’re not making promises when you speak, you should be asking for feedback and input and then, again, taking action upon this.

Community communication

Another important reason for you to speak rather than listen is the unfortunate situation of negative interactions and experiences within the community. If not for the sake of the community, then for the sake of your organization’s reputation, you must maintain a policy of zero tolerance of abuse.

When speaking with the community, you must always be open, sincere, and honest, brutally so if necessary. Part of this may include owning up to your mistakes, communicating what went wrong (and what’s being done to correct it), and making sure it never happens again. This is more than just PR; it’s building, reinforcing, and validating the trust and relationship you’ve established with the community.

This level of listening, delivering, and communication can form a strong foundation of trust that will get your organization and the community through both good times and bad. When both sides trust and support each other, that’s when the real magic begins to happen. Furthermore, that’s when other people, viewing the community from the outside, start seeing that magic and want to be a part of it. A strong, vibrant, and trusting community practically builds itself. All it needs it an understanding hand to help guide it and to keep the negative influences and personalities—which find their way into every community—from taking root.

That guidance, and building and maintaining trust, can be a full-time job. Organizational interaction with a community requires a lot of hands-on, high-touch, intimate and open work, otherwise community trust is lost, and community members will turn away from the project/product and the organization. This work is the purview of specialists, people who have invested the time and effort to become intellectually and emotionally familiar with and to the community. These are people who become trusted members of the community and work for the organization as advocates for the community to help provide maximum benefits to both sides of the equation. These people are often called community managers, despite the fact that most of the management that they have to do is upward and internal to their organization, rather than within the community.

A good community manager is knowledgeable of and trusted by the community, so little management is required on that front. What is more often the case is that the organization for which they work does not fully understand the complexities and benefits of the work that the community manager is performing and will—intentionally or not— obstruct or attempt to control the community. This puts the community manager in a difficult position, where they are forced to explain diplomatically the counter-productive actions of the organization to a perplexed community, while also trying to explain the benefits (at risk of being lost) of community support to an organization that may not have thought such things through prior to establishing a community support program.

Stay tuned for the third and final article in this series, coming next week.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.

Practical business reasons to support open source communities

Originally published on opensource.com.

Recently I’ve had several conversations with open source friends and colleagues, each discussion touching upon—but not directly focused on—the subject of why a company would/should/could support a community around a project it has released as free/open source, or more generally to support the communities of F/LOSS projects on which they rely. After the third one of these conversations I’d had in nearly as many weeks, I dusted off my freelance business consulting hat and started mapping out some of the business reasons why an organisation might consider supporting communities.

In this post, I’ll look at community from a business perspective, including the effect community can have on an organisation’s bottom line. Although there are communities everywhere, I’ll approach the topic—meaning, communities, their members, and their contributors—from a free/open source perspective. So please stick around, and maybe you’ll learn ways to communicate the importance of community to your organisation.

(Also, be sure to check out my list of 16 resources for measuring open source community ROI.)

What we mean when we talk about community

First, let me explain what I mean by community. A community is a self-organized collection of people sharing a concern or interest. Although it’s possible to build, grow, and manage a community, this concept of self-organisation is important for providing and maintaining the vibrancy that comes with a strong community. Strong communities are composed of people who self-identify as members of the community, not those who are assigned or forced into it. Members may join or leave the community at will. The members of a community retain complete agency as to their initial and continued membership.

Why would a person become a member of a community? Some will drop in to acquire help for a problem they’re having, but merely dropping in does not necessarily mean a person identifies as a member of the community. Those who return, however, have at least started this self-identification process. Something they experienced on their initial visit convinced them that this is a group with which they’d like to continue to associate. Perhaps they return because of the social dynamics. Perhaps it’s for the shared affinities and inspiring conversations. Perhaps it’s for the friendships they are building. Whatever the reason, a community is similar to so many other things in life: First impressions matter. A community environment in which people do not feel heard, do not feel appreciated, and do not feel comfortable leads to the erosion of the trust and bonds that allow a community to thrive, in addition to increased ill-will toward those who ostensibly claim management over the community.

Communities, fundamentally, are people. Typically the community “personality” is an amalgam of the personalities of the most prominent members. Thus, if the personality skews too far toward the negative, the community will develop a reputation as being negative and unhealthy. One role community manager(s) play is to help shape and guide the community’s personality to build an environment that helps the community members meet their goals, and that benefits organisations that support it.

Business benefits

Why, though, would an organisation invest resources in supporting and guiding a community? How does community-building help the bottom line?

Measuring the ROI of community is tricky, but really no trickier than any other outbound communication effort your organisation attempts. If you’ve ever tried measuring the impact of your organisation’s PR, outreach, branding, and advertising efforts, you know how difficult a task this can be. However, just because something is difficult doesn’t mean it’s not worth doing. Although measuring community support success is challenging, supporting a vibrant community can provide many benefits, both quantifiably and otherwise.

A strong, engaged community gains your organisation the holy grail of marketers everywhere: word of mouth marketing. The community you support will become your street team, spreading word of your organisation and its projects to anyone who will listen. Additionally, an engaged community will provide the most on-time and in-depth market and competitive research. Community members become not only your staunchest defenders, but also a ready, willing, forthright, and cost-effective focus group when the organisation needs to try out new ideas. When you’re out of new ideas, your community will be there as a resource to provide you with the inspiration and experience necessary to spark and potentially implement well-targeted and brilliant innovation, while also pointing you to new tools and best practices to bring that innovation to life more quickly. When that innovation does take off and your organisation is looking to expand, the community it has supported provides a rich and passionate pool from which to recruit new team members, dramatically reducing the time and resources required not only to fill open positions, but also for onboarding once hired.

If word of mouth marketing, market research, product focus groups, and a technical talent pool aren’t enough for your organisation, there are myriad other business benefits to supporting a vibrant community. For example, community members, having been involved in technical development, will likely be early adopters of your latest technology or solutions. The support community members provide each other not only leads to lower support costs for your organisation, it can also lead to lower cost of ownership for the community and those who rely upon it for assistance. And if something does go wrong with your product, for example, an engaged community can provide higher goodwill, tolerance of errors, and public support and PR in times of crisis. Of course, this community support for your organisation only lasts as long as your organisation remains supportive of the community. The moment members of your community sense your organisation is being disingenuous—and they will sense it, on that you can rely—they will rightfully drop support for your organisation, and possibly expose it and all of its flaws.

When considering the benefits of supporting a community, and the metrics for determining success, it’s important to remember that most of these benefits require playing the long game. Trust is not earned overnight, and without the trust of the community, your organisation is unlikely to reap the benefits of supporting and being a part of that community. Most discussions about metrics should be phrased in the context of months and years, rather than days and weeks. Give your program adequate time to get off the ground and start showing results before using those metrics to determine whether the effort is successful.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.

Google’s disappointing response to the “manifesto”

I’ve been sitting on this for a day, and I really do have better things to do than to scold strangers on the internet, but after sleeping on it I find I need to get this out…

Yesterday Google released its official response to a recent internally-released-but-now-leaked manifesto on gender and Google’s support of its equality. The official reply does Google, its brand, and its reputation no favours.

For starters, this so called “manifesto” is the worst sort of faux-intellectual, self-delusional, self-congratulating, adolescent bullshit. Full stop. This man obviously thinks himself very clever and knowledgable, when evidence shows that he is anything but.

But I’m not here to talk about this programmer today. The last thing this creature needs is more attention. I’m here to talk about how Google is making a very dire business mistake.

The response states:

Part of building an open, inclusive environment means fostering a culture in which those with alternative views, including different political views, feel safe sharing their opinions.

In principle there is nothing wrong with this statement, but the reality is that while people should feel safe sharing their opinions, they also must be trained that not all opinions or topics are appropriate in all environments or conditions.

In this case, the unnamed software developer has expressed an opinion which is counter to Google’s own “strong stand on this issue.” There is nothing wrong with that. He is welcome to his own opinion, however catastrophically wrong, puerile, shortsighted, and unadulteratedly stupid it may be.

However, this opinion was expressed in such a way that it has publicly called Google’s commitment to gender equality into question. If that’s not enough of a negative effect for them, then how about the bottom line? The furor over this simplistic armchair philosophy of a screed has seriously injured Google’s multi-billion dollar brand and wasted countless hours of company time.

How many millions of dollars of damage has this man’s public mental masturbatory male power fantasy done already? How many millions more will it take to heal the wound he has caused?

There is safety to express one’s views, and then there is safety to torpedo a company’s reputation. There is free speech, and then there are the ramifications for one’s speech. This software developer must learn that while he has the former, he also has the latter.

For the sake of its brand and its reputation, Google must make a decisive statement now. It must do better than the flacid response it made yesterday. It must show that actions which cause harm to the company and its initiatives are not welcome and will be met with a commensurate reaction. Or, more colloquially: Ya don’t shit where ya eat, dude.

Fire this man & make a statement to that effect. He’s a fool with poor judgement and he’s an albatross hung on Google culture and Google reputation.

A CEO is a Leader: The Recent Mozilla CEO Kerfuffle

Experience comes for free. Learning takes effort.

On March 24th, Mozilla announced that they had named Brendan Eich as CEO.

On April 3rd, Brendan Eich, after much internet uproar over his $1000 donation to disallow same-sex marriage, stepped down as CEO of Mozilla.

So.

WTF happened here?

First of all, some facts…

  • FACT: Brendan Eich is well within his rights to support his personal beliefs through financial donations. Furthermore, that he did not back down from his position shows a strong sense of integrity. He was correct to do what he did. (ed. note: I very strongly disagree with Eich’s position on this matter and share Rarebit’s disappointment, but defend to the death Eich’s right to express his opinion.)
  • FACT: Team Rarebit and others were well within their rights to express outrage at the appointment. They were correct to say what they did.
  • FACT: Yet others were well within their rights to defend the appointment. They were correct to say what they did.
  • FACT: The Mozilla board of directors appointed Eich because they truly believed they were doing what was best for the organization. They, however, erred.

What appears to have happened is that the Mozilla board of directors misunderstood the role of CEO in an organization, particularly in a non-profit and mission-driven organization.

A CEO isn’t merely a leader; a CEO is a Leader. In a non-profit and mission-driven organization, a CEO is a LEADER. LEADERship extends far beyond merely setting technical and strategic direction for an organization. It includes becoming the very public face of everything for which the organization stands.

As an organization with a brilliant track record for supporting diversity and freedom of all sorts, Mozilla could not have a CEO who was on public record as opposing what a great many people see as a civil right.

Undoubtedly, as CEO, Eich would have continued his admirable track record of not allowing his personal political and religious beliefs to impact his professional performance. He had, after all, been CTO of Mozilla almost since the beginning and from all appearances his personal beliefs did not affect that performance. But being CTO is not being CEO. A CTO is responsible for setting and delivering the technical vision for an organization. One’s opinion on social issues is unlikely to come up in such a role.

A CEO, on the other hand, is responsible for setting and delivering the overall vision for an organization. This vision includes not only business strategy but also culture and mission. As such, a CEO’s beliefs must completely track with those of the organization which they lead. This is part of what makes the hunt for a new CEO so challenging. While a CEO’s personal beliefs may not affect the easily quantifiable parts of their job, (as we have now seen) they can have untold effects on responsibilities which, while more fungible, are no less important.

If there is any blame to be placed here, it is with the Mozilla board for not realizing this fact. They were aware that Eich had taken a public stance on an issue which could be seen as contrary to the Mozilla culture, yet they apparently did not see this as a potential problem for acceptance of him as a CEO. It was this ignorance and lack of awareness which led to the recent drama. Thankfully ignorance is curable. And undoubtedly Mozilla has had an effective dose of its medicine for this ailment.

There is no doubt in my mind that Brendan Eich has the experience, the vision, and the competence to lead Mozilla for years to come. He has proved that with his many years of experience as CTO. But from a cultural point of view he was, unfortunately, damaged goods. As such, the Mozilla board of directors should have refused delivery of the CEO package. If they had, they could have retained him, his passion for the open web, and his talents to help further the Mozilla mission.

Instead they are left with a learning opportunity and without the contributions of a founding father. Thankfully, the organization is populated by thousands of brilliant and insightful human beings. Mozilla will recover from this mistake, and even while recovering it will continue its work toward the open web. Those of us who agree with and believe in this mission should, now more than ever, support Mozilla. Let’s turn this experience into learning and continue to move forward.

The Rising Costs of Aging Perlers: Part 2, The Business

At this point you’re entirely justified in asking, “So what?”

The fact of the matter is, the lack of junior programmers is a very big deal from a business point of view, both to companies which already use Perl and those who might otherwise consider it. This directly and strongly impacts the bottom line of any Perl-using development shop.

According to Payscale.com, in San Francisco the median pay for a junior software developer is $66,000. For a senior software developer it’s $111,000. To be honest, we’re in a boom here right now. It’s my experience as a software development manager that each of these numbers is at least $20-$30K too low, but let’s run with the Payscale numbers. It’s obvious that a senior software developer is going to cost a shop a minimum of nearly $50,000 more than a junior developer.

Now consider the structure and needs of your typical software development department. There are a number of tasks which absolutely require the skills and expertise only a senior developer can bring to bear, but the majority of the work most likely can be performed by more junior developers with appropriate supervision. You do not need every member of your team to be senior and, at an extra $50K a head, you can’t afford to do it anyway. That sort of staff expenditure is an irresponsible business practice. However, as unreasonable as it is to expect a company to pay so much more for experience they don’t need, it’s equally unreasonable to expect a senior developer to accept less pay than (s)he has earned through years of training and experience.

Companies in this position, in order to continue using Perl, will have few options available to them. One of those options is to start training all incoming developers to use the language. While this is possible (undoubtedly some companies already do this), it is itself a very expensive proposition, often costing tens of thousands of dollars in training costs, time and productivity. A number of companies may run the numbers on the investment they’d be required to make in training and decide that it provides a much lower return than undertaking the arduous task of rearchitecting the software to use a language where they are able to hire staff (and at a more reasonable rate of pay).

Alternatively, companies which do not yet use Perl may be turned away from the language for similar reasons. The harsh financial realities of running a business—rather than technological merit—will end up dictating which programming language a company will use for their product. Selecting a language for which you can only hire senior developers is a very bad business practice, which leaves Perl in a poor position from a business point of view.

From where I’m standing, it does not appear as though the Perl community is doing much to correct this issue. As I detailed in my earlier post, in many cases Perl’s new programmer outreach appears fairly crummy if not virtually non-existent. This needs to change before Perl starts to face a cultural extinction. Perl needs to start creating fledgling Perlers to help sustain and grow the language through it’s next twenty-five years. As well, this will add new blood to the community and help diversify the gene pool. The more diverse a community, the better it’s able to adapt to the changing conditions which might otherwise overwhelm it.

A diverse or deep gene pool gives a population a higher chance of surviving an adverse change in conditions. Effects that cause or reward a loss in genetic diversity can increase the chances of extinction of a species. Population bottlenecks can dramatically reduce genetic diversity by severely limiting the number of reproducing individuals and make inbreeding more frequent. Wikipedia page on Extinction

In the final post of this series, I’ll detail some suggestions for avoiding this cultural extinction. Read Part 3.

Putting Away My Pitchfork: The Yahoo Remote Worker Announcement

On February 22nd, 2013, Yahoo! CEO Marissa Mayer announced that all remote employees will be required to work from their local Yahoo! office by June.

The internet grabbed its pitchforks and lit its torches then exploded with anger and derision.

Does this announcement place a hardship on remote Yahoo! employees? Probably.

Is this a draconian move by Mayer? It seems that way.

Would I have done the same in her place? I don’t know. And neither do you.

The fact of the matter is that none of us are in her place. As a company, Yahoo! has been foundering for years and Mayer is now at the wheel trying to right the ship. I’m not their CEO. Neither are you (unless you actually are Marissa, in which case, “Hi!”).

To be entirely clear and open: My initial reaction to the announcement was horror and anger. I am a supporter of remote working arrangements, and not only because I have one myself. I realize that there are good people everywhere and setting up an infrastructure to support remote workers allows companies to find the best people for the job, no matter where they’re located. However I also realize that without the appropriate infrastructure a remote working arrangement can be disastrous to a product and a company. It’s not for everyone. It’s not for every company.

Mayer is many things, but one thing she is not is a fool. Before this decision was announced she knew it wouldn’t play in Peoria. She knew there would be PR fallout. She knew the internet would cast her in the role of the wicked witch. She also knew a hell of a lot of other details to which none of us are privy.

This could not have been a swift decision, made in a moment of passion. Undoubtedly it was researched, calculated and discussed ad nauseam. Without access to that research and the discussions around it, none of us can know whether this is a good decision for Yahoo!.

I feel for the Yahooligans who now must uproot their working lives, I truly do. But I’m going to resist my impulse to pillory Marissa Mayer for her decision until I know more about what led to it.

‘Fail’ doesn’t have to be a four-letter word

Projects fail. Companies crash and burn. Screws fall out all the time; the world is an imperfect place. Just because it happens doesn’t mean we can’t do our best to prevent it or—at the very least—to minimize the damage when it does. As a matter of fact, embracing failure can be one of the best things you do for your organization.

First, let’s start with a few extreme examples of how things can go wrong…

A grim roll call

  • Despite warnings from many engineers, the space shuttle Challenger was allowed to launch with a faulty design on its oxygen tanks. The thinking, paraphrased, was “it will only be dangerous in these specific and unlikely circumstances…” Those circumstances, unfortunately, occurred.
  • A stuck valve, a signal light known to be ambiguous and lack of training led to the near meltdown of the TMI-2 cooling tower at Three Mile Island, to date still one of the worst nuclear disasters in history.
  • The Deepwater Horizon oil rig, off the coast of Louisiana, exploded in 2010 due to a number of factors: A cementing procedure was not followed correctly, allowing gas to escape from the well…on a windless day when a man was welding nearby.

Each of these tragedies has something in common: it could have been avoided. In each case there were known problems or procedures which were ignored and in each lives were unnecessarily lost. Each was the result of a compounding of small issues and oversights which unfortunately combined in just the right proportion at just the right (or wrong) time, small issues which were insignificant…until they weren’t.

Most likely lives are not on the line in your business but that doesn’t make your project failures feel any less personally and professionally devastating at times. Like these three tragedies, it’s likely that your failures can also be avoided.

Before suggesting how to avoid project failures, we should take some time to understand some of the factors which lead to them in the first place. There are many reasons why a project might fail, but two of the biggies are Culture and Cognitive Biases.

Cause #1: Culture

Do you like failing? No, nor do I. In general, humans do not like to fail. If things don’t go as expected we tend to get very cranky and sometimes irrational. This is unfortunate as failure is one of the most effective teachers we have.

Many project cultures are openly hostile to failure in any degree. In these cultures, backing or working on a project which doesn’t succeed as forecast can be very unhealthy for one’s career. Mistakes—even honest ones—are punished. This frequently leads to errors and oversights being swept under the carpet rather than being brought to light and addressed promptly. As we’ve seen in the examples above, ignoring the small things can have devastating results.

People in these cultures go to great lengths to avoid association with failure. Frequently, they’ll shelve a new and potentially profitable endeavor rather than take the chance it may fail. This risk aversion stymies innovation and company growth. As well, when a new project is pursued and is not going as planned the people associated with it will not report this underperformance. Doing so is often perceived (at best) as rocking the boat or (at worst) hitching yourself to the failing project. Therefore the project chugs along, devouring company resources, rather than being cut as it should be. All because of a culture which is hostile to failure.

Cause #2: Cognitive Biases

We all come with mental software packages which help us cope with life, allowing us to form judgments and take actions in situations both mundane and exceptional. Usually these work as expected and everything is just fine. But then there is the edge case, where the software doesn’t work quite as it should. This is a cognitive bias, “…a pattern of deviation in judgment that occurs in particular situations, which may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.

While many cognitive biases have been identified, there are four which most commonly contribute to instances of failure. You will all recognize them:

  • Normalization of deviance: The tendency to accept anomalies as normal. “Yeah, we get that error message all the time. Nothing’s ever blown up so we just ignore it now.”
  • Outcome bias: The tendency to focus on the outcome rather than the complex process leading up to it. “Sure, some things went wrong during the code deploy but the product shipped and isn’t that what really matters?”
  • Confirmation bias: The tendency to favor evidence which will support existing beliefs. “No, see, I know Windows would suck for this purpose because I read this article by RMS…”
  • Fundamental attribution error: The tendency to put too much blame for failure on personal rather than situational factors. “We fired the out-sourcers because they were hacks who didn’t know anything.” (Actual: the out-sourcers weren’t given the information and support required for success)

Suggestions

The possible causes for project failure are too varied and unpredictable to be able to avoid them all. However, given what we know it’s possible to minimize the impact and occurence of many potential failures.

First and foremost, it’s necessary to change the project and/or company culture so that it encourages people to report problems, no matter the size. The saying of this is, of course, much easier than the doing. Changing a culture is difficult but, at least in this case, very worthwhile. You can only solve those problems you know. The ones which go unreported end up costing dearly in money, time, effort and team morale.

Any cultural change must have honest and complete support at the highest levels of the organization. An effort like this can only succeed with commitment and leadership. Management must understand why the change is needed and lead by example. Only then will other members of the team feel comfortable enough to pull back the curtain and expose the problems which are holding the organization back.

Leadership should also learn to celebrate rather than blame those who bring errors, problems and failures into the light. Such actions should be seen for what they are: successfully preventing the waste of vital resources. Most people in tech have heard the phrase, “Fail early, fail often.” Few live by those words or reward those who do.

Many organizations will perform a postmortem on a project which has failed. While useful, these processes don’t even show half of the picture. The best way to identify issues which may put future projects at risk is to postmortem all projects, successful or not. Thanks to outcome bias, a near-miss will look like a success and typically will then escape a postmortem scrutiny. This leaves a raft of issues unidentified, ready to appear and compound in future efforts.

But even this won’t help you identify potential problems when you need to. While locating and anaylzing them after they’ve occured is, of course, valuable, wouldn’t it be better to spot them before they become real problems in the first place? Part of the cultural changes which must occur is an organization-wide commitment to spot and report potential problems as quickly as possible. This is more likely to happen if people are asked to use simple and familiar tools to make the reports. Rather than re-invent the wheel or roll out yet another tool for team members to learn, I suggest that the organization’s existing issue tracking system be used for this purpose. After all, while these problems may not be software bugs they are issues which need resolving. Simply create a new database/project/what have you in your issue tracker then open it up to everyone in the organization. It does little good to report issues if people are not able to see them, after all.

Reporting the issues isn’t enough. If people believe that the reports go into a black hole, where they are never viewed let alone addressed, they will stop creating them and you’ll be right back where you started. These issues should be analyzed to determine the root causes for them. When resolving a problem, all too often people will scratch the surface and leave it at that. “This build failed because $team_member didn’t follow the procedure.” That’s not a reason for the problem; that’s a symptom. The true reason is buried somewhere in there. Why did $team_member not follow the procedure? Is the procedure wrong? Was there some exception? Was $team_member getting undue pressure to work faster, causing corners to be cut? Did $team_member not know that the procedure exists or that it should be used in this situation?

The statement, “This build failed because $team_member didn’t follow the procedure” is a presumptive and possibly incorrect placement of blame. As you can see, it is much more likely the case that the system within which $team_member is working is flawed than that this person is incompetent. The urge to point fingers is strong, but a vital part of the cultural change required is to discourage laying blame without doing analysis. Take an hour to speak with everyone involved to figure out the true underlying reasons for the error. Never punish but in the cases of gross negligence or repeated incompetence. Let people know it’s not only OK to make mistakes, it’s entirely natural to the human condition. Not only will you find that people start reporting and addressing issues before they become real problems, you’ll also find that team morale improves as people realize that they’re respected and trusted.

Once you’ve identified the underlying reason(s), make sure to correct and communicate. It does no good to analyze a problem if you’re not going to do something with what you discover. Fix the procedure. Provide additional training. Add a new Nagios warning. Modify the schedule to allow time to do things right. Bring in a specialist. Do whatever needs to be done to be sure the issue never happens again. And, of course, it’s vital that you communicate not only the necessary fixes but why they were necessary in the first place. Team meetings are a good way to do this but don’t forget that issue tracker. Any resolution should be captured here for posterity. Just like adding comments to a complicated piece of code, Future You will be grateful if you document both the problem and its solution.

Other Resources

As I mentioned above, there is a myriad of ways in which a project can fail. This article only starts to address that and some of the things you can do to prevent or minimize damage. If you’re interested in learning more, here are some of the resources I’ve stored up on the subject. Most of them are from HBR, so you may need to pay to access them. You can also probably get them from your local public or university library.