Managers read it, my teammates in Seattle read it. Nobody ever helped us (because you know pair programming is so much more efficient if you can have two programmers blocked when you could just have one staring out of the window and typing "help" to invisible people). If at all I would be unblocked after a few days usually the problems was some kind of unguessable piece of configuration that should have been part of the README and/or code, a problem completely unsolvable without knowing what to do. Only then I could continue doing a minor change like updating a CSS file for the next Safari or IE quirk, usually just 5 minutes of work.
Apparently helping remote teammates to get unstuck in their work just wasn't an interesting performance metric.
Until this day I still can't believe that everybody was just throwing tens of thousands of dollars of work out the window because helping stuck teammates wasn't counting towards some kind of bonus.
In fact, there are many social group situations in which asking specific people is far more effective than asking questions "to the group".
Nah, let’s just alternate between micromanaging and being totally absent; fret about lack of productivity or lack of progress; maybe institute a daily stand-up.
Source: am a manager.
You actually expected that what I wrote was a literal quote from the only thing I ever said during those days? It probably was something more like:
"Tried to run project X but kept getting error Y. I tried to figure out where it comes from but it seems to missing some kind of value it pulls from somewhere. Tried every step in the README and installed twice. I think the information in the README is incomplete and there's another step. Nobody else had to use this repo before here so the guys here can't help me out either. Can you help me out @colleagueFromTheUS1 or @colleagueFromTheUS2?"
After 48 hours I get very specific about being completely blocked and that I have exhausted every way thinkable to get it running. So nobody would be living in the fantasy the problem was going away by just ignoring it long enough.
We're humans. Unless there's been a training day or a Readme file explaining HOW to report a bug, I think it's perfectly reasonable to expect this protocol to work:
"I'm blocked!"
"Why?"
"{reason}"
If nobody ACKs the "I'm blocked" message, it's reasonable for someone to think that nobody cares or nobody is listening. This is a normal human protocol, as used in most human environments.
"{problem}!"
"What's happening? How can I help?" (any considerate person nearby responds)
I just cut your protocol complexity by half. ;-)
It’s rather unrealistic for the manager to be understanding all the time and coax a team member to give all details of every problem...
Dig as far as you can, record it all, then escalate. You also have to gauge how critical it is and how much of your time (esp. if other things are building up) to spend on it as a factor of when to take it up the line.
Tbh, I haven't had any managers lately that have been that great but I'm still holding out hope.
Those people should never be managers.
> Source: am a manager.
> I'm blocked, woe is me" is garbage
As a manager, are you prepared to put your real name to these comments?
This is an anonymous public forum with a massive audience and great content. Let's keep it civil and not target individuals. Please don't try and start witch hunts to ruin someone's career just because you do not agree with him.
Comment sounds like typical 'pull yourself up by the bootstraps', meant to put down new talent, ignoring that complex, modern dev environments have many parts that are completely out of reach for newcomers without adequate onboarding.
Like you said, why not both? The employee is already asking for help, that's their part. The manager needs to come in and assist, unless he enjoys churning his dev team.
That is not asking for help. Asking for help would be "Can somebody please help me? ... rest of message here...". Even better is asking an individual (or individuals) directly.
Say what now? Mentioning you are blocked, in a stand-up, multiple times is a cry for help. What is the point of having stand-ups if you're not assisting blocked team members?
The standup is for blockers to be announced. It's the 3 stage of the standup.
Sounds like poor management, don't blame the new guy, he did say he was blocked in standup. How is he to know who to ask. Whose time can he impinge upon. It might be he asks someone who helps him but he gets in trouble because he now took up that persons time from something else.
The manager should see oh he is blocked, I'll assign so and so to help unblock him.
Sometimes it's on me.
Source: I manage managers
When a member of your team can't perform because he's not given the proper resources(access, help, info, etc), it should be your number 1 job to find out why is that the case and do everything in your power to rectify that.
One could argue that it's your only job actually.
I just want to point out that that is a lot of assumption based on the limited (probably paraphrased) context we have here.
You can bet I was a hell more specific about both the problem and who should help me.
People ask for help in different ways based on personality, skill set and experience. It’s more important to meet them where they are than sit back and smugly suggest they lack individual ownership.
Good: "Hi, Sumitra. Can you help me with this or recommend someone who can?"
Good: "Hi, $MANAGER. Can you help me with this or recommend someone who can?"
I've never been at such a company and I hope I never will.
This is very good- something managers should do for all of their direct reports. If not every day, then often.
The bystander effect is real, but I wouldn't expect to see it in organisations with explicit hierarchies. Can you imagine this happening in the armed forces? If this happens under your watch as a leader, you're not good at leading.
Otherwise, a common issue for a team with colocated workers mixed with remote workers is a facility to ignore calls and messages.
Central people get easily overworked, interrupted and drown into tsunamis of requests. One of the coping mechanisms in these situations is to just ignore most requests, and only deal with people getting loud enough to be heard. In a mixed environment, the coworker siting 10m away has an easier time grabbing attention than the icon in the chat room with a unread badge.
Even simply knowing when someone is taking breaks can help to time requests to get them at the right moment.
I have remote days every now and then, and it’s interesting to see how the game is completely different, and how often I end up asking someone physically there to go talk to people on my behalf.
(Note that being remote in an otherwise physical team makes this significantly more complicated as well.)
It's the same thing.
CPR for example. It's one of the primary tenants. Assign individual responsibility to people to ensure this group paralysis doesn't happen.
So if there is a micro-crunch coming up (i.e., I need to have an SOP drafted, tested, etc by this afternoon), the entire morning I tend to blow off other peoples issues. Until I can get a chance to come up for air.
But that makes me feel bad, so what I end up doing instead is I go home at the end of the day and work till past midnight just to get caught up on what I couldn't do in the daytime. For any outside-the-box work I tend to pull 20-30 hours stints over the weekend. After 25 years of this, and as I need more sleep since I'm getting older, I can be a bit snippy when someone breaks me out of my concentration because they can't figure out something, and they have a down customer that needs service "right now".
I started out as the eager mentor, even when it was among my peers in university. But somewhere in my ~25 years of R&D, I started to notice how coworkers would become dependent. They would ask for help on types of things that I knew I had figured out myself, even when I was a novice. They develop the plea for help as a first reflex to avoid any learning tangential to what they consider the task at hand.
So, I found myself swearing under my breath and refusing to be their search engine or man-page. Depending on my mood that day, I might tell them I have no time and they should google it themselves, or I might pretend I don't know the answer either. Sometimes I relished the time to sarcastically school them on the mundane deductions it would take to answer their question from the very screen full of error messages they pasted at me. But, I already knew they would miss or ignore the hint, and be back again next time they stumbled.
Sadly, I think this cultivated impatience leaked out into my attempts to mentor a very junior staff member we had a couple years ago. I could no longer really distinguish "too lazy to try" and "drowning". They found a new job after a year or so, and it was probably wise for them. I am still trying to visualize how I can do better the next time we try to onboard somebody far junior to our current team...
1st year
'Thanks for your help finding that error that was holding us up.'
2nd year
'We are all finished now. Just sent it over to you for debugging.'
3rd year
'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management
4th year
Management: 'we need to talk a about the regular delays here. We have several teams waiting on you. Also your own code checkin's are much lower than theirs. Seems like you are only making changes to what others write.'
Management publishes a Medium article "We fired our top talent. Best decision we ever made."
From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now <Peer's> inability to properly take notes or retain information. <Peer> knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally <Peer> will have better knowledge retention by synthesizing their own notes.
Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.
For programmers: jump ship. A well-executed handoff process will not only maintain goodwill but remind others of your value.
Of course, by the time you have upper management yelling at you because "several teams are waiting on you", the response becomes "why have you allowed several teams to become completely dependent on one overworked person?"
The other, more drastic solution (as someone else said) is simply to move jobs. This can be the only way to fix the issue if the entire management structure is corrupted and you don't think it's fixable from within. You could even just leave, start a consultancy company, and let the second team know that you're available for hire when they need you.
- If you reach this situation, you're more competent than the rest of the group. Nobody to learn from, time to go.
- "Management" is a big machine, with its own insider culture and politics. It does not change overnight, do you want to wait 6 months minimum for things to get better?
- Changing job is good for just about everything: career, money, knowledge... as long as you don't do it too often.
- Meta-bonus: getting into a job with better peers means tighter work-friends. It's not fun to be around people overdesigning object-oriented projects when you understand functionnal programming and low-level debugging.
> 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.
>> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck.
This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc.
That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc.
Partly this is because I really cannot be bothered to keep such details in my head, anyway.
Honestly, there's not much you can do if you feel like your company is not acknowledging work that you believe is a valuable use of your clock time.
What I notice more senior people do is 1) expose clear SLAs to require their help and 2) get in the habit of producing more artifacts while they concentrate so they can refocus faster after an interruption.
What has your career trajectory been like over the past 25 years?
For example, back in 89 (I was 18 - 19 then) the company I was at had a need to access multiple screens at the same time in their green-screen (serial terminal) application. So I wrote a multi-session terminal emulator. Ended up being a lot like what GNU screen is today (not sure if screen existed then, this was pre-internet days for me).
Other times I'd write up software distribution systems, monitoring systems, etc. Or work on creating things like a custom interpreted language, just because an app developer at my company needed that. Or write hand-coded postscript, because someone's app needed that.
In my current company, I'm still a Linux systems engineer / Lead, but I've been on-loan to our app development team to help with C-based libraries that they need (this code is a couple decades old, and they don't have any C hackers that can work on it). This is software that interfaces with medical testing equipment, so it feels like I'm making some difference.
Lately I've been brushing up on my web development skills, becoming buzzword-compliant, and putting together web apps both for internal use, and related to maintaining our product.
I guess I should have went into full time development years ago, but I was always worried that I'd get shoved into boring business applications instead of working on really interesting stuff. So I've stayed in the Unix/Linux ops role, found out that a lot of what I've been doing is now called DevOps, and doing open source work on the side.
As for the trajectory, I haven't changed jobs that often. I've had a couple of dud-type jobs where I lasted 1 - 3 years (they didn't want someone who could do "extra" stuff, because that "made the rest of the team look lazy" as I was told in a performance review once). But when I start at a good place I try to make a good first impression, then a better second impression, and try to work and support as many people as I can (while doing my best to make them look good, but making sure I get recognized too). Helps to have a number of people that "have my back".
While I agree that it would have been nice if somebody helped you, you are in control of your own destiny. If nobody is helping you, you need to personally escalate it and reach out until you get the job done. If somebody did this on my team, the first question I would ask them was why the hell they let themselves sit blocked for days.
...and of course my team would have been more proactive on helping you because one of our core values is help your co-worker, but that is besides the point here.
And didn't you have backups of that repo?
The company needs to take at least partial blame here.
Note that I am not convinced that this is the case here - I simply don't have enough information to make the judgement.
Wat?
My other thought was to file blocking bug/defect issues on the relevant software because obviously if it can't build in the first place it's certainly not passing QA.
Some of this may get to the level of passive-aggressive or aggressive-aggressive bridge burning.
Unfortunately most people I have met do not think like this.
This happened to me once a few years ago, once I finally figured it out I put all this silliness into one single bootstrapping function you could call to get the pig of an application to run, and asked the lead dev to add it to the core library. Later that day I got called into my manager's office as apparently my behavior was disruptive and problematic.
(not saying it was necessarily about something real, just that it could be)
Managers absolutely don't seem to care about actually building a team and cultivating a culture of success.
Engineering managers are way way worse than Soccer managers in this regard.
I would put this all on the hiring processes right from how we hire engineers and managers and what gets a promotion. But unfortunately, our industry would rather remain blind.
The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.
No, it really, really isn’t. Maybe 1 in 1000 cases are like you describe but the rest is just that older engineers are harder to exploit.
If only there was a way for employees to rate their Manager instead of the other way.
Then again, I've been very selective in where I work. People like to bash the "culture" stereotype, but it's definitely something I consider when I'm looking for a job... you know, how people are expected to interact with other people, not whether there are ball pits and the like.
When you have a recognized long-term leader that doesn't need to constantly re-justify their involvement and existence (something akin to a BDFL), more collaborative group efforts can be fostered, and individual gamification is much less useful, because the people who know your behavior are going to be there for a long time and there is a lot of personal continuity. This system is, of course, not without its own type of flaws, but it doesn't have the same negative feedback incentives for individual contributors.
It's hard to get that long-term involvement in the tech industry specifically because the rapid rate of technical change limits career length and portability. Skills in language/system/framework X rarely retain marketability for more than 3-5 years. Most people don't have the stamina, interest, or whatever it is that's needed to keep up with the constant re-education and re-justification cycle into their 40s and 50s. They look for an out: early retirement, promotions into non-coding management positions, etc.
To the extent that individual metric gamification is higher-than-normal in tech, I would attribute most of it to the effect of shorter career tenures, both overall and at specific companies.
I think short-term thinking by superiors causes short-term behavior by reports.
If the management pays fairly, with fair raises, fair balance, fair acknowledgement of all kinds of work and not just the flashy stuff, most reports would focus on the right things, do their jobs well and not look to switch jobs all the time.
But if the management is always trying to escape giving promotions/raises, does not acknowledge the underlying effort to get something to production, only thinks about their own empires (basically short-term selfish thinking) it will cause a disproportionately high number of reports to behave the same aka look out for their selfish interests.
I am absolutely certain that top companies look to retain good players (top != stock price or market cap).
pfft. If it's a web app (from 2015-2018) I have even more sympathy for the OP than on any other platform.
Here's an example from last year-ish:
* Get repo from external contractor (let's ignore the 1+ weeks trying to get an install of Git approved)
* Try to get npm working - can't get through our firewall
* Figure out the right chaining proxy to use
* Spend a non-zero amount of time trying to work out all the right bits to flip to turn off ALL SSL verification from npm because interception proxy
* Hit the Windows MAX_PATH limit and have to spend ages trying to delete files that NPM's created (original developer used Linux)
* After npm starts downloading stuff correctly, suddenly it needs a binary dependency (and thus more build tools)
* Give up and check in said binary dependency from elsewhere
* Finally build all the CSS and minified Javascript and check it all into source control with a warning to other devs not to rebuild it unless absolutely necessary
Not necessarily. In my case, we have a web application where it eventually turned out that the variable was read from an environment variable. On a server where I didn't have access.
In a manner of speaking he did pull the andon cord by speaking up in his team meetings and alerting people in Slack, but the cord means nothing if there is not a culture supporting the alert.
In a room no-one enters;
Snow blankets roadblock.
That’s what these companies need. The entire business comes to a screeching halt.
And if they really needed more motivation, production servers could be shut down if the issue was not resolved in 24 hours. That will really hold their feet to the fire.
When you're co-located with someone you develop better comradery with that person. You'll know them better and they'll come right to your desk when they ask for help so you're more likely to help them. And you sit with them as they execute commands so you can see exactly what's going on.
remote coworkers are easier to ignore, harder to help, and harder to socialize with.
I can imagine situations where you should care about the company's performance, like a non-profit or certain startup situations, but I think the majority of enterprise developers fall under the above.
Certainly it might've been more efficient if one of your colleagues helped you debug the issue. But in the absence of help, it's not clear why you didn't dive in and start debugging on your own (rather than doing nothing). You'll learn more that way too.
Also it's not clear to me that learning how to use Process Explorer + using it, when that's not your job, is actually meaningfully more efficient than staring out the window all day.
I’ve generally heard “blocked” from weaker team members when it pertains to working on our stuff.
Sure, you can be blocked due to infrastructure / external dependency, but if you have the source code, unblock yourself, mate.
Programming is going to be a frustrating career for you otherwise.
It's not time efficient for everyone to work separately down to reverse-engineering the machine code to work out what's missing every time.
If not, you should be able to at least start debugging. You should get some error message (maybe that indicates some env variables not set, something not installed, etc). It seems odd to have not spoken directly to your supervisor or product owner to say "hey, this isn't working because X. What do I need to do / who can I talk to for help?"
Years ago I worked at a desktop software company that hired me to be their "Windows expert". They had a team of strong programmers who mostly had a Mac background, and they wanted to improve their Windows offerings.
I often spent a couple of hours a day doing what I called "house calls": finding out who was having trouble with a Windows issue and stopping by to lend them a hand.
This was before "pair programming" was a common term, and full time pair programming would drive me nuts, but these house calls were very productive. The other team members knew the product code much better than I did (being a newbie), and my Windows experience helped them work through platform issues. Plus sometimes just having another pair of eyes look at a problem.
Often a 20-30 minute house call would save a team member many hours of work.
At one point, a teammate thanked me for helping with a tough problem and asked me, "How can you afford to be so generous with your time?"
Some time after that, the VP of engineering (who I'd worked with previously and was on good terms with) asked me if everything was OK. He had noticed that the other developers on the team had lately been more productive than ever, but my own productivity wasn't quite keeping up.
I think I mentioned that some of my time had gone into helping the other developers work through their Windows and other issues, but I didn't have the presence of mind to say, "Maybe my help has been one reason their productivity has gone up. I thought that's what you hired me for. Can we make it part of my job description?"
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 a play succeeding to never touch the ball. You really want something like value-above-replacement, but that's pretty hard to measure without a clear definition of what "success" is and reams of data.
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 is meant to describe a player's impact on the floor outside of things like assists, points, rebounds, etc.
Happen to have any additional reading on that? (only if it's a handy link for you, otherwise I'll google it). I've re-started watching NBA recently after about 20 years or so, and it's the first time when I hear about this concept, one which sounds very intriguing and interesting. Maybe it was also used 20 years ago, but back then I didn't have access to Internet and as I don't live in the States the local sports newspapers (which care more about football/soccer) weren't mentioning it.
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 of it.
This is what plagues me with most corporate companies in the United States. It should be about teamwork not about what this person did or I did, rather what the team did.
Sure you can value people individually, but teams trump individuals all day long in the long run.
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.
Moving on is a fact of life, more so now that ever. My parents both worked for the same company over 35-40 years before they retired; I don't think I can imagine that'll be even close to the norm for many in the workforce now (especially software / other tech).
(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").
That's why they have a million statistics, these days. Goals, assists, distance covered, top speed, region of the pitch most used, etc.
They especially undervalue actions that happen "away from the play" (the software-engineering equivalent might be something like rewarding a teammate who steps in to help you fix an critical block-ship bug, missing the person who had the foresight to write a test case two years ago that prevents a bug from occurring in the first place).
And also the guy who pressured the opponent into attempting a difficult pass so that his team mate could win the ball in the first place.
It's still not perfect: people could be spending them helping someone from another team and that would go under the radar (except the peer reviews), but it still worked a lot better.
People were taking one bug, breaking it in to 3 or 4, then closing all of those.
"Add button for X" became
* "add button on form" * "add CSS for button" * "update CSS for button" * "add CSS files to build process"
Friend of mine took a bug - it was a moderately big one, touched multiple systems, but was a bear to work on. No one else touched it. He spent a few weeks making it work. Eventually closed it. Was reprimanded because his bug-closing stats were bringing down the department's numbers. He was counseled that he should have broken it down in to a few dozen issues, so that he could have closed more and "kept up" with his team mates.
No one else would touch that bug. Most people hadn't been there long enough to decipher how complex it was. But.... they got bigger bonuses because ... bug closing numbers.
We all probably have similar stories to share, and I know the "what gets measured gets gamed" mantra.
It's still frustrating to know that this mentality infects so many professional "thought workers".
The article explains the process by which good, honest workers become corrupted into this mentality. Whether you want to do good work or not, most people don't have the confidence, security, nest egg, etc. to quit their day job, so they assimilate out of the necessity to keep their bills paid, and this becomes a cycle. The naive worker comes in determined to do a great job, soon learns that "great job" is not a straightforward evaluation and that people who have no real involvement, knowledge, or investment have control over their career trajectory, and then optimize to improve those numbers.
These people then get promoted and a) consider failure to game the system evidence of naivety, and expect this same political awakening in candidates as a "rite of passage"; and/or b) rise through the ranks without realizing that they've gradually internalized the system, and that they're inadvertently making the same loose determinations based on impersonal, macro-level metrics that are easily gamed, partially because as you get promoted, you can't possibly come to a deep intuitive or direct understanding of the work of everyone in the ranks. Rinse and repeat. The ABCs of employment are "Always Be Campaigning".
Strong, personal leadership from invested, intelligent people with conviction is the only antidote, and even when you get these people, it's a constant battle to keep their disinclination for political games from destroying things.
I was supposed to complete an existing project. Only problem was, new bugs kept getting added by the tester, and were then assigned to me by the project manager, so the number of issues kept growing. I would fix them (or existing ones) during the week, but at the next conference call it would still look like I was not making progress, because the total number of open issues did not shrink much.
This led to weekly inquiries of "when will it be done", and pointing out that it was essentially a moving target, due to circumstances beyond my control, did not help much. Eventually I did catch up, but the damage was done. Apparently this manager now thought of me as somebody who wasn't very productive. They moved me to another, completely unfamiliar project, where I got essentially no help from others, then decided that I was not productive enough and let me go.
In retrospect, being asked continuously when the project would be done, was an indication that I was the only one being blamed for its delay. I was afraid to rock the boat though, and quietly assumed that surely this manager was taking all the factors into account (especially since I did point them out a few times). As it turned out, they were not, and I will not make this mistake again, should a similar situation come up in a future job.
This is really at the heart of why most people don't speak up (or speak up more loudly) - fear. Fear of losing the job, income, etc. There are no easy answers to this, short of having - if not FU money - a comfortable cushion to see you through a year or two between income streams.
What does not get measured gets ignored. It's not necessarily a bad thing to measure stuff. But it's easy to overlook a metric that later turns out to be important.
If you're measuring the wrong stuff, or measuring it in the wrong way, your metrics are again erroneous and your decisions will be based on ghosts.
Lao Tzu was truly onto something when he said "the more I learn the less I understand".
To take a narrower view, it sounds like that place needed to assign weights to the different bugs, so that the big scary bug was worth 20x (or whatever) of the trivial 'tweak the CSS' bugs.
Helping other teams succeed is a cultural thing and your organization has to encourage it with its practices and procedures.
[0] http://www.businessinsider.com/bridgewater-employees-rate-pe...
This is why I generally dislike measuring individuals against specific metrics. I try to set individualized metrics for all of my direct reports — for example, if I had a developer who keeps checking in code without valid tests, code coverage might be a metric I track with him just to help him understand how he’s doing against his personal goal. Even within the same job description there is often room for a significant variation in technical and interpersonal skills, and you need a team with a good mix of both to be successful. A one-size-fits-all approach to individual metrics just leads to a team of people with the exact same skill set.
I think the way you measure teamwork is at the team level by having a consisitent set of team-level metrics the entire team is judged against. This means individual personality and career path variations don’t matter as much. I’m talking things like say, number of broken builds, velocity improvements, production issue counts, etc. These should be business outcomes that the product folks care about. If you make it the team’s responsibility, you’ll find teamwork happens more naturally.
This approach to performance management is in direct opposition to stack ranking, and a big part of why I refuse to work for a company that forces its managers to stack rank within teams. The question of “what makes a good employee great?” is so difficult to answer that if you have multiple high performers, it’s effectively arbitrary. It also tends to punish people who are maybe less technically brilliant, but have strong interpersonal skills (after all, how else does a mediocre programmer make it through a CS degree?) Those interpersonal skills often lead to better technical discussions and avoidance of miscommunication between technical folks.
Interesting management approach. My questions are:
1. How do you account for new team members in a team's metrics? A new junior dev will take some time to become productive so do you add the new member's progress to the team's metrics by making it responsibility of one or two experienced teammates? For instance, you might have internal progress indicators like - by month: 1 the junior should have read access to certain repos that are crucial to a good understanding of the application architecture; by month 2: made a certain number of commits; by month 3: written X number of tests etc.
2. How do you use these team metrics to recommend promotions and raises for individuals?
2. I don’t! Well, not directly. Team metrics usually have some impact on bonus money and raises, but that’s all based on budget so it’s not consistent year-to-year. Metrics should be used to drive behavior, but behavior should be used to determine promotion. Is the person a team player? Have they developed the skills necessary to be successful at the next level? What does the next level look like for them — is it management or engineering? A lot plays into it, and you have to have career path discussions with folks. Can’t solve this one with metrics :)
Businesses don't handle processes that produce variable outcomes very well since it opens them up to risk. Or stated another way, businesses love the notion of fungible employees and a one-size-fits all process to shepard those employees.
Fungible employees makes sense if you are in manufacturing where low skill workers are the norm, but not so much if you are in the knowledge industry, where there are variations in the skills each employee excels at.
IMHO, the dynamics of knowledge work is similar to a team sport like soccer/football but businesses would prefer that the dynamics be similar to manufacturing line workers.
Most of the time other people leave or move to other teams.
Being a decent human being is not about getting practical advantages - otherwise sociopaths would be the most helpful people around.
Instead, many large corporations want to instill a culture of competitiveness and often cynicism because competing is what they do.
Cooperation, lasting relationship between employees, mutual help, solidarity are increasingly scary words for many companies.
Sociopaths are exploiting the macro-level heuristics we've developed as a species to come to an immediate, reasonably-likely evaluation of safety, tending individuals toward trust, and danger, tending individuals toward defensive action. It takes knowledge and experience to differentiate between a good read based on sincere action and a bad read based on intentionally-deceptive action.
Sociopaths often will appear like the most helpful people around, and sometimes may actually be the most helpful people around, for the duration of the time that they need you to be on their good side. Then they'll dispose of you ruthlessly. If you don't pick up on the signals ahead of time, you don't find out until you've been backstabbed. If the sociopath is skilled, they ensure that you can't "come back from the grave" and cause problems for them.
It's not that corporations don't like cooperation in principle. From a high level, in fact, many corporations are actively and honestly trying to cultivate it. It's just that our systems keep the exploits too open to the relatively-rare maladjusted power player (normal people will sometimes flirt with the same tactics to avenge personal grudges, etc). This forces everyone into a defensive position, if it doesn't force them out of the game entirely.
Once an organ grows to exceed the direct influence of a very small handful of truly good and wise leaders (the more palatable tech word may be "visionaries"), it will inevitably mandate this weird perceptual bastardization.
So basically the long-term effect of these systems was me to slack on whatever my manager deemed important to get done to whatever extent I could while I did whatever would win me clout points with other developers or let me learn a cool skill.
I also got pretty jacked from sneaking off to the gym etc. Lol it was lit
Even on the team level you're still reading tea leaves if you're going into the issue tracking system. The only measure that should matter is execution towards a business goal. A team that is killing it consistently is doing the right things, or is being given the right projects.
You could give as many kudos as you wanted, and it had zero impact on performance appraisal/raises, but it sure gave people the warm and fuzzies reading about random mini-stories of someone going above and beyond here and there.
I think it was pretty effective at fostering a culture of collaboration, and it also helped surface issues-masked-as-heroics, such as people working chronically late on some projects. It also gave greater visibility to the existence and importance of the various departments, which one might not have gotten an appreciation of otherwise.
Its interesting that throughout my career I've found it has been challenging to communicate group and individual contribution in meaningful ways to people without the whole picture. That is especially true when the activities don't translate directly to sales revenue.
As a result, you get people who leave who were much more important to the organization than the organization understood and the folks left behind are stuck trying to recover and make up the loss.
If there was a manager measure of 'OQ' (organizational quotient) it would measure the ability to recognize and optimize the net productive energy of an organization. Groups without that awareness seem to wither as they pursue one or two 10x employees without regard to how to support their activities.
As you say, zero impact to people in terms of their performance reviews (which were a topic of discussion in their own, each employee having to write a mini-manifesto for their year ahead) and kinda became a popularity contest where people were giving kudos to their office buddies.
And don't get me started on the people that left heart stickers with messages like "thank you for starting the best company in the world" on Benioff's profile.
Another issue is that tech orgs are extremely political. There was one person who had single-handedly created a viable migration path from the company's aging proprietary framework to .NET MVC5, but no kudos there. Just lots of pushback and skepticism.
On one project I shaved about 40 minutes to an hour per day of finger twiddling frustration off of everyone’s work. For the team size that paid for itself in under two months. Only ever got appreciation from subordinates and flack from my good for nothing boss.
But what I figured out not long after that was that you understand the work a lot better when you see it from other peoples perspectives, and you only learn about that if you are willing to help and to be candid about the state of the project. People open up. They share maybe-bugs before filing them (especially from the QA team) and then when the inevitable OH SHIT meeting happens you are the only one who has had time to think about a solution ahead of time.
Disclaimer: I work at Google.
Isn't that a metric?
If you are assisting, and this includes providing support for someone else's code, or doing "invisible" tasks (setting up a redis cluster or writing end-to-end tests), this often finds its way into one email group or another. In fact I remember the names of the "helpers" as you put it by the virtue of their emails and to that end I value them, just as much if not more, for keeping us shipshape.
IMHO, you should find these emails, and I am sure they exist already, and use it as your metric.
Scott Fitzgerald wrote “Show me a hero and I’ll write you a tragedy.” I say show me email chains, and I will show a hero.
Of course I am not stating the obvious fact - which is that your manager, if he or she is worth their salt, should totally value the role "helping" plays in making good software.
I've had the experience several times where extensive, detailed emails would always meet the same reply: "Thanks. Let's talk about it in the morning." These people are wise to the game, and they rely heavily on the imperfect nature of human memory; memorialization in the written record must be approached very carefully.
The email chain that shows Employee A to be a hero equally shows Employee B as a victim in constant need of assistance, obstructing other work, taking valuable time from others. As such, "Bs" will avoid asking in a recorded form, avoid giving credit to helpers when writing about their work, and so forth. Even if they mean well and earnestly want to credit the many people who've helped, it's too easy for a malevolent actor to turn it against them, so after a few raw experiences, they learn to avoid it -- just like what happens in the article.
The only real answer to these questions is to have an informed, rigorous, and fair-minded chain of command that has experience and cares deeply for the company's long-term well-being, which is, needless to say, quite rare. It is also worth noting that such noble persons are likely hurting themselves by acting this way and making enemies for themselves, as people who truly didn't deserve promotions, etc., whine and search for flimsy excuses.
In my experience people also ask for help through private messenger discussions (slack/skype etc), which of course don't leave any "official" trail and are not supposed to. Of course, a not-so-bright manager could force his/her direct reports to only use "official" channels for work-related communications, but then people would be afraid/ashamed to ask "stupid questions" in public/through an official channel and then disaster happens (it's also my experience that lots of serious bugs have been caused by people afraid/ashamed to "just ask").
There's only one way to actually measure someone's output, and it's working close to the team and witnessing their actual productivity. Getting involved. 1-on-1s.
Of course the farther removed from this process the more politics come into play.
Will show you a hero six months after they tendered resignation.
If you know ahead of time that you are doing "the dirty work", which usually you don't, do you know how long you are going to do it for, and if it makes sense to apply for a transfer?
Would your manager approve of your ladder transfer if he/she needs to back-fill your position when a good engineer is hard to find or keep to begin with? (Actually, there are scenarios where a manager wants to keep underperformers from transferring out, too)
Lastly, did you really want to be a Tools and Infrastructure engineer to begin with? It started with just being scrappy in order to get the project to a place where you can contribute shiny new features, which everyone is waiting for you to do, yourself included. If you transfer ladders, what are the chances you will be able transfer back in any reasonable amount of time to get credit for doing a good job on what you wanted to work on?
Michael's work situation seems prevalent through a Google-like org, and a ladder transfer is unlikely a realistic solution for that.
This was highlighted to me recently when someone in Slack noted that one person had ~50X the kudos of everyone else and asked how that happens... and they said "just go hang around in team X's channel, they'll give you a 'taco' any time your answer a query."
Given Google's promo system (where a committee looks at candidates from very different teams) this then means they'd have to try to normalize the data for it to be useful.
Is the goal of using something like this to help people show more gratitude or is it for performance feedback?
And can those two things coexist or do they conflict with each other?
Would love to hear your thoughts.
I don't think they should be used for perf as they are not intended to be objective feedback.
Even if it is - don't be that manager of the group with the least group kudos/tacos?
Sorry, you got duped into having sympathy and showing teamwork.
The better you are at convincing others we're a team and hard work is it's own reward when it's really just dog eat dog the higher up the food chain you go.
Using this, everyone can know what other people is working and who is helping who like that. For every month at a team meeting, people who got more points will be appreciated in front of the whole team. The total points is calculated using a formula such that a member who just start giving/receiving more points per jem than other so that new comers will be appreciated more.
It works really well and at performance review, managers will consider this stats. Also the performance review contains two peers (chosen by us), and all kind of managers who we are reporting.
It helped us discovering the importance of assists, so now we have support teams dedicated in assisting project teams.
Project-driven environment + no estimate or log = politics
I can have my head down all week neck deep in code but because of this I'm not interacting with people around me as much and basically get punished for focusing on work.
There is a simple metric for workplace success: if most people are happier while you're around (including and especially anyone above you in the chain of command), you're winning; if not, you're not. This can probably be summarized as "popularity". A few things can overcome this, so you may want to be careful not to go 100% focused on it, but you will definitely prosper if you make it the focus of 95% of your work.
Developers who like to debate and don't take it personally when a colleague disagrees are at a distinct disadvantage here, despite simultaneously frequently being some of the best qualified coders, because they don't understand that they're rare, and that many other people take any form of non-ambiguous criticism of their ideas or work as a major offense: taking bread out of their kids' mouths, etc.
I have a theory that the more a person cares for niceties, appearances, and superficialities, the more it shows that they're incapable of operating at a level any deeper than that (that is, capacity and the presence of superficial tokens generally understood to mark capacity are inversely correlated; e.g. an expensive watch does not necessarily indicate power, wealth, or importance; compare Dunning-Kruger Effect). People who are capable of doing useful work seem to find these superficialities asinine and have difficulty hiding it, whereas people who aren't capable of useful work try as hard as possible to keep the focus on the surface level, because that's their only hope.
Since the surface level is immediately apparent and the importance of the subsurface may only become apparent after some experience, imposters can, and frequently do, find great success.
But I would say a lot of managers are trying to get their coders to be more productive with coding. When they introduce something like "assist points" which is really just a popularity game, it doesn't incentivize coding as they think it does. It incentivizes more socializing. Which frequently also means less productive with coding. Don't get me wrong I do need to work with my coworkers, but a lot of the time I need to be working alone, or just send a quick email. And I'll get punished for doing that even if that's the most productive thing to do.
On your theory--I think it depends. Sometimes it's "I'm insecure and need to compensate in some way, like expensive watches" but sometimes it's "I take pride in everything I do, including my looks." Also while in some ways I'd probably be happy to wear PJs every day, I understand that the easiest way to get more power in social situations and business is just to dress nicely.
The third category, of whom I’ve known several, is “capacity/competence, with an attention to the superficialities because they know how much those matter.”
That is, I haven’t found it to be an inverse relationship. I find it to be a 2x2, and if you happen to be someone with less capability and more ability to BS, then yes, you lean on your strength to obfuscate your weakness. But you can also be strong in both, or weak in both.
I also think there are a lot of jobs where deep mastery doesn’t generally exist (eg, mopping), and so those people just have no idea what deep competency discussions are like. It’s like flatland, only the third dimension is expertise and complexity.
A little bit of pushback on the more technical or capable people and they will start dropping the facade, whereas the less capable will just hold it up higher, because it's the only thing they know. They have no conscience accusing them of misrepresentation, no sense of guilt or concern that they may be drifting afield from an acceptable core. They only learn that they need to wear the tokens more convincingly next time.
So yes, you can have people who wear the tokens for expedience and out of a recognition that its important to fulfill the heuristics, but they're no competition for those blissfully unaware that there is anything else involved.
In my experience (I sort of enjoy fashion) most people cannot tell the minute differences between "tailored outfit & basic color coordination" and "total fashionista who keeps up with everything." I can walk around with a fake Coach bag, get compliments all day, most people just do not know.
There's exceptions of course, certain offices/fields of work. But it's not common.
How do you feel bonusly avoids this potentially awkward gamification/popularity contest? I feel like most people I know would just give 30 bonusly to a random person on the last day of the month, but maybe your colleagues are a little more disciplined :)
I'd be cautious of directly measuring "assistance" outside of peer input in perf to avoid an unhealthy incentive. The most helpful people I've worked with in the past tend to grow through strong peer reviews and having the most opportunities to join new projects.
The OP here really misses the point of demonstrating impact. Doing the right thing ethically then for the business is a strategy that is, well, rarely the wrong thing. Optimizing just for getting promoted might is a greedy strategy that might get you promoted once, but good luck finding peers that want to work with you again.
As a former manager, the closest I came was making a point to observe who was helping who within the team. And following up by asking people during their 1 on 1s if they felt anyone was being especially helpful to them, explained things well or not, etc.
People who helped their teammates very much got a boost in their prestige in my view, and that was good for additional job security or additional pay. If they struggled with a couple tasks, but had helped some teammates when they DID understand what to do, that very much increased my willingness to help them or give them extra time to figure things out.
In a previous company we had a better mix of peer reviews and input from technical leads (that were not your bosses). This was by far the best system I've seen to date for a company of that size.
In small companies there is typically good visibility into what everyone is doing. If you have good management then things tend to work very well. If you have bad management it can be worse than large companies.
One thing I've come to learn is that this sort of stuff, call it culture, has to be a priority for the company's leadership, they have to keep inspecting it and fixing it. They need to talk to people and understand their concerns. Otherwise it always drifts the wrong way. The Google system from what I read here sounds terrible.
EDIT: Having people try to optimize to play the system, just like the article describes, is inevitable so you must ensure the incentives are aligned. Make sure you find ways to look at the stuff that really matters and make sure you're not antagonizing your employees with your review system.
The metric might be a good idea, but I think the real problem goes deeper than that.
Take a step back and ask yourself a more fundamental question: should everyone who does good work be promoted?
By definition, promotions are limited and each level is more difficult to attain than the last one. Obviously, you can't promote everyone. Even worse, not everyone will be happier when promoted. So why does literally everyone want to be promoted? Why do they work so hard to get it?
It's because there are no other ways of rewarding good work. And by "rewarding", I don't only mean "giving people recognition" or "giving people fun work". Those are important and should not be overlooked. Nevertheless, if you don't also give people money, sooner or later they'll fall behind their needs or just the rising costs of everything around them. Then they'll have to choose whether they need money more than intrinsic rewards. And then we're back to the original dilemma: do I play the promotion game or do I just bugger off somewhere where I can get what I need?
TL;DR: Retention shouldn't be only about promotion. Give people real rewards and incentives for doing a good job at their level.
That's not really the case if the promotion ladder is a skills/experience based ladder and not a responsibility ladder. If being a "senior engineer" just means you have reached a certain level of proficiency, then there's no reason everyone can't be promoted to that level.
I think that's a better system, because one person may have 2 first author publications and 3 second author publications. Another person may have just 1 first author publication but 12 second author publications. So you can weigh and evaluate each person based on their assistance and contributions to others.
It has slack integration so sending /yei @someone is super easy. I probably do it multiple times a day.
I have to say, after it was introduced, there definitely was a slight shift in culture.
I strongly believe your 10x programmers are the ones that help the whole team become 10x by building great tools and showing best practices that makes everyone move faster.
Let's say there are 4 voters: A, B, C, D, voting on policies 1-10. Everyone gets a certain number of votes (say one per policy, so 10 total).
Voter A only really cares about policy 5 & 7. So they want to buy votes for these 2. They can give up their votes in, say, policies 1-4 to get 2 more votes for policy 5, and can also give up votes 6, 8-10 to get 2 more votes for policy 7. So they put 8 votes into the "common pool" in order to ensure that, in addition to their vote for 5 & 7, each policy also gets 2 extra votes?
I now recall that sqrt(1) = 1. I did not recall that 2 minutes ago.
FWIW, the paper describes it as a vote currency that can only be used for the vote, as opposed to cash you could spend on anything. The voice credits have to be distributed to voters.
'individuals pay for as many votes as they wish using a number of "voice credits" quadratic in the votes they buy.'
People who had a lot of "assists" at our company regularly brought in 1000+ points a month, which then translated in $100+ in amazon gift cards or steam points.
The only thing we know matters is the team does well or not. So I suggest trying different methods of building/running a team, and let them go. See which teams succeed and try to copy that success or give them more power.
To give some flavor to my idea - maybe the level of helpfulness you should ideally give is very low. Perhaps it enables weak members to suck up lots of time. We just don't have good data in this area.
From my experience it works amazingly well. It's silly, but if you are ever having self-doubt, a gift card from a coworker really helps.
I completely agree with you on this. Also, I like the idea of formalizing with "assist" metric, so that people are sure that their work won't go unrecognized.
However, you need to strike a balance between helping out peers and having impactful projects.
Just talk like normal people. The more you talk openly about who's contributing and who's not the easier it becomes.
However as the writer of the article pointed out often times you can't see when other people are improving your ability to do work whether that's through writing more documentation, improving some internal infrastructure, or other often invisible things that can drastically improve your life as an engineer.
I think an effective approach would be through time tracking (i.e: writeup on how you spent your time for the day) in conjunction with some analysis on how the time you spend on certain things correlates with what other engineers are doing. This of course would rely on everyone being detailed in their writeups and the analysis still might not catch certain things because it's difficult to write down exactly how you spent your time. Perhaps you could only write down the three most difficult/annoying problems you ran into and just track that.
I remember reading about some company that is trying to make this easier by tracking computer use and creating graphs of how people interact within their organization and how that changes over time but that doesn't seem like it would work everywhere.
I don't know if there is a way to truly quantify teamwork or organizational impact. I think the important thing is to encourage your organization to communicate more: talk about what you're doing, why you're doing it, and how it helps others within your organization. If your organization is fairly big write about it and share your writeup internally. Train people within your organization to speak up if they feel they aren't being appreciated for the impact they made.
Ultimately I think it's an extremely hard problem because it stems from the question of what having a positive impact means. The answer to that can branch off into millions of different small tasks that could be totally unique to a subset of people within your org.
----
The best you can do is:
* Measure what you can.
* Know that's not the entire picture and it never will be.
After that try to create a culture that:
1. Speaks up about their own impact
2. Shares the impact of others' work, especially of those who might not speak out much
3. Is openly appreciative of and encourages 1 and 2.
Although your peers saying you were helpful is not enough, you need to demonstrate impact (and other attributes depending on your level).
You'll see patterns in the upvotes and downvotes. The upvotes might signal "This person helped me a lot." The downvotes can catch interpersonal problems that might otherwise be hidden from you. For instance, someone on your team might be guilty of sexual harassment, but they are clever about hiding it from you. Your only clue will be that, say for instance, all the women keep downvoting that person.
While I appreciate the goal, I have been put in such situations before and must say I hate such questionaires and ratings. Of course they are not anonymous. And if that is so, do I tell the truth or do I lie? I don't want to lie. But I also don't want to cause trouble for my coworkers because of some misunderstanding.
Admittedly, I don't have a better alternative though.
For example, when downvoting: flip a coin, if it comes up heads, downvote that person. If it comes up tails, only downvote that person if you think they deserve to be downvoted.
Doing it this way, each person can be expected to get roughly 50% of people downvoting them. If the number is enough higher than that, then that person probably deserves the downvotes, but you can't tell who they came from.
Anyone from Shopify here? If I recall correctly, this was tried at shopify and has since been removed due to people gaming the system for their friends.
A point that Dev 1 gives to Dev 2 will not likely be equal to a point that Dev 3 gives to Dev 4.
This will be especially true if everyone has the same quota of assist points to assign, as people may very easily receive different amounts of help, and thus their "actual help per assist points assigned" values will differ.
There is a really great idea in there somewhere - create incentives for helping others - but I'm struggling to come up with a good way to implement it that doesn't just water everything down.
The closest I can think of is how repo commits can be counted/graphed per user. Works easily for code jockeying, but less so for softer talents like pair programming.
Basically it's a thought experiment in which all team members of a project (or group, etc) estimate the impact when losing various members of the team (whose work presumably is done by other team members or contracts) on the final cost.
Run some math on the data and you have a group estimation of the relative contribution of all members.
I have a theory that the reason more managers don't use this available tool is that it would probably rate management contribution on the lower end...
Players will game the system, the mere fact that the game exists itself will change the overall dynamics, this and that everything is in constant, natural change, all makes it necessary to maintain the gaming rules.
So anyway I think that was probably valued by our project manager who is also a former techie, because she probably realized if I didn't do it, that PR wasn't going in that release.
Sounds like a super fun place to work. ;)
Track management only.
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 they must distribute to people who help them the most.
While I don't love the idea of gamifying it, all the places I've ever worked have had too strong of a reverse incentive towards individual achievement, especially when it comes to promotion, and not nearly enough support for teamwork in specific and measurable ways.
Anybody have experience with teamwork metrics like this, or others that worked or didn't work?