Gatekeepers are a problem in communities. They decide — often arbitrarily — who can and cannot be members of a community. Are you a true Scotsman? A gatekeeper will tell you. And if there’s something they don’t like about you, or they’re feeling particularly ornery, they’ll keep you away from the community.
Gatekeeping is a problem in open source communities. More experienced (or just louder) contributors set a bar that new contributors cannot meet. This is bad for folks who want to contribute to the project, and it’s bad for the project’s sustainability.
A recent Opensource.com article asked “What is a Linux user?“. In the initial version, it left open the possibility that if you’ve only used a Linux desktop that doesn’t require a ton of tinkering, then you’re not a real Linux user. Fortunately, the comments called this out quickly. And the author, to his credit, did not hold this view. He quickly updated the article.
The revised article does a much better job of closing the door on gatekeeping, but I would rather it have never run at all. By engaging in debate on the question, you give it validity. It’s best to deal with gatekeeping by not even acknowledging that the question is valid.
When working in a group, you may sometimes struggle to get the group won over to your way of thinking. It’s a challenge. Sometimes you can’t state your case in a compelling manner. Sometimes your idea is terrible. Sometimes the group just won’t listen. But there’s a shortcut you can use to give your opinion a head start: write it down.
Blank pages are scary. They contain infinite possibility. It turns out that infinity is a really big, daunting concept. People don’t like them. This makes the blank page your opportunity.
Undoubtedly, the team will edit your draft heavily. It may get to the point where nothing remains of your original work. That’s okay. By having your opinion be the starting point, you give it some extra weight. You’re framing the discussion. If you’re particularly sneaky, you can even go a little beyond your actual position so that when it gets edited more toward the “middle”, it lands where you wanted.
This isn’t a fool-proof method by any stretch of the imagination. But you’re giving your idea a little bit of a boost. Even if your position isn’t the one the group settles on, being willing to write that first draft sets you apart. It doesn’t particularly matter if it’s good or not, because it’s going to be revised and revised and revised. So do you yourself a favor and just write the damn thing.
I don’t remember how it crossed my field of view, but I recently read a blog post from the CEO of Carta. In it, he talks about their company culture and how new employees get introduced to it. Since I have had a few conversations on this general topic with my colleagues who are in charge of such things at my employer, I read it with great interest.
Until I got to the sports team analogy.
Most companies find role models in other companies (e.g. Facebook, Google, GE). They aspire to be like “Company X”. I propose an alternative model for Carta. We don’t model ourselves after companies. We model ourselves after professional sports teams. My question for you is, “What is the difference between a company and professional sports team?”
What?
There are many similarities between Carta and a professional sports team. For starters, our entire company meets everyday at 8:30am to begin the day together. Everyone — engineering, sales, services, office management. Nobody is exempt. In sports, even the goalie, who may have a completely different practice schedule from the rest of the team, still meets at the same time to warm up.
[…]
Most people think it’s crazy that we make everyone be in the office at 8:30am every morning. We think it is crazy not to. The New England Patriots would never tell players, “Show up for practice when it is convenient.” If you want to be the best in the world at what you do, start every day together.
This is bad. It is so bad. What I read when I see this is “if you’re a parent, we don’t want you.” Or any other number of reasons why being in the office regularly at 8:30 might not work.
Now don’t misunderstand me: it’s important to be a reliable coworker. But the idea that the entire company needs to start the day together is ridiculously exclusionary. Sports teams practice together because they need to work closely together in split-second situations. They need to develop an almost telepathic understanding of what their teammates will do. They also get paid millions of dollars a year.
Your office manager does not get paid millions of dollars a year. The success of your company does not depend on the perfect, split-second timing of your lead developer and East Coast sales representative. You should develop team rapport and trust but in a way that makes sense for the work they do. Not exclusionary Valley Bro crap.
There are some really good ideas in the post: the full-day culture orientation, the idea of not taking too much capital in an attempt to grow as fast as possible, the idea that everyone contributes to customer success. But the shadow of the crappy sports analogy is deep enough to overwhelm the good parts.
“We welcome our customers,” Best Buy training supposedly says, “not greet them.” First off, if you’re doing this, fuck you. This is silly word-lawyering for any job, but particularly for retail. They’re already relatively low-paid and high-bullshit, why are you making it worse?
But even apart from treating your employees like they’re people, there’s a business argument for this. Over-engineering customer service interactions makes them less serving of the customer. Empowering the employees to serve the customer leads to better service. And it turns out better service can help you keep your customers.
By coincidence, I had to deal with a couple of financial firms earlier this week. The first interaction boiled down to “welp, I can’t really do much for you. Go away.” The second, with Fidelity, made me feel like my problem was their problem, too, and it would get solved. Every time I’ve needed something from Fidelity, I’ve felt that way.
The same is true for T-Mobile. Even when it’s possibly not their problem, they do as much as they can to help me solve it. As a result, I’m still a T-Mobile customer, even though the coverage map isn’t as coverage-ful as I’d like. This is in no small part due to the quality of service I’ve received.
In both of these cases, the customer service representatives don’t feel like they’re mindlessly reading from a script. I get the sense that I’m talking to an actual person who wants to solve my problem, not close my case. They don’t seem to be judged on the difference between “greet” and “welcome”.
Chris Siebenmann recently wrote a post about Golang where he said: “Go is Google’s language, not the community’s.” The community makes contributions — sometimes important ones — but does not set the direction. We frequently use “community project” to mean two separate ideas: a corporate-lead project that accept community input and a project (that may have corporate backing) lead by the community.
Neither one is particularly better or worse, so long as we’re honest about kind of project we’re running. Community-contributed projects are likely to drive away some contributors, who don’t feel like they have an ownership stake in the project. Chris mentions that Go’s governance has this effect on him. And that’s okay if you’re making that decision on your project intentionally.
Some community-contributed projects would probably welcome being community-led, or at least somewhere closer to that. But technical or governance barriers may inadvertently make it too difficult for would-be contributors to ramp up. This is one area where I don’t think GitHub’s position as the dominant code hosting platform gets enough credit. By having a single account and consistent interface across many unrelated projects, it becomes much easier for someone to progress from being a bug filer to making small contributions to becoming (if the project allows it) a key contributor.
Jessica Liebman wrote an article for Business Insider where she shared a hiring rule: If someone doesn’t send a thank-you email, don’t hire them. This, to be blunt, is a garbage rule. I don’t even know where to begin describing why I don’t like it, so I’ll let Twitter get us started.
Don’t accept a job offer from a company that didn’t send you a handwritten thank you note after the interview. You’re the person adding value. Not the other way around. https://t.co/2hLg546FUc
Seriously though, this sounds problematic. Insofar as it's a recognized social norm to send a thank you note, it'll be a meaningless formality, hopeless for distinguishing good candidates. Insofar as it's not, you should infer *nothing* from the fact that someone didn't send one!
This is an arbitrary bit of gatekeeping that is both culture- and generation-specific. In doing this you’re also gong to skew results to people who act and think like you, thereby decreasing intellectual diversity on the team. A thank you is classy, but not a disqualifier.
When I’ve been on the hiring team, a short, sincere “thank you” email has always been nice to receive. But I’ve never held the lack of one against a candidate. It’s not like we’re doing them some huge favor. We’re trying to find a mutually beneficial fit. And employers hold most of the power, in the interview process and beyond.
You can lament it if you want, but the social norm of sending thank yous for gifts is greatly diminished. So even if it would have been appropriate in the past, it’s no longer expected. And, as noted above, it’s culture-specific anyway.
Until employers see fit to offer meaningful feedback to all applicants, they can keep their rule requiring thank you notes to themselves. And even after that. If an employer wants to use arbitrary gates that have no bearing on performing the job function, I don’t want to work for them.
Over the years, I’ve received a lot of feedback on my writing. Some of it has been helpful, some less so. Little of it has coalesced into rules that I could easily share, but once piece of advice stands out: delete the last sentence.
I first received this advice when I was in high school. A young and idealistic NJROTC cadet ensign, I wrote several memos to our commanding officer about various incidents. I had a tendency to close with a request that he take the action I desired. Ryan Brown was remarkably kind and mature for a high school senior — instead of ignoring it or getting angry and dismissing me out of hand, he took me aside. “Cotton,” he told me, “the next time you write a memo, delete the last sentence.”
I thought of this again recently when I was replying to a message on a community mailing list. I don’t remember what the person wrote, but it was off-topic. I was going to say “This is off-topic for the devel list”, which is benign on its face, but didn’t really add anything except an implied “fuck you, go away”. My experience is that the last sentence in a reply like that is almost always inflammatory.
I get it. When you’re writing something, you want to have a good close that really drives your point home. I catch myself doing that all the time. But if you’re writing well, particularly in email, you don’t need a punchy ending because you’ve already made your point. In the above, other parts of my reply already indicated that the message wasn’t suitable for the list, and I explained why. Repeating myself there didn’t add any value to my reply, it was just repeating myself for the sake of repetition.
“It’s on the roadmap” was a common expression when I worked in customer-facing roles. That statement is a delightfully vague response to feature requests. It might mean “it will be in the next release.” More often, it was as close as I could get to saying “yeah, there’s no way in hell we’ll ever get around to implementing that” without getting myself in trouble. Cowardly? Probably. But at least it was tactful.
At a previous company, we did actually have a product roadmap. It looked forward through the next year, broken down by quarter. The first quarter was generally pretty accurate, even if some of the work slipped a bit. The second quarter was okay. The third and fourth quarters? Well they didn’t really reflect anything approaching reality.
But for me, it’s all about how the road map is used. “Road map” is a pretty lousy term, when you think about it. I spent a lot of time looking at road maps as a kid (I’m so cool!) and they almost always gave an accurate representation of what was coming a mile or a hundred miles ahead. Product road maps, if taken that way, lead to lies and broken promises.
For me, a better framing is a product forecast. When the National Hurricane Center forecasts hurricane tracks, they don’t just draw a line and call it a day. The forecast graphic shows an area of uncertainty that expands with time. When a storm is a few hours offshore, you can generally be fairly certain where it will make landfall. When it is days away, the potential landfall area is much larger.
Example hurricane forecast graphic from the National Hurricane Center
The analogy isn’t perfect, of course. Products can pivot much faster than hurricanes can. And storms are things that just happen to us, whereas the product is something we can consciously effect. But in general, I like this idea. In the short term, you know what you’re working on and what you’ll be able to deliver. Beyond that, you know where you’d like the product to go, but something may happen between now and then to change it.
I like the “Yes, No, Maybe” model that Ben Balter wrote about last year. In his post, Ben limits the roadmap to the next three months and categorizes work as “yes we’re doing that”, “no we’re not doing that”, and “maybe, but we need more information”.
The advantage of the three-month window is that it prevents the roadmap from becoming a giant lie. But extending a product roadmap (or forecast) beyond three months helps give some context to the work being done in the short term. People benefit from having a longer-term vision, even if they change direction before they ever reach it. Forecasts are wrong sometimes, but they represent the view of the future from the best information available at the time.
Recently, the Fedora Engineering Steering Committee (FESCo) entertained a proposal to allow people to file issues in the repo where Fedora RPM spec files live. They ultimately rejected the proposal in favor of keeping those issues in Red Hat Bugzilla. I didn’t weigh in on that thread because I don’t have a set opinion one way or another, but it raised some interesting points.
First, I’d argue that Bugzilla is hostile for end users. There are a lot of fields, many of which aren’t meaningful to non-developers. It can be overwhelming. Then again, there probably aren’t too many end users filing bugs against spec files.
On the other hand, having multiple places to file bugs is hostile for users, too. “Where do I file this particular bug? I don’t know, I just want things to work!”
Having multiple places for bugs can be helpful to developers, so long as the bugs are filed in the right place. Spec file bugs make sense to be filed in the same place as the spec files generally. But they might make more sense elsewhere if they block another bug or fit into another workflow. And the odds of a bug being filed in the right place isn’t great to begin with.
This is a question for more than just Fedora though. Any project that has multiple pieces, particularly upstream dependencies, needs to think about how this will work. My take is that the place the user interfaces with the code is where the issue should be filed. It can then be passed upstream if appropriate, but the user shouldn’t have to chase the issue around. So if an issue manifests in my project, but the fault lies in upstream code, it’s my responsibility to get it fixed, not the user’s.
So now that I’ve typed all this out, I suppose I would argue that issues should be enabled on src.fedoraproject.org and that it’s the package maintainer’s responsibility to make the connection to Bugzilla where required.
I recently saw a tweet that offered advice to new Microsoft employees:
Small advice for MSFT new hires: Don't worry if you feel totally overwhelmed for weeks or even months. That's normal. There's a lot of self-starting people need to do. Stick with it, you didn't make a mistake. You'll probably feel a lot more confident in 6-12 months.
— Carmen Crincoli ⭐️ (@CarmenCrincoli) March 4, 2019
My initial reaction was that this is very true and also bad. I said it was a sign that the onboarding process is broken. But there’s more nuance to it. I want to draw a distinction between not knowing all of the pointy ends of a job and not knowing how to do the tasks necessary.
The former is good for personal growth. I wouldn’t want to take a job that I already know exactly how to do; I won’t learn that way. And even when you’ve done the job somewhere else, each organization has unique nuances that it takes time to learn.
Where it gets troublesome is when the difference between what you’re asked to do things you haven’t been taught how to do. Here I mean the internal processes and tooling, not the general act of doing it. It’s reasonable to expect a marketing person to know how to write a blog post; it’s not reasonable to expect them to know how to submit it through your internal tooling.
Perhaps that’s not what Carmen meant, but it’s certainly what came to mind for me. When I joined Microsoft, we had no documentation for what was expected of people in my role and no documentation for how to execute those tasks. So I would have people coming to me for things that I had no idea how to do — or even what they were. In my time there, I tried to document as much as I could so that the next person who joined the team would have a less stressful onboarding experience than I did.
But even if Carmen was talking more about the “not knowing the pointy ends” scenario, it occurs to me that this may not be healthy. Personal growth is great, but if the difference between what you know how to do and what you’re expected to do gets too large, it’s no longer growth — just stress. People I spoke to at Microsoft seemed to embrace the “you’ll feel stupid” part, and maybe that’s unavoidable, but it’s not a good thing to embrace.
In a talk at the Southern California Linux Expo last week, Jono Bacon said something that really stuck out to me. “[Burnout and stress] is a topic that isn’t talked about enough. In our industry, particularly in Silicon Valley, stress is glorified and that’s stupid.” If you’re in a position to help with onboarding new hires, give them the tools to know how to do their job so they can learn how to do their jobs.
