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.
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:
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.
Carlos Valdes-Dapena thinks so. In an article for Harvard Business Review, he argues that most team building events are a waste of time and money. He has research to back it up, but I think most people who have participated in hokey corporate team building events would say “duh”. But there’s a difference between Team Building™ and team building.
Team Building™ often consists of contrived situations that seek to forge bonds within a few hours. They’re expensive and elaborate. They may involve cheesy, forced metaphors. Participants feel uncomfortable and coerced.
Team building is not something that can be forced. It can be encouraged, given conditions to thrive. Ultimately, though, it must happen organically. So any team building exercise that’s worthwhile has to be a slow burn. Relaxed, informal lunches can do a lot for helping people work together. I’ve enjoyed trips to a bowling alley and to a cave system.
The key part is “we’re going to spend some time together away from work”, not “we’re going to lock you away so that you become a team”. Even though the goal is to improve team cohesion, you can’t just sit there and expect it. Give people space to socialize and interact on their own terms so that they can form bonds on their own.
This is particularly important for distributed teams. In my experience, even brief face-to-face meetings dramatically improve how I work with others. When I visit offices or run into colleagues at conferences, I try to spend as much time as I can being social. I ended up skipping several sessions at DevConf because I figured the opportunity to have a cup of coffee with a project contributor was more valuable than attending a talk that I could watch on YouTube later.
Good team building exercises are cheap and easy. They aren’t a burden on your team. But they take time.
I began my professional career working for a large university. In the first three years, I worked in a small department, but I later spent three years in the central IT organization. I got a lot of exposure to the bureaucratic machinery. Then I went to work for a 25-person company for five years. When Microsoft — a company of over 130k employees — acquired my employer, I was thrown back into the bureaucratic machine. But it turns out my bureaucracy survival skills had atrophied a little bit.
It took about three months before I got my footing and was able to start navigating the bureaucracy again. I like to think that when I’m in shape, I’m pretty good at it. So I’ve collected some of the rules I’ve learned over the years.
There are meetings for everything. — You may even have a meeting to plan the real meeting. If your deity is particularly mad at you that day, you’ll have a post-meeting meeting, too. This happens in almost all large organizations. It becomes too large and impersonal for people to keep up on what’s going on, so they’ll have lots of meetings so everyone can stay informed. Even if the meeting could have been an email, it will still happen because that’s the safer option.
Meetings will always begin with 5-10 minutes of late arrivals and AV/conferencing troubleshooting. — Computers are so much easier to use than in years past. So much just works. But somehow getting the projector to join the web meeting will continue to elude even the smartest people in the room. And because everyone is invited to all the meetings, they’ll probably be a few minutes late to yours.
The only thing worse than being in all those meetings is not being in those meetings. — It sucks spending all your time in meetings instead of doing your job. But decisions are (sometimes) made in meetings. If you’re not included, you’ll be left out of important decisions.
Conway’s Law is real. — Anything your organization designs will look a lot like the org chart.
People will take your responsibilities when it benefits them and give you responsibilities when it doesn’t. — In a large organization, you need to be visible to get rewarded. So if someone can benefit by doing your job for you, they will do it. But if it won’t benefit them, they’ll try to pass the task on to you.
People are more likely to ask for volunteers than to volunteer. — This is related to the last one. It’s easy to put out a call for volunteers. It’s harder to step up and volunteer. This is in part because people will often not volunteer and if you step up every time, you’ll have way too much work on your plate. The solution here is to assign tasks instead of asking or hoping for volunteers.
You can say no. In fact, you should. (to travel, to working outside of business hours, etc). — It won’t hurt your performance and it will help your sanity. I wrote about this in greater length last month.
Everyone will agree about broken processes, but no one knows how to fix them. — Large bureaucracies will have a lot of processes that probably made sense at one point, but grew or decayed to the point where they are inarguably broken. But how do you fix them? Nobody seems to have a good answer. Sometimes there are people with a vested interest in maintaining the status quo. Other times, it’s just a really big ship to try to turn around and no one has the time to devote the necessary work to it.
The only way to find out how to do something is to ask. There will be no documentation, and if there is it won’t be discoverable. — Every once in a while your predecessor will be someone like me who leaves the documentation in a better state than they found it. But for the most part, people don’t even bother writing documentation because they don’t want to, they’re not required to, and it will be out of date by the time someone reads it.
References to products will survive a lot longer than the products themselves. — For months, I would hear people at Microsoft talk about “S+”. I figured out from context that it meant a meeting invitation, but I couldn’t figure out why. Turns out Schedule Plus was a product in the 1990s. I was there 20 years after the functionality was merged into Outlook, but I still heard references to it.
Interpersonal relationships are how things get done. — Make friends. Make lots of friends. Make friends with people in other departments. Keep in touch with them as they and you move around the organization. Whenever you need something done, it’s much more likely to happen if you know someone you can talk to personally. Relying on official channels will, unfortunately, result only in waiting and inaction.
Those are the lessons I’ve learned. I’m sure there are plenty more. If you have lessons for surviving bureaucracy, let me know in the comments.
One thing about humans is that we’re really good at habituating. It doesn’t take long for something new to become normal. This really came to mind last month when I presented a pair of talks at the DevConf.cz conference in Brno, Czech Republic.
One of my talks was a 25-minute presentation on project management in community projects. As I was putting the talk together, I started thinking “this is a nothingburger.” Twenty-five minutes isn’t enough to give any useful depth of information. So all I’m doing is giving a basic description of my job.
As it turns out, “nothingburger” was the exact hunger level of the audience. When I asked the room, only three people or so said they were professional project or program managers. An intro-level talk was exactly the right target. Doing the work every day, I forgot that it’s not everyday for other people. Even people who do related work might find something worthwhile out of it.
l should have known better. Even in my own company, I’m the only program manager who works directly in upstream projects. The rest are focused on the company’s products. Unless they served in my role previously, the people on my team don’t necessarily know how my job is different from theirs.
I left DevConf.cz feeling inspired to seize the momentum and keep moving on some things I’ve wanted to do. And it’s a good reminder to myself and others that we’re not the best judges of what others will find interesting.
I often see developers, both open source and proprietary, struggle with trying to use bug trackers as support tools (or sometimes support tools as bug trackers). I can see the appeal, since support issues often tie back to bugs and it’s simpler to have one thing than two. But the problem is that they’re really not the same thing, and I’m not sure there’s a tool that does both well.
In 2014 (which is when I originally added this idea to my to-do list according to Trello), Daniel Pocock wrote a blog post that addresses this issue. Daniel examined several different tools in this space and looked at trends and open questions.
My own opinions are colored by a few different things. First, I think about a former employer. The company originally used FogBugz for both bug tracking and customer support (via email). By the time I joined, the developers had largely moved off FogBugz for bug tracking, leaving us using what was largely designed as a bug tracker for our customer support efforts. Since customers largely interacted via email, it didn’t particularly matter what the system was.
On the other hand, because it was designed as a bug tracker, it lacked some of the features we wanted from a customer support tool. Customers couldn’t log in and view dashboards, so we had to manually build the reports they wanted and send them via email. And we couldn’t easily build a knowledge base into it, which reduced the ability for customers to get answers themselves more quickly. Shortly before I changed jobs, we began the process of moving to ZenDesk, which provided the features we needed.
The other experience that drove this was serving as a “bug concierge” on an open source project I used to be active in. Most of the user support happened via mailing list, and occasionally a legitimate bug would be discovered. The project’s Trac instance required the project team to create an account. Since I already had an account, I’d often file bugs on behalf of people. I also filed bugs in Fedora’s bugzilla instance when the issue was with the Fedora package specifically.
What I took away from these experiences is that bug trackers that are useful to developers are rarely useful to end users. Developers (or their managers) benefit from having a lot of metadata that can be used to filter and report on issues. But a large number of fields to fill in can overwhelm users. They want to be able to say what’s wrong and be told how to fix it.
In order for a tool to work as both a bug tracker and ticket system, the metadata should probably only be visible to developers. And the better solution is probably separate tools that integrate with each other.
Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code.
We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.
I’ll grant that not all of these issues are with the code itself. In fact a lot of it isn’t the code, it’s the inputs given to the code. So when I talk about “good coding” here, I’m being very loose with the wording as a shorthand for the technology we produce in general. The point holds because the code doesn’t exist in a vacuum.
It’s not just about the outputs and real world effect of what we make. There’s also the matter of wanting to build the best team. Inclusion opens you up to a broader base of talent that might self-select out.
Being inclusive takes effort. It sometimes requires self-examination and facing unpleasant truths. But it makes you a better person and if you don’t care about that, it makes your technology better, too.