I stumbled onto a post about pairing designers and developers and it got me thinking: why stop there? Is that the only important pair of competencies?

Of course not.

Any two people with different responsibilities and backgrounds can be interesting when they sit next to each other.

I just have one tip you need to remember, all the time, when working with other types of people: learn how their shit works.

I know it’s a big thing to ask, and you’re not getting paid any extra for it — and god forbid you might have to think for a few minutes — but hear me out!

Put your ears where their money is.

Any time any part of someone else’s work touches any part of your work, ask them how it works. Why is it like that? What are the alternatives? What makes that approach so good? What’s the theory or the strategy?

The obvious example is designers and developers learning from each other, but talk to the business development people, or the sales guys, or the accountants, or the consultants, or your client’s personal assistant.

Find out what they control, and ask about how it works.

Ask them what their clients ask for. Ask them what their biggest problem is. If they could change anything about their job to make it easier, what would it be? Is it easier if your invoice is in dollars or euros? Why?

You’d be amazed how soon you will start seeing opportunities to connect two parts of the business that nobody ever cared to ask about. And you’ll be double-rainbow-amazed how often you spot people trying to fake some expertise, because you actually know.

It is not uncommon for me to work on projects where I meet with the sales team about product packaging, the biz dev team about pricing, the tech team about development schedules, the executives about the 5-year plan, and the designers about layouts all in the same week.

What is a bit uncommon is to talk to the sales team about how the layout team can create products that are easier to sell. Or with the biz dev team about how they can make more money by adding free features or fewer products. Or talk to the designers about how their style choices are effecting the dev team’s work load. Or to design information architecture that will make it easier to switch strategies next year when the industry shifts.

So learn how shit works. I promise you’ll thank me someday. And I promise that other people will thank you.