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.
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.
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.
> 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.
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?"
> 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.
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.
Wish I had time for a longer comment, but this advice rings very true for me. Reflecting back on grad school and the transition to professional life, you have to realize that your role changes every couple of years and that the things that got you to one stage won’t get you to the next. Many people end up stuck in a local maximum (lacking vision) which partly explains the Peter principle.
Thought this was going to be about how to find your actual blind spots, which for anyone who doesn't know is draw two dots on a plain background, a couple of inches apart, look at the right dot with your left eye, or vice versa, keeping the other eye closed. Move closer until the other dot disappears. Still amazes me every time.
The issue I have here is that it’s not clear how to identify the mini games to improve.
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?
Ah - if you feel this way, then I probably wasn't on the nose enough with this specific point. I was trying to balance a few points (i.e. IMO most people focus too much on marginal improvements in skills that got them to where they are) and not enough on building awareness of what completely new skills they need to build.
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.
Opposite to the author, I've fixated on just a few hobbies which have captured my interest for many years (drawing and Japanese-English translation being the big two). In regards to my hobbies, this assessment is extremely accurate! Had never thought of things in terms of "minigames," but when I do make appreciable progress, it's because I've given myself a new minigame to crush. Unfortunately, I haven't cracked the mentor puzzle either, though I'm sure it would help enormously.
I was about to comment too. I'm noticing this very strongly e.g. in my early endeavors in music (2-3 years into the bass, 6 month seriously into the guitar after getting the neck aligned)
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.
That jealousy goes both ways. I often wish I was one of those people who can share stories about their adventures into many interests, or who can relate to a wide range of people because of their variety of experiences. Going deep can be very isolating. Unless my conversation partner happens to have some overlap with my limited interests, I'm at a loss. Too many conversations end with the other person staring at me like I came from another planet :(
Have some of this as well, what helps me is picking up tangential hobbies where some skills may carry over(or vice versa). I would say tennis is my main hobby, and recently I have started playing a little bit of pickleball and racquetball to get variety. The skills and tactics for tennis are pretty different from the other two, but having things like hand eye coordination and footwork carry over are a big plus! Conversely I picked up 3d printing last year with the intent of learning to 3d model, and I felt like a pretty big noob trying to figure it out. At the end I just resorted to printing what others had already modeled haha.
I don't think chess is the best example for 'minigames'. You play a lot of mini games when learning, but the pros are very focussed on the larger strategy. The mini games are executed below their main attention. I think their 'blind spots', what GMs call 'blunders', are at a level that does not map with our normal reality.
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.
I really like this post thank you for sharing. It led me to your other post on management lessons from your toddler and I'm really, really digging your ideas and style.
i think the point about adding minigames vs refining the ones you have is very good. ive noticed that with music performance, sometimes its a little counterintuitive though- often a minigame can itself be refined into a few mini-minigames, and that really helps things. its such a constrained discipline i think sometimes its all about making whats already "easy" easier.
as good as this advice is, there in lies crux of human nature. Once one succeds in a task, it provides validation of the method followed, hence no need to "go back" and move on to next taks. At least this is what i have seen ohter people do and so have i.
i guess this is what seperates good performer vs mediocore ones.
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.