How to approach your work using a mindset borrowed from Agile development methodology, which promotes strong working relationships and nimble planning in order to achieve better outcomes.
We’ve interviewed countless independent contractors and clients, done boatloads of research, and experimented, ourselves, with different approaches to contract-based work. When we first started to have these conversations and think critically about contracts between clients and contractors as we were building Ditto, we were focused mostly on finding a way to ensure prompt, predictable payments. The idea was that we were building a product to help people get paid on time, every time. We knew too many freelancers who wasted time chasing invoices or who had been ghosted by clients, and we knew too many clients who struggled to get invoices from their freelancers in a timely manner (yes, really!) or who were surprised by an invoice that exceeded expectations (and not in a good way.)
Making payments prompt and predictable seemed like a good goal… but what we ultimately uncovered was a much bigger opportunity.
The lightbulb really went on for us when we started to think about breaking work into phases, and about linking payments to those phases. We realized that there were benefits for both clients AND contractors - especially when working with a new resource for the first time.
Instead of committing to a large project, signing a cover-your-ass contract, and putting down a hefty deposit, a phased approach to outsourced work allows for more flexibility. If the project doesn’t turn out to be quite what was expected, or if the resource doesn’t turn out to be quite the right fit, it’s a whole lot easier to unwind the project if you’re looking at wrapping up a discrete phase versus trying to get out of an all-encompassing long term contract. Contractors are assured that they’ll be compensated for their time, even if things go south, and clients are assured that they will be able to easily make adjustments to their outsourced work and workforce when necessary.
This is an entirely different way of approaching outsourced work. It is akin to the difference between “waterfall” and “agile” development.
In the “waterfall” approach to development, there’s a whole bunch of planning up front. You make assumptions, you estimate times to delivery, and then you’re expected to be off and running. Often things don’t go quite according to plan, but it’s tough to make changes, and it can be mentally uncomfortable to feel like the team is always one or more steps behind where they’re supposed to be. The temptation is to plow ahead with the plan, even if you begin to realize that the plan was flawed.
In “agile” development, you learn and adjust as you go along. You’re able to be more responsive and more accurate in estimating how long something will take. You’re also more likely to build the “right” thing, because there’s a build-measure-learn loop built into the process, versus trying to do all of the learning upfront. Learning naturally will happen as you go - so you budget time for it and then use what you’ve learned to make improvements to the plan as your understanding improves.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This sentiment is one we’ve latched onto as incredibly applicable to contractor-client working relationships. In fact, we’ve created our own version of the agile manifesto.
We are uncovering better ways of managing outsourced work by doing it ourselves and helping others do it.
Through these efforts we have come to value:
- Individuals and interactions over protections and promises
- Quality work product over comprehensive documentation up front
- Client collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We’re building this ethos into our product, but you don’t need a special tool like Ditto to start approaching your work with more of this mindset. It may take some time for the client/contractor culture to change, and it will likely be a little uncomfortable, at first -- any time you’re deviating from norms there’s bound to be some discomfort.
Try it, though, and experience the benefits for yourself.
Start your next project with a discovery phase. You can tentatively scope out and show the client what future phases might look like, but be clear about the fact that the “discovery” phase is exactly what you say it is - a discovery phase. It’s an opportunity for contractor and client to feel one another out; to assess whether the working relationship has promise; to make adjustments to communication style or project deliverables; and sometimes, to determine whether the requested project is in fact the highest priority work to be done for this client - i.e. whether this particular project should move forward, at all. (It can be a bummer to pass up a payday, but clients appreciate, remember, and ultimately reward this kind of behavior.)
We advocate for using an escrow service to protect both client and contractor, but you can address invoicing however you like. The key here is to keep the phase small enough that you’re minimizing risk, yet large enough that you’re delivering something of value.
At the conclusion of the discovery phase, move forward with scoping the next phase or two. Only commit to a phase when you’re sure that it’s accurately scoped. Make sure that the client agrees to the phase as scoped and commits to paying you for the work. If a client asks for something that is out of scope for this particular phase, explain that you can create a new phase for that work. Sometimes you’ll need to prioritize the new phase over what you’re presently working on, but the key is that you’re not just letting the scope creep. (This, too, is a technique employed in agile development -- sometimes stakeholders need a reminder that once a deliverable is agreed upon, changes CAN be accommodated, but there will necessarily be trade-offs, and there is also an established process for accommodating changes -- they can’t just be slotted in willy-nilly.)
Do the work, then repeat the process. Take it one step at a time. We expect that you’ll find that your work - and your working relationship - benefits from this approach. But hey, if it doesn’t? Use what you’ve learned and adjust accordingly. There’s no right way to be more agile.
...
