How your company can build and keep community trust

Originally published on opensource.com.

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

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

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

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

First build trust

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

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

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

Community communication

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

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

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

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

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

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

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

Practical business reasons to support open source communities

Originally published on opensource.com.

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

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

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

What we mean when we talk about community

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

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

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

Business benefits

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

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

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

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

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

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

Google’s disappointing response to the “manifesto”

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

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

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

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

The response states:

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

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

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

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

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

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

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

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

What to know before you open source an internal project

Originally posted on opensource.com in June 2017.

Before your company makes a project open source, make sure you’re ready for all your new responsibilities to the community that forms around it.

Your company is going to release an internal project as open source. Congratulations! You know your code is ready, but are you ready for all your new responsibilities?

Once a project has been released as open source, your company is not only responsible for the project, but also for the community that will form around it. This often requires changes to the development/build/release workflow. This is not about the code per se; it’s about all the processes and infrastructure that surround the code that make the open source project successful.

Here’s what you need to know and expect before you release your open source project.

Identify your company’s goals

Before you go much further, take a moment to evaluate your company’s goals for releasing the project in the first place. The company will invest a lot of time and effort into preparing this for release—and a lot more in maintaining the project and the community that forms around it. While it’s possible that these efforts are altruistic, it’s more likely that the company expects something for its investment.

Make sure you’re aware of these goals before diving into the project and its community. Taking steps to ensure your company can meet them not only helps the company, it helps free and open source software (FOSS) overall. Companies that don’t know or don’t meet their goals with an open source project withdraw from FOSS participation entirely, and that helps no one.

Understand community expectations

While your company may still hold the keys to the kingdom and decide what contributions to merge and when to bundle a release, all development must be done in the open in communication and coordination with the community that forms around it.

In other words, the project must operate according to established community expectations for an open source project. These expectations include (but are not limited to):

  • All development work—including bug fixes, new feature development, product roadmaps, and discussions and issue tracking about these things—occurs publicly and in coordination and cooperation with the community.
  • All build processes related to the code (continuous integration/deployment, etc.) operate publicly and are accessible by and to the community.
  • The company accepts contributions from the community, where “contributions” means not only code but also documentation, design, product roadmap guidance, governance, and other matters pertaining to the project. All contributions must be reviewed and considered promptly, and feedback must be provided publicly.

Know that community is key

Open sourcing a project creates a lot of work, though in practice it’s usually no more work than proprietary software development. Still, there can be considerable effort required to transition processes and culture to work efficiently and effectively in the open and support an open source community.

If it’s so much work, why do it?

As I mentioned earlier, businesses don’t usually release projects out of the goodness of their heart. They do it because they want to benefit from the community that hopefully will form around the project—but those benefits happen only if the company earns, builds, and maintains the community’s trust.

That trust happens by doing all work in the open and in communication and collaboration with the community. Any fully unilateral or private decisions the company makes will violate that trust and alienate the community. When a community is alienated, they leave (sometimes forking the code to start over elsewhere).

There is no way to benefit from a community that disappears. That leaves the company with a bunch of code that is open but no one uses or cares about, not to mention unable to meet the goals it set when it open sourced the project.

Launch your public issue tracker

Once a project is released, all bug reports—previous and new ones—must be available in the project’s public issue tracker. Here are some things you need to do:

  • Move pre-existing bugs/tickets/issues to the project’s issue tracker.
    • Be aware that moving often requires a script.
    • Before you move anything, review all existing issues and close those that have no real hope of ever being fixed.
    • Make sure to remove any proprietary information from any pre-existing bugs/tickets/issues before moving them to the public tracker.
  • Decide whether to move closed bugs/tickets/issues to the public tracker.
    • This is optional, but it can provide valuable context for future development.
    • Make sure to remove any proprietary information from any closed bugs/tickets/issues you plan to move before making them public.
  • Create a new workflow so all bugs/tickets/issues will be routed efficiently to and through the public issue tracker.
    • Coordinate and train all company staff who report or interact with bugs/tickets/issues.
    • If you use a publicly available issue reporting tool (e.g., ZenDesk), the new workflow must ensure that issues reported there are efficiently transferred to the public issue tracker and the reporting parties (usually customers) still receive the service and information they have come to expect.

Be ready to open your product roadmap

Once a project is released as open source, its development roadmap and all related discussions become publicly available.

  • All discussions and decisions about what goes onto the roadmap (and why) must now be held publicly and with the community’s input.
  • Community feedback should be integrated into the roadmap.

Please note: While the roadmap and all discussions about it occur in the open and with input from the community, unless it has made other accommodations the company may still have the final word on what goes onto the roadmap, when, and why. This should be done in a manner that is respectful of the community the project now serves and supports.

If the public roadmap includes features that interact with or rely on proprietary features, everyone who interacts with the project must be careful not to leak proprietary information in discussions about the public roadmap.

Define the contributions workflow

Once a project is released as open source, all contributions to it must use one public-facing workflow, regardless whether the contribution is from the originating company or the community.

Here’s an example of a typical workflow:

  • A contributor forks or clones the public repository to their own computer.
  • The contributor creates a feature branch of the repository and develops their contribution on that branch. This work, as it’s being done on their own computer, is private.
  • Once their contribution is ready, the contributor submits their contribution back to the public repository. (The process depends upon the version-control system in use and the preferences of the project.)
  • The contribution is publicly reviewed by community members who are qualified to do so (typically known as core contributors). These people then choose to merge, defer, or close (decline) the contribution. If the contribution is merged, it may be to master/head or a different branch, but this depends on the project’s needs and workflow.

Each project must consider and decide upon its specific contribution needs and workflow and make these publicly available in the project’s CONTRIBUTING.md file.

Don’t forget about the build process

The build process is often overlooked when planning to open source an internal project. This is unfortunate, as the build process also happens in the open once the project is released.

Some things to make sure of when opening the build process:

  • There is no proprietary or internal-only fork of the code.
    • If there is, it will betray the trust of the community, who will leave.
    • It will also greatly increase the work required to merge and maintain code.
  • All build processes must work against publicly available code, either the master/head or a stable branch maintained for build (whatever makes the most sense for the project and product).
  • All build artifacts should be made publicly available immediately upon build completion.
    • How they’re distributed after that (e.g., pushed to customers) is a business decision, but the build artifacts (including final binaries) are always publicly available.

Support open discussions of community governance and tooling

Once a project is released, all decisions that impact it or its community must be made in the open, including changes in governance, adjustments to tools such as version control or continuous integration, and changes or additions to communication routes.

This does not necessarily mean that every tiny decision must be sent to committee or requires full discussion from the entire community. Often it is enough to solicit suggestions and feedback from the community and consider them when making decisions.

All final decisions, the reasons behind them, and their expected outcomes must be publicly announced, available, and documented in whatever tracking system the project uses for such things (usually a mailing list plus the documentation system or a wiki).

Open anything else pertaining to the specific project

You get the idea by now:

Anything at all related to the project will need to be done in the open.

Once the project is released as open source, it no longer belongs to “you,” the company, and now belongs to “we,” the community (of which the company is a part). This means the community must be included at all points going forward.

I have time availability for another client! Is it you?

Open sign by caveman92223 on Flickr; CC BY-NDSince I left the Helion OpenStack team, I’ve been helping companies–particularly startups and small/medium businesses–with Open Source, Technology, Community, Business, & the intersections between them. So far it’s been some of the most rewarding work of my professional life. I’ve worked with brilliant people helping them and their companies understand and contribute to free and open source software, as well as develop corporate open source policies.

I’ve been keeping it to one client at a time while I get my practice up to speed. Now I’m ready to ramp it up and add another.

Here’s a sample of what I could do for your company:

  • Counsel and collaborate with company leadership on corporate open source goals.
  • Define corporate open source usage and contribution methods.
  • Develop policies for open source compliance and risk management.
  • Train staff and leadership on meaning of and best practices for releasing and contributing to open source.
  • Analyse processes and provide change recommendations for using and contributing to open source, including community growth and engagement.
  • Develop staffing and hiring plans to support open source development, contributions, and healthy community engagement.

While my primary focus currently is consulting, I’m always open to hearing about full-time positions working in the open source space, be it leading open source software development as director or VP, managing open source program offices, or developing and growing developer advocacy and other community programs.

Contract or full time, I can help your company succeed with open source. Have ideas, leads, or just questions? Drop me a line. Let’s chat.

Changing the language

The other day I tweeted this:

Tweet by @vmbrasseur: "If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers."
Tweet by @vmbrasseur: “If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers.”

This tweet is a necessarily brief exclamation of something which has been on my mind a lot lately and warrants a larger post. In summary: The words we use matter.

It’s probably safe to assume that nearly everyone reading this is involved with creating software. Even if you’re not, you’re undoubtedly aware that software development is a complex process composed of many moving parts. While it’s possible to create software on your own, it usually works much better when we collaborate to build each of the parts.

Despite recent “full stack” trends, none of us can be specialists in every facet of the software development and creation process (nor should we try). Many different skills are required for the process to work smoothly:

  • Before writing a single line of code, product management, user experience, and user interface design are necessary to make sure you’re creating software which is valuable and useful to the end user.
  • The crafting of the deliverable software product involves front end coders, back end coders, security analysts, database administrators, and documentarians. It may also require more specialised roles such as mobile coder or data scientist.
  • Before the software can be delivered, quality assurance and product management must confirm that the software not only meets the needs of the end user but also that it works as expected (or at all).
  • The actual delivery of the software is the responsibility of system administrators, operations, and devops. They, along with DBAs and customer service representatives, also help to ensure the software remains available.
  • As the software progresses through its life cycle, customer service receives additional support and outreach assistance from marketing, sales, and community management.

This is the software development process. This is what it requires. A true “full stack” software developer would be skilled in all of these roles (which is why the very concept of “full stack” is laughable). Yet lately when we speak of software developer we mean only those who create the code. As we see above, programming is only a portion of the process, just one of those many moving parts. The term as currently used disregards the myriad other roles required to develop a successful piece of software.

It’s unclear what nudged our language to shift such that “software developer” has come to exclude the majority of roles responsible for successful software development. It’s not as though there is any shame in the title of “programmer.” It’s a descriptive title but more importantly it’s one with decades of rich history behind it. By using “software developer” instead we’re not only excluding people, we’re turning our back on this history and everything which it affords us.

Why is this important?

Words matter. How you talk about things affects how you think about them. To discuss “software development” as though it were a purely programmatic act excludes a large percentage of the people who participate in the process and encourages a “cult of the coder” mentality such that programmers are lifted up to near aristocratic levels.

This programming-centric view does software development no favours. By excluding other roles from the language we use, we also exclude them from how we think about the process. The piles of startup corpses strewn along the road to business success are a testiment to how ignoring things like user needs, market fit, and usability will scuttle even the best coded piece of software. Recent findings by GitHub show that excluding documentation from the process has negative effects on the adoption of and contributions to free and open source software projects, no matter how well architected their APIs.

The biggest loser in this “cult of the coder,” though, is the end user. The poor unfortunate souls who struggle to use a UI created by someone inexperienced in the skill, who growl in frustration as yet again a software service updates without a much requested feature, who are astounded by Internet of Things products with no concept of security, who puzzle out and reverse engineer undocumented installation steps. So much productivity, opportunity, and customer good will lost because software companies often focus more on programming than on the entire software development process.

Don’t get me wrong: I love programmers. I’ve spent most of the last ten years of my life leading programming teams and departments. Programming is a highly specialised and ever changing part of the industry. It’s populated by some of the most clever, most inspiring, and kindest people with whom I have ever had the honour to work. It is not the fault of programmers that the language shifted around them. It is the fault of our industry, our community, and our culture.

We can do better. We can do better for the end user, for programmers, and for everyone involved with or impacted by software development. It all starts with changing our perceptions through language.

Let’s start to shift the language back and reclaim the term “developer” for all who participate in this complex process rather than just the programmers. Let’s evolve the mindset back toward one where we recognise the contributions of all of the roles which contribute to delivering and supporting a successful software project. Let’s call a spade a spade and a programmer a programmer and just get back to work creating software which changes peoples’ lives in valuable ways.

Public Speaking Resources

Had you told me 10 years ago that not only would I be on the open source/tech conference speaking circuit but that I would love it, I would’ve looked at you like you had three heads but only two eyes between them all.

And yet, here we are. In 2016 I presented 18 talks at 15 events all over the world. So far in 2017 I’ve either presented or organised 9 talks or events. I advise people on their conference proposals, bios, and on the talks themselves. I provide training for those who wish to get started in conference speaking. This is not at all the life I envisioned for myself; it’s So Much Better and I’m grateful for the opportunities I’ve had so far. Thank you, all.

In 2016, in collaboration with Josh Berkus, I presented my first ever speaker training workshop. Since then both Josh & I have presented the material separately and each made it their own. We’re covering more ground this way, training far more people than we would if we had to coordinate between our very hectic schedules.

During the writing process of that workshop, we created a bibliography of public speaking links. In the year and a half which followed, I kept adding to that bibliography whenever I discovered a link which we hadn’t included the first time around. It was turning into a really great resource for those wanting to learn more about presenting at tech conferences, but it was impossible to find. Who drills down into the repo of a workshop which was presented only once? No one, that’s who. So the valuable bibliography was lying dormant. Well. It ain’t sleeping anymore…

🎉 Please welcome the Public Speaking Resources repo into the world! 🎉

Currently weighing in at 50 different public speaking and conference presenting links, this is one of the best resources you’ll find for improving your conference speaking experience.

One of the advantages of pulling the bibliography out into its own repository is that it’s now very easy for anyone to contribute a new link or resource for the benefit of everyone. We ❤️ contributions and contributors!

Even if you don’t have a link to contribute to the collection, the repo also serves as a focal point for a community which can answer your tech conference presenting questions and help support you on your path to becoming an amazing conference speaker. There are two ways to get this support:

  1. Open an issue with your question or suggestion and we’ll do our best to guide you.
  2. Join in the real-time conversation on the #public_speaking IRC channel on Freenode. Yeah, we know that Slack is the new hotness, but this project still kicks it old school. But fear not! The IRC channel is covered by the project code of conduct, so you needn’t worry about dealing with the less savory elements of the internet. You also don’t need to jump through a lot of hoops to join in the conversation. Just hop on the webchat, pick a nickname, and you’re good to go! If you’d like to learn more about how to use IRC, there’s an article for that.

There ya go! Please share this public speaking resource with everyone who might be interested and please contribute. Together, we’ll help a lot of people improve their public speaking, their self confidence, and their careers.

Organise your job hunt with Trello

Demo Job Hunt Trello Board Because I’ve moved on from previous job I have the legitimate pleasure to be speaking with a number of organisations about my next steps. At current count I’m speaking with a very-surprising-to-me 10 different companies, which usually might cause a bit of an organisational headache. Thankfully, years ago I came up with a system which keeps me sane during a job hunt.

We all know it: Job hunting sucks. One way to make it suck less is to keep good records so you always know where you stand and with which companies. Some people use their email for this, but no matter how good the search capabilities email is not a good project management system. Make no mistake, job hunting is a project just as much as developing a new version of your software. If you treat it as such you can reduce stress and improve your chances of success. Having good records allows you to be prepared and put together when you get that random recruiter calling and assuming you remember all of the details of their specific job. When job hunting you very much want to look prepared and put together. First impressions really do matter.

Record keeping

When I say “record keeping,” what do I mean? What sort of records should you keep? It’s a lot more than most people consider. You should track:

  • PDF of the job posting
  • Research on the company, position, & expected salary
  • Resume & cover letter used for application
  • URL/method for following up on the application
  • Every email & correspondence
  • Notes from every call and meeting

That sounds like a lot, and depending upon the activity of your hunt it really can be. Not only that, but all of these items must be available at your fingertips at any moment, just in case you do get that random recruiter call. So how do you keep track of so much information while still making it highly available? As you’ve already guessed from the title of this article, I use and recommend Trello for this purpose. Here’s how I do it…

Trello to the rescue

Trello is a kanban tool where tasks are represented by cards and each step of the process is represented by a column. Cards are moved between columns as they work their way through the process. The collection of columns and cards all live on a board. You can make good use of the tool with very basic To Do, Doing, Done columns, but you’ll get better results if the columns represent the actual steps of whatever process you are performing. The columns on my Job Hunt Trello board represent the typical steps in a hiring process in the software industry, plus a few extra for record keeping:

  • Gathering Info: I’ve heard about the position and am doing research to see whether I’d like to follow up on it in some way.
  • Applied: I’ve applied for the position and am waiting for more news.
  • Phone Screen: I’ve had some initial interested contact for the position, typically in the form of scheduling/having a phone screen, and am waiting for more news.
  • First Interview: I’ve either scheduled or had something which could qualify as a first interview for the position and am waiting for more news.
  • Second Interview: If necessary for the hiring process, I’ve either scheduled or had something which could qualify as a second interview for the position and am waiting for more news.
  • Offer: I’ve received an offer for the position and am considering/negotiating it.
  • Accept: I’ve accepted an offer for the position.
  • Declined: I’ve been declined for a position at any point in the process.
  • No Word; Assume Declined: I’ve heard absolutely nothing about the position after a long wait and have assumed that the organisation is not interested in my application. At the end of a job hunt, this column usually contains the most cards. Companies are utter rubbish at communication with applicants.
  • Withdrew: At some point in the process I decided that I was not interested in the position and I withdrew my application from consideration.
  • Defunct: The position no longer exists for some reason or other (usually budget cuts).
  • Meh: After gathering information but before applying, I decided I have no interest in pursuing the position. I could just archive the card, but there’s value to me in the perspective afforded by reviewing what positions I walked away from and why.

Gathering Info

Each position which catches my eye is captured in a separate card on the board. Typically the card starts in the Gathering Info column. If there is a job posting for it, I’ll save that off to a PDF then attach that to the card. Why? Because job postings have a tendency to disappear when you least expect it. For instance, if a company has decided it’s received enough applications it may unpublish the job posting. Should that happen and you’ve not saved a copy of it somewhere, you will no longer be able to reference it when a recruiter calls you out of the blue assuming you remember all of the salient details of the position. Attaching a posting PDF to the card ensures you’re never caught off guard.

At this point I’ll also research the position and the company, including reaching out to people I know who currently work there or have worked there in the past. All of this background information is added to notes in the card, collected in one spot for quick reference. If I like what I’ve learned, I’ll apply and move the card to the Applied column. If not, I add a note about why I don’t like the position then move the card to Meh.

Applied

Applying for a job is not a fire and forget process. There are artefacts which come out of it: the cover letter, the resume, and possibly some application-specific questions. Each cover letter and often each resume is customised for that specific application (why? read these). These, as you may expect, are also attached the the card. Some application processes include additional questions relating to the position. I copy those and my answers to them to a note in the card. Should those questions come up again during an interview process, I want to be able to answer consistently or otherwise refer back to my previous answers. Should the application process result in a URL for checking on the application status, I’ll also make sure that ends up in the card at this stage (normally in the Description field at the top so it’s easy to locate).

LOCKSS

While the posting PDF, cover letter, and resume are all attached to the card for the position, I’ve been in this industry too long to put all of my data eggs in one basket. These also get committed to a git repo which I maintain for this purpose. It contains every copy of my resume, every cover letter, and every job posting I’ve looked at for nearly a decade. Overkill? Perhaps. But unlike many people I will never have to rewrite my resume because I can’t locate a file I haven’t looked at for several years. It works for me and, as they say in the library and archiving world, LOCKSS.

“Ageing” cards

The movement across the board is fairly logical from here. As a particular position progresses through the process, its card moves to the appropriate column. Trello has a card-aging power up which will change the appearance of a card if it hasn’t been touched in a while, which really helps a lot. This allows me to see at a glance where things are in the process, which positions may need a follow-up from me, or which may be duds which need to move to the No Word; Assume Declined column.

Email is a poor filing system

Every piece of correspondence about a particular application is added as a note on its associated card. To do this, I make heavy use of Trello’s “email to note” feature. Each card has a unique email address. Mailing to it will add that email as a new note on the card. If the email has attachments, those will be attached to the card as well. I forward or BCC all email correspondence to its associated card, so I never have to go digging through my email archives to find an important message. The “email to note” feature is very handy in this way, but I do wish it would include the To:, From:, and Date: lines from the email message headers. This is valuable information but is stripped from the email when the note is created, so more than once I’ve still had to spelunk through my email archives to locate an address for someone who messaged me months back.

Aside from correspondence, I also tend to take a lot of notes during all job hunt-related conversations. To whom I spoke, when, and about what are all vital information as the process continues. I usually take these notes in Evernote (which until recently worked better for offline note taking than Trello) then transfer them to Trello after the conversation and/or interview is complete. Each piece of information slides into place to fill another hole in the puzzle, revealing more of the picture of the organisation. Keeping them all in one spot on the card allows me to review all notes and correspondence in advance of subsequent meetings or interviews. I’m always on top of the information and am able to be more prepared (and therefore more confident) during every interview. It really is like a superpower, that confidence boost of being prepared.

Closing the board

Once the entire process is done–a new job is located, negotiated, and accepted–the final step is to close the Trello board for that job hunt. It’s immensely satisfying to be able to put down your tools and walk away after a long and successful project, and closing the board is a great (if perhaps overly metaphorical) way to end one phase of your life as you start out on the next.

So that’s all there is to it. Create a board, create columns, a card for each position, attach all the things, note all the things, keep the cards moving down the board. Boom, you’re done.

Where to see more

If you’re interested in seeing more, I’ve created a public demo job hunt board. It doesn’t have attachments on the cards or many notes, but it can help you get a better sense of the workflow and how it might be useful for you.

Thinking Outside the Big Green Box

In October I had the dubious honor of laying off my entire team (they’ve all found excellent new positions). At the time I was to have joined them in a workforce reduction, but my position was retained and instead assigned to the group of people included in the SUSE acquisition of HPE Cloud. The acquisition is now complete and I once again find myself in a position to make a change.

I joined HPE in September of 2015 because I wanted to make a difference to a team of open source developers. To do so, I stepped down from a Director role into a Senior Manager one. The team was amazing, full of people whose capabilities and brilliance humbled me daily. I have no regrets and am grateful that I had the opportunity. I did not want to see it end.

The SUSE acquisition has put me into a different role, one which isn’t the direction I wish to take my career. Furthermore, it would do so at a Senior Manager level. I didn’t mind the step down when I was supporting a team devoted to open source, but upon reflection I find I do mind it when I’m working on a product rather than a passion. Therefore I’ve chosen to leave the team which has moved over to SUSE. They’ll do great, but they’ll do it without me.

While I am moving on, it’s not without sadness. I am leaving behind several inspiring people. Jim Meyer has proved the power of empathy and compassion in leadership and in product development, supporting and encouraging each member of the team to live life to the fullest and become the best person they can be, all while advancing the Helion OpenStack product. Allison Randal has been a sympathetic listening ear, always there with advice and an overflowing love for the team and for free and open source. Samuel de Medeiros Queiroz, I may miss you most of all. Your energy, enthusiasm, and passion continually remind me of the magic of open source, bringing people together and changing lives for the better. Thank you, to these three, Danielle, and to all the Parrots (you know who you are).

What’s next? Well, that’s a very good question. Running an open source program office would be fairly ideal. I’ve been working in the open source policy and strategy space for a while and would like to do that full time rather than on the side as I have been, but I don’t wish to limit myself. I’ve been leading software engineering departments and teams for most of the past 10 years. My teams tell me I’m a superb manager and leader. I know business. I know open source. I know community. How can I combine some or all of these? Let’s find out.

If you know or hear of anything in the open source space (strategy, policy, leading a team of people who work in open source, etc), I’d really appreciate it if you could send it my way. I currently have a contract helping a company open source an internal product. I’m looking forward to that project, but it’s temporary. I’m looking for the Forever Home I’d hoped HPE would be.

Drop me a line: anonymoushash at vmbrasseur dot com.

My resume: http://www.vmbrasseur.com/resume.pdf.

No, I will not “lighten up”

Here’s a conversation I was in recently. It’s paraphrased and anonymized because I’m not here to name-n-shame.

Person1: Oh hey, $less_popular_project I work on was found to be one of the most secure!

Me: Nice! Good for them. /me boosts signal

Person2: Too bad no one uses $less_popular_project, lol

Me: Not cool. Don’t bag on other projects.

Person2: Lighten up. It’s a joke, jeez.

Had Person2 known Person1 I could’ve let it go as banter between friends, but Person2 didn’t. Person1 was a stranger to them.

I’d intended to leave it at that. I said my piece and pointed out bad behavior, but after thinking about it a bit, no. I’m not done yet. I’m sick of this crap and I’m going to plant my flag in the sand.

Person1 was excited that their project was receiving well deserved recognition for all of their hard work. Person2 used this as an opportunity for a cheap shot and hurtful language.

No matter what the intention (“It’s a joke, jeez.), hurtful language is still just that: hurtful.

There is absolutely no benefit to being mean here. This sort of micro-aggression is masquerading as humor but is amusing only to the teller, not to most of the hearers and certainly not to the target.

Angry cat photo from Flickr user jing.dong, CC-BY-NCFor many years now I’ve been (usually gently) calling people out when they try this sort of thing, but right now I’m going to be more direct about it:

Shaming people’s open source project or community, programming language, platform, editor, framework… This is what bullies do. It’s not funny. It’s not useful. It’s just childish and mean. Knock it the fuck off.

OK, maybe that was more than a little direct. Whatever. I’m tired of third-rate bullies hiding their attacks behind “it’s a joke, jeez.”

I will be firm, polite, and respectful when I do it, but make no mistake that I will call you on your shit and at absolutely no point will I “lighten up.”

At this point someone will chime in with “Yes, see Aurynn’s post, too!” so let me just beat you to that: The very good Contempt Culture by Aurynn Shaw