Finding your flow when working in a dev team
At Makers Academy, you learn in a bunch of different ways — pairing, mentoring, workshops — but the learning curve is probably steepest when you’re doing one of the longer group projects in the final weeks.

Suddenly it’s no longer about working to your own timetable, but about finding a way to make something happen as a group, in which people inevitably have different approaches, objectives and quirks.
It can be the very best of times if you get certain things right — and the absolute worst if you don’t. I’ve found myself thinking about the elements which help a team find its flow. I reckon these are some of the most important.
Goooooaaaaaaaals
Everyone knows a project should have objectives, but I’ve worked in so many teams and organisations where objective-setting has felt like a bit of a box-ticking exercise.

But there’s a reason that they are useful and important. When you use them right, they keep a team aligned, goals make decisions for you and they drive you towards some sweet delivery.
In my first project, we set good, clear objectives. By the end of the two weeks, we wanted to be able to use Rails confidently and have something complete which we could all feel proud of.
So when we were given new client requirements in week 2 (several new features and migration to a new stack using Express and React), despite being very tempted to dive into React, our clear objectives meant that it was a no-brainer to focus on building out the new features in Rails.
Here’s how to make objectives work for you:
- It takes longer than 10 minutes to write good objectives. Start by understanding your brief, what are the most important elements or critical success factors you need to nail to be successful? When that is clear, try to understand the individual motivations of people in the team. Discuss this as a group and probe — if someone says “I want to learn to work in a team” find out why, what does good look like, how are they measuring that goal?
- Write your objectives as solid statements you want to be able to say at the end of the project, it makes them much more real. “I want to get better at reviewing code” is ok. “I give constructive feedback which helps my team member become a better developer” is better.
- Keep them simple. Keep the list short.
- Try not to lose sight of them when things get busy. Flash them up at the start of planning meetings to remind people what was agreed. Things will always change, so check they still make sense as you’re moving through the work.
- When you inevitably have to prioritise or reach a fork in the road, use them to guide your decision-making process and move forward with a clear direction.
How before what

When a team gets together, it’s tempting to dive right into the doing. But I’ve learnt that it’s worth agreeing how you’re going to work before you get anywhere near the code.
Here’s a good example. At the start of my first group project, we discussed git and agreed how we wanted to make commits — often, with clear messages, including labels such as SETUP or REFACTOR to let everyone know what the work related to. Unfortunately that didn’t stop us getting into a mess a few days later when we found ourselves picking through nightmare merge conflicts and committing failing tests into our master branch.
So we took some time our to reassess our branching strategy and added the final agreed approach to a team git document. There are loads of ways to manage git workflow as a team, but the important thing is to pick one and be consistent. We now had a single way of working with Github and were a whole lot more confident and efficient using it.
Other stuff to work out upfront:
- When will you work? Do people have commitments mornings / evenings / during the day? When are people away? When are people at their best?
- How will you pair? Will you keep two people on a feature till it’s finished (even if it takes a couple of days) or switch one out each day? Each half day?
- What is your strategy for when an individual or pair gets blocked on a task? Will you all down tools to help? Do you want to put a time limit on blocked activity before changing things up? At what point will you ask for external help?
- How open is everyone to feedback? Do people have a preferred way of giving and receiving feedback?
- How does someone get the best out of you? What about the others in the team? Frameworks like Myers Briggs can be a really useful way to let each other know the do’s and donts during group work.
Sharing is caring

Any well-oiled team will be dividing up work and ensuring there is no overlap in activity. But this can lead to silos where only certain people understand certain parts of the code base / configuration.
This might seem ok when you’re getting through tickets fast in the early stages but it’s so much less fun when something goes wrong and only one person can even start to debug the issue.
Take time out to share what you’ve learnt. It doesn’t have to be an hour-long presentation — just take 10 minutes to stand in front of a whiteboard and draw out how something fits together. It will help other people in the team but it will also help you to consolidate your own understanding — win win.
During my first project, our team did a fantastic job documenting how new technologies work to share learnings across the group and we even did a mid-week workshop with the rest of our cohort to share what we’d learnt about Github.
Retro cool

Retrospectives — when you get together as a team at the end of a spring to think about how you could work better — are my favourite Agile ceremony. They are a great moment to celebrate wins and work out where to improve in a really constructive way.
There are loads of ways to do retros but my personal preference is to keep it really simple. Grab a whiteboard and make 3 columns — what went well, what could be better, actions. Give everyone a pen, fill out the first two columns, tick other people’s comments which resonate as you go. Then discuss, keeping action-orientated — throw ideas into the action column and come away with a list of new things to try in the next sprint.
Listen to your gut
I reckon project work might be a bit like dating someone — if it feels too hard, it’s probably because it’s not right!
If you feel like a project isn’t going well, it’s really important to stop and understand why. Ways to tell it’s not going well: people are quiet, anxiety levels are running higher than they should be, ideas aren’t forthcoming.
That was my team in the first few days of our final project at Makers. In choosing to build a microservices architecture, we had bitten off more than we could chew and we were all a little grumpy under the pressure of it, certainly not at our best.
So we called an emergency retro and had a pretty frank conversation about what was going well and what could be better. In the end, we took a really brave decision to completely change our project on day 3 (of 10). Although we’d lost time, we worked much better and with the benefit of hindsight it was absolutely the right thing to do.
Any other tips for great group work? Feel free to add your thoughts in the comments below — and thanks for reading!
