> It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or w

> It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations. Visibility metrics don't always correlate well to actual productivity. Interesting. As a visible person, I see the opposite of this. I'm currently in an IC-ish role. In this role, I am the one who speaks most in meetings, most talkative in company chat compared with the rest of my team (they rarely write anything, weeks can go by), and spend more time putting together documentation and reports (even when the whole team is asked to in theory, it seems to fall on me). This makes me the most visible, but it's having an undesirable effect for me: I'm highly productive in the sense that I've closed several longstanding issues that were considered hard to solve and lingered for years, and will continue to do that with all major issues in the project. I'm confident it's the right approach, because of the project's history and some consistently missing or broken functionality, that if I didn't do this, the product would be an endless tarpit of not-quite-working enough for end users to actually choose it. But my way of doing this produces fewer PRs than the rest of my team, noticably so. As a review put it, "their productivity is measured more in quality than quantity". That's because I think hard about what the actual strategic goals are, figure out solutions to problems everyone else seems to consistently skip over even when they are long-term showstoppers, and actually put together a working solution. Some of these are just clever bugfixes in poorly understood areas. But in other areas you could say I'm re-architecting and developing new techniques, figuring out parts that work well together and how. But I'm definitely not the parochial "architecture astronaught": My hands are dirty with plenty of coding, and to be honest I'm not sure there is another way. In my experience some techniques used have to be demonstrated in working code before people will recognise that they work or that they provide an advantage, e.g. in significant algorithmic complexity, or changing something from taking days to a few minutes, or reducing a terabyte of storage to a hundred gigabytes. Talking about it isn't enough and short write-ups don't convince either. A thorough writeup would be a lot of work itself (eg. like an academic paper is a lot of work), and would be considered a waste of time by others I think, and probably ignored as acedemic papers tend to be anyway. It should be done after, rather than before, a working implementation. Some things, you can spend weeks talking about and nobody seems to pick up the real point. Or you can ship a surprisingly short PR that makes something work that didn't before, and it's a breakthrough. And management might see it as a mere bugfix, or they might recognise why it took time and is valuable. It doesn't help that we are all in different timezones; it's fully remote, and the team operates in a very atomised way, hardly talking except in management meetings. I hope to change this eventually but for now I need to work on shipping technical solutions to major areas that I don't think will be solved without me doing so. I'd love to be do this more collaboratively. But at least for now, my teammates don't seem to have the relevant knowledge and understanding to help effectively with the parts I'm working on, and one doesn't seem to want to be helpful anyway. And, how to say this - they very rarely communicate except to comment on PRs and in management-led meetings. One set up this obstacle a month after I joined: "You can't expect a new person to know what needs doing on a project" (that means me), they want tasks from "people who have worked for years with the project", which makes collaborating in the same areas a real time sink with respect to progress. So back to the point of gauging who's actually doing the work: I'm highly productive in one sense: I'm making transformative changes that will help the company and its product achieve their stated goals, and I'd go a little further in this instance and say I don't think they would achieve it without someone on the team taking my approach. That's why I'm doing it. I'm definitely conscientious and working hard. The changes are visible: The effects can be seen and enjoyed as well as making the product more effective. But in another sense, I'm gauged as not particularly productive for two reasons: I'm most visible (because I talk in meetings, etc.), and I ship fewer PRs than others on the team. My teammates ship something more often. It's good that they do, as to be honest one of them often appears not to understand the context of the component they are working on (from basic questions in management meetings), but gives a good story of working hard and shipping something. Their work isn't wasted, it will eventually be used, but someone will still have to develop it further to use it. It's interesting to see that by me being more visible in explaining what I'm working on and why, there ends up being more attention on basic metrics of my output in management meetings. More time is spent by management asking why I haven't produced X and Y, and that I "need" to ship PRs more often (I'm struggling to figure out how to do this effectively given what I'm working on, though). In the same meetings when my teammates also haven't shipped anything, this doesn't seem to get much attention. I imagine this is almost entirely due to my talks setting high expectations, and the management's idea of what they are looking to see. Politically I think I'd be more secure just staying quiet, and churning out more basic bugfixes and minor features, knowing that the project is kind of doomed due to key unsolved technical issues, instead of dealing with those issues and explaining how the solutions work. So who "doing the work"? I think it depends on what you decide productive means. I think it's valid to decide that I'm not productive from a certain point of view, but it's also valid to decide that I'm highly productive from another point of view. My own take on it is I'm doing the right thing for the company and the project, specifically in terms of management's stated goals for the project, but that it's not well understood or particularly visible to others at this point in the trajectory which means I'm taking a personal risk doing so. (I don't think it's much of a project risk (except for bus factor). And if our team wasn't so atomised, or if we had similar knowledge and understanding, there wouldn't be the bus factor either, but we have what we have and changing it will have to wait.)