Contractor Operating Principles

This is the first page every contractor should read because it explains how we expect people to operate from day one. Technical ability matters, but the way you listen, communicate, estimate, ask questions, and use your tools determines whether your work creates momentum or drag.

The default we want is simple: understand the problem carefully, add judgment beyond your tools, use the context already available to you, make smart use of your lead’s time, and work in a way that respects the client’s budget.

You are accountable for judgment

We are not hiring mechanical people. We do not expect you to simply pass every task into coding agents, accept whatever comes back, and commit it. AI agents are leverage, but your responsibility is to add a meaningful layer of judgment on top of them: understand the task, guide the work, review the output, catch risks, improve the solution, and explain the tradeoffs.

If your lead feels they are only talking with an LLM through you, then you have become a friction-adding layer instead of a value-adding teammate. The reason to keep you in the company is that you make the work better, faster, safer, and more context-aware than an agent would on its own.

Listen carefully

We do not like repeating the same thing multiple times. Write down instructions, confirm important details, and treat every conversation as context you are responsible for preserving. If a lead has to explain the same decision or expectation again and again, the issue is not just communication; it is lost time and attention for the whole team.

Good listening also means noticing what was actually asked, not just the first interpretation that came to mind. Before starting work, make sure you understand the outcome, the constraints, the urgency, and the standard of quality expected.

Ask smart questions

A well-asked question can save five badly designed questions. Do not ask scattered questions one by one if they belong together. Bring structure: explain what you are trying to do, what you already checked, what options you see, and what decision you need.

Good questions make it easy for someone to help you. They reduce context switching, show that you did your homework, and protect the team from unclear assumptions.

Be resourceful before escalating

Do not block yourself too quickly. The answer you are about to ask for may already be in a Slack thread, a Linear issue, a project document, an email, the codebase, or the documentation for the tool you are using. Look first, gather context, and come back with what you found.

This does not mean hiding uncertainty or spending hours alone. It means making a real attempt before escalating, so that when you do ask for help, the question is grounded in evidence instead of guesswork.

Master your tools

Learn to use your tools deeply. As a developer, read the documentation for the technologies you are using. Learn to use the terminal effectively. Learn how to search Slack, Linear, email, and the codebase. Learn how to prioritize and tag your emails. Learn how to get the most out of your browser, editor, debugger, and AI tools.

The expectation is not that you already know everything. The expectation is that you steadily become more capable at finding, understanding, and applying information without unnecessary hand-holding.

Your role as the Project Technical DRI

Most developers at FuzzyFlags will be the Project Technical DRI for their assigned project. DRI means Directly Responsible Individual: unless another DRI is explicitly named, being assigned primary responsibility for a project means you own its technical reality.

As the Project Technical DRI, you are responsible for:

• Understanding the system, current priorities, and relevant client context.
• Choosing or proposing the technical approach.
• Producing estimates and immediately revising them when new information changes feasibility.
• Owning implementation, code quality, testing, releases, and technical documentation.
• Keeping decisions, progress, blockers, and risks visible to contributors and the Technical Delivery Lead.
• Giving clear technical input for client updates and attending technical client conversations when needed.
• Approving feasibility before the Technical Delivery Lead commits a delivery date.

Being the DRI does not mean doing every task yourself. It means ensuring the project has a coherent technical direction, delegating with enough context, and remaining accountable for the result. It also does not make you the portfolio coordinator. The distinction is deliberate: the DRI owns technical truth; the Technical Delivery Lead (TDL) owns delivery coordination.

Project responsibility split

Responsibility	Technical Delivery Lead (TDL)	Project Technical DRI
Acknowledge incoming client requests	Owns	Informed
Triage urgency and business impact	Owns	Consulted
Decide technical approach	Consulted and challenges	Owns
Produce estimates	Validates and communicates	Produces
Commit dates to clients	Owns	Must approve feasibility
Implementation	Helps selectively	Owns
Code quality and testing	Monitors risk	Owns
Regular client updates	Owns	Provides technical input
Technical client meetings	Facilitates	Attends when needed
Staffing and scheduling	Recommends	Communicates needs
Operational escalation	Owns	Supports
Commercial or scope escalation	Escalates to company leadership	Informed
Documentation and continuity	Enforces	Produces technical context

This split is not a reason to wait for permission or create another relay. The TDL can challenge a technical plan but does not silently override the DRI. The DRI can reject an infeasible commitment but cannot leave the TDL without the technical context needed to communicate responsibly.

Do not wait for the Technical Delivery Lead to translate technical context between you, contributors, and the client. Communicate directly, preserve decisions in shared project context, and surface uncertainty while there is still time to act. Read Technical Delivery Ownership for the complete operating model.

Estimate before beginning work

Always give an estimate before beginning meaningful work. We operate on a client’s budget, so time is part of the product. A task may be obviously one hour of work for your lead, but if you were planning to spend ten hours solving it, that is a problem we need to catch before the time is spent.

Estimates do not need to be perfect. They need to be honest, early, and updated when reality changes. If you discover that a task is larger than expected, communicate the new estimate and the reason.

We do not value false promises. If you are planning to do something, it is better to give a longer timeline that you can actually make true than a short timeline that misses reality several times in a row. Trust is built when your estimates help people make good decisions, not when they sound optimistic in the moment.

Some estimates are genuinely hard. It is acceptable to say, “I need two hours to investigate before I can estimate this responsibly.” That is engineering. It is also acceptable for an estimate to become wrong when new information appears, but you must communicate that as soon as possible, explain what changed, and give the clearest updated expectation you can.

Protect time and budget

Effectiveness is not the same as trying to solve everything alone. Taking five minutes from your lead can be the right decision if it prevents two wasted hours. The wrong pattern is wandering for a long time without a clear plan, without asking for direction, and without communicating risk.

If you are blocked, say so early. If the task is bigger than expected, say so early. If there is a cheaper path, a risk, or a tradeoff, bring it up while there is still time to make a good decision.

Communication is your job, not an afterthought

The best engineers do not write code in isolation and then surface at the end of the week. They communicate rhythmically, clearly, and with intention, because information is what lets a team move fast. If your lead does not know where you are, what you are working on, or when you are available, they cannot plan, they cannot unblock you, and they cannot protect the project. Silence is the most expensive thing a contractor can produce.

Own your time and availability

You are responsible for your schedule, not your lead. That means communicating your working hours, your availability, and any time you will be out of office before it becomes a surprise. If you start late, end early, or step away for a few hours, say so. If your day is fragmented, be explicit about when you will be reachable and when you will be heads-down. Your lead should never have to guess whether you are online or wonder why a message went unanswered for hours. Owning your time is a sign of professionalism, and it gives your team the predictability they need to coordinate around you.

Configure Slack notifications on every device

You must configure and test Slack notifications on both your laptop and your phone. Slack notifications can be unreliable—especially on mobile—so installing the app is not enough. Verify that the correct workspace, channels, direct messages, notification schedule, and operating-system permissions allow important messages to reach you.

Mobile access is part of being a dependable teammate. You are not expected to work continuously while away from your desk, but a quick reply from your phone while grabbing coffee or running an errand can unblock someone and prevent hours of delay. A couple of timely messages can create far more value than returning later to a problem that could have been resolved immediately. Do not let a preventable notification configuration issue become a communication failure.

If you are free, say so

Nothing is more damaging than a contractor who runs out of work and says nothing. If you finish a task and do not have the next one, communicate it immediately. If you are waiting on a review, a dependency, or a decision, do not wait quietly. Ask for the next task, offer to help elsewhere, or flag the idle time so your lead can reallocate effort. Idle time that is hidden is budget lost without return. Idle time that is communicated is an opportunity to redirect energy where it matters.

Close the day with context, not just code

At the end of your workday, push your changes. Even if the work is incomplete. Even if it is messy. Even if it is WIP. What matters is that your lead can see what you touched, where you are stuck, and what remains. Follow every end-of-day push with a brief message: what you worked on, what is still in progress, and what you plan to tackle next. This simple habit transforms a black box into a conversation. Your lead can review overnight, leave feedback, and plan your next morning while you sleep. Do not let your day end as a mystery.

Report progress daily before 5:30 PM

Every day, around 5:30 PM, check in with your lead and report where you stand. This is not a formality. It is a critical window. If you submit changes now, your lead has time to review them, ask questions, give feedback, and prepare the next day’s work before you log on again. If you wait until the next morning, you lose half a day to silence. The 5:30 PM report is how you create momentum that carries across time zones and schedules. It is how you ensure that every morning starts with clarity instead of confusion. Make it a habit you never break.

Respect decision boundaries

Do not make bold architectural decisions without tech lead approval. Escalate early when a change affects system boundaries, platform choices, or long-term maintenance.

Work ethics

Our work ethics are the foundation of how we operate. Read them in the dedicated Work Ethics page before continuing.