Live data from Hacker News

Why I Quit Google to Work for Myself

mtlynch.io

151–160 of 783 posts

Re: Why I Quit Google to Work for Myself

#151
post #72
post #29

> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while. The idea would be something along the lines of everyone gets a set of assist points…

I worked in a remote team once helping a company in Seattle (that perhaps had a bit of a jock culture problem). I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.". To b…

Isn't the Toyota's idea of Kanban supposed to alleviate this? As in if there is some problem with the production line, anyone can push the stop button, and everyone assists?

Re: Why I Quit Google to Work for Myself

#152
This might work for a company with no competition and railway cars full of advertising money coming their way regardless of their actions.

In other places these things end up as a massive disaster and end up creating a culture of sabotage. There is a lot of backroom dealing that goes in these 'anonymous' committees. People who sit there aren't individual evaluators like in a public exam. They are generally people who come from teams around you. And they try to optimize and sabotage based on what is good for them. For example, a well deserving candidate's promotion can be turned down for a total irrelevant reason, while some political lackey could get promoted by adding all sort of cooked up recommendations to their 'promotion packet'. Most of the times all this is done so secretly that when promotions are announced the come across as a shock to most people. Of course people see through this all the time, and cubicles full of employee always talk of 2 + 3 not adding up to 5 in these cases.

Another huge scam in these things is the 'important work' bogey. You could have contributed way more code, fixed a lot more bugs and added a lot more value, but your promotion can be denied on the grounds of not doing 'important work'. What the definition of 'important work' is nobody knows, as its largely defined by work done by the guy getting promoted, no matter what work that is.

There are more things to this. For example, salary negotiations play another toxic game here. In most companies budgets are fixed. So a manager is likely to reward his lunch buddy far more than other people in the team. Eventually over 3 - 4 years you realize some of your team mates are now making way more disproportionate money compared to their peers and the work. This spills into all sorts of other opportunities.

The best thing I heard was from one manager, who told, if your manager isn't telling your for sure a few months in advance that you are getting promoted, you most likely aren't.

In most companies its already decided who gets promoted, they just have to do these 'promotion packet' and 'anonymous committee' rituals to cook up documentation to justify it, to protect themselves from law suits later.

All of this called 'negotiation' by those who benefit from these schemes. In reality it is getting financial and other favors in return for proximity and servitude to power.

Re: Why I Quit Google to Work for Myself

#153

Earlier quoted context omitted.

I've never tried it, but I suspect you'll run into the same issue that sports does, where "assists" don't accurately reflect the people who are making things happen on the court. We miss the perimeter shooter who positions themselves just so to pull two defenders out of position, but give credit to the point guard who makes the now-easy pass for the "assist". It's entirely possible for the person most responsible for…

You're forgetting that you could also track secondhand assist as well. I can't speak for programming but in soccer this is well-known. It's just very hard to Value just like an employer would in terms of having that person on board for morale. Fortunately the better people get it and understand that that person should be value even if they weren't directly involved in making the change but they were definitely a part…

A person’s projected morale is very under-appreciated. I don’t know if I’m at the point in my career that I boost morale just by being on the team, but I do know there are people who, if they left my company, would have an impact on my morale even though I never ask them for help or work directly with them.

Just something about knowing a person is an amazing and knowledgeable resource and he’s choosing to work here of all places is a subtle morale boost. When they decide to leave, others might start asking “well if that guy left, am I still making the right decision to stay?”

I’m sure we’ve all experienced someone important leaving our company and having a waterfall of turnover that follows it. That is very disruptive and more should have been done to keep that one employee or at least keep the rest that followed them out the door.

Re: Why I Quit Google to Work for Myself

#154

This covers a lot of the same ground as Brendan Reid's "Stealing the Corner Office"[1], which gives a playbook for helping stuff like this work in your favour, rather than against you. You fit the profile of what Reid calls the "Smart but Stationary Manager" - a guy who is a lot smarter than a lot of the people who do get promoted, but who doesn't optimize for the right factors. Reid's point is that a lot of these gu…

Agreed. In the book, “Secrets to Winning at Office Politics”, this type of person is know as a Martyr: Someone whose actions help the company but hurt or do not help themselves.

The important point is that helping the company and being promoted are not necessarily correlated and may in fact be orthogonal.

Re: Why I Quit Google to Work for Myself

#155
post #103

> Google does a good job of building a sense of community within the organization. That is the true test. You are supposed to pretend only to buy into it but never really believe it. Understanding that things function on two levels is critical. One level is the superficial "we are a family, community, we are not evil, making the world better". But that's the trap to catch all the naive people and extract extra work h…

This is absolutely correct. These rules are also specifically there to self-select only those capable of understanding and navigating the meta rules, as only people with the capacity will be able to run a company like google at a senior level.

If you think a promotion committee is tough to handle, wait till you hit a real board of directors with millions of dollars at stake, shareholders, regulators, colleagues fighting for your role and a million other competing pressures.

Re: Why I Quit Google to Work for Myself

#156

Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front. IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine. So certainly "can fix bugs and write docs and tests" isn't…

At many organizations, Senior Engineer is not the end of the IC track, not even close. For example: ... > Senior Engr. > Staff Engr. > Sr. Staff Engr. > Principal Engr. > Sr. Principal Engr. > Distinguished Engr.

It doesn't sound like they meant that senior was the last possible level, just the last level to which promotion in a career should be expected through "normal" growth and development. It looks like less than 1-2% of engineers at my company (FAANG) are above "Senior".

Re: Why I Quit Google to Work for Myself

#157
post #117
post #85

Earlier quoted context omitted.

> We miss the perimeter shooter who positions themselves just so to pull two defenders out of position, but give credit to the point guard who makes the now-easy pass for the "assist". The NBA has an advanced metric for that called gravity. As you could imagine Steph Curry's gravity is through the roof. Another related metric is +/- for when a player is on the floor. That one is more nebulous and error prone but it i…

Gravity isn’t metricized (and it would be hard to do so), the best we can do at the moment is indirectly measure it via +/- or other stats like what SC30’s teammates’ true shooting percentages are with him on and off the floor.

I think it's something that might be quantized through SportVU and the advanced analytics they provide, but not published anywhere to the public.

Re: Why I Quit Google to Work for Myself

#158

Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front. IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine. So certainly "can fix bugs and write docs and tests" isn't…

The role of a senior software engineer totally is to handle bugs and produce docs. The difference is that seniors should expect to work on more difficult systems, bugs, and documentation tasks.

When we don't value docs and bug fixing, we create undocumented and buggy code. When we don't value it by relegating it to junior developers, we miss opportunities to mentor others by both explaining the system at a high level and also using failures as teachable moments at the line level.

A Senior developer who shows understanding of multiple systems at a high level (making docs) in an organization as well as being able to understand and deconstruct the work of others (fixing bugs) consistently is qualified for a higher level role where they work across multiple teams of developers.

Re: Why I Quit Google to Work for Myself

#159

Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front. IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine. So certainly "can fix bugs and write docs and tests" isn't…

> Writing documentation and fixing bugs is in fact not the bar for a senior software engineer.

The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.

In some cases, the biggest problem is building and launching something shiny and impressive. In other cases, the biggest problem is fixing bugs. Refactoring complex/unstable systems to make them more simple/reliable. Figuring out the things that no one knows, and writing clear documentation for it so that no one will need to be blind again.

The sign of a good leader is correctly identifying the right thing to work on, and then getting it done, regardless of how "menial" it may seem. A culture where people are only recognized for working on shiny things, leads to organizational clusterfucks like Google's hangouts/allo/duo fiasco.

Re: Why I Quit Google to Work for Myself

#160

Earlier quoted context omitted.

I've never tried it, but I suspect you'll run into the same issue that sports does, where "assists" don't accurately reflect the people who are making things happen on the court. We miss the perimeter shooter who positions themselves just so to pull two defenders out of position, but give credit to the point guard who makes the now-easy pass for the "assist". It's entirely possible for the person most responsible for…

This is what +/- and its variants are for. Especially useful for sports like hockey where scoring is rare. Of course, in a work environment this is even harder to try and measure, if for no other reason than that people are almost never 'off the court' and if they are there are many confounding factors.

Yeah, there's a bunch of advanced stats that more accurately model this in sports. My point is twofold:

(a) despite the existence of better stats, a lot of people still care about goals/assists, because they're much easier to understand.

(b) the difficulty of measuring these stats in low-scoring sports (soccer, hockey) is greatly magnified in business; instead of scoring O(1) points per hour, a small software team may "score a point" every couple weeks or quarter or year. Additionally, the number of people contributing is often greater, and we see fewer "identical lineup, but with player A swapped out for player B" situations (and ~never for long enough to get meaningful stats about "points scored").

Post reply on HN