When a dev team starts to grow, it's unavoidable that you'll have to implement some procedural overhead.
Let's acknowledge that communication is costly. That doesn't mean it's not vitally important to the success of your team. As teams grow, you have to put communication protocols in place to keep the team humming as a cohesive unit.
Creating routines gives you easy knobs to turn when something needs to change, and makes room for more important conversations to happen.
If you want to retain your talent and build a team that's invested in delivering the best possible software, demonstrate trust.
Find hook points into your process. These are steps that you know will always occur, into which you can build reminders for your team to take additional steps.
You don't need the perfect solution at the outset, you just need to take a step in the right direction.
High performing teams have a strong sense of team identity. They are a resilient, self-correcting system, but this culture must be intentionally created and cultivated early on.
What do you do when you don't have enough information to confidently commit to a feature? Research spikes deliver value to your product in the form of reduced uncertainty.
When you identify a problem in your process but you don't have any ideas for how to fix it, ask yourself "Why is this happening?". Then ask "Why is *that* happening?" Don't stop until you get to a root cause with a concrete behavior that can be addressed at a department or organizational level.
Always remember that the work done on an item has no value until a feature is delivered to the product. Here's how to optimize your dev board for the delivery of compact, clearly-defined features.
Imagine for a moment that you are in charge of an end-to-end global supply chain with very high seasonal demand. You spend most of the year prepping for one big contract, with a massive scope and a 100% immovable deadline. One day per year, you work a 24-hour shift to deliver custom orders to every single household on the planet. What's your first step?
Don't confuse your tools with your discipline. When all you have is a hammer, well, you know the rest...
It's difficult to change someone's behavior by mandate. A team that performs well has routines that build trust in each other and allow for periodic introspection.
Too often when developers have to pass off a project or some amount of information, we assume that the other developer can instantly read our mind. Our colleagues are smart and capable, so we assume they must be able to look through our code and understand everything that we've done without need for further explanation.
Misunderstandings grow in the empty spaces where we leave things unstated. One of the best things you can do as a team is to cultivate a clear, concise communication style that puts the main point right up front.
As your team grows, your mindset has to shift from "What do developers A and B need in order to be most productive?" to "What does our *development team* need in order to be most productive."
Don't worry about all of the things between here and there. Start with what's right in front of you.
You're spending too long deciding the specifics of too many things.
You're not doing your product any good while you stand there thigh-deep in the cold water. Dive in and ship your feature.
My four-year-old was getting a little mopey in the mornings when it was time to go to preschool. He would tell me that he doesn't have any fun there. Of course every afternoon when I pick him up, he's happily playing with his friends, excited to show me the cars he's made out of LEGOs or the dinosaur city he's built.
Don't let your work items languish in the Blocked list. Have a plan for getting them back underway ASAP
When you really understand and accept this, it's incredibly liberating. Move early and make sure you have tight feedback loops to evaluate how you're doing and make improvements.