Plays Nicely With Others

Here’s a way to think about grading your communication skills, as a technical human working with other humans:

  1. Technically competent.

  2. Able to do work with other technically competent people without making them want to run for the hills.

  3. Able to do work with technically competent people, realizing extra value through collaboration.

  4. Able to discuss issues with non-technical people (e.g., users) without making them want to run for the hills.

  5. Able to engage in brainstorming and problem solving with non-technical people, around the issues they’re facing.

  6. Able to communicate with folks who’re less technically proficient than you without making them want to run for the hills.

  7. Able to coach folks who’re less technically proficient than you through issues they’re facing, ensuring they make progress, stay engaged, and learn.

  8. Able to communicate with technical folks who have communication issues themselves.

  9. Able to help guide technical folks who have communication issues toward better technical and interpersonal outcomes.

  10. Able to work with teams of technical folks of varying technical and communicative abilities.

  11. Able to help steer teams of technical folks of varying technical and communicative abilities toward better technical and interpersonal outcomes.

This is just a sketch. Tell me why I’m wrong or what I’m missing.

Further Study

Understanding an idea isn’t a Boolean situation. You don’t understand an idea or not. There are degrees. And different ways of understanding.

Just like there can be different approaches to proving the same mathematical theorem.

Just like there can be different real-life examples of the same interesting pattern.

Even if you understand the mechanics of an idea, further study can be valuable.

Faking It

A first-date question, a cocktail-party question: If you could go back in time and tell your teenage self something, what would that something be?

Here’s an option I’d consider:

Most people, most of the time, do not have a plan. They’re faking it.

Most of the rest, most of the time, maybe do have a plan, but they’re not acting on it effectively.

All the adults are figuring it out as they go. You don’t reach a point where you know what you’re doing. There’s no map.

Delete The First Draft

An old post, Delete Your Backlog, advises agile teams to fearlessly delete things from their backlogs, with the expectation that the truly important stuff will find its way back.

This pattern works for writing, too.

Many times over the years, I’ve written lengthy drafts of posts and papers and lost them to my inept use of whatever tool I was using to write. (Most often web-based tools.) This doesn’t happen to me much anymore, but it does still happen to people all the time.

Good for them.

Good for them because the first draft is better for feeling your way through what you think and what you want to say than it is for saying the thing you ultimately want to say. But when we have a first draft sitting there, it’s tempting to call it a day. Make a change here or there, sure, but nothing big. Certainly nothing fundamental.

When you lose the first draft, what’s gone is cruft and structure. The good ideas are still there in your head. Like Delete Your Backlog says: “If you can’t remember it, it’s probably not that important. If it is important, it’ll probably find its way into your attention again.”

Ideally, your second draft won’t bring back the cruft and it’ll have its structure informed by the work of the first draft.

Sums

Let’s call it a game, any thing you and I do together.

A zero-sum game is a thing we do where, for you to win, I have to lose. A situation (competition? negotiation?) with finite resources. If I get more, you get less. We share one cake. If my piece is bigger, your piece gets smaller.

We often think of things as zero-sum games when they can really be positive-sum games, games where nobody needs to lose, where all parties can come out ahead.

Teaching is wonderfully positive-sum. I can give knowledge to you without losing it myself. Maybe you teach me something, too. Either way, our net knowledge is more than we started with. Good game.

Reminders About Humans

Humans lie.

Humans lie to themselves.

Humans are stupid.

Humans are gullible.

Humans get jealous.

Humans are brilliant.

Humans mean well.

Humans can scale. But not out of the box.

Humans are moody.

Humans are quirky.

Humans are different.

Humans have pride.

Humans have reasons.

Humans have stories.

Humans have secrets.

Humans have dreams.

Humans have priorities.

Humans have bills to pay.

Humans are unpredictable.

Humans are creative.

Humans are resilient.

Humans work the system.

Humans have bad days.

Humans get bored.

Humans are irrational.

Humans have feelings.

Humans like winning.

Humans like knowing the answer.

Humans get comfortable.

Humans go on autopilot.

Humans crave certainty.

Humans hate risk.

Humans don’t listen.

Humans make assumptions.

Humans procrastinate.

Humans don’t get to the point.

Humans hate it when you don’t get to the point.

Humans rationalize.

Humans get defensive.

Humans sweep things under the rug.

Humans rubberneck.

Humans rush.

Humans can zoom in.

Humans can pan out.

Humans want to trust you.

Humans hate to owe you.

Humans are polite.

Humans will do you a solid.

Humans reciprocate.

Humans gossip.

Humans remember.

Humans like to have fun.

Humans love free stuff.

Humans make mistakes.

Humans freak out.

Humans love learning.

Humans can’t read minds.

Humans want to make a difference.

Humans want credit.

Humans explore.

Humans explore the world.

Humans explore each other.

Humans explore themselves.

Humans resist.

Humans get nervous.

Humans are stubborn.

Humans adjust.

Humans invest in relationships.

Humans crave approval.

Humans forget stuff.

Humans need reminders.

Make The Business Case

I’m a developer. I was trained to do technical work. I mostly get paid to do technical work. So I tend to think about problems at a technical level.

But: The people paying me to solve problems at a technical level don’t care about the technical details. It’s a black box to them.

If they knew all the technical details, they’d probably be able to solve their own problems.

This black box has inputs and outputs. They want me to go inside the box and either change or add to how the inputs affect the outputs. They do this because they need the black box for some reason. Usually the reason is related to a business — they use the black box to make money, either directly or indirectly.

Again: My head is wrapped around what’s going on inside the box. The people I work for care about what’s going on outside the box. They only care about the inside of the box inasmuch as it affects what happens outside the box.

Sometimes there’s a problem here: Sometimes I want to change what happens inside the box without the people I work for asking me to.

Usually this is well-intentioned: I want to improve the code because I want to make it easier to change. Maybe four of the last five new features have been painful to add and I can see a way to make similar future features much easier with just a few changes.

But:

  • Changes to the inside of the box are risky. They might affect how the inputs create the outputs. The risk might be small in a clean codebase, but it always exists. So if I’m going to make a change, I should have a reason.

  • Changes to the inside of the box have an opportunity cost. I have to spend time on them. Spending time on something means that I don’t spend that time on something else. So what I spend my time on matters. It should provide a benefit — at least as much benefit as that something else.

The business case for a change is our reason for doing it from a perspective outside of the technical black box. How does it improve the lives of the people I’m working for? Why is it worth the time they pay me to spend on it? Why is it worth spending that time on it versus spending that time on something else?

If you can’t give a reason for making a change that makes sense from the perspective outside of the black box, you should not make that change. Period. You introduce risk and opportunity cost at no benefit to the users of your product. That’s bad for business.

What The Audience Wants

An affirmation for public speakers:

The audience is not there to judge you. They’re there to learn and to be engaged and entertained, not to judge you. Give them what they’re there for.

In fact, the audience wants you to succeed. When you succeed, it’s not just you that gets something out of it. They do, too. And when you fail, their time is wasted. They’re rooting for you to give them what they’re there for.

I Love This

Technologists like to make systems better. We look at a system, see how things work and we’re drawn to “problems”: errors, inefficiencies, potential for confusion, etc, etc.

On a team, though, when we find a better way, we should often steer clear of “This is better.” Instead, consider: “I love this.”

“Check this out, this will make x, y, and z easier and lets me not even worry about p, q and r. I’m loving it. What do you think?”

Even if you have objective reasons to point to for why a thing is better, it’s not as if subjectivity just goes away, bowing in the face of objectivity. We like to think this should happen. It doesn’t.

Show me a thing that you think is better than my thing and I’m likely to get defensive. Show me a thing you’re excited about and maybe I can get excited, too.