iiinova — where your digital self keeps evolving

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 29/06/2026

1/6 People often say LLM agents are “just another abstraction layer.” I think that confuses abstraction with automation. A useful tool is not automatically an abstraction.

132

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 22/06/2026

Today we're going to talk about “work streams” - Product - Support - Change requests Or rather, about “fictitious work streams” emmanuelvalverderamos.substack.com/p/the-work-l...

011

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 04/06/2026

The plan is restricted to reaching 100% coverage and not stopping until it reaches 100%. The LLM bypassing the restriction. What a great tool!

000

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 21/05/2026

The evolution of my substack is interesting, I never thought about reaching more than 3 people hahah, but I'm happy to see that is growing

011

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

I'm interested in this opinion; could you provide real-world examples of where this happens? On the other hand, I must emphasize that these are not metrics.

000

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

33/ Final punch line: Productivity means work was produced. Effectiveness means the right result was achieved. Efficiency means resources were used well. The best software teams do not just produce more. They produce the right work, with less waste.

010

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

32/ Software engineering needs sharper language. Productivity is not effectiveness. Effectiveness is not efficiency. Efficiency is not productivity. A strong team needs all three, but each one tells a different part of the truth.

211

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

31/ The real danger is using productivity as a moral word. “She is productive.” “This team is productive.” “That sprint was productive.” Maybe. But productive at what? For whom? At what cost? Toward what outcome? Without those answers, the word hides more than it explains.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

30/ Good teams separate the questions. For productivity: What are we producing? For effectiveness: Why does this work matter? For efficiency: What waste exists in how we work? When the questions are mixed, the answers become vague.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

29/ Good engineering management does not ask only: “How do we make developers more productive?” It also asks: “Are we working on the right problems?” “Where are we wasting capacity?” “What makes valuable change expensive?”

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

28/ In software, individual output is not the same as system output. One person can create work. Another reviews it. Another tests it. Another fixes it. Another supports it. The system pays for the whole chain, not just the moment of creation.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

27/ This is why local productivity can damage team outcomes. A developer may look productive by pushing lots of code. But if that code is hard to review, hard to test, hard to understand, or hard to operate, the output moves cost to everyone else.

112

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

26/ Another aha moment: Efficiency without effectiveness creates polished waste. The workflow is smooth. The pipeline is green. The meetings are short. The tickets are clear. And still, the product does not get better.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

24/ Productivity without effectiveness creates inventory. More code. More features. More configuration. More maintenance. More surface area. The team produced work. The system inherited responsibility.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

23/ But the order of measurement is often reversed. Teams count tickets first. Then velocity. Then throughput. Then deployment frequency. Those numbers may be useful. But none of them, alone, tells us whether the work was worth doing.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

22/ The order of thinking matters. First: effectiveness. Should we do this? Second: efficiency. Can we do it with less waste? Third: productivity. How much are we producing? If direction is wrong, producing more only scales the mistake.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

21/ The same activity can be judged three ways. Shipping a feature: Productivity asks, “Was work produced?” Effectiveness asks, “Did it solve the right problem?” Efficiency asks, “Was the cost of producing it reasonable?” Same work. Different lenses.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

20/ Example: CI/CD. A team builds a faster pipeline. Productive? Yes, engineering output was produced. Effective? Only if it improves integration, release safety, or feedback. Efficient? Only if the pipeline reduces waste instead of adding ceremony.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

19/ Example: automated tests. A team adds 200 tests. Productive? Yes, tests were produced. Effective? Only if they protect meaningful behavior. Efficient? Only if they give useful feedback without excessive cost, brittleness, or noise.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

18/ Example: refactoring. A team spends three days improving a messy module. Productive? Yes, engineering work was produced. Effective? Only if it supports a real need, such as safer change or lower risk. Efficient? Only if the improvement was not bigger than the problem.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

17/ Example: a reporting feature. The team delivers it in two days. Productive? Yes, work was produced quickly. Effective? Only if the report helps users make better decisions. Efficient? Only if the team did it without avoidable waste, rework, or unnecessary complexity.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

15/ In software engineering, “more” is dangerous without context. More code can mean more maintenance. More features can mean more complexity. More tickets can mean more fragmentation. More activity can mean more coordination cost. More output is not always a better system.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

14/ This is why “the team is productive” is not enough. Productive in what sense? Producing more code? Producing more features? Producing more decisions? Producing more learning? Producing more customer value? The word needs a specific object.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

13/ That is the third trap: Efficiency is not wisdom. A very efficient delivery system can still deliver the wrong product. A clean pipeline does not fix a weak product decision. Speed and low waste are only useful when direction is sound.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

12/ A team can also be efficient but ineffective. They move fast. They automate steps. They reduce meetings. They cut waste. They spend little. But they are still building the wrong thing. Doing the wrong work cheaply is still the wrong work.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

11/ That is the second trap: Effectiveness does not erase waste. Doing the right thing in a painful and expensive way is still costly. Good outcomes matter, but the way we reach them also shapes what we can afford to do next.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

10/ This is common in legacy systems. The team knows what matters. But every change is slow because the system is hard to understand, hard to test, hard to deploy, and hard to modify safely. The direction is right. The cost of movement is too high.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

8/ That is the first trap: Productivity is not impact. Writing more code does not mean solving more problems. In software, a lot of work can be produced while the important problem remains untouched.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

7/ A team can be highly productive and deeply ineffective. They build a lot. They ship a lot. They close a lot. But the product does not improve, customers do not care, revenue does not move, and support pain stays the same. More output. Same reality.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

6/ This matters because software teams often celebrate productivity too early. “We shipped 12 features.” “We closed 80 tickets.” “We merged 40 pull requests.” Fine. But that only says work was produced. It does not say the work mattered.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

5/ The simple distinction: Productivity = how much work we produce. Effectiveness = whether the work achieves the right outcome. Efficiency = how well we use resources while doing it. Three different questions. Three different judgments.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

4/ Efficiency asks: How well are we using our resources? Time. Attention. Money. Energy. Coordination. Cognitive load. A team can solve the right problem, but with too much waste, rework, waiting, and friction. That is effective, but inefficient.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

3/ Effectiveness asks: Are we producing the right work? A team can ship a feature, but if customers do not need it, the team was productive but ineffective. The work happened. The outcome did not.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

2/ Productivity asks: How much work is being produced? In software, this may look like features delivered, bugs fixed, pull requests merged, tests added, incidents handled, or code changed. Productivity is about output. Not automatically value. Not automatically quality.

100

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 19/05/2026

1/ In software engineering, we often use “productivity” as if it meant everything. It does not. Productivity, effectiveness, and efficiency are separate ideas. Related, yes. Interchangeable, no. Confusing them is how teams become busy without becoming better.

231

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 03/05/2026

Esto seguramente sea porque la mayoría de las personas no sepan de dónde viene la palabra Trabajo. La palabra "trabajo" proviene del latín tripalium un instrumento de tortura compuesto por tres palos (tri-palus) donde se ataba a reos o esclavos. Este es un buen recordatorio.

010

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 03/05/2026

3/5 These are just a few of the many things that came up during the postmortem. If you ask me whether it’s the tool’s fault, I’d say no. The problem isn’t working with agents. The problem lies with the people who do this kind of thing.

121

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 09/04/2026

Software semantic diffusion and solution explain on a diagram 🔴Problem

121

Emmanuel Valverde Ramos @emmanuelvalverde.dev · 31/03/2026

Please add this to your definition of refactoring, because people are still planning refactoring tasks even though this book is now in its second edition and is over 20 years old.

000