Facebook VP of Engineering on Solving Hard Things Early(firstround.com)
firstround.com
Facebook VP of Engineering on Solving Hard Things Early
http://firstround.com/article/Facebook-VP-of-Engineering-on-Solving-Hard-Things-Early
7 comments
Colour me disappointed. It's like the last 50 years of management and organizational research never existed.
Peter Drucker is rolling in his grave right now. Great marketing for first round, though.
Peter Drucker is rolling in his grave right now. Great marketing for first round, though.
Isn't that one of his points? Quoting the article: "Every early stage company thinks it has reinvented management."
If I understand him correctly this means that we should look back at prior research of management and draw inspiration from that instead of "reinventing management".
If I understand him correctly this means that we should look back at prior research of management and draw inspiration from that instead of "reinventing management".
I don't get this response or AznHisoka's - this seems like fantastic advice on how to build a startup. It's the team that is going to solve the biggest, most interesting problems that are harder than one person, and being able to pull together that group and make them happy and effective is hugely difficult.
Management is the first hard thing that is easy to get right early.
This is very true. I've seen a lot of very talented engineers struggle without management. The "I don't enter timesheets, and I work on my own problems because I'm a damn good engineer" mindset didn't scale when the upper management didn't know how long things too to do, and couldn't agree on or document priorities.
Despite the emphasis on "We don't have managers", management is needed. It's as simple as rules of behavior.
This is very true. I've seen a lot of very talented engineers struggle without management. The "I don't enter timesheets, and I work on my own problems because I'm a damn good engineer" mindset didn't scale when the upper management didn't know how long things too to do, and couldn't agree on or document priorities.
Despite the emphasis on "We don't have managers", management is needed. It's as simple as rules of behavior.
Disappointed. Thought it was about solving hard technical problems first, not cultural. Figuring out how to crawl 100 million pages a day is certainly, etc. Rather than how to establish a good culture. Managing 20+ ppl is a GOOD problem to have b/c it means u most likely raised lots of funding, or got tons of revenue already.
You don't really need to solve the hard technical problems until you've raised money or have revenue, either.
That's why programmers are second-class citizens in the VC-funded startup world. Business guys want you to think that technical talent is important (at least, until you ask for money or equity) but they get away with treating it as a commodity because they can always back-fill (or, at least, think they can) with more expensive and skilled people later on.
The bottleneck is the connections to raise money. Connections don't guarantee funding (far from it) but ensure that, if you're rejected, the investors will (a) mentor you until you have something they will fund, and (b) use their network to find other opportunities for you, should the startup not work out. That makes the founders free of the personal financial panic under which it's actually extraordinarily difficult (if not impossible) to be technically creative.
That's why programmers are second-class citizens in the VC-funded startup world. Business guys want you to think that technical talent is important (at least, until you ask for money or equity) but they get away with treating it as a commodity because they can always back-fill (or, at least, think they can) with more expensive and skilled people later on.
The bottleneck is the connections to raise money. Connections don't guarantee funding (far from it) but ensure that, if you're rejected, the investors will (a) mentor you until you have something they will fund, and (b) use their network to find other opportunities for you, should the startup not work out. That makes the founders free of the personal financial panic under which it's actually extraordinarily difficult (if not impossible) to be technically creative.
Where is your data that programmers are second class citizens in the VC funded startup world? That may have been true a decade ago, but one would be hard pressed to argue that now, especially in light of the NVCA's own data.
The irony of posting that baseless assertion on Hacker News is also not lost on me.
The irony of posting that baseless assertion on Hacker News is also not lost on me.
To solve the hard technical problems later you have to solve the hard cultural problems now
Because the initial culture is how the company will grow. If there isn't a strong culture, they will hire a bunch of "specialists" that think scaling means porting to Java and using lots of XML
Because the initial culture is how the company will grow. If there isn't a strong culture, they will hire a bunch of "specialists" that think scaling means porting to Java and using lots of XML
> Describe culture in ways that make people think and debate rather than universally agree.
Great point. As Ben Horowitz compares Square with Amazon, you wouldn't be sitting at a desk made of a door since Square highly values design and Amazon highly values frugality. Also, I can only imagine the discussions at Facebook with the focus on taking huge risk for the sake of innovating.
I guess his sentence also applies to people you would hire - everybody would universally like certain things about a culture, but if you're more risk-averse, I guess you wouldn't fit in as well at FB.
Great point. As Ben Horowitz compares Square with Amazon, you wouldn't be sitting at a desk made of a door since Square highly values design and Amazon highly values frugality. Also, I can only imagine the discussions at Facebook with the focus on taking huge risk for the sake of innovating.
I guess his sentence also applies to people you would hire - everybody would universally like certain things about a culture, but if you're more risk-averse, I guess you wouldn't fit in as well at FB.
I was afraid that this was going to be a post on solving hard technical things early. Which is a terrible idea, because it's basically making large bets on your future direction before you have any data about where you're going.
But this is actually pretty sensible. People learn culture mostly by osmosis, and the bigger you are, the harder culture is to change. If your organization is kinda screwed up at 5 people, it's reasonable to bet that growth will magnify the problems, making it pretty screwed up at 25, and a big ol' mess once you cross Dunbar's number at around 125.
But this is actually pretty sensible. People learn culture mostly by osmosis, and the bigger you are, the harder culture is to change. If your organization is kinda screwed up at 5 people, it's reasonable to bet that growth will magnify the problems, making it pretty screwed up at 25, and a big ol' mess once you cross Dunbar's number at around 125.
You're right, but people are going to take it wrong.
If you're a startup, tackling a huge problem that you don't know how to solve is very likely to lead to failure. You are correct in that.
But let's say you're starting a project. The technical part of the project is mostly straitforward, but there's this one part that you're not really sure anybody knows how to do. You'd better do that part earlier rather than later, or figure out a way where you don't have to do it. Find out how big the problem is when you still have time to do something about it. Find out if it will kill your project before you do a bunch of work that will be wasted because you can't solve the hard part.
If you're a startup, tackling a huge problem that you don't know how to solve is very likely to lead to failure. You are correct in that.
But let's say you're starting a project. The technical part of the project is mostly straitforward, but there's this one part that you're not really sure anybody knows how to do. You'd better do that part earlier rather than later, or figure out a way where you don't have to do it. Find out how big the problem is when you still have time to do something about it. Find out if it will kill your project before you do a bunch of work that will be wasted because you can't solve the hard part.
I think these are both aspects of risk reduction. When you say "a project", I think you're saying, "Assume the business problems are solved." In which case, yes, technical risk is next. Startups too are faced with technical risk. But there's no point in solving technical problems until you have reasonable proof that doing so is worth your time.
hiphopvm is an incredible example of his logic at work
> Describe culture in ways that make people think and debate rather than universally agree.
Very subtle and probably pretty important. Facebook's cultural values were constantly under debate and if nothing else it made every employee consider them.
> We gathered together for end-of-week whiteboard sessions where we listed our most critical open tasks.
This is a neat idea. We do high-level daily syncs here, but this might be a neat way to help build accountability and inspire more collaboration on tasks.