> 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…
Why I Quit Google to Work for Myself
151–160 of 783 posts
Re: Why I Quit Google to Work for Myself
#152In 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
#153Earlier 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…
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
#154This 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…
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> 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…
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
#156Writing 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.
Re: Why I Quit Google to Work for Myself
#157Earlier 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.
Re: Why I Quit Google to Work for Myself
#158Writing 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…
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
#159Writing 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 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
#160Earlier 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.
(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").