Skip to content

Comment on The Management Team - Guest Post From Joel Spolsky

Comments

The saddest thing about the Steve Jobs hagiography is all the young “incubator twerps” strutting around Mountain View deliberately cultivating their worst personality traits because they imagine that’s what made Steve Jobs a design genius. Cum hoc ergo propter hoc, young twerp.

I loved the swipe at the fake Steve Jobs's out there. I worked for one, although he wasn't young and it wasn't in Mountain View. He would cite Steve Jobs to defend defective practices. It was ridiculous.

It's a great essay, and I like Spolsky's management philosophy a lot, but I don't entirely agree. A business isn't academia. Businesses have to ship products and please their customers, and leaving these tasks to "the crowd" doesn't work. "The crowd", when we're talking about software engineers, produces brilliant chaos. That's great sometimes, and it can produce excellent products, but it's not good when you need focus or to meet a ship date. Sometimes a CEO or CTO needs to decide what gets worked on, how people do it, and to motivate people to make sure it happens.

Likewise, sometimes a leader needs to step in and resolve bike-shedding conflicts among two equally smart, strongly opinionated engineers who disagree on a core question, and to look for a compromise. "Management fiat" shouldn't be used lightly, but it's not without purpose.

That said, I think Spolsky deserves a lot of props for pointing out that the managerial relationship is two-sided. A lot of companies and bosses don't figure this out until they face uncontrollable talent bleed, and even then there's a lot of self-deception (I've known some ineffective managers to become bitter about their best reports "abandoning" them, as if it were some ethical lapse, but never to own up to their role).

"Likewise, sometimes a leader needs to step in and resolve bike-shedding conflicts among two equally smart, strongly opinionated engineers who disagree on a core question, and to look for a compromise."

The most effective people I worked for didn't try to dictate the solution to the conflict. They were effective at moving the disagreeing engineers past their conflict. Dictating a solution was always the last resort if the engineers had just "dug in their heals" instead of discussing rationally.

> The most effective people that I worked for didn't try to dictate the solution to the conflict

About China's presumptive next leader, Xi Jinping

His subtle and pragmatic style was seen in the way he handled a landmark power project teetering on the edge of failure in 2002, when he was governor of Fujian, a coastal province. The American company Bechtel and other foreign investors had poured in nearly $700 million. But the investors became mired in a dispute with planning officials.

After ducking foreign executives’ repeated requests for a meeting, Mr. Xi agreed to chat one night in the governor’s compound with an American business consultant on the project whose father had befriended Mr. Xi’s father in the 1940s.

Mr. Xi explained that he could not interfere in a dispute involving other powerful officials. But he showed that he knew the project intimately and supported it, promising to meet the investors “after the two sides have reached an agreement.” That spurred a compromise that allowed the power plant to begin operating.

“I thought, ‘This person is a brilliant politician,’ ” said the consultant, Sidney Rittenberg Jr.

> http://www.nytimes.com/2011/01/24/world/asia/24leader.html

I think Spolsky would agree. And my style is similar to his - Management Fiat is not the way to go, but it is my job to help ask the right questions to move the disagreeing engineers to find the right solution. Sometimes all it takes is having the two folks explain their positions, a la rubber-ducky-debugging (http://en.wikipedia.org/wiki/Rubber_duck_debugging)

I've chatted with a few potential cofounders over the past several months who have exhibited these traits - the arrogance, the condescension, the overall shady attitude. It's exhausting trying to explain to people that they are not Steve Jobs (also, that The Social Network is not indicative of how things actually work out here).

They might be the next Steve Jobs. You do not know that. Our culture handicaps a lot of people by promoting mediocrity and conformity and groupthink and putting artificial walls and ceilings around what a person is expected to do, nothing more or less.

Yes, and I might win the lottery, ergo I should spend all my money on lottery tickets.

Could Steve Jobs have been even more effective if he wasn't, in Spolsky's words, "a dictatorial, autocratic asshole who ruled by fiat and fear"?

It's possible. I know quite a few very talented ex-Apple engineers that left because they felt the environment was oppressive and stifling. Was Apple a better place without them?

I don't know. Jobs was crazy successful at what he did, but there's nothing in that to suggest that it was for the most visible reasons.

I agree.

Administration is part of what management do but it's a little demeaning to suggest that it's all that they do. Done right it should be closer to enabling and informing.

But I'll take it that it's a slightly exaggerated position to make people think about things differently which is fine.

Your word choices of 'enabling' and 'informing' suggest that the manager inherently has holds concentrated power and information and must dole it out where appropriate. That implicitly makes the manager a bottleneck.

Indeed, the word 'management' itself connotes a perspective incompatible with Joel's philosophy.

By enabling I mean the act of creating an environment that enables people to do good work. I've always like the metaphor that a project is like a truck and the role of the project manager is to keep the road clear. That's what I mean by enabling.

In terms of informing, I wasn't wild about the word but couldn't find anything better quickly. Where I was coming from is that in many cases developers and technicians don't have knowledge of the market, don't have much interest in liaising directly with customers and so on. That information should be fed back into the team and customers and others outside the technical team should have a voice which is another function one of the manager should provide.

I've always seen management in an ideal world as a peer role with different responsibilities.

If it's a core question, it's not "bike shedding." If the problem is really bike shedding, a good leader will get both sides to realize they're being ridiculous and wasting everyone's time over something trivial.

Yes, I wanted to write something similar. There needs to be someone with a vision of the 'whole thing'. The guy who steps in and tells the marketing guys that no, they can't add one more feature, or the hackers that no, they don't really need to implement their own database system, or whatever other things people get 'tunnel vision' about when not thinking about the company as a whole. Sure, in a good startup, everyone does keep that vision in mind, but it's good to have someone to adjudicate conflicts in a more or less impartial way, and set the general direction.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.