Cutting the legalese: Ways of working for tech projects that an 11 year old can read

Contracts are important. They’re there to cover your back and ours. In reality though a project lives or dies on the ways of working between teams.

Contracts often cover off a lot of that, they speak to things like timing and deadlines but when that comes wrapped up in legalese and buried in a subclause somewhere it gets lost more often than not.

So we’ve put together our own ‘no nonsense contract’ to fill the gap. It uses easy to understand language and simply restates common sense points. This does not replace our legal documents but we’re willing to bet that if everyone sticks to these points in reality we won’t ever actually need to reach for our contracts during the project.

Will it mean everything runs smoothly 100% of the time? Probably not. If everyone sticks to it will it mean we’ll be able to deal with anything that comes up in a positive, responsive way and keep things on track? Almost certainly.

So here we go. This our guide to how we want to work with you. It should take less than 4 minutes of your time to read through these 20 short points and it’s designed so it can be read by an 11 year old*. Can’t be much simpler than that.

The Developer Society Ways Of Working v1**

To deliver the perfect project, these are the principles we work to:

1. We are partners: We’re working with you because we care about what you’re trying to do.
2. Happy people work better 1: Projects can be stressful and hard. We all have deadlines to meet and managers to keep happy. Everyone is under pressure but no matter what happens, we expect everyone on the project to be friendly and respectful of each other at all times.
3. Happy people work better 2: This project is important. So are the people working on it. Sometimes out of hours work is needed but we do everything we can to protect the time our team gets to spend with family/bowling/horse riding/dog walking and all those other greats things. Some teams have different cultures around working late/weekends but we expect that you will try to stick to this too.
4. Listen to each other: Different people have different levels of expertise in different areas. We trust that you know your project inside out, we expect you to trust us on the tech side.
5. Mistakes hpapen: Until we’re all replaced by AI, mistakes will happen. When they do, we assume it’s not intentional and we will work together as partners to get things fixed because…
6. The big picture is what matters: Whether dealing with mistakes or planning the project, let’s always stay focused on why we’re doing this project. That will be our guide to know we’re making smart decisions.
7. Do the prep: Let’s invest in clear understanding up front. It might feel a bit slow but if everyone is clear on all aspects of the project at the start then we’re in a really good place. Try to tell us everything upfront because if there’s something we don’t know about before we start, then it might result in a surprise for you too in terms of cost or timings.
8. Ask questions: If you’re not clear on something, please ask! There are no stupid questions on a tech project and the only thing to be embarrassed about is not speaking up if you have an idea or concern.
9. Timing matters 1: Be on time. You’re working on other projects, we’re working on other projects. Let’s stick to the deadlines we set out. If we miss those deadlines it might add delays.
10. Timing matters 2: If either side has an urgent question, we should try to respond asap and if it can wait we’ll still get back to you quickly but we mightn’t be able to drop something else we’re doing right away.
11. Timing matters 3: We plan our schedules around how long we estimate work to take. That’s also how we cost projects. If there are changes or you need more work done, please give us as much notice as possible to avoid any clashes.
12. Timing matters 4: We expect you to pay on time so we don’t have to chase you. That’s not fun for anyone.
13. Consistency is important 1: It’s very important we know who we’re working with at the start of a project. ‘Mystery voices’ are the people who join a project later on: they often have different ideas or lack all the details of the project or discussions to date. We expect you to work with your team to gather input and communicate that in one clear way to us and if not, that will slow things down and might delay the project.
14. Consistency is important 2: It’s also really important that the right people are kept in the loop and we’re not cutting anyone necessary out but…
15. Respect the inbox: Everyone is drowning in emails! We should try to use CCs and explicitly move people to BCC or remove them from email chains where possible to keep conversations limited to the people who need to be involved.
16. Changes can happen 1: If we’ve made a mistake in the code, that’s called a ‘bug’ and we’ll fix that as soon as possible. We try really hard to avoid bugs but mistakes happen so please tell us if you see anything that isn’t working and we’ll fix it.
17. Changes can happen 2: Things change. We get it. Once you’ve given us a brief and confirmed the SoW we’ll work to deliver exactly that but we want to stay flexible too. Of course you can change your mind as you go along but that might mean we have to change the delivery date or how long it takes if it means doing extra work. There’s no problem if you have things you want to change but it might mean we need to adjust the conditions to that (Note: If you think upfront that your project is going to have a lot of changes, then we’d love to run an agile process with you).
18. Changes can happen 3: It can be hard to tell sometimes which changes are bugs and which are new features (a change or addition you would like to make to the project as briefed). It can also be hard to know how big a change is as the ‘one small thing…’ the day before launch might actually require several days work. We’ll be upfront with you about what it takes to make the change but please know that until we’ve given you an estimate on how long it will take, you shouldn’t plan around it.
19. Be responsible 1: At each point of sign off/testing, please take your time and carefully go through the work we deliver. Click the Tweet button and make sure you’re happy with the content in there. Make a donation and check that it gets processed. If you sign off and then want to make changes, we’ll try to help (remember we are partners!) but sometimes this means scheduling in extra work for us because we’ve gone past the window for your project. This sucks so let’s avoid it. To help out, we’ve got a quick guide to running testing/sign off here.
20. Be responsible 2: If we both stick to the points above, the project is going to be great. Of course you should still read the contracts we send through just to make sure you’re up on all the details but if we both stick to these points, then we’ll never need to look at the paperwork.

* Ok it mightn’t be the most scientific measure but to keep this super simple we’ve used the Hemingway Editor’s ‘readability’ test.

** We want to keep this list alive so from time to time we’re going to update it. The aim is to test it out and learn as we go. If you have any suggestions on things to add, please get in touch!

John Dunford is the Campaigns Lead at The Developer Society, a not-for-profit digital agency, working with NGOs and groups with a progressive mission to help make the world we live in a better place.

Stay in touch by subscribing to our updates here. Follow us on Twitter too to show a bit of extra love.

And of course if you liked this article, please add a clap below and share the piece — it means the world to us at DEV.