Organizational behavior 101?

I used to think studying organizational behavior and management was all bullshit. A bunch of guys sitting in the ivory tower thinking they know how to run a multinational? What a crock. But the more I work the more I realize how important organization--loosely defined as in how you organize people, structure reporting, allocate time, reward & punish behavior, etc--is. I'm still not convinced of the value of sitting in an undergrad class with 200 other people to read a 800pg textbook on organizational behavior. It just doesn't strike me as something you can learn in a classroom. Without lots and lots of work experience, you just won't understand. And even if you do, each situation is highly unique and nuanced, and once you abstracted it into a case study it just seems to lose the subtleties that make org problems difficult.

At any rate, now I am quite convinced that how you organize a group of people, has a huge effect on how productive they will be. Unfortunately, I haven't figured out a way to quickly become good at it.

Exhibit #1 -

Suppose you are the country PM for country X. you have been charged, ultimately, to win this market (let's use search market share), where you're currently getting your butt kicked. You need to convince engineering with your the overall strategy and product roadmap, deliver the products, and hopefully win lots of users. Suppose now also that your engineering office in X also opened recently, so you've now scoured the country for a bunch of top-notch engineers, all eager and excited because they want a chance to work at G.

Great, since a technology company absolutely have to hire the best damn engineers, you're off to a good start. No argument about that. But brilliant engineers don't necessarily sign up to crush some competitor or win a market. Few smart people join IBM thinking, "Gee, I'd really like to help Big Blue crush Microsoft or Sun or Oracle today." Smart, talented engineers join a company usually because they want to solve really challenging problems, enjoy the environment, want freedom and resources to pursue what excites them, and in general try to build cool shit.

Now you have a dilemma. You know (or think you know) what you have to do to win. Build product X, partner with Y, syndicate Z, improve infrastructure W, on and on. But the engineers may not at all be interested in X, Y, Z or W. Maybe your most talented UI engineer happens to
really get off on tweaking the subtleties of image search. But you just know that working on image search is useless for winning traffic right now, doesn't move the needle. What do you do? You can't force great engineers to do what they don't want to do; it'll be a disaster. At the same time, having him work on low-priority projects is just waste of talent. And maybe he's not the only one. Maybe some other senior engineers all want to work on a different skunkworks project, because they've all vested, and now only want to work on some pet projects.

So out of an office of maybe 15 engineers, you might only be able to convince half to really put their hearts into what you need to do to win. That's 50% efficiency, a terrible waste of eng talent and time. At the same time, you can't throw rank and ask the eng director to just crack that whip and get everyone in line; it might work elsewhere, but not at G. And even if it works, it would ruin the team culture and camaderie, so that option is out.

So, how do you reconcile the two? The easy answer might be, "Oh well, just find what people are interested in, and define Y projects in such a way that each person finds what they're looking for. So you can have your cake and eat it too." I think that works up to a certain extent, but it's not so easy, since it's kind of like sanding a square hold to fit a round peg. You can kind of do it, but it's not optimal. I think engineers are most motivated and productive when they find something they are really passionate and inspired about, not when you retro-fit a project to match their needs. You don't have as much of this problem at startups, since they are usually self-selective; people who don't identify w/ a startup's mission usually don't join it, unless there's a good chance of a good exit. And you can screen people out based on their stated interests. But in the case of G, where we're just trying to hire the damn smartest people we can find, it's not like we screen people based on their passions, especially in a remote office. In fact, we're known for only interviewing for ability, rather than work history or interest.

So what exactly do I do then? I need to win the market. But I also need to build a high performing, happy, and inspired eng team. How do I make the two work? I don't have a good answer for this, and I'm thinking about it every day. Comparatively, writing specs weren't all that hard...

Now I understand why good managers certainly earn their pay.