Author: stormy

Posted on

When you are afraid of risk, you create weak teams

First published on Medium.

When role models are risk adverse, they change the game for everyone.

Last night at kickball, a young woman on the other team decided to start bunting and she changed the preferred strategy for women on both teams. She was a strong player and she obviously thought her best option, maybe her only option, was to bunt. So quickly the feel became, to be a “team” player, all weak players should bunt. Never mind that by bunting you give up all chances of kicking a home run or even a double. Or of feeling proud of your kick.

She kicked a few good balls early in the game but got out on the way to first. So the next inning she decided to take advantage of the rule that helps weak kickers, and she bunted. There’s a line between first and third base, through the pitching mound, and no fielders are allowed in front of that line until the ball has been kicked. Pretty soon, the weaker players on her team (all women) were also bunting. Then the women on my team debated whether they should bunt. Then the stronger players on my team started encouraging the weaker players to bunt! That’s when I got upset. Upset at a world where teams encourage newer and weaker players to avoid risk, and therefore to avoid the chance to grow.

This is rec, co-ed kickball. Most of us haven’t played kickball in decades. Many of us haven’t played a sport in years. And several people don’t know the game well enough to know where the play is. The umpires are awesome. They encourage and help everyone. In addition to their umpire role, they often play surrogate coach and cheerleader. They don’t just say “1 out”, they say “1 out, play is at first”. And they check in with players. I think last night’s umpire could tell I was getting really annoyed. He checked in with me to make sure I was alright.

I remember learning to play kickball. It was a new school and a new sport. After my first “at bat” it became very clear I’d never kicked a ball. So my next at bat, everyone moved in for the kill. I had a wall of fielders all 10 feet from me. There was no where to kick the ball. So I love the rule that no one can be in front of the line until the ball is kicked. Rules that help new or weak players get started are good. When experienced players use those rules to their advantage, you end up with politics.

You end up with people examining all the rules to see where the loop holes or advantages are. Last night we ended up debating how many men could be on a team, what order they could kick in, if you could rush the ball once it was bunted, … and it became about the rules and winning, not about the game.

My emotional reaction was out of proportion for a kickball game. But it’s because I realized that I see this in the world all the time. When someone who is clearly capable says “oh, I could never do that”, they make all those people that are still learning doubt their abilities. When you turn down that client presentation or that keynote, when you start your piece in the meeting with “I’m not sure but …”, you show that you don’t think that you, a competent, experienced person, should take that risk. And when you combine that risk aversion with a do what it takes for the team to win, you cripple people. You end up encouraging your newer players to not take any risks for fear of hurting the team. Some times an individual has to take one for the team. Some times the team has to take one for the individual in order to grow a strong team.

While each individual has to decide on their own whether a risk is right for them or not, the team needs to watch and make sure that risk aversion isn’t becoming the norm, enforced by peer pressure, for their newer or weaker members.

Kick hard. Work hard. Take risks. Learn. Make mistakes. Help others make mistakes. Cheer them on. Grow your team. Be a role model.

Posted on

The code review culture kills new ideas

First published on Medium.

Many open source organizations start around code. Someone has an idea and they write some code to express it. If people like the idea, they add more code. That code gets reviewed and incorporated.

This works great while the project rallies around the original idea. However,when they go to add new products or plan new features, the culture of code reviews gets in the way of a culture of new ideas.

Why’s that? Because code reviews look for flaws. You need to make sure you don’t introduce bugs. Ideas, on the other hand, need a whole team of input before they are strong enough for the risk analysis. New ideas get stronger when people add to them, figure out ways they can help. Once ideas become a plan they need something like a code review but not before they become a plan.

Reviewing Code is about Eliminating Risk

When new code is submitted, it’s always reviewed before it’s accepted. And often there are very clear guidelines. You are reviewing to make sure that your project’s guidelines are met, that the code is well written and that it introduces no new bugs. Often this means you are looking for things that are wrong. You may also suggest improvements, but the focus is on looking for things that are wrong.

Reviewing Ideas is about Exploring Opportunity

When new ideas are reviewed, they are often not fully formed. Ideas, especially new product ideas, need the entire organization to help figure out the full potential, what each team could bring to the table and how people might react to it. New ideas need to be fully developed before you start poking holes in them. And new ideas cannot be fully developed by one person. They need a whole team of people to say, “yeah, that’s great, and I could help by linking it to this other thing I’m working on” or “yeah, I like that and it makes me wonder if we did this, if that would be even better.”

What happens when you apply code review techniques to ideas?

When you apply code review techniques to ideas, you kill them before they are fully developed. You look for everything that is wrong in an idea. You look for all the risks, all the holes, before you add your strengths to it. Just when the idea needs you to help figure out how it could succeed, you poke a hole in it.

Next time you see someone in your organization propose an idea, make your first reaction an additive action. Challenge yourself to make the idea even better instead of looking for the bugs.

Posted on

Let others choose their own hats

How many hats do you wear?

When I’m in a city and say I’m there for a software conference, I wear my “all technical people” hat. When I’m the only woman in a room of men, I wear my “the entire female gender” hat. When I’m the only American at a long table full of Europeans, I wear my “American” hat. At those times, I feel like my behavior reflects on an entire gender, nationality or industry.

That often makes me think and act very carefully. Sometimes that makes me feel guilty. It often feels stressful.

So just go easy on Marissa Mayer.

She didn’t choose to wear the female hat. But she did choose to wear the CEO hat. And the mom hat. And the female mom CEO hat. Wow! What a burden that must feel like at times. So give her some slack. Let her do the best she can the way she thinks is right. She obviously chose not to wear the “children should spend the first couple of months with their mom” hat. That’s ok with me. She’s wearing a lot of hats. And she’s pushing the stereotypes. For a lot of hats that I care about. Give her some room to breath. Remove the stress of imposing yet another hat on her. Support her in all the hats she has to wear.

I say this from my a day of camping without work and without kids. So pretty hat free, relatively speaking. Yeah to the female, mom, CEO!

Posted on

Don’t let them label you a demon kitty

Over the past couple of days I’ve had a number of conversations with women that have left me frustrated. And I realize I’ve heard a lot of stories like this. For the record each of these comments comes from a different woman who works for a different company, none of which I have worked at. So this is not about the companies but about empowering individuals.

Each of these women is super smart and talented, with a good career and has done and created awesome things.

  • “Is there a life outside this company? Tell me there are good places to work.”
  • “I’ve gotten so much negative feedback, I’ve stopped listening to any feedback. I think I’m unemployable now.”
  • “I’m not doing anything meaningful at work but I can’t quit. If they offered me a severance package, I think I’d take it.”
  • “I’ve given up on advancing my career. I just want to find nice people to work with where I can do good work.”

And all that reminds me of the lesson I learned from my demon kitty.

I used to foster kittens for the humane society. And one kitten they gave me was a demon kitty. She would attack me with tooth and claw every time I ate; she peed in every corner of my house; she shredded curtains. She was truly a demon kitty.

I took her back and said “I’m sorry, she’s a demon kitty, I can’t work with her.”

A few days later I called and asked how she was doing. They said “oh, she’s great, we placed her with another volunteer.” I didn’t believe them, so I called the other volunteer. She said, “She’s the sweetest little thing ever.” I asked her to describe the demon kitty just to make sure we were talking about the same cat.

Something in my organization (i.e. my house) was toxic for the kitten. Maybe it was the wrong kind of food, maybe it was the big slobbery dog, maybe it was the color of the carpets. Maybe I was just a terrible manager (i.e. foster mom). And she tried to tell me. And I gave her lots of negative feedback (sprayed her with water) and I labeled her a demon kitty and recommended her for lots of remedial behavior training. I failed her.

So if your organization is labeling you as a “demon kitty”, it’s not your fault, not any more than it was the fault of a six week old kitten. So, hold that knowledge, that it’s not your fault, and decide if you want to work it out with them or if you want to find a better home. Don’t let them tell you who you are or what you are capable of. Don’t argue with them about what label they’ve given you. Don’t let them make you feel like you have no other options. They might think you are a demon kitty, but if you’ve shown you can create great things and you work hard, there’s a place that will show you that you can be a shining star.

Posted on

7 tips: how to introduce yourself

I hate introducing myself. It’s very hard to introduce someone but especially yourself. So here’s what I’ve learned about giving awesome intros:

Picture of a llama touching noses with a dog
Photo by lucianvenutian
  1. Talk other people up. This may seem counter intuitive, but if you are doing a round robin set of intros, be sure to help others talk themselves up. For example, in a recent Kids on Computers set of introductions, Serena introduced herself. I jumped in to point out that she filed our original 501(c)(3) paperwork – which passed the first time. After that, several people jumped in to help others introduce themselves. The focus of the introductions becomes helping others, not trying to one up others.
  2. Know what you want. What do you want to accomplish? What do you want out of this group? Do you want them to know you can make decisions for your company so that they’ll negotiate with you? (Establish your authority.) Do you want them to see you as like them so that you can be friends? (Focus on what you have in common.) Do you want them to know how successful and fun your organization is so that they’ll volunteer? (Talk about what you’ve accomplished.) Knowing what you want to accomplish will help you focus on what’s important to stress in your introduction.
  3. Keep your audience in mind. You are not going to introduce yourself at a conference the same way you introduce yourself at the bar or at a little league game. I do not tell other parents that I meet for the first time at a little league game that I’m a VP at Cloud Foundry. If I intro myself that way, they tend to go “oh, nice” and move right on. It means nothing in that context. Being VP of Technical Evangelism at Cloud Foundry is an important thing to say when I’m talking to other people that lead developer relations and I want their help.
  4. Focus on accomplishments, not titles. Don’t be afraid of your title but realize that by itself, it might not convey anything. For example, saying I do advertising might not mean anything but if you could say “I did the ‘Got Milk?’ campaign“, everyone would know what you did.
  5. Know when to focus on your title. A few times to be sure to bring up titles are:

    1. Titles are important to that group. There are a few audiences where titles are very important. If titles are important in your meeting, you’ll probably know. Go ahead and use it.
    2. You are feeling overlooked or underestimated. Sometimes your title can convey your accomplishments better than the stereotypes associated with your looks. Legs of seated businessmen and woman wearing leg warmers
    3. Your title makes your role obvious – in one word it defines what you might want and what you have accomplished. For example, “high school principal” clearly defines a known role with authority.
  6. Don’t worry about sounding pretentious. If you worry about sounding pretentious or conceited or full of your self, you will either sound pretentious and conceited or you will sound insecure and dismissive of your own accomplishments.
  7. Listen to other people introduce you. One of the best ways to get comfortable with introducing yourself is listen to people you respect introduce yourself to new colleagues or friends. Listen to how they stress your accomplishments or strengths.

What are your tips for introducing yourself?

Posted on

Why child care at conferences is great

Child care at conferences is awesome but not for the reason you think it is. We think it helps women who have no other options for kids to attend. Really it helps all parents be closer to their kids, helping people in technology build strong families, relationships and communities.

Child care helps attendance for local meetups

Child care is often toted as a way to enable women to attend conferences. I think that’s really true when the conference is local. It’s not that women (or men) couldn’t find someone to watch their kids but it’s one less impediment. The meetup is posted, you see there’s child care, you can just rsvp. Later you might find child care or you might use the meetup child care.

Most people that travel for work have child care

But as anyone that travels a lot for work knows, it’s much more work to bring your child than it is to leave them at home. If you have to travel for work, you probably have child care options for your kids at home because there aren’t enough other options while traveling for work these days. (Luckily, I have an awesome extended support network at home.)

But child care at conferences is vital for our extended community

The reason I think child care at conferences is awesome is that it allows me to share my work, my travel and my colleagues with my kids.  It allows me to bond with my child in an environment that I don’t get to share with them very often.

My kids love attending conferences with me. They get to share my love of traveling, stay in hotels (which they still think is awesome), get swag, meet all the people I talk about and play with colleagues’ kids.

My kids have met my colleagues – really smart, funny people. They have played nerf guns and games with the kids of my colleagues like at the kid day at SCALE or the daycare at Grace Hopper.  They see what I do when I travel – my youngest turned the slides for me at my talk at SCALE and helped out at both the Kids on Computers and Mozilla booths. They’ve enjoyed exploring cities with me the weekend before a conference.

Hopefully they’ve learned more about the world, how technology makes it works, why open source is important and how people debate and collaborate on things that make the world a better place.

Posted on

What’s in a good developer relations plan?

Developer relations is the combination of activities, programs and tactics to get developers using or developing for your organization’s product or ecosystem. The goal of a good developer relations team is often to make your organization’s product or ecosystem the first choice for developers. (You may be doing this just to sell more of your product or you may be doing this because you believe your product’s mission helps make the world a better place. You are still trying to get more developers using your product.)

What’s the goal of a good developer relations plan?

Your developer relations plan needs a goal that you can focus on. You need to be able to measure the results of your activities so that you know what you should do more of and what you can do less of.

Some potential goals for a good developer relations plan might include: (Some of these by Patrick Chanezon.)

  • Increasing the adoption of your organization’s product. Example: more people using Firefox.
  • Increasing the number of available complementary goods. Example: more 12 factor apps running on Cloud Foundry.
  • Providing an opportunity for developers to profit. Example: an app store for developers to list their applications.
  • Growing the number of people that benefit. Example: training companies, consultants, app providers.
  • Reducing the cost and risk of using your product.
  • Increasing the percentage of developers that are developing only or mostly for your product.
  • Increasing the network effects in your ecosystem.
  • Decreasing the cost of adopting your platform or increasing the cost of leaving your platform.
  • Creating an environment where developers just assume they’ll use your platform.
  • Encouraging third party tools, trainers and consultants for your platform.
  • Creating a community of volunteer advocates.

Some developer relations groups also act against the competition. I don’t think that’s a long term strategy. Your product and ecosystem have to be good.

What are the stages of a developer relations audience?

Screenshot 2015-08-13 15.04.58

You can move from one stage to the other using many different techniques. Breaking down the stages a bit further, you can map how specific evangelism activities like blogging or talking, might take you from one to the other.

2015-08-13 15.13.55

Who should you have on your developer relations team?

While we usually talk about developer relations as teams, we also need to look at their functions. While each team has a primary function, functions are often shared between teams. Mozilla has outreach and content teams. Google is also organized this way, as presented in a talk by Patrick Chanezon.

  • Outreach. Creating awareness of the product or ecosystem among developers. Most outreach efforts include evangelists. These are people that go out and speak, engage with others, teach enough to get people started, write blog posts, let large numbers of people involved. They are typically most involved in the outreach and awareness part of the program.
  • Content. This includes tutorials, documentation and examples. Making sure that developers that are interested in the platform have the materials they need to learn it. This team should include technical writers, educational experts and programmers. These are the people that are most involved in the online training part of your program. They write documentation that lets people learn how to use the technology. Sometimes they write the examples. Sometimes they create training or online tutorials.
  • Support. When developers start using your product, they will need people to help answer their technical questions or help resolve the bugs they find. This team usually consists of support engineers. They are around to answer questions, help people get going, create code examples. Often when bootstrapping, this function comes from the evangelists but it’s really a different type of personality and role. This team is most likely to provide valuable feedback to the product teams.

There’s another couple of roles worth calling out.

  • Program managers. A successful developer relations program often relies on programs. These might be things like a world wide community run, simultaneous events or a “free phones for apps” program.
  • Key stories/participants/case studies. These are people that have a story that successfully highlight what you are trying to do. And, while they might not be evangelists, they are competent spokespeople. You talk about them, point people at them, highlight them, enable them to tell their story and help them spread it.
  • Event managers/coordinators. Smaller groups might have several volunteers. Larger organizations might have lots of volunteer meetup or hackathon organizers and maybe even a paid staff team to support them.
  • Community management. Whether or not you have an official community manager, there are probably numerous people helping out with “community management” whether it’s onboarding new contributors, reviewing patches or answering questions on the mailing list.

What are the key components? What types of tools and projects are useful?

It’s useful to first look at your project’s strengths. Do you have a large community? Strong contributors? A highly followed blog? A strong culture of global meetups? A clear brand?

Some of the projects and tools you might consider are:

  • Programs that support your goals. For example, Mozilla ran Phones for Apps.
  • Messages/materials. Developer relations can either include product marketing and press or work closely with those teams to develop messaging and materials that support the goals and the audience.
  • Events. Events can include everything from monthly meetups to hackfests to large annual conferences. Many teams often divide events into the organization’s events, sponsoring others events and sending speakers to events.
  • Training. As people join your ecosystem or start using your product, they are more likely to stay if they can get the training they want. Cloud Foundry has “dojos” – a place at several member organizations where interested developers can go train with a more experienced member for six weeks.
  • Examples. A key component of learning is being able to see how something is done and copy it. At Mozilla we created Demo Studio to allow people to share and build on others work on the web.
  • Documentation. Documentation is key to a project for two key reasons. One is discoverability and the other is learning and support.
  • Contributors. Depending on the type of product or organization you are supporting, you may want programs in place to specifically support contributors. This may be as simple as swag or as involved as official titles and budget for programs and travel for them.
  • Feedback mechanisms. An important part of many developer relations teams is providing feedback mechanisms for users to give feedback to the product teams. It helps to put into place objective tools and mechanisms for this.
  • QA forums. Question and answer forums like StackOverflow have become critical to how developers expect to find help when they are working. Having a standard place where your experts will be will help.
  • Membership. Often membership can support the different groups you want to grow. You can have users groups, contributor groups, advocacy. You can use titles, mailing list membership, swag and travel funds to distinguish and reward them.
  • Discussion. A place where people can come and chat and “hang out” with your community is important. Q&A forums often give them answers but not a sense of belonging. Also discussion groups are often an easier way for really new users to get started.
  • Advocates. Recognize our key advocates and give them a megaphone. Connect them with the press and speaking opportunities.

What does your Developer Relations plan and group look like? What would you add to create your ideal plan?

Posted on

The best jobs in life are challenging

The best jobs in life are not the easiest ones. The best jobs are the most meaningful ones. They challenge you – and make the most of your skills. The best jobs give you a chance to make a difference in the world. (And often great jobs also involve working with awesome people that also motivated by making a difference.)

Through exhaustive analysis of diaries kept by knowledge workers, we discovered the progress principle: Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work.
– Harvard Business Review

I’ve seen a trend in how people talk about vacations. Actually, maybe it’s not a trend as I’ve heard it for the past 20 years. People want to go on vacation and sit at the beach. Lie at the beach. In the sun. Doing nothing but reading. Relaxing.

Now, I love reading. Not in the sun, but I do love reading. I could probably spend a whole vacation, a week, several weeks, maybe even months, just reading.

But the best vacations I’ve had are the ones in which you try new things, are challenged in new ways and succeed. Sailing in the BVI, as the person in charge for the first time, was way more fun than any day I ever spent at the beach. (And, to be sure, I’ve found plenty of friends willing to go on these fun and challenging vacations!)

Same goes with work. You could probably pay me a lot of money to do nothing very challenging. Every time I see what someone pays to sit in business class, I think you could pay me that amount to not sit in business class! Just think, you pay $5,000 for business class on a 10 hour flight. For $500/hour, I’d happily sit in an economy seat! I can’t sleep, but I could read my book or talk to my neighbor. Things I’m happy to do for $500/hour. But it wouldn’t be a very rewarding job. I wouldn’t feel like I had accomplished anything (other than earning $5,000!) I wouldn’t feel like I had used any special skills or learned any new talents or made a difference in the world.

Now imagine a job where you had a meaningful challenge. A purpose like making sure the next billion people coming online have the ability to create their own content. Or a purpose like making sure people creating the apps of the future could focus on their apps instead of the infrastructure. That would be a meaningful challenge. And if you were doing it well – especially if you were doing it well with people that were equally motivated and fun to work with – you’d be having fun.

So next time you see someone having fun at work and you feel a little jealous, ask yourself:

  1. Is your work meaningful?
  2. Is it challenging?
  3. Do you enjoy the people you work with?

If not, what are you waiting for?

Posted on

10 quotes from Edward Tufte

I took Edward Tufte’s Presenting Data and Information class. Normally I would have tweeted these quotes (especially since Edward Tufte is active on Twitter!) but the room was dark and my phone’s screen would have looked like a spotlight. (This is not my summary of the day. Just some of the tweets I would have sent.)

  1. There are only two industries that call their customers users: illicit drugs and software.
  2. No visualization for little data. Use sentences.
  3. Taking notes shows respect.
  4. Marketing = amateur social science.
  5. It’s just as easy to get fooled by big data as little data.
  6. Just block people. If someone pees in your living room, you don’t want to stick around.
  7. By age 35, all future music will become an utter mystery.
  8. If you have an inherent interest in operating systems, it’s unnatural. (Operating systems was my favorite university computer science class! And my first job.)
  9. All complex ideas can be expressed in normal language. This is what reporters do.
  10. Distrust anyone who replies with character assassination.

And there was also lots of good content.  More later.