There is a lot of advice here, but the part about hiring seems to me by far the most important. Firstly, it's actionable - it sets a very specific guideline to follow. Secondly, it's crucial for the other things to work. If you don't hire the right people - those that are interested in building whatever you're building, no management voodoo will save you.
I have never found the traditional methods of hiring — resumés, interviews, quizzes — to be helpful at all. Instead, I look at two things: what someone has done and whether I enjoy spending time with them. The first shows not just their talent but also their ability to execute. If they haven't made something interesting, whether as a side project or at a previous job, then they’re probably not worth hiring. It's not that hard to sit down and accomplish something; be wary of people who haven't.
Similarly, you need to keep in mind that you're not just hiring a robot — you're hiring a flesh-and-blood human who you're going to need to spend a lot of time with during the day. That means they need to be someone you not just get along with, but enjoy being around. A formal interview, with all its stress and structure and contrivance, is a pretty bad environment for seeing if you like someone. Instead, just go get coffee and chat.
And also:
there are few things more fun than working hard with a really nice, talented group of people.
I couldn't agree more. If you don't have people that are interested in what they're doing and happy working with the other people that are also doing what they're doing, then you're going to have a weakest link scenario on your hands. The dead weight will be unhappy because they don't like what they're doing, and everyone else will be unhappy because they have to pull the dead weight (and the dead weight is complaining about being pulled!).
I was nodding in agreement at most every point, and then I wondered why there are no citations and whether Aaron has experience successfully using this strategy.
I'm the CTO of a startup and have been VP of Engineering or CTO of others before that. I like the idea of being a servant and working with people smarter than me. Right now I've got a team of 9 people working for me and most of my day is spent dealing with stuff so that they don't have to deal with those things.
Yesterday I did IT rubbish all day, and right now I'm fighting HP over what looks like poor support of multicast IP in one of their access points. These are things that need to get done and it's more effective if I deal with them, than involving the team. They need to get on with the coding.
I'm very happy to be in this position. But perhaps I'm an odd ball.
I fundamentally believe in this idea of "manager as servant."
I agree that "manager as a servant" is a good ideal, but not realistic, but for a different reason. It seems pretty obvious: "manager as a servant" clashes quite a bit with "manager decides who gets [fired|a bonus]", with "manager is usually older/more experienced", and also with "manager gets paid more".
The problem is, that the people who get promoted, don't.
Not in my experience. The place I work, the CTO (a non-coder for quite some time) gets it when it comes to being unassertive, taking all the blame, and none of the credit.
Why can't we go whole-hog on the "manager as servant" direction, then? Content creators hire/fire their managers. Money flows from those actually making it, downward. In tough times, people downsize by firing their boss. You give your manager performance reviews.
Why can't we go whole-hog on the "manager as servant" direction, then?
Who is we? I can't do it because I don't have the experience to run a company. If you do, go start one, and run it any way you like! I would hypothesize that given the median developer, such a company will dive right into the ground. What you need are rock-star developers.
Right now, as far as I can tell, rock star developers become well-paid consultants. It's a matter of supply/demand - junior developers who need their jobs more than their jobs need them are stuck in the corporate hierarchy. Great developers get consulting jobs and consistently charge ~$200/hour or ~$1000/day, pick who they work for, and have the chance to jump ship if they disagree with management. Some have recruiters, who act like agents do in acting/sports, to represent them/help them find work.
As the developer community as a whole gets better, I imagine one way the market could move is towards a "label" model (kind of, but not exactly like the music industry), where groups of developers form consulting firms for legal and business issues. Right now, the value-add of consulting firms is mostly brand and marketing. When a development teams start to demonstrate they are good enough to be recognized for their own brand, the social restructuring will follow.
Another direction the development of "enterprise software" market can move is partnerships - like legal or financial firms do. My wife works for PWC - a private LLP with 155k employees (8,280 partners [1]) and ~$30 billion in revenue. If they can outsource their financial and tax work to a finance firm, I don't see why banks should do tech in-house.
this is how i wish the bank bailout had gone. instead of essentially giving the ceos and other top bosses money, fire those suckers and get some fresh minds in to take responsibility. the government should be investing like an actual investor who wants to get their money back.
It depends on the type of culture. In Japan, if you wanted to address a person you should append "SAN" to their name, irrespective of his position in the hierarchy . SAN is equivalent of SIR in British.
By the way. Did you hear about Orhan Pamuk? He got the Nobel prize in literature 2006? The book called "My Name Is Red". There are much more about project management in his book that in this page. =)
Of course you must be a servant for those, who doing things that you unable to do. Of course, you must forget yourself when you're doing your job. Of course, you must pay respect and attention to the people around you sincerily.
I see. I wonder if this philosophy works at Apple. Do you really think apple products would be better if Steve Jobs always deferred to his staff by saying "you're the expert." Ridiculous. All of this stuff is very situation specific. I am sure that is what he does at Pixar (probably less) and not at all what he does at Apple, and rightly so.
I have never found the traditional methods of hiring — resumés, interviews, quizzes — to be helpful at all. Instead, I look at two things: what someone has done and whether I enjoy spending time with them. The first shows not just their talent but also their ability to execute. If they haven't made something interesting, whether as a side project or at a previous job, then they’re probably not worth hiring. It's not that hard to sit down and accomplish something; be wary of people who haven't.
Similarly, you need to keep in mind that you're not just hiring a robot — you're hiring a flesh-and-blood human who you're going to need to spend a lot of time with during the day. That means they need to be someone you not just get along with, but enjoy being around. A formal interview, with all its stress and structure and contrivance, is a pretty bad environment for seeing if you like someone. Instead, just go get coffee and chat.
And also:
there are few things more fun than working hard with a really nice, talented group of people.