About three weeks ago, I said goodbye to the team at Nodejitsu. I’ve been in need of a break and after spending a year and a half working on their hosting platform, the company is increasing their focus on enterprise products. It was a good time for me to step back.
Since leaving Nodejitsu, 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.
I’m sensing a different breed of community manager is bubbling up: those hired by startups to manage developer communities. Recent incubator Demo Days and conversations in community manager circles both reflect this. When I transitioned from Shapeways to Nodejitsu, I was pretty sure I was a weird outlier who was suddenly getting to explore my passion for developer culture, except even then, some of my community builder peers followed the same track shortly after I did.
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 first emerged. Your developer-focused company might not be about open source specifically, but if you’re trying to facilitate any kind of collaboration in the developer community, you need to understand how it 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 that all of this is imprinted on the community consciousness, and affects how technology gets made today. If you show up and behave as though there’s no history or cultural precedents, your efforts just 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 really care about brands as abstract entities though. It will matter whether you connect authentically in the places the community is most comfortable. It will matter whether or not you try and hard sell them on something. 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 that people 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.
What’s awesome is the mission for a developer community is pretty much the same as with any other. Create a space where people know and care about one another, and interaction is high. Devise a system where active participants can give and take, and be better off for it. Just get ready for the patterns to look and feel different.
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.
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.
When 2012 began, I was determined to make it a year of change.
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.
I first started frequenting NYTM about 4 years ago, when I was still working in the service industry, and decided that tech was the biggest untapped opportunity in my home city. I met Tony there the very first time the meet up gathered at FIT, instead of the IAC center (remember that?). I struck up a conversation with Peter Chislett, who was kind enough to lend me his iPhone charger after the demos wrapped up, and promptly introduced me to Tony. We hit it off instantly. I explained that I was looking to start getting more involved in the tech ecosystem, and he asked me on the spot to come by New Work City to discuss how we could get me involved in their efforts there.
After that chance meeting, I started running events for New Work City, designing gatherings for the membership, and interfacing with other leaders from around the fledgling tech community who often used NWC as their base. This taught me a lot of what I know today about community management and led to my picking up freelance work through the relationships I built. Eventually, this allowed me to move from the service industry, to my chosen industry full time. To this day, nearly every friendship or working relationship I have has come from either NYTM or Tony and New Work City.
Now, Tony is running for the NYTM board.
Tony to me is the picture of what NY tech could and should be. He’s welcomed in and connected countless people — I’m just one of many who’s benefitted from his enthusiasm and kindness. He’s a founding member of this community. The years he’s spent building New Work City points to his steadfast commitment to making relationships and infrastructure that last.
We’ve got the opportunity to have someone as exceptional as Tony be part of our leadership in NY tech. Let’s not miss out on this.
Every few weeks, Meghan Gill and I pick a weekend to get together in either her neighborhood in Queens, or in mine in Brooklyn. We catch up over brunch and then spend a few solid hours writing code. The work she does for 10gen and the work I do for Nodejitsu are similar in many ways, and it’s great having the chance to become a better developer alongside someone who’s working on the same kind of developer community questions as I am.
This past Sunday, an interesting thought came up. We were talking about how community efforts at 10gen took shape when the company first started, and how they’ve evolved since. She talked about the process of starting off as an individual contributor, and moving to where she is 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. One is not regarded as being above the other. They’re both looked 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, say, those working on an auto 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.
A few years ago when I left school and began exploring New York tech, the community was pretty much a hundred people in a room once a month for NYTM. This was before foursquare. Tumblr was a speck on the horizon. In my hometown, finance still reigned supreme. Since then, the community has grown to be thousands strong (NYTM’s current member count is 27K). NY has surpassed Boston as the country’s #2 tech hub. There are now hundreds of early stage tech companies here, and we’ve nurtured more mature players like Etsy and Meetup. Finance guys are jumping ship and trying to get into TechStars.
There’s just one problem.
NYC’s developer community is still a pale comparison of our West Coast counterpart. Our industries in NY have been dominated by the brightest minds in finance and media. That’s a great thing, but engineers here simply aren’t surrounded by people they can relate to. The result is that the developers who are in NY are missing the support structure, the exchange of ideas, and the technical mentorship that their counterparts in Silicon Valley benefit from. In order for developer culture to thrive here, developers can’t feel like the odd ones out.
Want in on EmpireJS?
There are still a few tickets left! Sign up here.
Opening night party is at Brooklyn Brewery on October 21st. See you there.
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 who are practicing being thoughtful and measured in a shared effort in the face of conflict can change the nature of a whole network shockingly fast.
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.