DEV Community: Filipe

The Cookie Cutter Method: Fast Estimates for Repetitive Work

Filipe — Tue, 10 Nov 2026 14:53:00 +0000

"How long is this going to take?"

You look at the ticket. You look at the engineer. The engineer looks at the ceiling.

There's no shortage of estimation tools. Story points. Planning poker. Monte Carlo simulations for the particularly ambitious. They all work - in theory. They share one blind spot: they assume the project is new.

But most of it isn't.

Think about what your team actually builds day to day. Integrating a new client. Rebuilding a feature on a new surface. Patching a set of servers. You've done versions of all of these before. The shape is familiar. You've just never kept a record of how long it took.

That's what the Cookie Cutter Method is for.

The idea

Break a repeatable type of project into its component tasks. For each task, estimate a minimum and a maximum delivery time. Save it somewhere sensible.

That's it.

Next time a similar project arrives, you open the template, adjust for a few variables, and have a defensible answer in under five minutes. No planning poker. No collective ceiling-staring.

An example

In the games and VR space, teams regularly create 3D environments inspired by the real world. New project, same basic shape. Every time.

Ideation

Reference gathering: finding real-world images to inspire the look
Concepts: low-fidelity drawings for early alignment

Design

White-box: a rough 3D wireframe to establish scale
Module planning: deciding which 3D models are needed
Material exploration: finding the right textures

Development

Final models: building the objects
Skybox: sourcing the sky around the environment
Light pass: making light and shadows read correctly

Polish

Optimisation: compressing the scene so it loads quickly
Audio: sourcing the soundtrack

Each task has a range - a fast version and a slow version. You're not pretending the work is perfectly predictable. You're capturing what you already know from experience.

Cookie cutting

A simple spreadsheet is all you need.

*in days per person

Easy peasy.

In this example, the project lands somewhere between one and four months. And now the interesting conversations can start: do we have enough people? Do we have the right people? Is the scope realistic?

You're not scrambling for an answer any more. You're leading the conversation.

Greasing the mould

You're probably thinking: this only works if every project is identical.

It doesn't have to be. Here's where the template stretches:

Complexity. Is this version harder than usual? Say, 50% harder. Increase the min and max accordingly. Simple as that.
Volume. You need one beach chair. Now you also need a table, an umbrella, and a glass with a slice of pineapple. Account for how many things you're actually making, and which are fast or slow to build.
Dependencies. Who can work on what, and when? Cookie Cutter estimates don't replace delivery planning - sequencing, critical paths, capacity. You still need that conversation. But now you have numbers to bring into it.

Will it give you a perfect estimate? Sorry, no. Nothing does. But you'll have a range in five minutes, one you can defend, and a conversation you can actually shape.

That's usually enough.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Why Appreciation Matters More Than Bonuses for Team Performance

Filipe — Tue, 03 Nov 2026 14:43:00 +0000

Bonuses! Promotions! Pay rise! Throw money at people and they will deliver their best work. Right? You would know better. These will at best keep them from leaving. To get the best out of people, they need to feel valued. And there is a cheap, easy way to make that happen. You just need to learn how to show it.

The power of relationships

Maslow's Hierarchy of Needs makes this concrete. The idea is simple: you need to fulfil the lower layers before you can reach the higher ones.

The basic needs are easy to cover at work - water, toilets, stable employment. The higher you go, the harder it gets.

Your company has tried to tap the highest level too. Take performance reviews. Their goal is to align people's internal drives with company objectives. How is that working for you? I would guess "meh" at best.

The problem is that it skips the middle of the pyramid: relationships. People want to connect with each other. They want to belong.

Appreciation

Appreciation communicates respect. It makes people feel valued. And it's different from those top-down corporate awards.

It happens at all levels. Colleague to colleague. Colleague to manager. And it happens all the time.

You might be thinking this sounds contrived. A little forced. I thought so too. But the difference between appreciation that lands and appreciation that doesn't is knowing which type to use.

The book 5 Languages of Appreciation in the Workplace argues that people feel appreciated in five different ways. All you need is to know which one works for the person in front of you. Let's go deeper.

How people feel appreciated

Words of Affirmation

You can praise people for their accomplishments, their character, or even their personality. Most people prefer to receive this in private. In small groups it's fine too.

Quality Time

Giving someone your time and undivided attention. It could be a one-on-one with no agenda, or a team event where everyone is genuinely present. It has to be real quality time - so put the phone down.

Acts of Service

Shows the person you care by lending them a hand. Say your colleague is running behind schedule through no fault of her own. She will feel encouraged if you help out. Even better if you volunteer rather than wait to be asked.

Tangible Gifts

Something that shows you put thought into it. Their favourite coffee, a Friday afternoon off after a long week. It's the thought that counts - which is a cliché because it's true.
Physical Touch
Don't! There is too much room for misuse. A high-five or a firm handshake to mark a win - fine. Anything beyond that, leave it out.

Where to start

Find out how each person on your team prefers to receive appreciation. Not by asking directly - nobody answers that honestly. Watch what they notice in others. Pay attention to what they do when they want to show appreciation themselves. That usually tells you everything.

Then do it deliberately. Do it often.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Backlog Freshness: A Simple Metric for Product Health

Filipe — Thu, 29 Oct 2026 14:41:00 +0000

Your team has more user stories than you can ever deliver. The backlog becomes a dumping ground. Difficult to prioritise. Easy to ignore.

So how do you actually know if yours is healthy?

I've been playing with the idea of backlog freshness.

Backlog freshness is the percentage of the backlog that has been created recently.

My team's backlog, for example, is only 7% fresh. There are 84 user stories in it. Only 6 were created in the last 45 days. The maths: 6 / 84 = 0.07 - that's 7% fresh.

Sound familiar? The bulk of that backlog was written by a previous generation of Product Managers and engineers. Priorities have changed. Many tickets are outdated. And everyone ignores the rest.

That means you have an illusion of having lots of work to do. In reality, no one knows how much of it is actually necessary.

So you have two options to make a backlog fresh again:

delay creating stories until they're needed (one to two sprints before, for example)
fearlessly prune your backlog - delete anything not clearly important, and anything unlikely to go into upcoming sprints

(I hear the hoarders out there screaming in despair. For you, the better option might be to hide things elsewhere rather than delete them. As long as they're out of sight from the team, that's fine.)

A fresh backlog removes that overhead. The team stops reconciling last quarter's priorities with this quarter's reality every time they open the board. They focus on the highest, clearest priority - because everything in the backlog is actually worth doing. No archaeology. No debate about what's still relevant.

Start there. Calculate your freshness number - it takes five minutes. Then prune fearlessly.

Is 100% the right target? I'm not sure it is. But I'd bet yours is lower than you'd like to admit.

I'm curious to hear your number.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

What Engineers Miss About Promotion Decisions

Filipe — Tue, 20 Oct 2026 13:31:00 +0000

You've just shipped something genuinely hard. Your manager knows it. Your team knows it.

The promotion doesn't come.

So you do what makes sense: you pick up a new framework, tackle a harder problem, push your code quality higher.

It still doesn't come.

The issue isn't your skills. It's that your manager is assessing you on things nobody put in writing.

So what can you actually do about it?

Learn to think like your manager.

You might still be thinking: "But we have a career ladder. I know exactly what Senior looks like at our company." You probably do. And your manager is still using mental models on top of it - consciously or not. Two of those models do most of the work.

Influence + Contribution

Everyone starts influencing, well, no one but the code.

Gradually, you move to influencing your peers, then your team, then the teams around you, then your department. And as your sphere of influence grows, so does your contribution - from individual tasks to a portfolio of projects.

There is no standard job title beyond Senior (here)The model's value is that it gives you a concrete way to evaluate where you actually are - not where you think you are.

Here's the exercise: list everything you've delivered in the last six months. For each item, ask who it actually affected. Your own output? Your team? Teams outside yours?

That's your current operating level. More importantly, it shows what would need to change to move up.

Clarity

"What's the plan for that service refactor?"

"We're still working on it."

Wrong answer. Not because you don't know - but because your manager was hoping you'd already figured it out for them.

As you grow, the ambiguity grows with you. A junior developer shouldn't expect much of it: the problem is defined, the solution is clear, the implementation is spelled out. But further up, the blank space expands.

Managers live in that blank space. The more of it you fill, the more valuable you become.

Think about the decisions your manager still makes that you could be making. The tickets that come back to you half-formed. The proposals nobody volunteers to write. Every one of those is an ambiguity you haven't claimed yet.

Setting your goals

The smartest move is to bring both models into your next performance conversation and translate them into concrete objectives.

Take whatever fits your situation - but notice what the examples have in common. None of them prove you can code harder. They prove you're already thinking at the next level.

Specificity matters here. "Increase my influence" is not a goal. "Lead the design session for the platform migration, document the decision, and present it to the team leads" is.

Putting it all together

Here's the process.

Reflect on everything you've shipped in the last six months. For each piece of work, place a checkmark in the diagrams: where does it land on influence, contribution, and clarity? You'll end up with an honest picture of where you're operating today.

Then write your new goals in terms your manager would use, not terms your IDE would recognise. Bring them to your next 1:1 and ask for feedback.

Whether or not you're already exceeding expectations, taking that step matters - because it signals that you're already thinking beyond your current level.

That's precisely what a promotion is supposed to confirm.

Does this guarantee one? No. Nothing does.

But it changes the conversation from "I deserve this" to "here's the evidence." And that's a much better place to start.

Post inspired by Laura Tacho, Gergely Orosz, and Ryan Peterman - worth reading if you haven't already.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

The Biggest AI Change in Software Delivery Isn’t in the Code

Filipe — Tue, 13 Oct 2026 13:24:00 +0000

Your delivery chain can compress from months to days. Not by generating code faster, but by changing what happens before the coding starts.

The chain
- We need a new checkout flow by Q3.
- Talk to the PM.
- PM needs a spec.
- That's the BA.
- BA needs screens first.
- That's UX.
- UX is mid-sprint.
v- So… Q3?_

Weeks later: engineering grooming. Sometimes months.

The chain existed because translating a fuzzy business idea into something an engineer could build is genuinely hard. Each handoff was a translation. Each translation takes time.

What has changed isn't the need to translate. It's who does it, and how fast.

From months to an afternoon

Your PM can now build a working prototype directly from a strategic idea. Not wireframes. Not a spec document. A working prototype, in hours, using tools like Claude Design.

Users validate the idea before a line of code is written.

Gone: the BA translation layer, the UX handoff, the approval loops. One person with the right tool can now do in an afternoon what the chain took weeks to produce. Your engineers receive something real to look at, to question, to build from.

The demo loop

That prototype goes to a pod of two or three engineers, not a grooming session. The PM walks each pod through it. Edge cases surface. Decisions land in real time.

A ticket follows. No user story - just what came out of that conversation: the edge cases, the decisions, the constraints.

What about everything that doesn't get said in that meeting?

Daily demos close the gap. The pod accepts the ticket won't be fully fleshed out from the start. Every day, they show running code (built since the day before) back to the PM. Feedback comes in. The work adjusts.

The org change nobody plans for

Your PM needs to be a different kind of person now. Not a spec writer or a backlog manager. Someone who can hold a product vision, prototype it in hours, and run a daily feedback loop with your engineers.

The old requirements chain didn't just slow delivery. It distributed accountability so thinly that nobody felt the full weight of a bad decision. The BA owned the spec. UX owned the screens. Engineering owned the build. When something shipped wrong, the gap between those handoffs was always where the blame landed - and where the learning was lost.

When your PM and the pod share a prototype, a daily demo, and a ticket that came out of a real conversation, something shifts. They are accountable for the same outcome. The gap disappears, because there is nowhere left to hand the problem off to.

The engineering manager's job shifts with it. Breaking the team into pods means fewer coordination meetings and fewer half-formed tickets. What appears in their place is harder to manufacture: engineers accountable for understanding what they are building, not just executing what someone else has written. That is a better job. Not easier. Better.

The experiment on my team

I've been running this model with a large team for the past several months. The daily demo cadence is still finding its rhythm. Some engineers rose to the accountability immediately; others are still waiting for someone else to do the discovery for them. That gap is now visible in a way it never was when tickets arrived pre-written.

Pod composition has proved messier than expected. When priorities are clear, the pods hold their shape. When they aren't, we add people, split pods, or run smaller groups than planned. The structure is more fluid than the model suggests.

What none of that messiness has changed is the result. The end-to-end journey from idea to production has compressed from months to days. Not by hiring faster engineers or buying better tooling. By changing what happens before the coding starts.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Your AI Productivity Number Is Right. So Is Your Team’s.

Filipe — Tue, 06 Oct 2026 13:07:00 +0000

Ask your engineers how much AI has improved their productivity. You'll hear somewhere between fifty and a hundred percent. Transformative. Game-changing. Then ask yourself whether you could stand up in front of your leadership and say the same thing with confidence.

Most engineering managers can't - not yet. The gains feel real, but they're hard to pin down. And that gap between what your team experiences and what you can actually defend is more useful than it might seem.

That gap isn't a measurement failure. It's the most useful signal you have.

The measurement problem

The gains your engineers are reporting aren't exaggeration. They're just measuring the wrong thing.

Ask where AI has actually helped and you'll hear the same answer across most teams: automation tests and boilerplate code. The mechanical layer - the work that needs doing but rarely needs thinking. If a test suite that used to take an hour now takes ten minutes, that's an 83% reduction on that task. That's real.

But it's only half the picture.

Where the saved time actually goes

Laura Tacho at DX puts the industry average at 3.75 hours saved per developer per week. Take that on face value. The question isn't whether the time is being saved. It's where it goes.

The time reclaimed from the mechanical layer doesn't convert directly into new features.

AI-generated code creates its own overhead. PRs arrive faster, which means review pressure arrives faster too - and reviewing code you didn't write, at higher volume, is its own drain on your engineers' attention. Generated output varies in quality. Security and maintainability issues that an experienced engineer would have caught while writing don't always surface until someone else is reviewing.

Meanwhile, the work itself doesn't hold still. A ticket is a snapshot - a fixed description of a feature the Product Manager wrote before anything was built. Once she can see intermediate output, her understanding shifts, and so does the scope, and the time to build the feature increases.

That isn't dysfunction; it's how good product thinking works. The work that exits a sprint rarely resembles the work that entered it.

What to measure - and what to fix

Your delivery metrics give you something defensible for leadership - a number you can stand behind when someone asks what AI is actually delivering. Survey data gives you the signal from inside the work, and the frame to make sense of the gap between the two.

To close that gap, you need to invest in the engineering harnesses that make AI-generated code production-worthy without consuming the time AI just freed up. That means reducing the review burden from agent-generated PRs (better tooling, clearer standards, automated quality gates, and early detection of architecture drift). It means ensuring generated code is maintainable, secure, and consistent with your architecture before it reaches a human reviewer.

Your engineers reporting 50–100% aren't describing where you are. They're describing where you could get to, once the engineering discipline around AI catches up with the adoption of it.

And when you get there, you might find speed wasn't the real prize. Working code earlier means product thinking catches up, requirements shift, and you deliver the right thing. Your delivery metrics won't show that - but your business will feel it. That's the gap worth closing.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Your Team’s AI Spend Is a Black Box — Even to You

Filipe — Tue, 29 Sep 2026 13:03:00 +0000

“I ran out of tokens.”

“Me too. Can we get more?”

“Sure,” says the business. “Where did they go?”

Silence. Shrugs. Someone mumbles something about refactoring.

That exchange is happening in engineering orgs everywhere right now. You’re under pressure to control the bill, not just explain it — and you can’t control what you can’t see.

We know the total bill. We don’t know which feature it paid for.

That’s not a tooling gap. It’s a visibility gap. And it’s costing you two things at once: a straight answer on return for the spend, and any way to weigh cost against value at all.

Cost and value, side by side

Cost attribution means tagging assistant usage to the piece of work it went into. Not a team. Not a month. A feature, a ticket, one line in a backlog.

It’s the half of the equation nobody has. A rough number exists for engineering time (e.g., person-days x daily $), but it’s never included what the assistant itself cost. What most teams have instead is a dashboard showing total tokens per person, maybe per team, refreshed monthly — useful for a finance conversation about the subscription, useless for putting a cost next to any one feature’s value.

That’s not an oversight. No assistant vendor has much incentive to make their own token spend easy to scrutinise.

Once you have cost attribution, you can finally put the two halves next to each other: this feature cost this much, and here’s what we believed it was worth. Sometimes they’ll agree. Sometimes the gap will be the most useful thing in the room.

From spend to a conversation with product

Here’s where the same data becomes your leverage in the conversation with product.

Two tickets, same sprint. PROJ-118 burned 400,000 tokens and shipped a feature two enterprise customers had asked for by name. PROJ-204 burned 2.6 million (six times the spend) fixing a papercut nobody had complained about.

Without attribution, both look identical in the backlog: five story points each, both “done.” With attribution, they’re not the same at all — one delivered named value cheaply, the other cost six times as much for a fix nobody asked for.

That’s the evidence you bring into the prioritisation conversation yourself: proof this sprint’s “quick win” has a track record of being anything but.

The good news: all of this is already sitting on your engineers’ machines, waiting to be read.

Where the data already lives

A Claude Code session isn’t just recorded somewhere — the session is the transcript. It writes itself to disk as it goes, a plain JSONL file sitting locally on the engineer’s machine: every prompt, every tool call, every token count. Nobody has to switch it on. It’s already happening.

The assistant also fires events at named moments in a session’s life — SessionStart when a session opens, SessionEnd when it closes, and others besides, though those two are all this needs. A hook is what you register to catch one: nothing more exotic than a line in a config file pointing an event at a script of your choosing.

on SessionStart  → run reminder_script
on SessionEnd    → run export_script

That’s the whole mechanism. No agent to install, no proxy to sit in front of the assistant, no changes to how engineers work. You’re reading a file that already exists, at two moments that already happen.

Building it: three pieces, one afternoon

With that in mind, the shape of this is simpler than it sounds. What follows is pseudo-code, meant to build intuition for how the three pieces fit together. If you’d rather start from real code, see the reference repo on GitHub.

1. A feature ID reminder, at SessionStart. Ask for the feature ID the session relates to, and check again a few prompts later if it never showed up:

on session_start:
ask("which ticket is this session for?")
on each prompt:
if prompt_count in [2, 5, 10, 20] and no ticket_id seen yet:
ask_again()

2. An export, at SessionEnd. When the engineer exits Claude Code, it runs whatever script settings.json points it to, passing that script the session's details. Your script's only job is to copy that transcript somewhere durable, off the engineer's machine, without making them wait for it:

on session_end(session_info):
    transcript = session_info.transcript_path
    spawn_background(copy transcript → database)
    return immediately

3. A batch job, run on a schedule. Step 2 only ever pushed raw transcripts into durable storage — nothing has parsed them yet. This job walks every transcript sitting there unprocessed, and turns each one into a single row of metrics in a separate table:

for each raw session not yet in the metrics table:
    tokens = sum_by_type(session.events)
    feature_id = find_ticket_reference(session.raw_text)
    cost = weighted(tokens, session.model)
    duration = session.end_time - session.start_time
    write_row(feature_id, tokens, cost, model, duration)

Token types aren’t priced the same, and neither are models, so weighted() needs both:

weighted(tokens, model):
    ratio = (tokens.input       * 1.0)
          + (tokens.output      * 5.0)
          + (tokens.cache_read  * 0.1)
          + (tokens.cache_write * 1.25)
    return ratio * input_price_per_token(model)

The 1.0 / 5.0 / 0.1 / 1.25 figures come from Claude’s own published per-token rates, normalised against input. That ratio holds roughly steady across the model family. What doesn’t hold is the absolute price — Opus costs several times more per token than Haiku, which is exactly what input_price_per_token(model) corrects for.

What you get, three weeks in
The first few weeks won’t tell you much. Give it time, and patterns surface: which tickets run expensive, which kinds of work quietly cost more than they should.

None of it decides whether a feature was worth building — that call still belongs to you. What changes is that you now have a real number in hand instead of a shrug, to put next to whatever value story the PM was already telling.

The question was never whether you’re spending a lot on tokens. It’s whether you’re spending them on the right things.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026