If your team is shipping constantly but it is still difficult to explain whether all that activity is creating meaningful value, the problem may not be productivity. It may be measurement.

Engineering has traditionally been measured through lines of code, story points, velocity, deployment frequency, or tickets closed. The problem is that none of these tells you the most important part: Did the work actually matter?

That is where Jade Rubick’s ValueSum metric offers an interesting alternative.

Instead of asking how much work was completed, ValueSum asks a much more useful question: How much value was delivered?

The basic idea is straightforward. List everything delivered during a period, assign each item a value score, and add the scores together.

Markets don't wait for Monday. News breaks on a Saturday morning, and most traders can do nothing but watch.

Not on Liquid. Trade domestic and international equities, commodities, forex, crypto, and prediction markets — all from one account, 24 hours a day, 365 days a year. Liquid gives you access to any market, from anywhere, anytime. To us, access is arbitrage.

Getting started takes under 10 minutes: log in with Google, deposit with Apple Pay or a bank transfer, and trade from your phone or desktop — wherever you are in the world.

While everyone else is refreshing headlines and waiting for the open, you're already positioned. That's the difference between reacting to markets and actually trading them.

Trade 24/7 on Liquid Today

For example:

The ValueSum is 17.

The logic is powerful because two things can increase the score: shipping more valuable work and delivering it faster.

That makes ValueSum different from simply counting output. Ten low-value features should not automatically look better than three changes that significantly improve the customer experience or protect important revenue.

Tip: Start simple. A basic scoring system that the organization actually uses is more useful than a sophisticated framework nobody wants to maintain.

The rise of AI has made the measurement problem even more obvious.

AI can dramatically accelerate certain parts of software development, particularly code generation. But faster coding does not automatically mean faster value delivery.

A developer may generate code in minutes, yet the organization still has to determine what should be built, review the solution, test it, integrate it, deploy it, and make sure customers actually benefit from it.

That creates a gap between local productivity and organizational impact.

ValueSum looks at the entire delivery system rather than giving credit to one tool or one activity. If AI helps engineering move faster but product priorities are poor, design is weak, or deployment remains a bottleneck, the overall value should reveal that.

Rubick describes using ValueSum at a company in 2025 where overall value delivery improved. AI contributed, but it was only one factor among several improvements. That distinction matters: ValueSum can show whether the organization is delivering more value, even when it cannot attribute the improvement to a single cause.

Tip: Don't measure AI success by how quickly code appears. Measure whether the organization is ultimately delivering more useful outcomes.

One of the most interesting aspects of the framework is that it does not isolate engineering.

Engineering can build quickly, but if product selects low-value problems, the score suffers. Product can identify an important opportunity, but poor design or unreliable implementation can reduce the value delivered.

The metric therefore exposes the system rather than celebrating one department.

That makes it particularly useful for conversations that are otherwise difficult to have. If delivery is slowing down, the question becomes less about blaming engineering and more about identifying where value is being lost.

Tip: Use the metric to start better conversations between functions, not to rank one department against another.

ValueSum becomes more useful when you look backward.

The value assigned before delivery will not always be correct. That is expected. People are not particularly good at predicting which features will create the most value.

Rubick suggests revisiting delivered work three to six months later and scoring it again based on what actually happened.

Now you have two perspectives: what the organization expected and what it eventually learned.

That gap can reveal whether teams consistently overestimate certain ideas, underestimate others, or misunderstand what customers actually value.

The goal is not to create perfect predictions. The goal is to become better at recognizing valuable work over time.

Tip: Treat incorrect estimates as learning opportunities rather than failures. The measurement becomes more useful when the team learns from its mistakes.

With Wati, every message across Instagram DM, Messenger, WhatsApp, SMS, RCS, and web chat gets an instant AI-powered response. Automations qualify leads, route conversations, and log everything automatically, so your team only steps in when it’s time to close.

See Wati In Action

There is another subtle benefit.

Breaking a large project into smaller valuable releases can increase the total ValueSum because value is recognized as it reaches users rather than waiting for one enormous project to finish.

That encourages incremental delivery, earlier validation, and faster feedback.

Instead of spending months building something only to discover that customers do not care, teams have more reason to test assumptions early.

In an environment where AI makes building software cheaper and faster, this becomes even more important. When the cost of producing code falls, choosing the right thing to build becomes an even bigger advantage.

Tip: Validate important assumptions early. Faster building is only useful when the destination is worth reaching.

ValueSum is not designed to become another scoreboard.

Rubick specifically warns against using it for individual bonuses, promotions, or aggressive team comparisons. Once people know a number determines their compensation, they will naturally find ways to improve the number—even when those actions do not improve the underlying outcome.

That is the classic problem described by Goodhart’s Law.

Long-term technical work can also be disadvantaged. Simplification, migrations, reliability improvements, and internal efficiency projects may create substantial future value without producing an immediate score.

A useful metric should therefore illuminate decisions, not dictate every decision.

Tip: Use ValueSum as a learning and leadership tool, not a weapon for performance management.

The biggest takeaway is not that ValueSum is a perfect measurement system. It isn't.

Its strength is that it shifts the conversation from activity to outcomes.

Instead of asking:

How many tickets did the team complete?

Ask:

What did the team deliver, how valuable was it, and what did we learn afterward?

That question becomes especially important as AI continues changing how software is produced. When machines can help teams write more code faster, producing more code stops being a compelling definition of productivity.

The real advantage belongs to organizations that can consistently identify valuable problems, deliver useful solutions, learn from the results, and improve the entire system.

That is the real idea behind Jade Rubick’s ValueSum: measure what changed, not simply how busy everyone was.

What’s your next spark? A new platform engineering skill? A bold pitch? A team ready to rise? Share your ideas or challenges at Tiny Big Spark. Let’s build your pyramid—together.

That’s it!

Keep innovating and stay inspired!

If you think your colleagues and friends would find this content valuable, we’d love it if you shared our newsletter with them!

As the world becomes increasingly digital, this question will be on the minds of millions of people seeking new income streams in 2026.

The answer is—Absolutely!

Thank you for taking the time to read today’s email! Your support allows me to send out this newsletter for free every day. 

 What do you think for today’s episode? Please provide your feedback in the poll below.

Share the newsletter with your friends and colleagues if you find it valuable.

Disclaimer: The "Tiny Big Spark" newsletter is for informational and educational purposes only, not a substitute for professional advice, including financial, legal, medical, or technical. We strive for accuracy but make no guarantees about the completeness or reliability of the information provided. Any reliance on this information is at your own risk. The views expressed are those of the authors and do not reflect any organization's official position. This newsletter may link to external sites we don't control; we do not endorse their content. We are not liable for any losses or damages from using this information.