Let’s see an article about measuring manager productivity.
IMO a manager's productivity is measured based on how well their team performs(or how well they present their team's productivity) and this article provides an approach on how to do so.
Engineering productivity can be measured, just not how you'd expect
71–80 of 122 posts
Re: Engineering productivity can be measured, just not how you'd expect
#72Earlier quoted context omitted.
What's missing from your assessment is how good the project itself is. Maybe Evan is a liability, but he might also be the reason why VueJS is popular and valued in the first place. It also seems pretty strange to me to count VSCode and GitLab in there, because those are worked on by companies with teams behind them that get paid and which will have constant churn. If you took VueJS, and had a team at Microsoft take…
> So I don't know that your explanation for the "risk" here has anything to do with "very high impact" When talking about risk, I mean immediate as opposed to long term. Obviously, if you pay people to take over vuejs, they can, provided they are qualified that is. But there is still the ramp up period and the risk of losing undocumented knowledge that Evan has, specifically with his understanding of "what doesn't wo…
I think my criticism is I'm not really seeing where in your data is risk or quality or success of the project quantified and correlated to this "very high impact" conclusion.
It seems you're inferring this "risk" from a qualitative perspective. Like hypothetically, we can imagine VueJS being more at risk of being abandoned because there's only one big maintainer. But VueJS hasn't been abandoned, and is doing well. So does the data support this hypothetical? And I'm also not sure how abandonment relates to productivity. If GitLab the company folds, that project will probably stop being developed and be abandoned, same as if Evan stops working on VueJS. Which one is more likely? No one knows, but companies can abandon an open source product probably just as much as community contributors. So I feel it's more about which one is more likely to be picked up after the current maintainers abandon it.
Re: Engineering productivity can be measured, just not how you'd expect
#73One thing that wasn't covered here is that productivity is about: > the effectiveness of productive effort and > the state or quality of producing something Those are quoted from the dictionary definition of productivity, and that definition in my opinion outlines a great insight. Productivity is about the "product" first and foremost. One thing that's often missing is teams don't have ways to quantify how good the p…
This is nearly always missed in my experience. A good product is "winning" for your engineering team, if you do not have a good product, you have lost. Would you have made a good product if your team spent less time in the locker room(meetings)? Maybe, and certainly more time on the field probably will increase your odds of winning, but it won't ensure it. This always takes me to USE YOUR PRODUCT. If you don't use yo…
> This always takes me to USE YOUR PRODUCT. If you don't use your product, you'll never know if it is good.
This is a bit absolutist. Sure, use your product when it makes sense like in your case but many people here build things for user groups they don't belong to (constantly).
Besides: are you hitting all the same use cases your users are and at the same rate?
This advice always sounds nice but it's impossible to apply for lots of people. More generically applicable advice is that you should be acutely aware of your users real(!) experiences. This can be by using the product or by making sure the team sees and hears raw user feedback. Preferably combined with data that helps prioritize.
There's nothing like hearing the frustration in someone's voice when they are trying to accomplish something and _your product_ is holding them back. (well, except for experiencing it yourself and then we've circled back ;) )
Re: Engineering productivity can be measured, just not how you'd expect
#74Measuring engineering can be a slippery slope towards stack ranking performance -- which ultimately hurts performance and culture. I think you have to measure with the intent to improve how your team works. If a manager can measure at the team level and open up visibility into the development process, they can hopefully find where things get frustrating (ex. waiting for someone to review a PR). That said, there seem…
I'm currently working on a solution that will try to quantify software development health, and what I've learned from analyzing thousands of popular open source projects, is you don't want a single individual to stand out. You want work to be fairly distributed to reduce knowledge risk. If you look at the busfactor section for the vscode and gitlab repository https://imgur.com/NfgvvTy (vscode) https://imgur.com/DK7rv…
[deleted]
Re: Engineering productivity can be measured, just not how you'd expect
#75The idea of identifying and removing a bottleneck isn't new. I don't know about randomly removing "blockers", it's generally widely accepted that only the bottleneck makes sense improving, everything else is wasted work as you'll just accumulate work in progress. People sometimes rebel a lot against this because "my code is a creative process and that's for factory lines" but I've never found myself worse off when improving a bottleneck, though you do have to fight the "but everything counts" crowd.
Re: Engineering productivity can be measured, just not how you'd expect
#76Earlier quoted context omitted.
This is nearly always missed in my experience. A good product is "winning" for your engineering team, if you do not have a good product, you have lost. Would you have made a good product if your team spent less time in the locker room(meetings)? Maybe, and certainly more time on the field probably will increase your odds of winning, but it won't ensure it. This always takes me to USE YOUR PRODUCT. If you don't use yo…
> This always takes me to USE YOUR PRODUCT. If you don't use your product, you'll never know if it is good. This is a bit absolutist. Sure, use your product when it makes sense like in your case but many people here build things for user groups they don't belong to (constantly). Besides: are you hitting all the same use cases your users are and at the same rate? This advice always sounds nice but it's impossible to a…
> This is a bit absolutist.
Granted.
> many people here build things for user groups they don't belong to (constantly).
A root of the problem. If you have no appreciation or desire to solve a problem well, you won't. There are very few pieces of software written for users that you can't figure out a way to use. If you can't use it, observe users, if you can't observe, ask users, if you can't ask, instrument their use. To your absolutist point, yes, it is not strictly an absolute, it is an encouragement to push as far along the empathy spectrum as you can.
Re: Engineering productivity can be measured, just not how you'd expect
#77Earlier quoted context omitted.
> So I don't know that your explanation for the "risk" here has anything to do with "very high impact" When talking about risk, I mean immediate as opposed to long term. Obviously, if you pay people to take over vuejs, they can, provided they are qualified that is. But there is still the ramp up period and the risk of losing undocumented knowledge that Evan has, specifically with his understanding of "what doesn't wo…
I think my criticism is I'm not really seeing where in your data is risk or quality or success of the project quantified and correlated to this "very high impact" conclusion. It seems you're inferring this "risk" from a qualitative perspective. Like hypothetically, we can imagine VueJS being more at risk of being abandoned because there's only one big maintainer. But VueJS hasn't been abandoned, and is doing well. So…
> It seems you're inferring this "risk" from a qualitative perspective
Yes this is correct, and I do want to make it clear that a project that is spearheaded by a single person like vuejs can still be a great product. And in no way am I trying to quantify "quality". I'm just saying, if you want to build a commercial/open source solution that uses vuejs vs react, angular, etc. this is the current state of its development/investment.
For some people/companies, this isn't an issue, because they feel the quality is worth the risk of having to take ownership of it themselves.
I guess the way that you should think about my statement is, "would you as a CTO for a company, be okay with having internal projects with development patterns like vuejs or would you try to create development patterns more like gitlab and vscode"
Re: Engineering productivity can be measured, just not how you'd expect
#78Earlier quoted context omitted.
Productive software engineers aren't "exceptional". If you focus on removing obstacles, you can make most software engineers productive. The point is learning from those who've succeeded before you, instead of claiming it's just magical chemistry happening. Or worse, starting again from first principles. No, that won't produce product-market fit, nor does it open up once in a lifetime opportunities, but it allows tea…
There are reasons why terms like 10x engineer, Rockstar engineer, Ninja engineers are thrown about in the industry. Google paid Anthony Levandowski $120 Million to lead their autonomous car project, before he went to Uber and the legal troubles. Uber was paying him more than Google. Facebook paid $16 Billion for What's App, which only had around 50 engineers at the time. Facebook was buying the IP and the productive…
Facebook was buying the IP and the productive software engineering members of the team.
Facebook was buying the customers. If it was just an engineering problem they could have done it on their own.
Re: Engineering productivity can be measured, just not how you'd expect
#79Good work. That is how it should be measured.
In economics as far as I know, they measure productivity via salaries. The more money people make, the more productive they are assumed to be!
Re: Engineering productivity can be measured, just not how you'd expect
#80I have to disagree with the idea that sales is somehow becoming a scientific process due to CRM. There are openly gut feeling fields like how a call seemed to go, how "hot" an opportunity is, etc.
Most of the ideas predate software as well. People had remarkably complex paper based sales systems.