Jan 3

Jan 3 Being a good co-worker is your job now

Don’t be a Milton.

“Never think that being polite is a sign of weakness,” Chen said. “It is really a sign of great strength. When people are rude, they expose their weaknesses. When we are polite, our enemies cannot see our weaknesses.”
—Phillip Starr, “The Making of a Butterfly”

In this series about the skills they won’t teach you in coding boot camp, we’ve talked about surviving day one as a new developer, and how to actually listen to your colleagues, instead of just humming a song in your head while you wait for them to stop talking.

In this final part, then, let’s talk about how to be the best co-worker you can be. Ultimately, that’ll contribute more to your career success than anything else you could learn.

Being a better co-worker is your job now, in other words. Here are a few tips that will get you started on the right lines.

Don’t be the “opinions guy”

It’s a curious feature of modern life that we’re expected to have opinions on everything at all times, whether we’re particularly well-informed about that topic or not. People have a bad habit of constantly probing and auditing each other’s opinions, and challenging those that don’t fit perfectly with their own.

The office isn’t the place for this kind of thing (that’s what the internet is for). Just let people think what they want, however nutty it might seem to you, and resist the urge to educate them on everything they’re wrong about.

This isn’t to say, of course, that you should have no technical opinions about, for example, the right way to structure a particular piece of code. Naturally you will, and the more you become a master of your craft, the more such insights you’ll have. But the way to use that understanding is by doing the right thing, not by arguing with other people about what the right thing is.

And it’s always wise to remember that, however sure you may be about something, others may think differently, and that’s okay. You don’t need to badger everybody until they think the same way you do. After all, you’ve been wrong about things before, and now you know better.

You can’t learn anything if you don’t believe others have anything to teach you. Seek to understand, not to persuade.

Don’t be an advocate

One of the most annoying people in the workplace is the Advocate for something. You know of whom I speak. It’s the person who thinks Linux is the greatest thing ever, everybody should use Linux for everything, and if you’ve made the mistake of buying a Mac instead, you’re either misguided or an idiot.

Or maybe they’re an Anti-Advocate: “Go is a terrible language, and you should feel bad for using it.” Sure, buddy. Whatever you say.

These people are just boring, and their co-workers pretty soon learn to avoid their favourite subject, or to avoid talking to them altogether. But it’s no good, because they will somehow manage to bring every conversation around to the topic.

Exercising empathy

It doesn’t matter how nice a person is in other ways: if they have no empathy, they’ll be a bad co-worker.

PETER: Milton, hi, uh… could you turn that down just a little bit?
MILTON: I was told that I could listen to the radio at a reasonable volume from nine to eleven…
PETER: No, I know you’re allowed to, I just thought maybe as a personal favour…
MILTON: I told Bill that if Sandra’s going to listen to her headphones while she’s filing then I should be able to listen to the radio while I’m collating, so I don’t see why I should have to turn down the radio…
—“Office Space”

Perhaps this is less of an issue now that remote working is becoming more common, but when you share a workspace with other people, do be considerate about what noises, smells, or other distractions you might be emitting.

I once had a manager who played all his voicemails back on speakerphone, audible to everyone around. And he got a lot of them, presumably because he was the kind of person that people try to avoid face-to-face conversations with.

Everyone in the office hated this, but no one ever said anything. People don’t tell you when they start hating you.

Socialising outside work helps a lot. Sure, this is hard if you work mostly remotely, but not impossible. Remote and distributed teams often have non-work get-togethers for just this reason. If your team doesn’t do this, maybe it should. You can have a book club over Zoom or Teams, do a quiz, or even just block out the last 15 minutes of your weekly meeting for general chat. A formula that can help here is to ask each person to nominate something interesting but non-work-related that they read, watched, or heard about this week.

If your company or team doesn’t organise social events outside work, try taking it on yourself to do so. Pick some activity that just about everyone can enjoy, even if it’s just ironically: bowling, escape rooms, a board game tournament, go-karting, a movie marathon, a charity walk. The main thing is to have the chance to interact with your colleagues outside work: you might be surprised what a difference it makes to your subsequent interactions at work.

Meetings: less noise, more signal

For some people, meetings are their work, but for most engineers they’re simply an annoying time-suck, to be avoided whenever possible. When you can’t avoid a meeting, though, here are a few tips for getting through them with as little collateral damage as possible.

Some people love the sound of their own voice, and ideally all those people would just get together and have one giant meeting, while the rest of us get stuff done. Until that happens, you can at least avoid making the problem worse by keeping your own contributions to a minimum.

Don’t feel you need to say something just for the sake of it. Indeed, if you get through the whole meeting without being required to say something, then you probably don’t need to attend those meetings in future. It’s a win-win.

On the other hand, if you’re only in meetings when you need to be, and you only speak when you have something to say, then you have a better chance of getting people’s attention.

The stakes can be high

Work meetings are an interesting social dynamic, because you’re not just having a conversation with someone: you’re talking to them in front of their peers, that is, effectively, in public. People are more sensitive in this situation than they might be otherwise. Something they might perceive as a slight, or that they think others might perceive as a slight, can give offence in a meeting situation when it might not matter at all in a private chat.

If, as often happens, the boss is present too, that raises the stakes even further. Now it’s not just your peers who are listening and judging you, but the person who has power over your compensation and promotion. Maybe even your continued employment. Under these circumstances, a word or two from your co-workers can do you great harm, or great good. It all depends.

The presence of a boss is like an amplifier for the risk or reward of what we say in meetings, and the bigger the boss, the greater the amplification. Group chats such as Slack or Teams are like a meeting that never ends, in this and other respects, so be careful. Treat anything you say or type in such a context as being said to everyone present, whether they appear to be listening or not.

And, it’s important to add, treat anything you write to someone privately (for example, in an email or direct message) as though it will be shared with the whole company. One day, it might be. If you say something critical about a third party, assume they will see it sooner or later (and you may never know when that happens).

Being positive and constructive

One of the most endearing qualities you can have as a colleague is enthusiasm. We all know the person who shoots down every suggestion in meetings with the response “Well, that won’t work, because…” And we are not fond of that person.

Yes, it can be useful sometimes to visualise potential problems, especially if you can come up with solutions. But just rejecting all ideas out of hand isn’t constructive by itself.

Even if you think the proposal is fundamentally flawed, you needn’t phrase your response that way. You could say “That’s a really interesting idea. I wonder if…” and you can talk about the pros as well as the cons.

We just want to be visible

Have you ever wondered why some people seem to constantly speak up in meetings even when they don’t have anything useful to say? The answer is that they want what we all want: recognition and validation. They want someone to say, in effect, “Yes, we see you, Bob, and we think you’re a valuable member of the team.”

It’s easy to deny someone this validation, even when we don’t really mean to. Consider an exchange like this:

FEMI: I was wondering if it would be a good idea to store the what-nots in a shared database?
ERIC: What we should really do is cache that data in a key-value store local to the node, or maybe in a CDN.
(MURMURS OF AGREEMENT)

See what Eric did? He trampled right over what Femi just said, erasing their suggestion and replacing it with his own. Even though the one idea leads logically on to the other, Eric subtly managed to suggest that Femi was wrong, and that, in future, people shouldn’t listen to Femi, but to Eric instead.

Maybe he didn’t consciously intend to send that message, but that’s what people heard. We all know an Eric. How can we avoid being an Eric? By building others up, not shooting them down.

Validating and being supportive

After this meeting, Femi may think twice about voicing their ideas in meetings in the future. They may also think, with some justification, that Eric is a jerk.

Here’s a better way to handle this exchange:

FEMI: I was wondering if it would be a good idea to store the what-nots in a shared database?
ERIC: That’s a great suggestion, Femi. Could you talk about it a bit more?
FEMI: (TALKS ABOUT IT A BIT MORE)
ERIC: Yes, I like the sound of that. And what if we used a local key-value store, or even a CDN? Do you think that would increase performance?
FEMI: Yes, that’s a great idea.

Almost exactly the same conversation, at least on the surface, but with a radically different subtext. Eric first of all recognised Femi by name and validated that their suggestion was acceptable, and worth discussing. Rather than explain it further himself, as though it were his own idea, he invited Femi to talk about it, implying that he values their opinion.

Then he presented his own point, not as a substitute for Femi’s plan, but as a natural evolution of it: “Yes, and…”.

Rather than imply that he’s correcting Femi because he knows better, he asks Femi for their opinion about his suggestion. By deferring in this way, he sends the message that he thinks Femi is qualified to pronounce on other people’s ideas, as well as originating them.

Femi will remember this conversation very differently to the first version. They will feel that they contributed something valuable, that the contribution was recognised and appreciated by the group, and that it spurred a discussion leading to an even better plan.

As a co-worker, this version of Eric was supportive, listening to Femi’s idea and inviting them to talk further about it, rather than trying to shut them down and talk over them.

“Say my name”

When you’re in a discussion like this, pay attention and watch for opportunities to do the same kind of thing yourself. If a co-worker makes a point, acknowledge it, support it, mention them by name, and if the discussion leads to a fruitful result, show that you remember whose idea it was in the first place.

When you follow up on what someone else has said, tie it back to them by name, saying “To Helen’s point, it might be worth considering…” or “What Nasir said earlier reminded me that…”

When someone does this for you in return, take note of the warm feeling it generates in you: “I’ve been heard!”

Being a good co-worker is your job now

I think we all realise that it’s bad manners to actively shoot down a colleague’s idea or code in a group setting. But ignoring them, erasing them, or even just minimising them is a more subtle, yet no less effective way of making yourself an unpleasant person to work with. The behaviour may not be malicious in intent, but that doesn’t matter: it’s the effect that counts.

In general, you should always be seeking out ways to be kind, friendly, and supportive to your co-workers. That is your real job, regardless of what your business card says. And it’s not difficult. All you need to do is be the person that you’d want to work with, if you had the choice.

Courtesy is a sign of strength

Don’t expect everyone to respond in the same way, though. Some people won’t notice your kindness, some won’t value it, and some may actively exploit it. This is a shame, but there we are. Treat everybody with impeccable courtesy, no matter how they act in return, and you’ll have the high ground in every situation.

Never be suckered into tit-for-tat rudeness. When two people get up in each other’s faces, and the spittle starts to fly, no one watching will remember “who started it”. They’ll just remember two angry, rude people, and try to avoid both of them.

JARED: At Hooli, I once saw two engineers get into a fight so vicious, they almost made physical contact.
—“Silicon Valley”

You can’t like everyone you work with: that’s impossible. But you can be polite to them, even those who don’t return the favour. Especially to those people, indeed. It’s hard to imagine that anyone actually sets out to be a rude jerk, but this just seems to be some people’s default way of interacting. It’s important to show them that it doesn’t work on you.

By being rude to you, they hope to engage you in a who’s-the-biggest-jerk contest, and drag you down to their level. Instead, you can wrong-foot them by being extra nice. That worries people, because they won’t understand what you’re up to.

Well, that’s about it for this series. I hope you enjoyed it, and that it’s also prompted you to think a little about your career: how it’s going, and most importantly of all, where it’s going. Don’t forget to check out my book Code For Your Life for more.

Previous: People skills for developers