Master the Art of the Product Manager 'No'(letsnotdothat.com) |
Master the Art of the Product Manager 'No'(letsnotdothat.com) |
Assuming a PM cannot comprehend entire roadmap, vision and details in their head, simply have the answer based on merits.
This is the intercom post from 2013 on the same topic - https://www.intercom.com/blog/product-strategy-means-saying-...
Anyway, copied the "reasons" here in case you want to use it locally. e.g.
## bash:
shuf -n 1 why-not.txt
const sampleData = [
{ "text": "Let's add that to our discovery backlog" },
{ "text": "What problem are we trying to solve?" },
{ "text": "That's an interesting perspective for our long-term roadmap" },
{ "text": "Let’s park that idea for now" },
{ "text": "That’s worth considering once we have more resources" },
{ "text": "We should validate that with users first" },
{ "text": "Can we revisit this after the next sprint?" },
{ "text": "It’s a great thought, but let’s prioritize our current goals" },
{ "text": "I’d like to hear more thoughts on this from the team" },
{ "text": "Let’s circle back after we’ve tackled the core priorities" },
{ "text": "We need to ensure alignment before moving forward" },
{ "text": "That might be more relevant in the next planning cycle" },
{ "text": "We should let this marinate a bit longer" },
{ "text": "Let’s pencil it in for further discussion later" },
{ "text": "Let’s table this for now" },
{ "text": "That’s a good thought, but let’s revisit it later" },
{ "text": "Let’s keep this in mind for future consideration" },
{ "text": "We’ll need to assess this in the context of our current objectives" },
{ "text": "Let’s put this on the back burner for now" },
{ "text": "Interesting idea, let's explore that next quarter" },
{ "text": "We should prioritize getting feedback from stakeholders first" },
{ "text": "This might be a phase two initiative" },
{ "text": "That could fit in a future roadmap iteration" },
{ "text": "We’ll need to revisit this once we’ve hit our milestones" },
{ "text": "Let’s gather more data before moving forward" },
{ "text": "I think this could be valuable down the line, let’s revisit then" },
{ "text": "Let’s schedule a follow-up on this when the time is right" },
{ "text": "This could be part of a larger initiative, but let’s hold off for now" },
{ "text": "Let’s focus on the immediate deliverables first" },
{ "text": "We’ll circle back once we have more clarity" },
{ "text": "We already finalized our OKRs for H1 but if you throw it in the backlog maybe we can get it prioritized in H2 planning"},
]0. This idea is bad.
1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting.
2. This idea needs to be more fully developed before we can decide whether it is good or bad.
3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a priority.
4. This idea is good, and while it is not a high-enough priority to displace our current tasks, we will actively discuss including it when we plan our next sprint/release.
Depending on who you work with these may need to be gussied up with manager-speak to let people save face or to prevent people from hijacking the agenda to turn the meeting into a brainstorming session. But treating all of them as synonymous with "no" loses useful nuance.
1. The idea is technically feasible
2. The idea aligns with company's business goals
3. The idea is our team's responsibility and cannot be done by another team
4. The idea is more important than the other things our team plans to work on in the future
5. The idea is more time critical than the other things our team is working on now
If any of these cannot be proven, then it goes on the backlog as a P4 and nobody realistically will ever look at it. It's just the reality of corporate software building. There are always 10-50x more ideas than there are staff/time to work on.
Of course, all five of those can be, and often are, overridden by the Prime Directive:
0. One of the executives (often one of your grand-bosses high up on the totem pole) wants it.
Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more into it.
At the end of the day, ideas are just ideas. Execution is everything.
If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable.
If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.
Is it really true that your company cannot implement any idea that could potentially be done by more than one team?
Option value is a notion that Don Reinertsen promotes in his Lean 2.0 notion (google that and his name, mandatory stuff for wannabe PMs IMHO). Very simply put, he draws an analogy with stock options. They give you an option in the future to get some value. But there's a chance they'll be worthless and that you lose your money. The point is that the payoff can be much larger than the value loss. That's why they are popular tools for stock traders. There's a non linear relation loss-profit function. Which means you only need a few of your options to convert to profit to finance all of them. VC capital is based on this notion as well. Most startups are a write off. But a handful turn into unicorns and pay for the rest.
In product management, option value is the notion that some idea might be worthless but could end up being worth a lot. Doing a lot of work on something that's just not worth a lot is probably wrong. Doing a little bit of work on something that might have a huge payoff is probably smart. Even if it's slightly risky or uncertain. Doing a lot of work on a lot of things that might be valuable like that at the cost of stuff that you actually should be doing is probably not optimal and very risky. But you should be taking some calculated risks at least part of the time just in case. Worst case you lose some time. Best case you create a lot of value in a way that you never planned to. Balancing risks is your job as a PM.
The point here is that if you only do planned things and don't even entertain doing things that might be valuable outside of that scope, you are probably destroying a lot of value and you are placing a risky bet on your plan instead. If the plan is wrong, you might lose everything.
Which is one of Reinertsen's key arguments against the original lean movement. You throw out the baby with the bath water if you do that. Bad idea for startups because you now make a risky bet on your plan being correct. Which of course it often isn't in startups. Pivoting is the notion of being able to turn a bad plan around. That gets easier if you invested in some option value that gives you the option to do so. A lot of unicorns emerged out of the ashes of failed startups.
Big organizations are notorious for being risk averse and not having the internal capability to innovate even after they've identified the need to do so. As soon as management chains get involved, that's what happens.
As someone who has reason to call technical meetings on a regular basis, I've always had trouble with this. Do you mention 'brainstorming' in the agenda? Do you use a different header?
Most of the meetings I end up having are only vehicles to get necessary players into the same room and engaging in dialogue about a problem with a technical angle.
Advice appreciated.
I've personally found you should almost never need more than 30 minutes unless you specifically want to get into rabbit holes. And if you do need more than 30 minutes, it's probably better to split it into multiple sessions of no more than 30 minutes anyways to prevent this from happening. If you still have this problem at 30 minutes, shave 5 from either side (or both), which you can even use the excuse of giving time to transition between meetings.
That's not to say you shouldn't genuinely allow room for brainstorming, but if you're going to take an entire room of peoples time, make sure it's something the room agrees is worth discussing and find another time to do it instead of getting sidetracked now. If not, offer some 1-on-1 time, and move on.
The way I deal with this is several custom fields in our issue tracker kanban board that qualify any idea, no matter how good, crazy, in-feasible, etc.
The most important ones are:
- Value & Effort (one field) this is a quadrant of HighLow, HighHigh, LowLow, LowHigh. It's a reflection on what we would get out of doing something with the idea. High value and Low effort means you need a good reason not to kick an idea further. Low value and High effort kind of means a no, unless there's a really good reason. Anything in between can be decided on a case by case basis. I like the Low effort ones. They may not be that valuable. But sometimes they are nice to do. And you can just squeeze them in.
- Next Step: This is a range of values that provide me an indication of when I should look at it again. Some things need to be fast tracked. Some things need more discussion/elaboration. And the rest is stuff that we might revisit or reject right now. I don't tend to spend time on rejected ideas unless somebody brings those to the table again. Things that linger too long without being actioned are going to end up labeled as rejected. Which just means they stop consuming my time.
I have a few other fields (tags, priority, etc.) that are a bit more standard. But those two are the primary tools I use for deciding where to bucket ideas and how often to look at them. I should spend more time on high value ideas than on low value ones. And I should prioritize actioning items that have a next step that says I should do so. Anything else I can safely ignore indefinitely. If somebody doesn't agree, we can always discuss and change it. But there needs to be a good reason.
This isn't perfect but it's a good mental model of dealing with incoming ideas in a bit structured way. I hate overly long and poorly organized backlogs because they suck up a lot of time and energy without delivering much value. And the longer and more unwieldy they get, the less likely it is anything will happen. I sometimes refer to these things as idea shredders. Good stuff goes in, and then nothing happens.
Anyway, I'd be curious to learn what others are doing with their backlogs.
Just be direct and realistic. If it's to a customer, "we'll add it to our backlog for review" and tag it as customer suggestion so it doesn't just sit there forever.
1: Don't worry, nothing's going to happen.
2: Something may be happen but we should wait and see
3: Maybe we should do something about it, but there is no clear action
4: Maybe there was something we could've done, but it's too late now
Stringing along a bunch of people who think they are being heard and listened to when you are not is a morale killer when the tide goes out & we see who's been swimming naked.
In all seriousness, the best thing is to have management that clearly communicates what the high level company goals are on a quarterly (or whatever cadence is appropriate for your business) basis. People don't like to hear no, but they understand "the main objective for the quarter is to close $X in new deals in Y market segment, and since this isn't going to directly contribute to that, it's not going to be a priority in the near future."
It's a great idea in theory until you see how much two full days of timeboxed planning every quarter beats down dev morale in practice. It's great for teams that literally don't know what they're doing and don't know their dependencies, because it forces them to confront their mediocrity. But you have to move beyond it eventually.
One reason they persist in their insanity is everyone is an expert in giving excuses why their own team is too tied up with work to assist. Sure this reduces conflict over telling middle-management why their ideas are stupid, but in the long-run it's detrimental to the organisation to avoid explicitly hashing-out disagreements. Creating a culture where everyone lies to avoid hurting one another's feelings is not good.
You often still need people to feel like their ideas are being considered so they don't just shut down and contribute nothing in future meetings, or consider you to be railroading every meeting.
Granted, after the meeting, I'll often joking-but-only-serious point out "Look, our backlog is really long -- let's be honest, we're not going to revisit <that> for months at this rate, so I hope you realize it's not a priority and probably won't be unless the priority changes. If we need it on a shorter timeline, talk to <personName>."
I have very occasionally used hard-shutdowns of ideas or requests, but I think I have only used it when an idea was threatening to balloon the scope far beyond any hope of success. Maybe twice in the last few years.
("No, I'm not going to implement it that way -- it's needlessly complicated" or "I will not discuss timelines for phase 2 of this project until phase 1 is complete -- let's get back to closing out the outstanding issues with phase 1.")
There's a time to be frank, and other times you need to smile and gently redirect just to get things moving again before you waste an hour sparring or circling an endless unresolved debate.
Inside a company, I don't think there should be space for these sorts of responses. I can see these only being necessary/used where people are disenfranchised and not involved in setting or understanding the overall product priorities. But then I've always seen the PM's prioritisation role more as an expert mediator than a dictator...
I think its a funny website to browse and say "haha", but nothing more.
In practice, there is no easier way to annoy these types than by taking these platitudes at face value. Don't go gathering the data.
(I get why this style of communication has become common in business settings, especially in large orgs. It still rubs me the wrong way.)
Food for thought, don't make someone say no as often.
Nothing wrong there, it's not "no". Sometimes we put ideas on ice until there's time, or other factors align.
If your role is long-term, you have the underrated power of long-term planning. Often in past I saw the desire to tear down and hastily build something amazing in a few weeks, rather than chip away long-term where "amazing" gradually fades into view.
This one time, I was asked to make a countdown timer for new website launch, back when I worked with PM's who thought users gave a shit about website launches.
I am not sure what this site adds other than the ability for the uncreative to find snarky ways of telling people to fck off.
/s some, some PMs try and build product, most are large corps are figuring out how to segment their niche and extract max rev from the tech ladder
Nearly the entirety of this discussion outlines political and organizational dysfunction.
Blah blah blah the interests of the business. Fuck that. Capitalism sucks the joy out of software.
You'd think "it does X, Y, Z, and nothing else" would be clear-enough, but in practice a blanket prohibition is too vague to have force, it's an invitation for scope creep. So saying "it will not handle W" is useful, even if it seems redundant at first glance.
(Context: https://www.youtube.com/watch?v=hNuu9CpdjIo&t=56s)
Sales Engineers for example are trained never to give the hard No to a customer request. Sometimes, they think they are saying no but the customer hears, "maybe". For example, "we'll consider adding that to the roadmap". Now the PM is stuck developing a single feature, the customer just got handed a stick to beat you with, and your CFO just got lumped with revenue thats unrecognize-able until some feature ships in who knows when.
The features were typically well implemented and integrated with the rest of the product, and totally unused.
The features added substantially to the complexity of the code base. It's funny to see HN defend quality over quick and dirty software. Though I understand and agree with the sentiment, the unused features were much more difficult to remove because of their "quality" (as measured in the eyes of the dev team).
Rarely have I met one that can define actual priorities outside of this.
[0] https://en.wikipedia.org/wiki/List_of_countries_by_greenhous...
1. No such crisis exists
2. Why would you believe such a thing?
3. It's too early to draw any conclusions before the full investigation
4. Look over there, a new scandal
Reminds me of a product owner I had who abused priority categories by insisting that the majority of his tasks were "top priorities" because he had discovered that any time he didn't mark a task as a top priority it wouldn't get done.
Every team ended up sorting his tasks as a flat list so that when he asked people to "make this a top priority" it was up to him to decide where it went in the list and which of his other requests would get bumped.
[1] They either use the fact that they are fixing that thing as an excuse to not work on or deliver on time a different, more important task. If that happens, obvious questions about prioritization occur.
[2] They want a substantial amount of credit or recognition for doing it. Usually such fixes don't receive exec attention (since execs are tracking more important projects) and so don't get the same due as a properly tracked project does.
As an org grows the piece of the Effort Pie that is Development gets smaller and smaller. It's not that development gets easier, it's that every other part of the process grows in size and importance faster than the Development piece grows.
It takes about an hour of developer time to incidentally produce 20 hours of work elsewhere in the company.
Though that doesn't map to the 4 stages of stalling - it's a stage 5 - the oh crap stage.
(I guess one could also consider parts where people don't live yet...)
Prioritization isn’t always black and white.
These qualitative factors matter and shouldn’t be ignored. As always, you weight it against other trade offs.
Look at the end of the day you should be cultivating fellow thought leaders because when you grow up you learn your priorities are more often than not just your own egotistical nonsense and wrong. But you have a lot of phrases to cut others down.
Try something different.
Some people don't realize the value of something unless you show it to them. It's a risk for sure but honestly it keeps me sane vs trying to get 10 people aligned before starting something and then running out of time.
People will happily take credit for your work after it works.
Use sparingly of course, weigh in time for making the argument, but this is an artifact just as a convincing research, text or a plot. code can be part of the argument.
The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day.
The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the source code, it was purchased from someone and copied into the repo. I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen.
So I told the team that I think I can rebuild this thing from scratch faster than I can fix this bug. The intermediate db is pointless and most of the library code is dead, the rest is garbage. I can make a simple little thing that does exactly what we need better, faster and easier.
Nope. No bueno, fix what we have. So I spent a few hours over the weekend, less than a workday, building the new solution. Come Monday I had it pretty much working, a few things needed to be done but it already supported the use case. The pages were built correctly, they had the necessary content but some things were a bit messed up, nothing difficult to fix.
Showed it to the team, said I want to use this and delete the old stuff - nope.
The only half-decent explanation I got was that the client had paid a way too high amount of money for this garbage library and I guess the team lead didn't want to tell them we wanted to throw it out or something like that.
I got my ass handed to me by management for not going through the proper processes.
I learned something that day: I never want to work somewhere that engineers serve the processes and not the reverse. There are some that are good and necessary: like “thou shalt deploy via CD and not SSH into prod to edit code”. There are others that only exist to serve bureaucracy, and those try my patience.
I would probably be skeptical if somebody made these statements. You don't know what's wrong and you declare the code to be pointless. Maybe you put a good effort into it but I have heard it too many times that somebody declared "this is all crap. we need a rewrite". Most times they just didn't put the effort into understanding the current code. And usually the time to get to "pretty much working" is often only a fraction of what it takes to "totally done".
- "Pretty much working" means all the fun stuff is done and the actual hard thing is left to wrap up. It's a useless estimate that only accounts for your coding work, which is usually the smallest amount of work performed on an integration feature like this.
- It's a rewrite so we've gotta do a full regression test on every piece of data that thing pulls back. Since it's old functionality it's not fully covered by our automated tests, so this goes to QA. Our QA team is overloaded so this unauthorized, not on the roadmap project now needs to jockey for priority with things that Marketing is literally making artifacts for _today_.
- "It's already built" isn't really a justification for a priority change, so now I'm in the awkward position of changing priorities for a non-roadmap task and justifying this to every single stakeholder who is respecting the process, or telling you it'll be 2 months minimum before QA can even think about it. Either way no one is happy and now I have to worry about you going rogue again and trying to work channels around me to get this thing shipped out of band.
- It's a full rewrite and going through manual QA, so it's nearly guaranteed that critical, but undocumented business rule fixes were missed. Somewhere in that library is a weird function holding up the world, but it was "obviously cruft" and left out. There's a good chance we won't find the issue until it has already polluted a ton of Prod data. That's why I won't let you do Developer QA. You've only been here a year and this service predates you, me, and the rest of the team, we literally have no context.
- If the client finds out we did a full rewrite, they too are going to do a full regression test on their end. Do you know the size of the shitstorm this is going to bring on us? Every single question, problem, feature change, bug, enhancement, communication, _everything_ we went through over the last XX years since we built this integration is going to resurface. I get re-litigate every. single. thing. "Since you're working on our integration can we get XX, XX, and XXXX?" (each is a sprints worth of dev time minimum), "YYY isn't working, did you guys break it again?" (it's always been broken but now someone gets to spend 3 hours in Datadog pulling logs to prove this).
- I've been using the "Rewrite This Library" and "Refactor That Service" projects as leverage to negotiate for more budget to bring on 2 more headcount so that we could actually do those rewrites with proper time and space. You talking about getting 80% done over a weekend has completely undermined the work I've put into this effort, and at the same time didn't remove the Refactor issue from my backlog. Now I will essentially have to shit-talk you in my own 1-on-1s in order to regain lost ground. "sfn42 is a decent developer but he just doesn't have a lot of context to what's happening outside his role. Needs more time in the oven before he gets the bump to Sr. Maybe I can pull him into more planning meetings so he can start growing in this area" -- congrats you just got invited to 6 hours of meetings a month regarding work you won't perform.
- In 6 months when our team is planning out some future work that's just way too much for the headcount & timeline we have, and you bring up "we could really use another Sr. Dev or two, any word on our headcount request?", I might reply politely with a "still no word if we can pull that off this quarter", but internally I'm wondering if the pain of bringing a new dev up to speed is less than the pain of working with you.
- Lastly, the most petulant reason, you were told No last week. I'm sorry you lost a weekend to this, but a No is a No and I need you to understand that. Other things are happening at this company outside the scope of your purview.
Again, this is all drawn from my own experience. I had a mid-level dev show me a huge refactor he started on the weekend. He was convinced it was almost done, "just a few small things left" is an exact quote. However I knew that this part was literally the smallest bit of the effort. I was seeing at least 3 months of work across 4 departments before it would actually be Done, in Production, and working to our satisfaction.
If I had the space I would normally be just fine letting the young fella just experience that pain. Make him do the scheduling, put him on point for everything, and just let him spin on it for a month or so. I did not have that time and space, so instead we spent a few hours white boarding out the rest of what needed to happen, and thankfully he mothballed his project of his own volition.
We need to do something, my manager thinks it is too complex and we do not have the time, I have not been able to convince him (I am another manager), and yesterday I told my guy ... if it takes you X days, just do it and we will tell him later. He will find out after the coup and post-facto I can always justify it "oh we had so many other things going on, we never got to talk about this".
And my goal is to show that its value is more than the effort we spend with the workaround.
Even then, there's some nuance. During an outage, cowboy coding can get you back up and running much faster.
There was no reason all these data mutations couldn't have been in one place instead of all over the place. There was no reason to store it in one db then get it from that one just to store it in another db. Someone said the third party api was slow and unreliable but I don't see how that's relevant - if the api is down then you don't get updated data, it doesn't matter if we have outdated data in an intermediate db. We already have that outdated data in our main db and we'll get updates when the api starts working again. During testing I had absolutely no issues with the performance of the api, it transferred all the data we needed in a completely acceptable amount of time, and this was just in a nightly scheduled job anyway so if it had taken a minute that would have been fine as well. But it didn't, it responded in milliseconds. I never noticed any unreliability on their side either, but if it had been unreliable that would have been totally fine. The app just wouldn't have gotten updates until it started responding again. Nothing can solve that problem.
I honestly can't remember what the actual problem was or how I fixed it in the end. The code had been in production for years and only received the minimum necessary amount of changes. Some dependency or something probably broke from years of nobody wanting to touch that huge piece of crap.
But that's not why I say it was bad and pointless. It was bad because whoever wrote it didn't know about libraries for xml parsing and had implemented all of the parsing from scratch with string operations. We're not talking about real parsing here with lexers and tokenizers and stuff. We're talking about what you might expect if you gave a mediocre first year CS student the task of parsing some specific xml. The db interaction was similarly overcomplicated and outdated, and the code itself was sloppy and full of old messes nobody had bothered to clean up.
All it did was get some data, store it and make it available through some method calls, and for that there were like 50k loc most of which was dead and most of the code still in use was that monstrosity of a homerolled xml parser.
The things left to do on my new solution were trivial. Some of the columns had html tags and stuff like that in them, it just needed to be cleaned out where necessary. Some other stuff needed to be modified a bit. I did not skip it because it was hard, I skipped it because it was tedious and I didn't want to spend all the effort before I got the green light, which turned out to be a great decision because it didn't get the green light. And they probably still to this day waste man-hours on keeping that piece of crap running.
That's kind of my whole point - the "quick fix" took longer than a proper fix would have.
It's ok, you can say it was a bunch of regex.
But this was not complicated. I have underestimated refactors before, this was not one of those times. This was a simple little thing, just getting some data from point A to point B. It would have been easy to verify that the new solution generated the same pages (data in db tables) as the old one.
I didnt undermine anyone. I brought it up in a team meeting, I didn't take it to the department head. Sure I had been told no, but that no was based on the assumption that I was wrong about being able to replace it easily. My weekend coding was simply to prove that it could be done, which I did whether anyone believes me or not.
I really like your last paragraph. You didn't just say no, you walked through it with them and helped them see the problem. I am convinced that the only real reason this did not go through was because nobody else understood the problem. None of our team members had worked with that particular component, everyone were about as new as myself and dismissing my concerns without consideration. Most of all the team lead who hadn't written a line of code in decades and had absolutely no concern for code quality. The review mechanic in that team was push to test, have lead click through website to see if it seems to work, push to prod. Lead did not give a shit what the code was like. The quality of their projects reflected that.
We had over a dozen different apps and pretty much all of them were chock full of bad code written by unsupervised juniors on a tight deadline. All the apps used the same CMS in the backend but nearly all of them had a different frontend approach because they just let people pick whatever - one day you're working in Vue, today it's react, now it's angular, here's a svelte app, this ones just using jQuery and here's one just using vanilla JS. While I was there they let another guy start using a different CMS for another new app, because we didn't have enough problems with all the different js frameworks already, let's start using different backend frameworks too!
Hardly a single test suite anywhere except what I'd made. Everywhere I looked I found bugs and terrible code, every task I got I had to start by figuring out today's flavour of JS framework then try to understand how some junior using this project to pad their CV with the newest JS framework had mangled it together into a somewhat usable website and then how to make the changes I needed to make which 90% of the time was 29 times harder than it should have been because the entire thing was a complete mess hacked together asap and then duct taped, Jerry rigged and beaten with a hammer periodically over it's years of service.
I moved on from that team pretty quickly, and got into a different team much more in tune with my views. About a year later I was talking with two of my old team mates who had been somewhat annoyed with me and all my nagging about testing and code quality back then, at that point they had worked on some of my solutions and felt the benefits of the tests I'd created and the way I actually organized my code to make it easier to understand and work with. It took me by surprise when they flat out, unprompted just told me I was right. When I was working there I had a hard time because everyone disagreed with things I considered basic facts, I started to doubt myself. Luckily the next team was already doing all those things I wanted to do and more. Now I know that good code does exist, the methods I advocate do work, I wasn't just imagining things. That other team was just badly managed.
That's not to say everything I've ever done has been gold, I've made bad decisions and learned from them. But I stand by replacing that old integration library and I still don't believe in this "legacy code" mindset where changing some old pile of crap requires buy-in from multiple different stakeholders and so on.
I might get it when we're talking about large complex, business critical systems that really do require weeks or months of work just to replace a small part. But what I'm talking about is a small website developed in a matter of weeks that's hardly much more than a glorified pdf and where the code behind it has absolutely no business being as complex as it is. Even if my suggested change had broken some requirements they would have been quick to fix because the new code was clear and simple. And the worst case scenario would probably be some messed up formatting in a small article that hardly anyone is going to read anyway.
It should not have been a big deal.
But maybe you are right. That's also very possible
Because, they hear that a lot.
Then there is the misconception that China doesn't care, but their cities are a lot greener and prepared for transitioning to green renewals than many west countries.
Simple air quality indices would disagree. And greener than who? Are you going to cherrypick cities and energy mixes?
You're still not offering a solution (carrot/stick) to "support" a solution.
Air quality and industrial pollutants are a good example. Right now, China is prioritizing industrial expansion and energy stability until they hit whatever targets they have in mind. They'll be talking about carbon and pollution publicly once they can shut down their coal plants without destabilizing the grid.
Deprioritizing is not caring. Saying otherwise is crazy!
China literally produces the most solar panels, electric cars, and batteries by far. In 2022 83% of new electricity generation in China was renewable (https://news.ycombinator.com/item?id=42037497). That doesn't scream a country that "doesn't care".
They might be building a lot of new coal plants, but they aren't actually using them more than they already did (see above). Why would they waste their coal? They build more solar panels than they know what to do with, the sun is free, and they don't have NIMBY groups holding up construction.
Except not.
See this research showing that their domestic demand (ex-energy transition exports) is still massive and growing [0].
You're not alone as many on HN seem to have this misconception about greenwashing. The reality is different.
I'm saying the people who live there would emit the same amount whether they were 10 countries or 1. "China bad because total emissions" only comes up because they're 1 country.
> their domestic [energy] demand is still massive and growing
Of course that will happen as they develop their economy and improve their standard of living. But most of the new energy generation - 83% in 2022 - coming online is all renewable.
Would you suggest they don't develop, and remain poor? They'd be justified in saying "You first, rich Westerner". People in gigantic SUVs shouldn't throw stones at people in electric cars.
https://ourworldindata.org/grapher/co-emissions-per-capita
[1] As somebody has pointed out below - a lot of those Chinese emissions are ultimately produced for use in other countries. Places like the UK have simply shipped their emissions overseas - then complain about these countries rising emissions.
[0] https://dialogue.earth/en/climate/chinas-manufacturing-pushe...
> As somebody has pointed out below - a lot of those Chinese emissions are ultimately produced for use in other countries.
Not really. See domestic power demand growth for non-green applications. [0]
You are also forgetting total carbon emissions over the lifetime of a country - developed countries are responsible for a lot of the carbon in the atmosphere - and while developing countries might be catching up in day to day emissions they are nowhere in catching up in total emissions.
China is at 30% renewable energy. The US is at 21%. And the president of the dirtiest country in the world, lots of smart people are saying it, that's just what they call the US these days, they say, passed an executive order to ban new solar and wind power. Sad!
If China is using more renewables, then why are they producing way more GHG? See how this line of reasoning is flawed? This reality undermines your snark about having a higher % mix or per capita production, which is an incomplete rebuttal and serves greenwashing arguments.
https://www.collinsdictionary.com/dictionary/english/per-cap...
Some useful terminology for your journey.
Imagine you have a buffet. You have five people who each take 1 steak. Then you have one person who takes 4 steaks.
You are the person saying the one person taking 4 steaks is okay. The problem is the selfish four people who are eating 1 steak each. If they all stopped, the other guy could have 9 steaks.
Which is of course a silly proposition. The one guy could simply eat fewer steaks.
China is also the center of world manufacturing. The fact they make almost everything on earth but still have lower per capita emissions than the US is impressive.
But China on global warming
Second step do more as a country
Third step try to shame or encourage China and other countries into doing more
The US is still in the lead for total emissions historically and has a higher emissions per person. If it ignores it's responsibility it makes it very easy for China not to mention India or other lower total emissions countries to do the same.
China is doing something if not enough. The goal should not be trying to find a way to avoid responsibility because that's how you get all countries to avoid doing anything. The point is too keep pushing all countries starting with yours to to more
Do more? The US is buying pv panels produced on Chinese coal power. And no party is catching China's GHG productions.
Arguing cumulative historicals is playing into propaganda, and per capita? China is doing enough? They're building new coal plants! You can't be serious.
Did I say China was doing enough? No
Are they do enough?
Hell no
Is the US doing enough? Hell no
Arguing historicals and per capita plays into Chinese propaganda because there is some truth to it. There is also truth to the fact that China emits twice as much as the US and almost a third of the worlds emissions.
I don't like or trust the authorian dictatorship of China
But are you going to get China to emit less then they currently do by reversing the already inadequate measures the US is taking? No. We need to do much much more and get China and other countries to do more
If we use excuses of other countries to do less then so will they and we will all burn up together.
Emergency and industrial vehicles will need to remain ICE to a large extent because you don't want to be reliant on the grid and because they need tons of range, there's a reason they pay for extra large fuel tanks.
Vans and trucks don't really work as electric unless you're the post office just doing a trip around the block carrying no significant weight and stopping every 10 meters for the entire workday.
Cost and fire concerns are an issue.
People who travel long distance daily for work are much better served by a diesel.
Also chucking all of our ICE cars at the third world probably isn't a good way of improving emissions. What we probably actually need is hybrids, eco fuels, lighter and smaller cars on average, (electric) motorcycles/scooters, vehicles that last longer, retrofit emission improvement kits for older vehicles, etc.
This is bad faith when your text says you want to shame them into doing more. Someone doing enough doesn't need to be shamed into further action.
This is directly to your point. You ironically have US and China flipped, and China is largest AND fastest growing.
And cumulative emissions? Another ironic critique, given China is by far the largest and fastest growing emitter. Assuming you agree with the 1.5C target increase, we have a limited budget. Allowing a catchup (cumulative/per capita?) isn't sustainable to achieve climate goals.
The population of China is about 4x the US.
> Allowing a catchup (cumulative/per capita?) isn't sustainable to achieve climate goals.
Sure. But the current US position is to leave the Paris accords and drill baby drill - while China is leading on renewable generation.
Hardly anybody is doing enough - but blaming others and doubling down on consumption it's a sustainable strategy either.
...and they're also #1 by far on GHG emissions, which doesn't offset even proportionally.
It's like saying Bob might be a murderer, but...he's really works hard to teach each Sunday during Bible study. You're just moving the goalpost (and you never acknowledged how your initial critique about number sense was off base).
> Sure. But the current US position is to leave the Paris accords and drill baby drill
Whataboutism fallacy on top of recency bias, i.e., the US has been the largest producer of natgas since 2009 and petro since 2013.
[0] https://www.nytimes.com/2012/06/06/world/asia/china-asks-emb...
[1] https://dialogue.earth/en/climate/chinas-manufacturing-pushe...
You're saying that air-quality sensors at a location is "manual" reporting? That's your critique? What's manual about it? It sounds like an automated, objective sensor. Even if it were manual, the premise is that China is asking other nations not to release its air data. A 2012 article shows this has been happening for some time. Further, you need to elaborate what your point is (and answer "so what?") about gas measuring satellites.
> and you ignore the fact that China isn't a closed country, it's one routinely visited by internationals
How am I ignoring that? When did I say they were a closed country? Even more bizarre, you're introducing a strange claim that China isn't closed when China routinely scores terribly (worst category) on censorship and freedom of the press [0].
Here's another source [1]
> “China is making great efforts to improve the accuracy of its emissions inventories,” says Yuli Shan of Birmingham University in the U.K., who has tracked its data for years. But he notes that an assessment of China’s fossil-fuel emissions by the European Commission’s Emissions Database for Global Atmospheric Research found 23 percent more than recorded in the country’s U.N. submission for the same year.
You're welcome to provide resources that refute my argument, and I'll review.
[0] https://en.wikipedia.org/wiki/Censorship_by_country#Table
[1] https://e360.yale.edu/features/undercounted-emissions-un-cli...
China is responsible for >30% of ghg emissions and for 90% of incremental CO2 emissions growth in the last decade. Their population didn't grow more than ~2%! Your buffet analogy misses the constraint about the earth's carbon budget being limited to keep global warming to +1.5c. China is effectively blowing through everyone's budget so that no steak will be left and running the buffet out of business.
You compared China and Climate Change to a steak buffet. LMAO...
They care, they've bought more absolute effort to the issue than most countries, their future plans and projections are out there and on per capita basis they are doing better than most.
Your only line on this is that the country with the largest population has the largest energy consumption and emmissions.
And .. ?
In the future, good luck landing on claims you'll actually stand behind (still laughing at your revised definition of "manual") or advance your argument.
Do people in China emit less carbon per person than the US or not?
Meanwhile, you can't defend how that or the cumulative argument (which you abandoned) is relevant. I've acknowledged and pointed out the flaws in these points.
Edit: I'll also note that your undefined sense of "fairness" over accountability doesn't take into account how China is using slave labor and Uygurs to build PVs.
Just take the "L".
And in terms of prison labour ( another attempt at mis-direction by you ) - slave labour is effectively still legal in the US - the US has the largest prison population in the world ( by far ) and compulsory work from prisoners is legal.
So the US just moved from explicit slave labour, to imprisoning people and forcing them to work...... and yes - if you are from a particular racial minority you are much more likely to be subjected to this....
The? You mean your post. You introduced it. No wonder you're not making sense, given you can't follow your own comments.
Now you're saying slavery is legal "effectively" in the US? Stop embarrassing yourself.
The total world prison population is estimated at around 11.5 million.
China is second - with about 1.7 million - however that's at a rate of about 1/5 of the US.
It's legal to force those 1.8 million to work in the US and some states don't even compensate - and in addition your something like 6 times more likely to suffer it if you black.
So you have a legally endorsed method of forcing people to work in the US, often without any pay - just saying if it quacks and walks like a duck.....
> Figures for [...] China are incomplete[...] The China figures are for sentenced prisoners only. Figures for pre-trial detention and other forms of detention are not available; more than 650,000 were so held in 2009 (Supreme People’s Procuratorate). In addition, it is widely reported that more than a million Uighur Muslims are detained in camps in Xinjiang province.
Thanks for the laugh.
[0] https://www.prisonstudies.org/sites/default/files/resources/...
So you are trying to deflect again - and I notice you haven't address the key point - the existence of legalized enforced labour in the US.
If you dislike what China is doing then you should also be worried about what's happening in the US.
Guess work? This is coming from your own source, which undermines your point!
How are you adding
a. not available pre-trial detention and other forms of detention
b. and "more than" a million Uighur Muslims?
If you can't even provide credible information, then how does one even "deflect" it?
Still not pausing to think?
...which your own source undermines. I can't defend your own arguments for you without quality figures.
The US incarceration numbers in particular are extraordinary - about 1 in 7 of the worlds prison population is in the US. I'd be interested in your opinion of why that is.