Hacker News new | ask | show | jobs
by coffeemug 4696 days ago
I don't know the person or the YC company in question, and I realize I'm nitpicking, but these three things stuck out at me.

> I wanted to have a significant impact so I was constantly asking the founders to work on the long-term vision and culture for the company.

Anybody could waste months and months working on the long-term vision and culture. In a startup, that's next to useless as everyone should contribute to the long term vision. It's the day-to-day that's important.

> I also told them that VCs invested in talent and not the idea.

VCs invest in traction. "I come from a state that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I am from Missouri. You have got to show me."

> The leadership was struggling with the vision of the company. It was pulled in many directions - sometimes ad-hoc based on customer feedback or angel advice.

That's what an early startup is -- figuring out product/market fit, largely based on ad-hoc decision making like this. Picking a vision that just works is incredibly rare.

I know dozens of YC founders and in my experience they're really good at what they do, but you can't expect to stumble on Elon Musk, Jeff Bezos, or Evan Williams by joining a random YC company. There are probably less then a dozen people of this quality in the entire world, and YC invests in ~60 companies per batch for god's sakes!

EDIT. And also:

> The culture was bad. Engineers were constantly told what to do.

Engineers should be told what to do (but hopefully not how to do it). Being good at engineering doesn't in any way qualify you for being good at managing product.

EDIT2:

> Then another round of raising Series A started. The “nos" started piling up. Our last hope said “no" 2 weeks back.

Of course the nos started piling up. Having a few rejections is nothing, we went through ~60 rejections before raising the first round for our company.

Excellence in the absence of pressure wins you no accolades. How you act when the house is burning down is what ultimately defines who you are. It's cool if the guy wanted to leave because this kind of pressure isn't for everyone (and that's fine), but blaming two measly rejections on others is off-putting. It's easy to blame failure on others, much harder to take responsibility for it yourself and help turn a dire situation into a victory.

10 comments

> Being good at engineering doesn't in any way qualify you for being good at building products.

Being good at engineering is exactly being good at building products, whether its civil engineering and the product is a bridge, or software engineering and the product is an application.

Being good at engineering may not be the same as being good at deciding what the product should be, but no one should mistake "deciding what the product should be" with "building the product".

Agreed. I see many people that aren't that good at anything concrete and just sell themselves as "good at building products". If an engineer is not qualified to build a software (the product), who is?

I get that not everyone is cut for figuring out markets, sales, etc. But this crap about "you're only an engineer, you have no clue how to make a product" is a blatant lie.

Good engineers are all about the product. Coding is just part of it. The assumption about people that don't graduate in business can't create businesses is just pure ignorance.

You're right. I meant to say "being good at engineering doesn't qualify you for managing product". I fixed that sentence.
Gahh, this sentiment from product managers drives me nuts. IMO you will never have the best engineers work for you, because the best are very good at making product decisions / knowing the business in addition to excellent engineering skills.

To me this is the single most differentiating philosophy between great product managers and very mediocre ones.

The statement was:

> "being good at engineering doesn't qualify you for managing product"

Which is demonstrably true. They're two different skillsets. If we reversed the statement:

> being good at product management doesn't qualify you for engineering

We could also agree on that statement. That doesn't mean that there aren't engineers who are/could be kickass product managers, and it doesn't mean that there aren't product managers who could sit down and build the application.

But they're two different roles. Product managers are supposed to identify problems, design requirements, provide engineering with clear context and business data to help inform the priority, and then engineering should get to, based on that information, build the best solution.

Knowing what's needed and knowing what customers will actually buy is two different things...
I'll take it one step further and say being really good at engineering means you don't need anyone else managing product
The link you provide is interesting, though I think a big factor that it overlooks (that supports the same trend against the value of traditional management) is lean methods, which (while they are now applied other places) really emerged out of the most concave work (routinized production) and while they demand a certain amount of management in the traditional sense, narrow and focus the scope of management (and, in essence, make it more technical) while providing more involvement of line workers in substantive decision making.

Traditional management isn't just becoming less relevant because of "convex work", its become less relevant because it is an outdated social technology even for concave work, for which more-efficient replacements have been developed in the last several decades.

but no one should mistake "deciding what the product should be" with "building the product".

At particularly early stage startups, it not unheard of the developer having a decent say on what product to build. But it largely depends on company to company.

Regarding the author's original intent let's be honest: we simply don't have enough information to go on.
> you can't expect to stumble on Elon Musk, Jeff Bezos, or Evan Williams by joining a random YC company. There are probably less then a dozen people of this quality in the entire world

Adding nitpicking over nitpicking, this sentence do not mean anything. There is only one guy with the same quality as Jeff Bezos in the world, it's him. And you can say the same for anyone else. If you were talking about capability, then I assure you there are hundred of thousands Bezos (or Jobs) in the world. The old lady picking empty bottles in my street (Beijing), she might have gone through much harder time, have shown much more resilience, and have all the courage and strength of hundreds of Bezos. Given another life who can say right now she would not have been very capable of running a successful multinational?

Since I read Kahneman I reject this exceptionalism which is good for aiport books. A big boss has at most 30pc influence on the trajectory of the company.

It definitely feels like much of this post is presented in an overly negative perspective aimed at the startup, when in fact some of this may have come down to the employee not realizing what working for an early stage company entails, namely how haphazard some parts of it may be. It all looked so good when there's a sunny house full of co-eds smoking pot in The Social Network...
Sometimes I wonder whether someone's split-testing their article, because it seems like you're getting a completely different one.

Right before the 'significant impact' sentence is this one:

    One of the first things I did was steer the company
    in the right direction from a strategy perspective. 
    I constantly butted head with one of the founders 
    but my strategies were clearly impacting the revenue 
    numbers. For example one of the tactics doubled the 
    weekly revenue.
Seems pretty day-to-day to me. He's apparently in there as some sort of product manager / biz dev guy, but somehow you have the impression that he's a wet behind the ears engineer.
How should a PM/biz-dev guy handle this type of situation?

I'm curious how much do PMs really do push backs and shielding for the development teams and to what extent are they just taking marching orders from upper management.

It depends on the specific company and politics, but I'm guessing for me personally, if I was a PM, I put in the work to get into lowest rung of management. I make more than a engineer but not in a worker-bee role anymore so I'm pretty expendable. So I'm going to look out for my own self preservation first with upper management. Some engineers have combative attitudes and analytical view on creating business value without taking into consideration of expending political capital to get things down and massaging people's egos. Sounds like this guy is approaching a social game with still a programmer's mentality. PMs, please feel free to chime in how you pick your battles and push back with upper management correctly.

I'll offer my take on it, as a recovering software engineer who moved over to the product side. The first thing you have to learn is that nobody works for you--you can't tell anyone what to do. You have to persuade and convince. Both upward to your bosses and across to engineering, marketing, user experience, finance, QA, customer support, ops, everyone. You've got to get them to buy them into taking the product in the direction it needs to go. You have to be the buffer. You've got to shield your team from all the "churn" and "swirl" and indecision coming down from the execs, whilst shielding the execs from the day-to-day chaos, the bug firehose, and software design debates that are always part of major development projects.

And yea, you're seen as much more expendable than the engineers since you're not writing the actual code, so you have to play a little politics (the better the company, the less of that game you have to play). When a bad idea comes down from up top, you have to push back. You can't put all the CEO's product ideas on the fast track, as tempting as it is. Ever since that goddamned Steve Jobs book came out, every senior exec in the Valley thinks they're some kind of product visionary. You've got to have the judgment to marginalize and stall the bad ideas and go all-in on the good ideas--work with engineering to make them awesome.

But once in a while, something's gonna get rammed into the product over your objection, and it's going to suck. You just have to deal with it. Make sure when it's released it "sucks less". Make sure there are analytics all over it so in a few weeks/months you can point to hard numbers showing how much it sucks, and hopefully the product can pivot away from it.

I agree with you that PMs have to use charisma and influence to get things done, but I completely and utterly disagree that they are more "expendable." A good, certified, educated and experienced PM is worth a dozen engineers. You can find engineering talent almost anywhere - but good managers are a diamond in the rough.

I've been a PM for about a half decade now, and was previously a software engineer for some big name companies. I'm telling you, PMs, if they know what they are doing and are educated properly, are worth their weight in gold - because writing code can be outsourced, management can't.

Maybe it's different in Silicon Valley (which would explain a lot of the risk-taking, lax attitudes and failure rates of startups), but the rest of the country is the opposite of what you describe as the "expendable" PM.

Wow, it's so refreshing for me to read your post, thank you!

Unfortunately in my experience (on both ENG and QA sides), PMs only serve to try and fuck you over or overload your "plate" in one of dozens delicious ways. I'm desperately trying to avoid having my experience color the rest of my perceptions (and interactions) with PM, but it's a losing battle. It's becoming all the more easier to just say "fuck PMs" and be done with it :(

> Engineers were constantly told what to do.

I read this in the original article and thought "so it wasn't all bad"

The BIG POINTs of his whole article were that

1. He was sold on promises, hindsight is 20/20

You make your points with the hindsight of having actually been in that position. The OP made the clear point that he's coming from a stable Job, and the expectations outlined to him when he was hired were different form those he experienced.

2. The Article is meant to educate those who don't know 1

He was HIRED as an EMPLOYEE. The whole issue feels like a testament to how bad startups are at employing people.

> Engineers should be told what to do.

It depends, no engineer wants to be micro-managed.

Direction is being told what to do; micromanagement is being told how to do it.
Micro-managed depends on the level of detail of the "what". Engineers should be given high level directives but should be autonomous to execute them. I guess especially in a startup context where there is so much to do with too few ressources.
> Anybody could waste months and months working on the long-term vision and culture. In a startup, that's next to useless as everyone should contribute to the long term vision. It's the day-to-day that's important.

Months and months for culture? I've spent the better part of a decade and multiple companies trying to perfect the perfect culture startup culture. Not having a vision for the culture of a startup is, in my experience, plain crazy for the mid-to-long term health of the company.

Not having a long-term vision for the company itself also seems crazy for any of the founders. I always have a long-term vision. It usually overlaps heavily with my other founders. It changes when it is clearly the wrong path, but then we come up with a new vision and it certainly doesn't take months to develop. Sure, you take input from the team to smooth out the rough spots, but it is the job of the founders to be the genesis.

For goodness sakes, the center of my pitch when raising VC money is getting people to buy into the long-term vision. I use the long-term vision to hire employees. I use it on early customers. I can't imagine not having one.

> That's what an early startup is -- figuring out product/market fit, largely based on ad-hoc decision making like this. Picking a vision that just works is incredibly rare.

It is not normal to scrap your product every time an investor suggests something different. That way be dragons. Every time you pivot, you have to have a rationale for doing so. It certainly isn't willy nilly ad-hoc decision making. Pivoting is a deliberate act. It involves developing vision for where the company will go, who the customer is and why they would use your product. You don't just take a random stab in the dark every time you try to get user adoption and don't immediately see 100 million users. And on angel money, you certainly don't have the runway to pivot more than a couple times.

Looks like he deleted his post but here's the cache: http://webcache.googleusercontent.com/search?q=cache:http://...
> Being good at engineering doesn't in any way qualify you for being good at managing product.

You must be talking about the Google style engineering.