How I work
Remote work runs on trust. Here's how I earn it.
You can't look over my shoulder, so I make my work visible instead: written decisions, honest status, demos that show real progress, and a working day that overlaps with yours. This page describes the actual mechanics.
Operating principles
Four habits that keep a distributed team from slowing down.
Documentation, architecture notes, and screen recordings are part of my definition of done. At Thoughtworks these artifacts are how design decisions and operational learning survive team changes — I learned their value the hard way, inheriting a production system with a two-day handover.
Bad news doesn't improve with age. When something is off — a slipping estimate, a data correctness issue, a risky dependency — I raise it with logs, traces, or numbers attached, plus a proposed next step. DataDog, Sentry, and Kibana are how I debug; candor is how I report.
Vague requirements are the default state of real projects. I turn them into user stories and implementation plans before writing code, so the team argues about the plan — which is cheap — instead of the implementation, which isn't.
Running demos, standups, and retros is part of my normal week. Working software shown regularly beats status reports — it keeps stakeholders confident and catches misunderstandings while they're still small.
A typical day
Cuenca runs on your clock.
Ecuador is UTC-5 year-round — matching US Eastern in winter, one hour behind in summer. A normal day looks like a normal day for your team, too.
Training and reset
Trail run in the Andes before the workday. The discipline transfers: show up consistently, pace honestly, finish what you start.
Deep work block
The focused hours: implementation, debugging, design work. Async messages get answered at the edges, not in the middle.
Team overlap — standup, pairing, reviews
Live collaboration lands here, squarely inside US business hours: standups, code review, pairing sessions, stakeholder demos.
Second work block and handoffs
Finishing the day's thread, writing up what changed, and leaving notes so nobody is blocked on me overnight.
Clean stop
Status visible, blockers flagged, tomorrow's first task obvious. Remote teams stay fast when handoffs are boring.
First 90 days
What you can expect if you hire me.
Based on how I've actually ramped on past teams — including one where the entire handover was two days.
Days 1–30
Learn the system by working it
- Ship something small in week one — the fastest way to learn a codebase is to change it.
- Map the architecture, data flows, and deploy pipeline; write down what I find.
- Meet the people around the code: product, support, the engineer who knows where the bodies are buried.
Days 31–60
Take ownership of real work
- Own a meaningful feature or problem area end to end, from requirements to production.
- Start filling observability and documentation gaps I found while ramping.
- Contribute to planning: turn ambiguous asks into stories the team can actually estimate.
Days 61–90
Make the team faster, not just myself
- Unblock and support teammates; review with context, not just style notes.
- Propose improvements backed by what I've observed — with tradeoffs stated, not implied.
- Be the engineer stakeholders come to when they need a straight answer.