An engineering team’s formal processes — how you track sprints, run meetings, handle release cadence, and manage code reviews — helps set team velocity and impacts the happiness of individual team members. As the engineering manager, you’re in an impactful role to shape and improve these processes over time. Remember when making any change in process, be patient yet firm.
A common mistake by new managers is to assume a change will get immediate buy-in from your reports and bump productivity overnight. This rarely happens. Never let the first instance of a process imply its lasting effect. Every change has its own learning curve, and early usage patterns come with their own set of mistakes and confusion. For example, I’ve seen engineering teams new to standups skip over blockers discussion, or one participant will talk for too long. Or for teams that make estimates based on “engineering days”, engineers will be confused on what an engineering day means (e.g. day of time vs. day of effort) and if they are estimating for themselves or an average for the team.
Micromanagers tend to get restless as fault lines emerge. They will double down on the original process in response to a rough first or second attempt. Don’t do this. Allow the team to blow it, catch their own stumbles, and self-correct. By having some patience, when the new process does run into roadblocks you’ll have time to see stumbling points and consider alternatives.
My rule of thumb is to give any process change at least a month on a trial basis to work out the kinks. If after that time the work still is not connecting, be open to change. There is no one size fits all process for every engineering team and most process changes require at least small tweaks to succeed.
While change does take time and flexibility, be firm when you commit. Use the language of “will” instead of “could” when describing what will happen. Don’t allow the first bit of negative feedback to derail the idea. A lack of willingness to shake process up will make you look ineffectual as a manager. A fallback to the status quo will usually hamper improvements in engineer velocity and happiness.
That said, all good process changes require justification; when you’re presenting the process change to the team, emphasize the “why”. And while there’s usually a clear benefit to yourself and other leads, focus on how the change helps the engineers themselves. For example, if a deployment process change will speed code launches, don’t emphasize how this makes it easier to launch under tight deadlines. Instead, talk about how the extra momentum means the team will build cool stuff faster. Also, make process changes open to feedback. I like to end any “pitch” behind a process change with space to answer questions or concerns. If I notice any hesitation, I’ll follow up on the topic in my 1:1s.
This sort of detail around navigating change may feel nitpicky. Remember that process change is inevitable, and every team deals with it differently. Your success rate as a manager derives from how well you navigate it. Striking the right balance between firmness in conviction and flexibility for change is important.