Skip to main content

Rate Ethics & Considerations

Work vs. Work-Product

Be ethical! 

Your work can be bought, but your skills can not. 

How you complete a project is yours, this is the “work.” You’re probably using techniques that you’ve developed on your own and then you’re including them in the puzzle that is the “work-product.” The client always owns the work-product, and they can own portions of the work – but not your approach to that work. 

So here’s a good example. I’ve developed a series of media templates for projection that I’ve honed over many years, on many jobs, with many clients. If I use my media template for Client B, they absolutely own the media produced in that template, and they own the working file it was produced in, but they don’t own the template because you’ve brought that with you and refined it for them. Also: good luck figuring it out. If you bring a hammer that you’ve built yourself to a job and then paint it red with project money, does the client own the hammer? No. 

What if you amend the template concept with a technique you developed while with client B? Do they own this concept? In my opinion, no, because this is like red paint on the hammer. Sure, they paid for the paint, but they didn’t pay for the hammer. That said, you need to be careful here because there’s an implication of proprietary code that’s developed on a gig. The combination that makes up a Code can be protected, absolutely, but its many strings, as unique parts, cannot be. You can’t trademark a number, or a letter. 

What about a language – what if you develop a framework for a client? Then they own the framework and you cannot reuse it without clearance. Again, though, the framework won’t exist in a vacuum. You only can develop that framework because of your knowledge of existing frameworks. They can’t own the existing frameworks. 

What about a piece of hardware – what if you develop a new type of projection lens? Applying the same principles here, they own the lens, but they don’t own the skills that enabled you to design that lens. You can’t take that lens and use it with another client, but you could probably get away with designing something similar. Think about a car designer who goes from Audi to BMW: they can’t take trade secrets with them, but they can’t unlearn aerodynamic physics. 

Project Documentation

The only way you’re going to get more work is by working with people who recognize your work, or know someone you know, or they’ve already worked with you in another capacity. Applications for gigs where you don’t know someone (or something) in common, are sadly typically unsuccessful. At least in my experience. 

To that end: you need to be able to share that you worked on a project. You need to be able to say to a future employer “I worked on the Windows XP rollout” and ideally, you have a showcase video of Windows XP in action so that you can share it, or include edits of it in a personal reel. 

Some clients and/or client projects specifically prohibit you from doing this. Sometimes this is OK. If you’re working with a client and you are white labeled and there’s an NDA, there’s nothing you can do. 

However, when it’s not that situation, you should be able to share a final version of a public project and say you worked on it. You should keep all project secrets to yourself (like a product roadmap, or your partner list), but you should absolutely be able to share that you worked on it. Generally speaking, unless you’ve been canceled, this is good for everyone. If the Client is hesitant to allow the sharing that you worked on a project, you should include it in your rate negotiation. 

Always, always, always take photos and video documenting the project the whole way through. At worst, these images are used in private, internal wrap documentation and everyone will be pumped that you took the initiative. At best, you can share some of the finished product to future clients.