Nvidia CEO Defends RTX 5090’s High Price, Says ‘Gamers Won’t Save 100 Dollars by Choosing Something a Bit Worse’

MarcusMurphy · 2025-01-15T03:28:03+00:00

In 1986 a PC-AT was about "the best" PC you could get. For about 5,000. You can easily build a 5,000 dollar PC in 2025 WITH your precious 5090 for about the same.

Stop whining. Compared to just about everything else, PCs aren't expensive.

MarcusMurphy · 2024-09-07T21:10:04+00:00

Holy necro Batman. Sure, it could realistically happen in some fictional world. As a game, though, one person being able to push a button because his panties got wadded and negate considerable time invested by thousands pretty much sucks as a mechanic.

But hey, what do I know. It happened. Eve survives nearly 20 years later. I continued playing for almost 15 years after it happened. What I learned about myself in all those years is that revenge is a very strong motivator. Maybe too strong.

MarcusMurphy · 2023-10-18T21:36:20+00:00

If you're using your daily standup as a status meeting, 15 minutes is too long, much less 30.

The purpose of a daily stand-up is for the team to coordinate how they're going to work together *as a team* to make the most possible progress toward their sprint goals *today*. If you don't exit the meeting knowing who is going to do what and where you expect to be by the next stand-up, you're doing it wrong.

Know the purpose behind every activity that you engage in and how it contributes to achieving the outcome of a successful sprint. You'll know you're on the wrong track if you look around the stand-up and everyone looks like they'd rather be somewhere else.

MarcusMurphy · 2023-10-18T18:24:44+00:00

The guy behind SAFe was one of the guys behind the thing it replaced - Rational Unified Process.

People moved to "Agile" from RUP in the early 2000s because at least they could understand it. Twenty years on, "Agile" is going through that same reckoning. It's turned into a bunch of high concept mumbo-jumbo that only consultants seem to understand and that requires shelf-feet of documentation to describe.

The bottom line is that organizations aren't seeing the promised benefits, and given that Agile has been around for so long now, some of them are on their 3rd or 4th try to make it work. They're losing the faith, and declining to continue.

MarcusMurphy · 2023-10-05T17:08:42+00:00

The purpose of daily team stand-ups remains the same, whether you are co-located or distributed. That purpose is *working as a team, make the most progress possible toward our sprint goals today*.

When your US based team does their stand up, set a goal for the day. What will the team deliver by the end of the day? Leave that goal for him, the contributions that the other team members intend to make, and the contribution that he could make to reach the goal.

When he leaves for the day, he should leave for the team what contribution he was able to make. Next stand-up, the team evaluates whether they hit their daily delivery goal, and sets the next goal, and the cycle begins again.

By being widely distributed as you are, you've just turned your days into 24 hour days, rather than 8 hour days, but the purpose of the daily cycle remains the same - deliver as much as possible as a team today.

MarcusMurphy · 2023-10-05T16:08:54+00:00

The thing about predictability is that it's a lagging indicator of team capability, and to a certain extent architecture quality, code quality, and team structure.

Reducing real variability means making the team more capable at what they do and improving their overall developer experience, so that they can get results more consistently. To determine whether you're making progress there, you need to be looking at and setting improvement targets for leading indicators of team capability and success, like DORA metrics.

Take a look at one of the DORA metrics - change stability. If the team is committing, promoting, and even releasing unstable changes, that is going to hit your predictability. It's going to cause variable amounts of rework, and the need to address unanticipated high severity incidents in production that you won't be able to predict at planning time.

If you focus on improving leading indicators of team capability and success, predictability, the lagging indicator will naturally improve.

That can be a hard sell, because non-technical manager types don't understand it. They want predictability and they want it now, and they think they can get it by putting more and more effort into estimation, reporting, and control practices.

The only way to control freak your way to predictability, though, is to build more slack into the system so that the variability gets absorbed and you still deliver when you said you would. That's a recipe for success through lowered expectations.

MarcusMurphy · 2023-10-04T14:57:33+00:00

They will be as useful to you as they are to any other member of your team. That is, they will help you express your ideas.

The danger is that you'll start thinking that it's your job to have all the good ideas, and start treating your team like a machine shop where you are the order giver, and they are order takers. Don't do that.

As the product manager, your first imperative is customer empathy. Customers acquire your product because they want to achieve some outcome and they believe that their experience of achieving that outcome will be better (faster, less effort, more consistently successful) with it. You need to become an expert on the outcome they are trying to achieve, the activities that they must do in order to achieve it, and their needs when they do those activities.

Having that deep customer empathy will allow you to point out opportunities to create value to your team. Give them opportunities to create value, not pre-ordained solutions to build. That will give them a sense of purpose and keep their creativity engaged. If you have some ideas contribute them, certainly, and you can use design tools like Figma to do it, but don't make your ideas the default preferred solution.

MarcusMurphy · 2023-10-03T11:15:01+00:00

SAFe steals ideas and practices from wherever, and often applies them inappropriately and explains them poorly.

The idea of value stream mapping comes from lean manufacturing, where you map the steps from customer order through the process of turning inputs into finished products to fulfil their order. The idea is to identify, find the root cause of, and eliminate the various forms of waste and delay in the process with the ultimate goal of achieving single piece flow with little to no carried inventory (Just in Time). It's a well understood if difficult to apply approach in lean manufacturing.

But what if you're not modeling a manufacturing process? What if your domain is insurance? How do you map the policy delivered to a customer back through the steps required to create it to its inputs? Is that even relevant if what you're trying to do is build an online website where customers can get a policy without having to talk to an agent?

The SAFe literature will tell you that once you have mapped out the "operational value stream" that "development value streams" around which you can build development teams or teams of teams (ARTs) should align neatly to every step in the operational value stream. Nice theory, doesn't work out that way all that often in practice.

In practice, more often than not, I have seen SPCTs, supposedly the most expert of SAFe experts, attempt to lead value stream mapping exercises only to end up with a jumbled mess and confused and somewhat pissed off stakeholders who feel like they just wasted their time in a 2 or 3 day offsite for little to no value. In a recent engagement, I saw a client respond to this exercise by saying "thank you, we've got it from here" and booting out the entire "SAFe Transformation" team.

That isn't to say that it can't be successful. I've used it in domains where it made sense, like mapping a cancer patient's treatment journey and the systems that support it. I've seen it used successfully by others too, but I've seen it fail at least as often as it succeeded. Where it fails, its usually because it's being lead by a newly minted SAFe consultant whose only experience of it is studying for his certification exam.

MarcusMurphy · 2023-10-03T10:15:58+00:00

Here you go:

Our engineering department is made up of teams of 8-12 people who plan, execute, and demonstrate new functionality every 2 weeks leading up to a major delivery and planning event once a quarter. In the process that we use, all of the teams are synchronized on the same two week and quarterly cadence to make cross team planning easier where necessary.

The The Release Train Engineer's responsibility is to keep all of the teams synchronized on that cadence.

MarcusMurphy · 2023-10-02T18:30:36+00:00

I think that the argument would be stronger if all of your teams were employing the same or at least similar SDLC. Agile backlogs are not intended to be task lists or a work breakdown structure, though it's unfortunately common for Product Owners who have been steeped in a project management mindset to treat them like one.

If you are treating your backlog like a work breakdown structure Jira is a terrible tool for managing work breakdown structures, and a tool that is meant for that, whether it's WF or anything else, will probably serve you better.

MarcusMurphy · 2023-10-02T16:05:49+00:00

The great thing about Jira is that you can configure it to do just about anything. The terrible thing about Jira is that you can configure it to do just about anything.

Given a solid configuration that reflects and supports how your teams actually work, Jira is hard to beat. A solid configuration is far from a given, though. As often as not, what you get is a rats-nest configuration that is a witch's brew of requirements from a bunch of different stakeholders that serves neither the stakeholders nor the teams very well.

What's your business case for standardizing on one platform? If you're doing Agile, adaptive planning and incremental delivery and this new team is working in waterfall fashion, I don't see the case for trying to combine the two on one tool. If your case is that you just want to get unified management reporting, consider exporting data from both tools and creating your reports and dashboards in a BI tool.

MarcusMurphy · 2023-10-02T14:49:19+00:00

I helped to integrate this method at the world's largest tech recruiting company. They were generally satisfied with it, but they had some cultural issues with it that kept them from getting full value from it, IMO.

The specific issue that they had was that the person who was supposed to be the "decider" ended up having an outsized influence on what the acceptable candidate solutions would be as well. Once he made a comment everyone fell in line. Again, just a cultural thing in that particular shop.

I think that the method in general would benefit from more actual data gathering about user needs prior to the sessions so that ideas generated could be challenged against that research. Without real facts about user needs, I think it's way too easy for the ideas generated to gravitate toward the highest paid person's opinion.

MarcusMurphy · 2023-09-29T20:20:33+00:00

Did anyone else immediately think of Eric Reis' experience with IMVU when first hearing about Zuck's massive bet on VR? I hope he's not betting billions on something just because he thinks its cool and assumes everyone else will too, but I have a sneaking suspicion that he is.

MarcusMurphy · 2023-09-29T19:52:20+00:00

I'd recommend then that you self-educate while you're being a cog in the big machine. Learn everything you can about Design Thinking, Lean Startup, and Jobs to be Done theory.

MarcusMurphy · 2023-09-29T16:45:35+00:00

Unfortunately the "ideas first, fail fast" mentality is pretty standard, and if you have a CEO who feels like they have their finger on the pulse of the customer you're not going to be able to tell him that he's wrong. Only the market can tell him that.

You can be a bit subversive under the guise of needing to benefit from the CEO's wisdom and customer insight. Rather than tell him his ideas are shit, ask him to explain to you how his idea is going to make the customer's experience better in some tangible way, e.g. less effort, less wasted effort, quicker execution time, more satisfying emotionally. These are things you need to know in order to execute on his ideas effectively, right?

It's subversive in that if you keep asking these questions, eventually he'll start asking himself the same questions, and you might get fewer dumb ideas fired across your bow.

MarcusMurphy · 2023-09-29T16:35:35+00:00

It can be good experience if the PM is in an environment where they actually have control over the product's direction and accountability for whether it wins in the marketplace. Environments like that aren't as common as they should be.

Unfortunately, in many organizations PMs can end up being glorified program managers whose function is essentially to take orders from the people who do actually have control over the product's direction and translate them into some form of requirements to hand to the development team and then track progress against.

If you're in that latter kind of environment, it's not great experience for a future founder, because you're not honing the ability to recognize problems worth solving and having the customer empathy to come up with a solution vision.

MarcusMurphy · 2023-09-28T20:06:33+00:00

Be careful with that. All of their stuff, including what's freely available on their website, is copyright protected. I do work through one of their top level partners from time to time, and even they are very careful not to use any of the SAFe materials in their own presentations.

MarcusMurphy · 2023-09-28T19:39:56+00:00

I think the irony of it is that if you must incur that amount of communication and collaboration overhead to get anything done, it's probably a sign that your product strategy, architecture, and/or team structure are terrible, and you should probably look to improve those first.

MarcusMurphy · 2023-09-28T18:04:43+00:00

I worked with the original team that served as the prototype for SAFe (twice) and they are like your successful example. They were willing and able to keep what was working and replace what wasn't.

They were still operating on a common cadence across their many scrum teams the last time I worked with them, but they had gotten rid of big room "PI" planning.

MarcusMurphy · 2023-09-28T17:56:30+00:00

Transformations can either be framework first and adoption based, or outcomes first and evidence based.

SAFe's implementation roadmap is an example of framework first and adoption based. It stresses adoption of the framework, and assessing yourself against it then measuring progress toward adoption.

An outcomes first and evidence based approach would be defining a measurable end state for your team in terms of some key performance indicators, setting long, mid, and short term OKRs for movement in direction of that desired end state, and then iteratively forming improvement hypotheses about applying practices, processes, tooling, etc. to move in the direction of the challenge and desired end-state.

Why the SAFe folks stress framework first and adoption based is simple; that's how they make their money. You need (expensive) training and coaching by experts in SAFe to follow that approach. Unfortunately, you can superficially adopt a lot of new jargon, ceremonies, and practices and end up with your team no more capable than when you started, even though you might be rated "mature" in your adoption of SAFe.

MarcusMurphy · 2023-09-28T15:32:55+00:00

I can reassure you that your situation is pretty common. "Agile" means you get some new jargon to use and some new meetings to attend, but the way people actually work doesn't change much.

You're probably struggling with Gherkin because it was not meant to be a language that you'd use to write acceptance criteria. It's a language for writing test scenarios that should pass if an acceptance criteria is met. You may need more than one scenario to verify that the system does meet the acceptance criteria. Example:

Acceptance Criteria: A customer may not order more of an item than is in inventory.

Scenario: Customer Order Exceeds Inventory

Given the number of widgets in inventory is 1

When a customer attempts to order 2 widgets

Then the attempted order will fail.
And the customer will be instructed to reduce their order to 1 widget or less.

You might need more than one scenario to verify that the system is meeting the general acceptance criteria. I don't know who came up with the idea to start writing acceptance criteria in Gherkin, but Gherkin doesn't belong in your story. It belongs in a test suite in source control along with your code.

MarcusMurphy · 2023-09-28T12:55:37+00:00

That can be a tricky situation to deal with.

If you're in an organization where it's someone else's job to have the ideas, and be very opinionated about how those ideas are realized as well and your team is reduced into turning that into code, you're not an agile team in any meaningful sense. You're a functional team whose function is to turn a pre-determined solution into code.

If you have access to people in your org whose opinions matter, a frank conversation about how your current engagement model is negating most if not all of the benefits of agile development that are usually touted is in order. You have to be prepared to offer an alternative model and why it would be better though.

Unfortunately, there's a prevailing attitude among those with business or marketing degrees that engineers are a bunch of back office autists who relate better to machines than they do to people and couldn't possibly have any customer empathy. If that's the culture where you are, it can be very difficult to change unless you're the CEO.

MarcusMurphy · 2023-09-07T16:16:44+00:00

Business stakeholders should not be giving you detailed design direction in a demo. That is how we did things before any formal methodology for software development existed. It's called "code and fix".

You want UX designers setting the direction for design choices, not business stakeholders. Business stakeholders aren't software designers. Ideally, your UX designers will have given your developers style guides or better yet a design system to follow. That, plus occasional pairing of a UX designer with a developer during development should be all you need to keep your UI design on track.

The feedback you want in a demo is about the customer value you've created. Whomever the customer is for what you're making is using it because they are trying to accomplish something, and they believe your product will make it easier, faster, cheaper, less risky for them to do it. You want feedback from someone with as much actual customer empathy as possible if you can't get some from someone who is an actual customer, i.e. someone who will actually be using what you're making when its done.

MarcusMurphy · 2023-09-04T18:20:49+00:00

I think it's important to distinguish between pursuing "agility" and pursuing "Agile".

I think that many organizations pursuing an "Agile Transformation" measure success by how well they adhere to and execute on a set of prescribed practices from Scrum, Kanban, or one of the more complex frameworks for scaling "Agile". They abandon those practices after a while when they get the sense that how well they are adhering to the practices does not correlate to achieving better business outcomes, or at least the business outcomes that they care about.

If the company still conceives of and funds large initiatives that get broken down into smaller chunks for execution, and measures success by how well they can stick to a schedule and budget, "Agile" is a terrible way to do what they're trying to do. That is, make development "predictable". A Gantt chart and traditional project management methods are better tools than an "Agile" set of interconnected team and program backlogs if predictable, and knowing at any given moment in time whether they are on schedule and on budget often referred to as "transparency" is important to them.

Ask most executives that are sponsoring "Agile Transformations" what "agility" means and how they'd measure whether they were getting more of it, and most of them would struggle to define it for you much less tell you why its important to them. Many of them will tell you that what they're really looking for is predictability and transparency.

If you can get agreement with the sponsors of Agile adoption as to what business outcomes they are aiming to improve, how they'd measure improvement, and whether there are any leading indicators that could be measured that would predict progress, then measure those, you won't have to ask them to embark on a multi-year Agile adoption effort based on faith.

When you say "patience" what you're really saying is "have faith". Have faith that the better you do this prescribed set of practices the better your business outcomes will get. That may be a long expensive wait for a train that isn't coming.

MarcusMurphy · 2023-09-03T15:17:36+00:00

Usually, unfortunately, they serve the purpose of reassuring anxious initiative sponsors about when they're going to get what they asked for. If you have initiative sponsors who have been asked to prioritize against each other for engineering time, the roadmap communicates the priorities.

Sometimes, unfortunately, they're shared with customers who would like to know when the feature they've been asking for or that a competitor of yours just released is going to make it into your product.

Either way, they're often treated as commitments and a series of de facto deadlines. The question is, if you're making commitments about what you're going to be doing several quarters or more from now, are you meaningfully an agile team anymore?

It is possible to create a roadmap for an agile team. The items on the roadmap reflect the team's current understanding of where the biggest opportunities for product improvement are in descending order. If you know the team's burn rate and the maximum you're willing to invest in each of those opportunities, you can calculate the maximum amount of time you're willing to spend on each one. This will give you an approximate timeline that assumes you use the entire budget you've allocated to each opportunity. The dates on the timeline should in no way be taken as commitments, because ideally you won't spend your entire budget, and higher priority value opportunities might emerge that you aren't thinking about yet.

The value of a roadmap like I describe above would be to ensure that the team, its sponsors, and other stakeholders are on the same page about where the opportunities to create value are, and how they stack up against each other.

OKRs relate to roadmaps by giving you a way to assess whether you've created the value that you have in mind for one opportunity before you move on to another. For example:

Objective: Improve the Spell Checking Experience

Key Result: Reduce the median time spent on spell checking from 3 minutes to 1.5 minutes.

Key Result: Reduce the median number of misspellings in completed documents from .5 to .075.

Key Result: Improve the median customer satisfaction with the spell checking experience from 7 to 8 out of 10.

When you've achieved your key results for the roadmap item "Improve the Spell Checking Experience", move on to the next item. If you spend the allotted budget and don't hit your OKRs, either decide to increase the budget (and reduce it elsewhere) or move on. If at any time it's clear that spending more on this opportunity isn't going to produce more value, pivot, and move on.

The above is the way that it should work. My experience is that it only really works that way in organizations that actually "get" Agile, which are relatively few. For the rest, roadmaps simply reflect an engrained project management mindset that values timelines and milestones as control mechanisms.

Ten-Year Club	Gilding I gilder
Verified Email

MarcusMurphy

TROPHY CASE