I Know What You're Thinking

Back in grad school, I had a professor who told me about an interdisciplinary summer retreat he had been invited to years ago.  There were economists, political scientists (like him), sociologists, educational theorists, philosophers, and many other smart people.  Though they talked about a wide range of topics, he found it most interesting that, by the end, he could predict the kinds of questions people were going to ask before they asked them.

Economists would wonder about incentives, transaction costs, and barriers to entry.  Sociologists re-framed things in terms of demographics and norms.  Educational theorists were concerned about developmental impact.  Philosophers and English professors would bring the conversation back to 'the text.'  Political scientists would analyze power relationships and procedural constraints.  And so on.

This story has stuck with me for years, especially as I experienced the same thing myself in a similar summer seminar.  On the one hand, it's no surprise that professionalization teaches you a conceptual system with a specialized vocabulary, and it shows the value of doing so.  On the other hand, it's all a bit depressing, as if what we study and do for a living bends us to the wheel of a necessarily partial worldview.

Since leaving the ivory tower and returning to software full-time, I've noticed the exact same phenomenon.  In a technology firm, people from each team will have a perspective that's hard to shake.  Developers and architects will be concerned with system coherence and stability.  Testers live in a world of exceptional cases, where everyone is trying to divide by zero and servers are falling like flies.  Product analysts think in terms of costs, revenue, and rates of return.  Accountants want to know how they can report on it.  Support teams are concerned with how much manual intervention is required.  And project managers want to know how many person days it will all take.  And so on.

(This is all very rough, but you get the idea.  It takes a lot of work to truly appreciate any of these perspectives.)

It's important to recognize these points of view when working with other teams.  If you give a technical reason why it will take a long time to develop something, non-developers will only hear white noise.  They'll probably just think you don't want to do it.  But if you can talk about it using a set of terms they understand, such as existing products and features or past time estimates, you're much more likely to have a productive conversation.

This may seem like common sense, but I think it's one of the central challenges of getting things done in a complex organization: you have to be an expert in one knowledge domain while simultaneously being able to communicate with other experts in other knowledge domains.  All projects involve some give and take.  The less agile your process, the more important it is to make sure you have good communication from the start.  I've seen many projects fail because no one really understood what anyone else wanted.

Why Career Advice Sucks

It's not easy to give or receive career advice. I've talked with loads of people, read stacks of books, and even tried to offer guidance to a hapless few. And I've come to the conclusion that it's all a bunch of cliches.

For instance, everyone knows that they should be good communicators. Communication is what gets you a good job and it helps you figure out whether or not a job is a good fit for you. If your interviewer doesn't see the interview as a two-way street, get out!

Communication is essential on the job. If you don't understand requirements, you'll waste valuable time coding. You have to talk with your boss about what's going right and what's going wrong. If you can't communicate with your boss, get out!

Finally, you have to be able to communicate in order to get ahead. The powers that be need to know what you're excited about and where you want to go next. If you're unable to discuss your future at your company, get out!

But everyone knows all this. Two thoughts:

One is that it's not easy to see how to become a better communicator. I really like Michael Lopp's idea of a 'Trickle List'. This is a list of things you try to do every day, which you check off regularly and use to track your goals over time. For example:

• People — Have a random chat with someone
• Write — Write something, anything
• V — Take a vitamin
• Biz — Learn a part of the business
• Book — Read something in a book

I've copied Lopp's list exactly for myself, but the item I want to focus on is having random chats. I tend to get in early, put on my headphones, and am in the Zone by the time most people arrive. If someone starts talking to me, I think, "Why are you bothering me? I'm trying to work!"

Now I'm trying to have at least one random conversation a day. This improves my skills, helps me understand what's going on and, hey, I might make a friend or two. The point is that the Trickle List is a simple way to do something every day to improve something you want to improve. It helps achieve a cliche.

The other thing is that obvious truisms like 'be a good communicator' are easy to 'know' but harder to do. David Foster Wallace pays a lot of attention to cliches in his mammoth Infinite Jest, which is about addiction and takes place in a halfway house. Everyone knows the AA slogan 'One Day at a Time,' but until you actually have to work on just getting through the day without touching a substance, this cliche is meaningless. The people who stay clean longest are the ones who stop over-analyzing cliches and just repeat them until they actually mean something.

You don't have to be an addict in order to make sense of this. Every issue of the Harvard Business Review says exactly the same thing as every previous issue. Every management book repackages every other book, whether it's Seven Habits or Good to Great. You will not learn anything in a management class that you can't read on a bathroom wall.

This isn't a bad thing. You shouldn't stop reading. While skimming a blog post, you may just come across the truism you need in order to solve the problem you're currently facing. Since we face different problems all the time, we need to be reminded that we should work on our communication skills, or make sure we're prioritizing our time better. (Again, Duh.) We can always improve, and the things we need to improve are all obvious. It's the way you need to improve that can only be figured out by you.

On Leadership

"Leadership" is one of those words that used to make me cringe.  I couldn't see how it could be defined, measured, or taught.  I associated it with being a manager, something I haven't pursued--just like I haven't read Dale Carnegie's How to Win Friends and Influence People.  Becoming a leader, I thought, involved spending time away from the things that interested me most.

But, according to technical management guru Gerald Weinberg, leadership is "the process of creating an environment in which people become empowered."  A leader is someone who helps people solve problems.  It's not necessarily a manager.  The managers in your company might rarely or never be leaders--for example, if they primarily assign mountains of paperwork, engage in political infighting, or micromanage all work.

This is a powerful thought, though obvious once you've had it. A leader cares not only about their own work but helps other people get things done.  Of course, most work today is so dependent upon other people that it would be hard to get anything done without empowering others.  Being an effective leader seems synonymous with being an effective doer.

Weinberg suggests that leaders empower people to solve problems in a number of ways.  One important way is helping people understand problems and possible solutions to them.  Some people are leaders because they're great at getting to the root of a problem and convincing others that they're right.  Or, they can tell you why something you thought was a problem really isn't one.  Or, they come up with solutions that no one else has come up with.

Some of the best insights I got from the book involved interacting with coworkers.  Weinberg has found that attempts to help are often perceived as interference.  This is why it's important to ask whether or not someone needs your help.  I know people who are so eager and so full of ideas that they often cause those they were trying to help to stop listening.  "We're just trying to solve X, and you bring up 10 other things we should be doing!" they're thinking.  Similarly, when you can't understand why someone is acting a certain way, it's often best to assume they're really trying to help you.

There are plenty of nuggets in Weinberg's work, but something I'm going to try to work on is communicating my feelings, something I've never been great with.  Since you can never know how people see you or what they are thinking, your communications should not assume either.  That is, you shouldn't say, "I know you are having trouble completing your work because of issues you're having at home."  Instead, Weinberg suggests beginning with something more like, "I'm feeling frustrated that we're having trouble completing projects on time.  The only thing I can assign my frustration to is your frequent absences.  Is there something we can work out?"  This risks becoming psychobabble akin to "I feel that you feel that I'm feeling you're feeling, etc.", but I'm going to give it a try.