3 ms·

This post comes from the experience of several brutal multi-year engineering projects at Google that, in retrospect, I wonder "why didn't anyone criticize the i

This post comes from the experience of several brutal multi-year engineering projects at Google that, in retrospect, I wonder "why didn't anyone criticize the idiotic decisions that I was making?!". Along the way, I was making "good software engineering" decisions but very poor product decisions: specifically, the biggest risk to the project wasn't that the code was poor but rather that no one would want the thing that I had set out to build. I find that unless you're diligent about incremental validation, time on engineering projects is usually wasted on the scale of years by creating a beautiful castle that no one wants to live in. I now see that my project was a lot more like a little startup: by finding resources about how to make a startup go, I could have saved a lot of trouble. By taking this path, you still end up with a lot of waste (rewriting fast, poor versions of features to be better), but you're able to course correct earlier and have a lot better chance at the overall project being a success.

projectramo 4y ago
If that’s what prompted this I can see why you recommend videos. It’s the #1 recommendation for any startup advice source. But … you must have come across it before. What made you not pursue it? ie why was it a blind spot?
- zeptonaut22 4y ago
  Basically, I mistakenly thought "I'm working at Google, not a startup: this advice isn't relevant to me". What I didn't realize was that the startup world has lots and lots of info for figuring out how to build new things that matter while minimizing waste. Beyond senior SWE at most FAANG companies, you have to start thinking about how much your work matters as opposed to just how complex of projects you're able to handle. It was the "...that matter" suffix that really blindsided me, and I focused too much on "becoming a better SWE" through better coding, more interviews, etc. instead of building up the entirely new skillsets of things like customer discovery, soliciting customer feedback, etc.
uoaei 4y ago
> I now see that my project was a lot more like a little startup: by finding resources about how to make a startup go, I could have saved a lot of trouble. Google advertises the workplace to their employees explicitly as: 10.000 startups under one roof. I think that kind of structure was always the intention. It sounds like your managers/leaders didn't have a good way to convey those kinds of values.
- majormajor 4y ago
  From the ex-Google-in-the-last-five-years people I've talked to, it's very hard to truly operate that way when you have Google resources at your disposal. And the hardest-to-account-for of those resources is the credibility and marketing, since it's the furthest away from what engineers do day to day. For every project that we see that Google shuts down recently, we probably wouldn't have even heard about them if they were truly operating like a startup with startup resources. The projects were never good enough to get traction organically without that initial Google-name-bump or bundling when it was released publicly. Would any of their messaging apps in the past half decade had ever made a dent in the first place outside of the Google umbrella? Would anyone have tried to do Stadia independently (Quibi says "maybe" but in that case the massive capital gamble and poor return was much more obvious as a standalone enterprise, so it got abandoned much more quickly, even)? If you take "I'll have the chance to get this in front of customers" [because Google] for granted, it's very easy to get lost in a sea of "try to make it the perfect version of itself" instead of "what is the differentiator and unique need this is addressing?"
smugglerFlynn 4y ago
In my experience, this startup mentality works well not only for corporate projects / products, but also for orienting a team inside the organisation. Accepting that any team is actually a tiny business of its own helps to quickly orient around key stakeholders, get reality check that you actually contribute anything to the org, and cut down unnecessary activities. Importantly, all the startup tools like CustDev[0] techniques, Lean Canvas[1] and many applicable others are already there, built and tested by startup community over the years. 0 - The Mom Test by Rob Fitzpatrick is a good entry point https://www.amazon.com/Mom-Test-customers-business-everyone-ebook/dp/B01H4G2J1U/ https://www.amazon.com/Mom-Test-customers-business-everyone-... 1 - https://medium.com/@steve_mullen/an-introduction-to-lean-canvas-5c17c469d3e0 https://medium.com/@steve_mullen/an-introduction-to-lean-can...
jfengel 4y ago
From my experience, people probably did criticize those decisions, and you had excellent answers to them. It's really hard to know if the dog will eat the dog food until the dog food is ready to be served. You can try to extrapolate from early tests, but they'll seem promising, and you'll attribute hesitations to problems that aren't fixed yet. It'll all be obvious in retrospect, but no amount of criticism at the time will help you distinguish between a doomed project and the next Facebook. All of that self-help stuff telling you do dare bold dreams or whatever covers up the fact that the vast majority of them fail, and you only hear from the bias of the survivors. All I can offer you is this: Google has the resources to survive many failed projects, because the one that doesn't earns it plenty of money. That doesn't help at startups: only the VCs have the scale to survive 9 failures for the big success. But you, the project manager and employee, got paid for a few years building stuff... and you can consider yourselves part of the overall enterprise that produced one success.
preommr 4y ago
> the biggest risk to the project wasn't that the code was poor but rather that no one would want the thing that I had set out to build. Except for deliberately bad ideas, this is almost never true. There's always at least one other person that would find value in something someone is putting effort into building. What people actually mean to say is that the cost is higher than any realistic plans to monetize a project. A project where someone could make 30-40k per year in a country with a low cost of living would be a complete success for an individual where they get complete autonomy, job security, good work life balance, working remotely. But that same project would be a complete disaster for Google where that employee alone costs 4-5x in pure cash let alone stocks.

projectramo 4y ago

If that’s what prompted this I can see why you recommend videos. It’s the #1 recommendation for any startup advice source. But … you must have come across it before. What made you not pursue it? ie why was it a blind spot?

zeptonaut22 4y ago
Basically, I mistakenly thought "I'm working at Google, not a startup: this advice isn't relevant to me". What I didn't realize was that the startup world has lots and lots of info for figuring out how to build new things that matter while minimizing waste. Beyond senior SWE at most FAANG companies, you have to start thinking about how much your work matters as opposed to just how complex of projects you're able to handle. It was the "...that matter" suffix that really blindsided me, and I focused too much on "becoming a better SWE" through better coding, more interviews, etc. instead of building up the entirely new skillsets of things like customer discovery, soliciting customer feedback, etc.

uoaei 4y ago

> I now see that my project was a lot more like a little startup: by finding resources about how to make a startup go, I could have saved a lot of trouble. Google advertises the workplace to their employees explicitly as: 10.000 startups under one roof. I think that kind of structure was always the intention. It sounds like your managers/leaders didn't have a good way to convey those kinds of values.

majormajor 4y ago
From the ex-Google-in-the-last-five-years people I've talked to, it's very hard to truly operate that way when you have Google resources at your disposal. And the hardest-to-account-for of those resources is the credibility and marketing, since it's the furthest away from what engineers do day to day. For every project that we see that Google shuts down recently, we probably wouldn't have even heard about them if they were truly operating like a startup with startup resources. The projects were never good enough to get traction organically without that initial Google-name-bump or bundling when it was released publicly. Would any of their messaging apps in the past half decade had ever made a dent in the first place outside of the Google umbrella? Would anyone have tried to do Stadia independently (Quibi says "maybe" but in that case the massive capital gamble and poor return was much more obvious as a standalone enterprise, so it got abandoned much more quickly, even)? If you take "I'll have the chance to get this in front of customers" [because Google] for granted, it's very easy to get lost in a sea of "try to make it the perfect version of itself" instead of "what is the differentiator and unique need this is addressing?"

smugglerFlynn 4y ago

In my experience, this startup mentality works well not only for corporate projects / products, but also for orienting a team inside the organisation. Accepting that any team is actually a tiny business of its own helps to quickly orient around key stakeholders, get reality check that you actually contribute anything to the org, and cut down unnecessary activities. Importantly, all the startup tools like CustDev[0] techniques, Lean Canvas[1] and many applicable others are already there, built and tested by startup community over the years. 0 - The Mom Test by Rob Fitzpatrick is a good entry point https://www.amazon.com/Mom-Test-customers-business-everyone-ebook/dp/B01H4G2J1U/ https://www.amazon.com/Mom-Test-customers-business-everyone-... 1 - https://medium.com/@steve_mullen/an-introduction-to-lean-canvas-5c17c469d3e0 https://medium.com/@steve_mullen/an-introduction-to-lean-can...

jfengel 4y ago

From my experience, people probably did criticize those decisions, and you had excellent answers to them. It's really hard to know if the dog will eat the dog food until the dog food is ready to be served. You can try to extrapolate from early tests, but they'll seem promising, and you'll attribute hesitations to problems that aren't fixed yet. It'll all be obvious in retrospect, but no amount of criticism at the time will help you distinguish between a doomed project and the next Facebook. All of that self-help stuff telling you do dare bold dreams or whatever covers up the fact that the vast majority of them fail, and you only hear from the bias of the survivors. All I can offer you is this: Google has the resources to survive many failed projects, because the one that doesn't earns it plenty of money. That doesn't help at startups: only the VCs have the scale to survive 9 failures for the big success. But you, the project manager and employee, got paid for a few years building stuff... and you can consider yourselves part of the overall enterprise that produced one success.

preommr 4y ago

> the biggest risk to the project wasn't that the code was poor but rather that no one would want the thing that I had set out to build. Except for deliberately bad ideas, this is almost never true. There's always at least one other person that would find value in something someone is putting effort into building. What people actually mean to say is that the cost is higher than any realistic plans to monetize a project. A project where someone could make 30-40k per year in a country with a low cost of living would be a complete success for an individual where they get complete autonomy, job security, good work life balance, working remotely. But that same project would be a complete disaster for Google where that employee alone costs 4-5x in pure cash let alone stocks.