How to find your blind spots
zeptonaut.com
zeptonaut.com
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.
But … you must have come across it before. What made you not pursue it? ie why was it a blind spot?
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.
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.
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?"
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-...
1 - https://medium.com/@steve_mullen/an-introduction-to-lean-can...
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.
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.
This is an article of where blind spots might be but not about how to find them.
One of the suggestions is to find a coach — for instance online videos (not exactly a live coach) — but if you don’t know the mini games you should want to improve , how do you know which coach/video to invest in?
Generally, my suggestion is "weasel your way into coaching from people who are both much better than you at the thing and can break down their approach". Neither is sufficient on its own. In my experience, 1:1 coaches can be incredibly hard to find in some domains (esp. professional ones) and it seems like most people find them once they're already showing great promise at something, which means that they're not at the bottom of the bell curve. That means the onus is mostly on you to get to the middle. To do that, look for people who have found more success than you at the skill and are great at explaining their thought processes: podcasts and YouTube channels are invaluable for this.
Like most good advice (IMO), this is something that seems obvious but is rarely practiced.
(Software engineering and running are probably the ones I've sustained for the longest, though kids haven't helped with the latter.)
It sounds trivial, but if you can't solidly and reliably count up to fourths and eights - and weird patterns of fourths and eights across 2 - 3 bars - 16ths and triplets would be almost impossible to to right. And this is very similar to the "Added minigames" - you just add "and" in between the fourths and "ti" between the ands, no biggie right?
And speed is very similar. Hence the recommendation - learn a motive in a song until you can play it cleanly and slowly, and then speed up. Just going fast will usually end up being frustrating and bringing in bad habits.
And interestingly, while you can't transfer that much about playing well from a bass guitar to a guitar, you can transfer quite a bit of information about incorrect play and it's causes. The causes might have different rates of occurring - it's much easier to accidentally mute a guitar string and much easier to not fret bass strings precisely enough resulting in a messy buzz for example. But it's very recognizable.
It's like using fighter pilots as an example of how to be attentive. I don't think the most relevant examples ever come from 0.0001% of the population.
I guess I can expect the next Ted talk will be 'How to be like Magnus'. (Maybe Hikaru can be the speaker for more comedic value).
This said, I agree, and fitting with the theme, you need to move your head around focus wider to see the things that are hidden right in front of you.