Enemy Gate Down @enemygatedown - Tumblr Blog

Implementers and Integrators

Organizations need both Implementers and Integrators.

Implementers are those who specialize in nuts and bolts execution work. Migrating a database, designing a landing page, and running event logistics are all examples of implementation. Integrators observe disparate pieces of a system working in tandem, and discern ways of helping them work better together. This could mean noticing where teammates have a pattern of talking past each other and intervening to resolve confusion before the wrong thing gets built, or recognizing that two people want to develop similar skillsets and pairing them up to take an online course together.

In tech, we over-index on Implementers. I believe part of this comes from companies initially facing an existential chasm as a matter of course, which must be crossed by getting V1 out the door, or risking not having a company. At this point, implementing your way forward is really your only option. After you've implemented successfully enough to see another day, that experience stands as a powerful object lesson among your early team. A dopamine cycle has formed up around implementing, and the time you crossed the chasm becomes the stuff of shared legend.

As organizations age, the technical and human systems being maintained grow in size and complexity. The more pieces you have, the more different ways there are for them to malfunction. This is when the need for Integrators who can recombine or fine tune the pieces so they run together more powerfully, or reliably, or humanely, starts to really show.

This is tricky. Integration work can be a lot harder to account for. It requires observation before action, and often action takes the shape of nuanced adjustments which are only later felt system-wide. Frequently, an org under strain from growth will respond by seeking more Implementers, without realizing what they need is more Integrators. This is rational. We use our past experiences to inform our present strategies, and based on the past, adding more Implementers to make more things is how to get out of a pickle. Unfortunately, this old strategy applied to this new problem exacerbates the strain. An uptick in Implementers creates more complexity which needs to be managed, further increasing the need for Integrators. Contributing to the force of this tightening ratchet is the fact that Implementer work, with its tangible outputs, is vastly better understood, and almost always more rewarding in the short-term. Proper recognition of Integrator work requires a lot of faith, and interpersonal trust, and moving through uncertainty.

You might know Integrators under a different name: managers. Good management is more than bossing people around. A good manager bridges the divergence in people's frames of reference, creating shared meaning so that more than one person can do productive work on same problem. Inevitably flat organizations realize they need management once they hit a certain scale. Without designated Integrators, it becomes unclear where individual contributors can make the best impact—to say nothing about where they go when things stop working. Meanwhile, managers who do just boss people around leave their people feeling helpless and blindsided as a matter of daily course, as they lack a sense of the bigger cohesive picture and their role in influencing it.

Changing your toolset at a point when you're facing high stress and high stakes is exceedingly difficult. When nothing is working, and the pressure is weighing on your chest, stopping to ask yourself and your collaborators why things feel so off, or whether you're all solving the right problem, can seem like the most outrageous thing anyone could possibly do. Yet this sort of non-complementary behavior may be the best way to ensure integrity in the systems you're all maintaining.

Exploring the Human Implications of Conway’s Law

Conway's Law states that:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

In other words, the communication patterns in your team are duplicated in your software. I recently had a chat in which my counterpart made the point that if we take Conway's Law to be true, it should stand that the mental state of the individuals engaging in said communication is also having a great affect on your software.

When dealing with networks, we most often focus on the links between the nodes. It's the relationship between the pieces which produce a meta layer of dynamics to work with. Without connections, there is no network. Yet when dealing with networks of humans, the natural extension of Conway's Law calls on us to examine the state of nodes themselves.

In contrast to inanimate interactive entities, like servers, human nodes are neither uniform nor neutral. Much the way DNA contains a set of plans for how an organism's development unfolds, humans are carriers of their own design patterns. The way these design patterns are expressed in an organization will vary based on things like their past experiences and identities, whether or not they perceive that their contributions are respected, and whether they've gotten enough sleep or calories, just to name a few. An individual human node will respond to stimulus differently based on the state of these factors, which shifts how they will communicate on a given day. Conway's Law postulates that this is reflected in the software system they're building. Then, there's a concurrent process running where they interact with other humans in your organization, each with design patterns of their own. This combination produces the state of your software.

While preemptively controlling for every aspect of the communication between the humans designing a system seems unlikely, it stands to reason that optimizing for the well-being of the individuals doing the work can be a sort of resilience engineering. Things like proper compensation, respect for boundaries, a blameless culture, and clear opportunities for advancement create circumstances most likely to engender an open, well-regulated, constructive mental state. If Conway's Law is right, maintenance on the state of the human nodes in a network paves the way for more constructive communication patterns, and better software.

Will voting functionality on Facebook solve anything?

Word came out earlier this week that Facebook is running an experiment, giving a small number of users in New Zealand upvote/downvote buttons on comments. I'm wondering what Facebook is looking to learn.

Upvotes and downvotes have been around since forever on gamified platforms like Reddit and Stack Overflow. Voting introduces a sense of right or wrong in a community. It quantifies the value of your participation, turning your popularity, or lack thereof, into something measurable. It's opinionated. Fittingly, voting is a functionality which took root in technical, programming-focused, and gaming-adjacent communities.

Facebook has a whole different premise than gamified discussion sites do. They built their social network around sharing and staying in contact with loved ones. They made it frictionless to share anything about yourself, in the hopes that you would share everything about yourself. Facebook makes money by using the data they have about you to show you extremely tailored ads. What you see in your Facebook timeline is algorithmically generated and optimized for content which you are most likely to react to, fueling engagement. Facebook has, of course, been under scrutiny since news of the data leak to Cambridge Analytica and investigations into how the site has been used to organize local violence in Sri Lanka.

So on the one hand, you have platforms which are about getting people to post and quantify the value of each other's words (Reddit, Stack Overflow), and on the other, a social network which aims to make you observable and reactive (Facebook). And voting, a core functionality from one is being essentially air-dropped over to the other. Where could that be helpful? Where could that be harmful?

There's been a lot of talk about fake news lately. I tend to think the definition of "fake news" is far more slippery than most of us care to believe, but that's a post for another time. Point is, there's concern that there's no way to discredit something posted in bad faith on Facebook, and in the form of voting, there's functionality which allows every day users to do just that. I get why added opinionated functionality might seem like the right counter-measure.

What I wonder is, will the mob mentality which tends to form up during user voting ultimately help or harm the nature of the interactions taking place? When asked, a company spokesperson said "People have told us they would like to see better public discussions on Facebook, and want spaces where people with different opinions can have more constructive dialogue...Our hope is that this feature will make it easier for us to create such spaces, by ranking the comments that readers believe deserve to rank highest, rather than the comments that get the strongest emotional reaction.” The idea that folks will believe the posts which should be ranked highest aren't also the ones which emit the strongest emotional reaction runs counter to everything I’ve ever known about humans and keyboards.

Furthermore, when a post gets heavily downvoted...what happens? Will there be someone on the other side, at Facebook, able to step in? I'm guessing not. Will there be anything that happens when a comment is heavily downvoted? Unclear. Is this all about making sure we just keep clicking things? Maybe.

All in all, this sounds like an interesting experiment and I'm glad to see Facebook do something. I really hope they speak publicly about their findings. But I also see how this feature could cause users to double down on their existing disagreements, grudges, and gripes.

Finally, copping to the fact this is an experiment, this measure strikes me as misguided because voting sets users up to reach for a goal which Facebook has not defined. Whether you’re trying to drop the best meme, or the most articulately explained physics equation, seeking votes means you’re aspiring to be something valuable in the eyes of the group. What is it people are reaching for when they seek upvotes on their Facebook comments? What kind of discussion space is Facebook looking to create? How do the answers to the previous questions vary based on the demographics and context of the folks doing the posting? Without answering these, Facebook is simply bolting another tunnel onto the multi-level hamster mansion, and hoping the novelty of its presence gets the critters to stop fighting.

Commit History

This is primarily an exercise in record keeping. Two years ago I wrote a post about burnout and went silent. Here are some things which have transpired since:

I found work which fits the parameters outlined here.

I published Contributions to put myself on the hook for figuring out more purposeful work, aiming at either of two broad categories: #1 enabling networks of people to help each other or #2 helping the technology industry be a better version of itself. I’ve now clocked nearly two years as a Community Manager at Stack Overflow. Both sets of parameters are being met surprisingly well.

Better attention management.

Our attention spans don't scale to the size of the internet. In March of 2014 I took the month off Twitter, which gave me a chance to examine how it was re-patterning my brain. The silence was delicious, and the hiatus equipped me to make clearer decisions about where I spend my cognitive resources. My relationship to social media hasn’t been the same since.

The start of a thesis.

In May of 2015 I presented at CMX Summit East on the five traits of enduring communities. This was the first time I'd done any speaking since taking time away, and it was rewarding to lay down a cohesive set of ideas which were the product of several years of work. I also couldn’t have asked for a better place to do it. (To David, Carrie, Yrja -- thank you!)

These are subtle but significant changes which come from focused effort. I look forward to continuing to put in the work.

Reset

About three weeks ago, I said goodbye to my team. I've been in need of a break and after spending a year and a half working on technical infrastructure for the dev community, the company is increasing their focus on enterprise products. It was a good time for me to step back.

Since leaving, I've been able to think more about what the last few years of my working life have looked like. In the span of the last three years I've helped two companies move from early-stage to mid-stage. I've handled user shitstorms, overseen dozens of launches, pulled all nighters, been through the fundraising process twice, managed people, turned customers into close friends, and kept countless moments of high emotion from tearing people apart. Along the way I developed a knack for breaking down silos between technical and non-technical teams. I love watching organizations grow and flourish. I've been humbled at what it is to be a manager, and to serve those who have entrusted some part of their career to me. This work is a privilege.

I'll also be the first to say it. I've burnt myself out, hard.

I drove myself to unhealthy levels of exertion too hard for too long in pursuit of the next milestone.

I was over-investing myself in the organizations I was part of. I was making my work the one single point of failure for my ego.

After awhile, my friends never saw me anymore, I forgot why I ever liked the things I liked, and crossing off virtually any 'to do' list item took an excruciating amount of effort.

Why did this finally dawn on me? Historically, one of my biggest assets is my ability to think deeply about a messy problem, and formulate a single response that makes things click into place. I'm also good at simulating other people's experiences and modeling interactions. It's part of what made me a good community manager. After driving myself too hard for too long, my ability to do those things dulled.

I also realized I wasn't fully listening to the things people would say to me. I caught myself categorizing what kind of conversation I thought I was entering ahead of time, associating a few normal behaviors with that type of interaction, and going on autopilot. Upon realizing this, I responded by pushing myself harder in an attempt to recoup lost productivity. Soon the combined momentum and pressure were taking on a life of their own. I was doing the next thing that presented itself because it seemed easiest at the time, and I was too harried to synthesize what the pieces added up to. I was struggling to connect with people.

You own your tools

If I stop, and think (which I haven't done in years), I know damn well there's a problem with all that.

The always-on, drive yourself into the ground, race to the top of Hacker News, pwn Demo Day approach is a specific tactic, and not a long term strategy. It needs to be implemented at certain critical points in a company's life-cycle, assuming you're trying to build a venture capital-scale business.

This tactic needs to be employed when:

1) you're first starting out and successfully doing or not doing certain things (making a product, getting money in the bank) determines whether or not you have a company at all.

2) your entire company is pushing to meet a discrete and time sensitive deadline, the outcome of which is has been deemed similarly pivotal as the very earliest stages of your business. (in the style of #1).

That's it. Those are the only times when the approach to work that I was taking are appropriate. (If you're running a lifestyle business, you're playing a different game all together, and more power to you.) And if you've convinced yourself that you're always working in one of the two sets of parameters I described, thereby creating constant life or death urgency, you're doing it wrong.

There are extenuating circumstances, but if you've made your working life into one long string of extenuating circumstances you're designing for diminishing returns and eventual failure. You can either become amazing at self-regulating and prioritization overnight, or pull the plug, make a full stop, and engage in some serious self-assessment. Personally, the former wasn't working for me, so I eventually chose the latter.

Well, what now?

It would be lovely if I could explain to you all the things I've figured out and the wisdom I've found. The reality is I'm still pretty turned about, and clarity takes awhile to cultivate. Fortunately, I'm already feeling more like myself than I have in a long time. After just three weeks, the haze is clearing. I'm also resisting the urge to dive back into a full time job at the first sign of relief. I can't do my best work if I'm not a whole person, and I think I owe my future teammates that much.

My life's work is too important to go through it mindlessly. That's what I started doing, and I don't want to keep compromising. I view work as a calling, and jobs are individual vehicles to help materialize some piece of the puzzle. I've proven that I'm incapable of doing anything half-heartedly. It lets me rally myself and those around me, but the dark side of this tendency can get seriously bleak.

I need to learn better self-management, so I'm going to keep taking time. I'm going to keep spending long aimless afternoons in the park, reminding myself of what makes me smile, and letting the bits of understanding filter in, packet by packet. I'll keep writing, I'll keep talking, I'll keep renewing friendships, and I'll keep thinking about how to do work that pays respect to either of the problem sets I outlined here.

I'll keep you posted.

So You Want to Work With the Developer Community?

When I transitioned into working with technical communities, I was pretty sure I was a weird outlier who was suddenly getting to explore my passion for developer culture. Then I noticed something funny; some of my peers followed the same track shortly after I did. Investment in developer tools has also been on the rise, so demand for this work looks like it'll keep on flowing.

If it's going to be a trend, I'd like to help newcomers serve the developer community better and be more successful in their own right. Here are a few things I wish someone had told me.

Developer community management isn't new

What is somewhat new is early-stage venture backed companies concerning themselves with it. For a long time, this was the domain of enterprise software giants. Community management has been core to successfully run open source projects since open source emerged, and in OS, community decisions and engineering decisions are often been inextricably linked. Your developer-focused company might not be driven by open source specifically, but if you're trying to facilitate any kind of collaboration, you'll need to understand how open source works.

If you want to study some of the roots (and you do), go read about the Java Community Process, find out what Ubuntu's community efforts entail, and get to know the backstory between Sun and Oracle. This may sound outlandishly academic and arcane, but I promise you this is imprinted on the developer community's collective subconscious, and is affecting how technology gets made today. If you show up and behave as though there's no history or cultural precedents, your efforts wont go as far.

The incentives are different

If you've been working with a non-technical community, you've likely been investing time and effort into helping your community members feel close to your brand. Developers don't care about brands as abstract entities. It will matter whether you connect with your community in the mediums they're most comfortable in. It will matter whether or not you try and hard sell them. If you're a developer, everybody wants a piece of you, both from a positive standpoint of being able to set your price in the market, and from a negative standpoint in the commoditized and transactional ways people will approach you as a resource. The things that made your old community feel appreciated might not transfer. Developers want to build good systems and be recognized for their contributions. Prepare to understand and respect that.

It's not a spectator sport

The only way to be a facilitator is to be a member. I don't believe you can successfully work with the developer community if you're not actually part of it. Building with code is the act of assembling individual actions into a process that can be repeated whenever desired. You should have at least some understanding of those components, of the technical facets of your specific ecosystem, and a few opinions on them. It's far better to fail at hacking tiny things together than it is to not try at all. Prepare to show up to events, just be there, and get your hands dirty. It may be tempting to think that as a community manager you can just deal with the big broad picture. I believe that you need to understand the granular components in order to make your vision real.

Creating a space where people know and care about one another, and interaction is high is still the name of the game, whether or not you work with the developer community. Just get ready for the social mores to look and feel different.

Contributions

I'm obsessed with work. Sometimes (okay, a lot of the time) that means I'm a workaholic, for better or worse. When you get to the heart of the matter though, I'm driven by a sense of my 'life's work'. As in, what will I make with other people, over the course of my lifetime, which will elevate other human lives? How do I know what to work on? How do I maximize time spent working on the right thing?

In my career so far, I've thrown myself into some very different parts of the world. Consumer startups, enterprise software, and open source are some prime examples. The people who reside in each of those sectors don't usually sit down and have real conversations with one another. While jumping between silos has sometimes been a shock to the system, and has occasionally been very lonely, it has given me the opportunity to understand the experiences and motivations of disparate groups of people who usually would never cross paths. Standing at the crossroads of these tribes and playing in the ambiguous space in between them has allowed me to stress test many of my own assumptions, and has afforded me a much bigger picture of reality.

Based on my learnings, there are two classes of problems that I would like to spend the next 10+ years of my life's work focused on. This is an early attempt to articulate the two different problem sets that I find most compelling. They may change, but its a start.

1) Peer to peer empowerment via large networks.

How do we help individuals create things, make themselves useful to one another, and live better lives because of it? Since the financial crash of 2008 many of the economic paradigms that we'd come to take for granted, like employment and the value of a college degree, have largely stopped working. This is slowly breeding a generation of micro-entrepreneurs and DIY-ers, and a trend towards sharing and collaboration so that resources can be used effectively. Current examples are the Etsy's, the Shapeways', and the Kickstarter's of the world, but what comes next? There are certainly a multitude of ways to help people lift themselves up at scale in the current landscape which have yet to be implemented. Helping people adapt to and thrive within this new climate is one of the things I would most like to do with my time.

2) The global technology community

I recently read a post called After Your Job is Gone. Check it out, I highly recommend it. It helped me to understand how very lucky I am, as is every other person employed in tech, to be in this sector. We're in a great place while the divide is deepening between us and much of the rest of the world. It's easy for us to slip into thinking that our bubble is the world. This loss of perspective can lead us to waste our remarkable abilities on non-problems, or much worse, waste each other's time on destructive in-fighting. The question here is, how can we, as this privileged part of the global population be the best versions of ourselves? This is something I'd like to spend considerable time devising solutions for.

I hope that by sharing this, I'll have an easier time aligning my small daily decisions with big these priorities.

If you're trying to figure out where you'd like to contribute, perhaps we should talk.

Things I Believe

Roughly a year ago, I wrote these down. I was in a tangled confusing mess. At the time, I was trying to determine an outcome to something I couldn't control. It just wasn't in my hands. Recognizing this uncertainty, I tried for hours and days with my analytical abilities to play chess with reality, calculating each move until I had a known outcome. This left me more frustrated and mentally exhausted than I'd started out.

I couldn't force it. So instead, I asked myself what would endure, with or without the temporary situation I was wrestling with. What would matter 40 years into the future? These were my answers, and I decided the time was right to share them:

Business works better when a company is a medium to express what you stand for.

Business works better when you care about the people you work with, and create a product which is an expression of those relationships.

You can never have ownership over someone else in work or in love. You can only choose to spend mutually beneficial time together.

When there's no longer mutual benefit, reassess your terms.

Simple decency always trumps formal protocol.

Generosity, and creating experiences which make people smile, usually get you more than you started with.

If you love what you do, you'll profit more.

If you want to make big gains you have to be vulnerable.

Define your standards. When push comes to shove, maintain them.

The world will always be too complicated for us to know every answer ahead of time. Pick your axioms, and in moments of doubt, fall back on them.

Thanks to Buster Benson for his 'A Few Rules I Try to Live By' which helped inspire the thoughts above.

An End to 2012

When 2012 began, I was determined to make it a year of change.

Professionally, I switched companies and roles: a change from an e-commerce/manufacturing marketplace to an open source driven cloud computing company. I dove into JavaScript and Git, got to know servers a whole lot better, and learned how to collaborate with a remote team. I began leading our support engineers.

Personally, I forged relationships with people who I expect to know for years, and strengthened existing ones with friends and family. Some fell apart, and came back stronger. I can honestly say I’ve never been surrounded by better people than I am today. I started a yoga practice. I began weight training. I’ve been experimenting with how personal discomfort can be a teaching tool.

2012 has been exceptional. My only regret is not having been present for more of it. I’ve dug into whatever’s come my way, and sometimes, I’ve let the hours and days pass me by. I haven’t taken sufficient time to think.

My hope is that 2013 will be similarly dynamic, but I want to increase how much I synthesize the experiences I’m having. We only get one life, and I want to make sure I’m feeling the seconds.

Here’s to lots of laughter and learning in 2013. I’m glad to be on this ride with all of you.

Makers and Managers: The Community Version

I recently caught up with a good friend who also works with the developer community. They spend their days at one of NY’s more mature tech startups, and we discussed how community efforts took shape in the early days, and how they've evolved. They spoke of the process of starting off as an individual contributor, and moving to where they are now: facilitating the work of a team of individual contributors.

It got me wondering, is this the only way? Is it is always necessary for more mature community managers to become team leaders in order to feel their work is relevant? Or is it possible for a seasoned community manager to stay hands on working with their communities, facilitating interactions directly on the ground, and to still feel like they're adding value and making traction in their careers?

In the software development world, there are typically two tracks for an engineer: become a manager, or remain an individual contributor. In organizations that know what they’re doing, one is not regarded as being above the other. They're both viewed at as critical but different ways to add value. Baked into this is the fact that software engineering is a highly specialized skill, so the people doing the day to day work of making software are viewed differently than those working on an assembly line.

As community management gets to be more mature, my peers and I are increasingly moving into team leadership roles. While it definitely suits many of us, I also think we've felt like since the product of our work isn't code, we haven't had much choice. We've needed to follow traditional business protocols that show when we're stepping up. I wonder whether by following some traditional assumptions, we're potentially misusing great talent.

As good companies move beyond the startup phase, and start considering what it takes to keep community managers (and teams of them) happy it'll be an important thing to consider.

Community Interactions: The Most Important Question You Can Ask

Communities and organizations are made of relationships. They consist of the connections we make between one another, and how we either move those connections forward or get in their way. It's that simple.

Relationships which don't benefit everybody involved don't last. They may continue for awhile, because one person or group is in need of what they get from the other. The alleviation of their immediate short term pain is worth the hit they're taking. But as soon as the one in the disadvantaged position gets the smallest edge on the situation, they're going to look to flip the game. If you squeeze too hard on the advantage you have, you ultimately you lose a supplier, a team member, or a customer. So how can we can counter this natural, but totally destructive cycle?

I've become fond of a simple qualifying question:

Is this helping us both be the best version of ourselves?

Whether you apply this question to an interaction between two individuals or to whole subsections of a big group, the effect is the same. Personally, it gets me to stop thinking about the next few hours or weeks, and helps me to see things in terms of years and defining moments, how the small choices I make everyday actually make me who I am. It frames you and the other guy as both having valid goals and things you care about, and things you're probably both working towards. If I'm squeezing the situation too hard, its the wake up call I need to stop.

Communities can't thrive if the people in it are treating each other like resources to be exploited. Consider what it would be like if the relationship in question gave you both extra strength and bandwidth so that you could each do what you do better. How would that get everyone where they want to be faster? Or make the relationship more durable? This line of thought is an insurance policy.

The only way to start is with yourself. Then you figure out how to incentivize your closest confidantes in the community to ask themselves this same question, and to share your answers or, as the case may be, your failings with each other. A small subset of a group practicing being thoughtful and measured in a shared effort in the face of conflict can change the nature of a whole network.

#community #negotiation #relationships

When to Hire a Community Manager

Recently I've had a number of conversations with founders looking for advice on when to bring on a community manager. People are increasingly hiring for the role, but the question of when (and whether) it fits into the company is often still a mystery. To help everyone figure out what they want and end up happier, I'd like to shed some light for founders and potential candidates.

Hire a community manager if and when:

* You have users

It sounds obvious, but you'd be surprised how often this isn't the case. There are lots of companies who hire someone with the community manager title to get users when they don't yet have them. I believe that's turning the wrong dial. Your initial users will come, or not, based on your product and if user adoption at the early stages is less than expected, you need to tweak and reflect on your product. Throwing another person into the mix will likely add to the confusion. Make sure you've got a healthy engaged user base to start with, before you consider hiring a community manager.

* Your interaction with your users has gotten to be more than you can handle

Having a sizable engaged user base on its own is key, but it isn't enough. There needs to be an element of critical mass. What do I mean by this? In the best cases, a founder manages all interaction with users at the beginning. Support, customer feedback, and just being there until you know the key players by name. If the pieces are in place, these interactions will increase in depth and number. There's going to be a certain point where the relationships are both too valuable not to nurture, but too numerous to keep up while also fulfilling other duties as a founder. This is when you might seriously want to consider bringing someone else on, but you need to think about one more important piece.

* You're ready to put your customers at the center of your business for the long-term

This requires some self reflection. Building and scaling a people-centered business is both hard and insanely rewarding. I wrote a bit about in a previous post (Are You Ready to Run a Customer Centered Business?). Hiring a community manager is the single biggest step you can take towards investing in your users. If you want to make user happiness a core business competency, and create an ecosystem in which people can impact each other's lives, go you!

I simply urge you to consider what you're taking on preemptively and make this choice deliberately. There's nothing worse than when the community manager is the only person in the company who really cares about the community. Think a few steps out and save yourself the internal strife later by deciding how much this matters to you now.

Just running through these bullet points giving a simple yes/no will provide visibility into whether it's right to hire a community manager (or whether the company you're interviewing with has it right). My hope is that this framework can help founders and candidates get more out of their efforts by providing a little more rigor, and setting expectations more effectively.

Disappointing Users = Disappointing Friends

One of the rules of thumb I use to judge the quality of my work is how much interacting with community members feels like interacting with friends. This is especially evident in how you handle disappointing people.

If I have to let my community down (which at some point will be inevitable), it should feel like I'm having to disappoint people who know me, put their trust in me, and who expect better. Uncomfortable? Absolutely. But the discomfort far outweighs the value. By the same token, if I do a gut check, and it doesn't feel pretty much synonymous, that's a sign that I need to reorient my approach. Time to reassess.

The irony of course, is using a more emotionally difficult feeling as a rule of thumb for something positive. It's something you find a lot when you work with communities -- embracing difficult moments with your members is one of your greatest strengths. It ultimately put you on the path for a deeper, happier connection with them.

Are You Ready to Run a Customer-Centered Business?

Running a company whose end goal is making your customers happy is hard. Obviously running a company at all is hard, but a business all about your users is fundamentally different. Have you considered what it means to be responsible to for a lot of people's happiness, to set that as part of your mission?

Everyone says they're pro-user. Let's face it, nowadays if you're building something on the internet, you're expected to talk that game. But it's important for founders and their teams to understand what they're signing on for. Once you've gotten your first few thousand users, and maybe closed a round of investment, and are suddenly hunkering down to try and create exponential growth, and thinking your very first thoughts about scaling, a shift begins to take place.

To build from this point with a close connection to your customers is going to be a whole different kind of hard. Have you thought about how it'll change your day to day? More bug reports with more urgency, apologies, communication around issues. Having a developed understanding of how your community will respond to things affects your decision making. Before you're at the point of hiring someone to lead your community, figure out whether or not you want a community.

Assuming you've done a good job, and hired the right community lead, they'll be in your face all the time with things that need to be handled for your customers. They'll push you to make things better for them. You need to know whether that's something you want.

If you don't feel you're suited to run a community driven company, that's ok. There are verticals and business models, even in tech, that don't require you to place user engagement and happiness as your raison d'etre. But do some soul searching beforehand about yourself, your team, and what you want to build, and know where you fall on that spectrum.

The Importance of Informality

How informal is your team? Do people follow social protocol, or display certain types of etiquette? If so, do all those little things and the extra seconds and thought cycles people spend on them move your company's mission forward when aggregated?

Informality is one of the most essential ingredients in enabling fluid exchanges of information between people. If you're willing to set aside some of the established ways of operating socially, because you agree amongst yourselves that they're unnecessary, you're making yourself more vulnerable. It's about being just a little unguarded. If you're doing that all at the same time, together, that fosters trust.

And I don't need to tell you that trust and free flowing information are crucial when a group of people need to pull together to solve difficult, exciting problems.

Informality is also a happy by-product. An output, not an input. Informality arises because of the other things you're doing right. There are external signals associated with informality, especially in the corporate world, but just because an office lacks suits doesn't mean the people in it trust one another. Don't confuse the external signals with the internal substance.

The meaning of work, and the relationships we have with our coworkers are transforming fast. So what are you doing to foster trust?

Standing on the Shoulders of Giants

This is Part Four in a Four-Part Series on Observations on Community Building

Somehow I've reached the 4th post in my experiment. Nice. I'll end off with some suggestions on where community managers can look in order to get a deeper understanding of our own work.

Even though companies hiring people to nurture communities is a new thing, the dynamics of communities go back a looong way. So its not surprising that lots of other disciplines have great bodies of knowledge to draw from.

If you're like me, and are trying to seek out and learn from a few of them, here are some places you might want to start:

1) Open source

Open source is pretty much the grand daddy of modern digital communities. People donate their time to a project to contribute to the greater good, and the results are owned by everyone. Now if your community surrounds a for-profit product, its probably structured a little differently. But when you're considering how to create buy-in and foster a distributed sense of ownership, there's much to be learned from open source practices. To start, check out the Starfish and the Spider, and read up extensively on Linux.

2) Behavioral Psychology

The study of why we do what we do is pretty important when you're looking to reach large groups of people and persuade them towards positive actions. Like it or not, as humans we have patterns to the way we respond to things, and behavioral psychology puts many of those patterns into tidy little packages. Influence by Robert Cialdini is a fun read on the topic.

3) User Experience and Interaction Design

UX design is all about understanding your users, and Interaction Design deals with crafting sequences that engage and delight them. They shape the way a platform interacts with its users, then we as community managers mold the way users interact with one another atop that platform. After users have spent some time with your product, usually they begin to have suggestions, which can then be sent back to Product, creating a positive feedback loop. Getting to understand how product designers think, and working together seems wise, given the meaningful ways our work impacts each other. I strongly suggest reading Seductive Interaction Design, and Subject to Change.

I hope that as community management develops, we all get smarter about drawing from established disciplines. The sooner we can put into perspective where this stuff comes from, the more effective we'll be.

Community vs. Marketing

This is Part Three in a Four-Part Series on Observations on Community Building

What's the difference between community and marketing? Moving from the all-encompassing view I took in my last post, and back to the more specific realm of web companies, this is a question that me and my peers are asking often as we figure out our teams and our strategies.

This would be my take on it: metaphorically, marketing gets people off the street and in the door, and community makes sure they want to stay once they're there. They're situated at different parts of the "funnel".

I tend to find that doing marketing work vs. community work really do involve different types of thinking. In the marketing mindset, you're thinking in terms of what's going to catch people's eye, and how to maximize appeal. When you're in the community mindset, I find you do more thinking about the emotions and the behaviors of large groups of people, and trying to tweak a network to maximize harmony. They both still have a lot to do with company values and identities, which is why people in both roles need to see eye to eye.

Especially in really early stage companies, one person often fulfills both needs. In the context of the startup where everyone wears 5 hats, this makes sense. However, what's best from a community perspective isn't always best from a marketing perspective. That's why when your company gets to the point where it makes sense to have one person handling marketing and another heading up community it can be a beautiful thing, so long as they're upholding the same values.

Trending Blogs

Recently Viewed Blogs

Enemy Gate Down