Producing value in a block
This page explains how to produce value in a block of Engineering Capacity, and how to show it to the client. Clients and engineers share one definition of value; clients read it in What we mean by value.
value
noun
Value is meaningful progress toward something that matters to the client.
Meaningful means the progress makes a useful difference to the client: it helps them do something useful, improve something that matters, or make a better-informed decision.
The test: What can the client now do, do better, or decide because of this work?
Examples on this page are illustrative. They are not measured results from Exalynt or a real client.
Why value is how Exalynt works
Clients buy capacity one iteration at a time, with no retainer and no lock-in, because nobody can know everything about a piece of software up front (see Sharing risk).
- Client buys a blockThe block, not the hours, is the commitment.
- Confirm the goalIn the client's language, not technical terms.
- BuildGet something working early, then improve it.
- CheckpointWhat changed, why it matters, what's next. Never hours.
That means:
- Every iteration is where the client decides again. Revenue follows value the client has seen, not a long-term contract.
- The client pays the same no matter how long the work takes. Exalynt absorbs the overrun when work runs long, and keeps the benefit when experience makes it fast. Using time well is part of the job.
- We usually operate what we build. When software is Operated by Exalynt, its operations plan costs the same however often it breaks, so fragile software turns into unpaid operational work for us.
- Rework uses up the client's future capacity. A bug shipped today gets fixed with a block the client pays for later.
- Quality is how we keep clients. Clients can leave at any time and take their code and data with them. They stay because the work is good.
Your payout for a block is fixed before you start (details), and it doesn't change with how many hours you spend. What value changes is whether clients keep buying blocks, and that decides how much work there is for everyone.
The forms value takes
Value doesn't have to be a new feature, or financial right away. It can be incremental, preventative, or become useful over several iterations. It does need a credible connection to the client's needs, and evidence that fits the claim.
Capability
Do something useful that wasn't possible before.
- Customers can book an appointment online.
- Dispatchers can assign a technician straight from the schedule.
- A deployment pipeline, so the booking app can be released and run.
Improvement
Make something easier, faster, safer, or more reliable.
- Staff confirm a booking in one step instead of three.
- A backup that has actually been restored in a test.
- Booking rules kept in one place, so the holiday-hours change is one edit.
Clarity
Better understand a need, answer a question, or choose a direction.
- The current scheduling tool already supports the workflow.
- After trying the booking flow, deposits move ahead of reminders.
- A technical experiment shows the proposed design can handle both locations.
Some work builds toward these results over several iterations. We explain what it enables, what has been verified, and what remains.
Clarity counts when it helps move the work forward. More information on its own isn't value.
How to produce value in a block
Value is something you produce with the client, not for them. Neither of you knows everything at the start, and you don't need to. Software development is a process of discovery: you build something, the client reacts, and both of you learn what matters. Each iteration moves toward what the client wants, as you both understand it today.
1. Start from what the client wants
Clients often start with one sentence, such as "Scheduling takes too much of our time," and aren't sure yet what they want. That's a fine place to begin. Ask enough to choose a useful first step, not for certainty, full requirements, or a business case, and let the work answer the rest.
Keep these questions open for the whole engagement, not just the first week. The answers will change as the client sees the work:
- Who are we helping, and what are they actually trying to accomplish?
- Which constraints actually matter?
- Should software solve this at all?
- What is the simplest responsible next step?
"Don't build it" is a successful outcome. If an iteration shows that an existing tool solves the problem, the client has saved money and we have earned their trust.
2. Iterate fast and finish with something real
A block is one week, unless an exception is warranted. Plan backward from the Checkpoint:
- Agree on this iteration's goal in one sentence, in the client's language, such as "By Friday, customers can pick a time and get a confirmation." A bigger or less certain goal may need a short conversation, never a form.
- Pick the most valuable slice that can be meaningfully finished in this block, not the most interesting one. Often that's the slice that teaches you both the most.
- Get something working early, then improve it. Don't leave integration to the last day.
- End every block with progress the client can see, in any of the forms above. If the work isn't finished, say what's complete, what remains, and what it enables next. Don't relabel effort as value.
- Stay inside the purchased capacity. If more is worth doing, it belongs in the next block, agreed with the client.
3. Discover and adjust together
Every checkpoint is a chance to learn what the client actually needs. Seeing working software often changes their mind. That's the process working, not a failure of planning.
- Show work early, and say how stable it is. Every piece of work carries a stability level, so a rough prototype on day two is useful feedback, not a risk. A prototype isn't production-ready just because it demos well.
- Treat a change of direction as progress. If the client sees a feature and decides they need something different, the work that got them there helped them decide. Say what it taught you both, keep what still fits, and move on. Don't call it wasted work, and don't claim the set-aside feature is still delivered value: its value was the decision it made possible.
- Help the client decide, then follow their decision. Explain the options and tradeoffs in plain language. The client sets the direction, and can change it at any checkpoint.
- Raise risks as soon as you see them. Short iterations exist so a wrong direction shows up in days, not months. Don't save bad news for the checkpoint.
- Name the limits: what's incomplete, assumed, not covered, or still uncertain.
- At the checkpoint, give the iteration update, then recommend what to do next and which block size fits it.
- Don't report hours to clients. They bought a block, not a timesheet.
4. Use capacity responsibly
Each block includes responsibility for the client's progress and contribution to Exalynt's engineering community. Plan focused client attention appropriate to the block, uphold quality, and make room to review, pair, mentor, and help others. Use internal effort ranges as planning guidance, not hours to fill. Balance these responsibilities across your commitments and raise conflicts before either is neglected. Significant shared work requires explicit coordination.
Both responsibilities are included in the block and its payout. Exalynt doesn't buy its own blocks for ordinary shared contribution, and it isn't unpaid work you're expected to do after your commitments are met. On top of that, helping your own team is paid on their blocks too: when a teammate fulfills a block in a week you're available, you earn Team support (details).
Focused client contribution
Give the client's work focused attention appropriate to the block, pursue useful progress, and meet the quality standard the work requires: the standard its stability level needs, not perfection.
All of your work for this client counts:
- Clarifying the problem, discovery, and feasibility work.
- Design, investigation, prototyping, implementation, and debugging.
- Testing, security, reliability, and quality assurance.
- Deployment, documentation, training, and handoff.
- Pairing and code review on this client's work.
- Sharing decisions and context with your team, so the work doesn't depend on one person.
- Foundations and improvements the client's needs depend on.
None of it is a leftover after the "real" deliverable. Appropriate quality is part of responsible delivery. When you tell the client about it, describe its effect, not "best practices."
When another engineer helps with this client's work, their review or pairing contributes to this client's result, and a brief session fits within the helper's own shared contribution. It isn't a separate charge to the client, and it isn't counted against anyone's block twice.
Shared engineering contribution
Shared engineering contribution is a regular responsibility, not something you do only when a client's work happens to be easy. Plan room for it:
- Reviewing another engineer's work, on your team or any other.
- Pairing to help a colleague reason through a problem.
- Mentoring and sharing relevant knowledge.
- Improving shared tools, documentation, and engineering practices.
Within your Engineering Team, this help is also what Team support pays for. Each block a teammate fulfills pays every available teammate 3% of its basis, whoever helped on it that week, so there's nothing to log or claim. It's paid by availability on the expectation that available teammates review, pair, and share context when the team needs it, not as a fee for any one review.
Some of this helps engineers on other engagements, and it won't always benefit the client whose block supports it right away. That's intended: it sustains the collaborative organization that delivers every client's work, and clients are told so plainly (What a block supports).
An iteration that needs more client focus can carry less shared contribution. If collaboration is repeatedly squeezed out, rebalance your commitments rather than dropping it or doing it after hours.
Not every internal activity counts. Shared contribution isn't a way to fund unrelated product development, open-ended internal projects, or general company overhead from client capacity. Larger work of that kind belongs in a self-funded block or another existing arrangement.
Ordinary help and substantial shared work
Ordinary reviews, brief pairing, and mentoring are included in the model, so they don't need a compensation conversation for every interaction. When help turns into sustained ownership, substantial implementation, or a commitment that competes with your client work, coordinate it explicitly with Exalynt, so assignments and compensation are handled under existing policies instead of absorbed as informal help. Generosity shouldn't become an unlimited obligation, and the most reliable contributors shouldn't be the ones overloaded.
Raise conflicts early, with your Team Lead or with Exalynt, which assigns capacity, so client commitments stay adequately supported and collaboration is distributed fairly.
Planning with effort ranges
Blocks follow a 1:2:4 capacity unit model, so a Core is twice a Flex and a Dedicated is twice a Core. Each block has an effort reference that describes its overall scale to clients, and internally a client effort range for planning focused client attention:
| Block | Units | Effort reference | Client effort range |
|---|---|---|---|
| Flex | 1 | ~10 hours | 5–10 hours |
| Core | 2 | ~20 hours | 15–20 hours |
| Dedicated | 4 | ~40 hours | 30–40 hours |
How to read them:
- The effort reference is overall scale. It covers focused client work and ordinary shared contribution. It isn't a promise of that many hours exclusively for the client.
- The lower end of the client range is sufficient focused attention. Normally plan at least that much room for the client's work, with flexibility when useful work is completed efficiently or priorities change.
- The upper end allows more client attention when the work needs it. It isn't an amount to consume or a guaranteed completion limit.
- Shared contribution fits within the overall allowance, not on top of a fully allocated workload.
- Balance across your commitments and iterations. Every block doesn't need an identical split, and there is no fixed percentage for shared contribution.
- Don't routinely give a client less attention than the block warrants. Repeated deviations, or blocks that regularly land far from their range in either direction, call for a conversation about sizing, allocation, or expectations. Raise it at the checkpoint or with Exalynt; it's a sizing conversation, not a failure.
- Unused client effort isn't a license for unrelated work or extra client scope. Use judgment and coordinate priorities.
These are approximate guides, not entitlements, percentages, or timesheet targets. Hours describe effort and planning; they don't set a floor for value, and you should never pad work or manufacture tasks to reach a number. Your pay stays the same either way. Your payout is fixed before you start, however long the work takes.
In practice
- The client's work is harder than expected. More of the allowance goes toward it. Investigation, experimentation, and debugging are part of the work, and Exalynt absorbs that variance by design, so don't cut corners. Tell the client what remains uncertain, and raise sizing if it keeps happening. Don't promise unlimited completion within the block.
- The client's work progresses efficiently. Verify quality, agree the next useful client step, and make your planned shared contribution. Don't pad hours. If the next useful step is unclear, discuss it with the client.
- A colleague needs a review. Ordinary help is included, so give it. If it grows into sustained implementation, coordinate it before it competes with your client work.
- Reviews keep happening after hours. That's a sign your commitments are too full. Raise it so commitments and allocation are adjusted; shared contribution isn't meant to be unpaid extra work.
- Never exceed the purchased capacity without the client's agreement. If more work is worth doing, it belongs in the next block.
- Do not report hours to clients as though they were billed. Talk about outcomes and what we learned.
Showing value to the client
The client should be able to answer the test from what you show them: what can they now do, do better, or decide?
The iteration update
Every checkpoint answers three questions:
- What changed?What now works, improved, became clearer, or progressed?
- Why does it matter?How does it relate to the client's needs, in their language?
- What does it enable next?What can the client now do or decide, and what remains?
It's not a reporting template. A few sentences at the checkpoint, in a message, or in release notes is usually enough.
- A new capability
- Discovery
- Supporting work
- A change of direction
- What changed?
- Customers can now choose an available appointment and receive confirmation.
- Why does it matter?
- This removes the scheduling back-and-forth for those bookings.
- What does it enable next?
- Next, we can add cancellation or put the workflow in front of customers.
- Not yet
- We have not yet measured actual staff time saved.
- What changed?
- We confirmed that your scheduling tool lets other software create and cancel bookings, and connected a test account to show it working.
- Why does it matter?
- Self-service booking can build on the tool your staff already use, rather than replacing it.
- What does it enable next?
- You can now decide whether to go ahead.
- Not yet
- We haven't checked how it handles your second location.
- What changed?
- We moved the booking rules, which were copied in four places, into one, and rechecked booking, rescheduling, and cancellation.
- Why does it matter?
- That fixes the double-bookings you saw when two staff edited the same day. Customers won't see anything new.
- What does it enable next?
- Next week's holiday-hours change becomes one edit instead of four.
- Not yet
- Automated tests for rescheduling are still to come.
- What changed?
- Your staff tried the booking flow, and you decided customers should pay a deposit when they book, before we build reminders.
- Why does it matter?
- Deposits go after the no-shows you mentioned more directly, and adding them now avoids reworking the booking flow later.
- What does it enable next?
- Next iteration, we add deposits to the existing flow. Reminders can wait until you've seen deposits in use.
- Not yet
- We haven't chosen a payment provider, and part of the confirmation screen will change.
Describe the difference, not the activity
- Instead of"Built a calendar integration."Say"Customers can now select an available appointment and receive confirmation."
- Instead of"Researched scheduling APIs."Say"We verified the required workflow is supported and demonstrated the connection, so you can decide whether to proceed."
- Instead of"Added backups."Say"We restored a test backup successfully, demonstrating recovery for the covered data and documenting the remaining gaps."
- Instead of"Refactored the booking code."Say"We removed duplicated booking rules that were causing inconsistent behavior, verified the affected flows, and made future rule changes possible in one place."
- Instead of"Improved scalability."Say"The schedule page loaded every appointment ever made. It now loads one week at a time, so it stays fast as your history grows."
- Instead of"Followed best practices for secrets."Say"The payment key is no longer stored in the code, so a leaked copy of the code can't be used to take payments."
Show evidence that fits the claim
| If you're claiming | Show |
|---|---|
| Something now works | The working flow, end to end, ideally with realistic data |
| Something improved | A before-and-after comparison |
| A risk is lower | The safeguard verified, such as an alert that actually fires |
| Data can be recovered | A recovery exercise, and what it did and didn't cover |
| An idea is feasible | A prototype, labeled Prototype |
| A question is answered | A short written finding, with the evidence behind it |
| The client can decide | The options, their tradeoffs, and your recommendation |
Learning counts when it settles a question that matters, including a decision to stop or change direction. "The provider's API can't book across two locations, here's the test, so we recommend a different provider" is useful. "We spent the week trying things" isn't.
Value comes from more than code
None of this work is value just because it happened. Explain its effect, as in these examples:
Understand
- Discovery and problem clarification"The real problem is double-bookings, not the booking form."
- Feasibility testing and prototypes"The payment provider supports deposits. The prototype takes one in test mode."
- Design and meaningful tradeoffs"Option A keeps the current calendar, at the cost of rarely used recurring bookings."
- Recommending an existing solution, or not building"The scheduling tool already offers online booking. Turning it on avoids building one."
Build
- Implementing useful capabilities"Dispatchers can assign a technician straight from the schedule."
- Testing and quality assurance"Booking, rescheduling, and cancellation are checked on every change."
- Maintenance and refactoring tied to a need"A library update fixed the wrong times in confirmation emails."
Run
- Security, reliability, monitoring, backups, and recovery"If bookings start failing, we know within minutes, not from a customer."
- Deployment and operational readiness"Updates go out without downtime, so they no longer wait for the evening."
Enable people
- Documentation, training, and handoff"The office manager can add a new service type without our help."
- Collaboration, pairing, and code review"Review caught a rule that would have allowed bookings on public holidays."
Not every engineer on a project has to deliver a separate feature. Pairing and review show up as a better result for the client, not as an extra deliverable or an extra unit of capacity. When the reviewer or pairing partner comes from another engagement, a brief session is part of their shared engineering contribution, so it isn't charged to the client separately.
How much progress was made
Show the extent of progress with capabilities completed, improvements verified, risks addressed, and decisions enabled. Never offer hours, lines of code, ticket counts, purchased capacity, a value score, or a dollar conversion as proof of value. Use numbers when they help and you can support them, and label each one:
| Label | Means | For example |
|---|---|---|
| Measured | We observed it. | "The restore took 12 minutes in our test." |
| Estimated | We worked it out but didn't observe it. | "At about 40 bookings a week, this removes about 40 phone calls." |
| Expected | We think it will happen, given use. | "Staff should spend less time on scheduling once customers use it." |
Capacity, value, and business results
Keep these separate when you talk to the client:
- BoughtCapacityAn engineer's time, talent, attention, and focus for one iteration, at a fixed price.
- Delivered and shownValueThe useful progress that capacity contributes to, explained at every checkpoint.
- Realized later, not promisedBusiness resultsMore bookings, saved staff time, or lower costs, through adoption and use of what was delivered.
Not every iteration has to finish a feature, and a block doesn't guarantee a fixed amount of value. An improvement you deliver isn't the revenue or savings the client may realize later, so don't imply those results.
Frequently asked questions
If I finish a Core block's work early, is the block done?
You don't need to fill hours. Verify the quality of what you finished, and if there's a clear next useful step toward this iteration's goal, take it. If the next step is unclear, discuss it with the client rather than inventing work, and make the shared contribution you planned. If the block turned out much larger than the work needed, raise it at the checkpoint so the next one is sized better. See Use capacity responsibly.
What if the work is going to take far longer than the block's client effort range?
Deliver the most valuable complete slice you can within the iteration, then explain at the checkpoint what remains and what it would take. Do not quietly extend past the purchased capacity.
Am I paid for reviewing a colleague's work on another engagement?
Yes. Ordinary reviews, brief pairing, and mentoring are part of every block's shared engineering contribution, which is included in your payout. You don't need a separate assignment or a compensation conversation for each one, and it isn't unpaid extra work.
Do I need to log the help I give teammates to earn team support?
No. Team support is paid to every available teammate on each block the team fulfills, other than the Team Lead and the engineer who fulfilled it, whoever helped that week. It isn't tracked per review or per block. What's expected is that you help when your team needs it (details).
What if helping a colleague turns into a large piece of work?
Coordinate it with Exalynt before it competes with your client work. Sustained ownership or substantial implementation is handled through assignments and compensation under existing policies, not absorbed as informal help.
Can I give a client less attention because I'm helping others?
Not routinely. Plan focused attention appropriate to the block, and let shared contribution fit within the overall allowance. If client work and collaboration keep competing, raise it early so sizing or allocation can change before either is neglected.
Does every block have to deliver a feature?
No. A block can end with a finding, a decision, a verified foundation, or a risk removed, as long as you can explain the useful difference and what remains.
The client changed their mind about something we built. Was that work wasted?
No. Discovering what the client actually needs is the point of working in short iterations, and the work helped them get there. Say what it taught you both and what still carries over, then follow their new direction. Don't present the set-aside work as if it were still being delivered.
Do I need metrics at every checkpoint?
No. Describe what changed concretely. Use numbers when they help and you can support them, and label them as measured, estimated, or expected.
The client asked for something I don't think will help. What should I do?
Say so, in plain language, with your reasoning and a simpler option if there is one. The client decides the direction; your job is to make sure they decide with the tradeoffs in view.
Does an operations plan pay for code changes and new features?
Not substantial ones. A plan pays for production care: monitoring, investigating alerts, routine restoration, and routine maintenance. Substantial code changes and new features use Engineering Capacity (details), which is why quality matters.
Does this apply to self-funded work?
Yes. For a self-funded block, the Sponsor is the client, and the same definition and update apply.