Early in my career, I used to think process was something people introduced because they were bored and had nothing better to do apart from bothering us, the productive, bread winning devs that built the thing.
Years later I found myself working with a team that had all the elements of a process and none of the glue that holds it all together. There were strict rules for some things, zero rules for others, and no idea of why each rule was introduced or how. “Why do we do it this way?” was something I asked a lot… always coming back with little to show for, or a very unsatisfying answer like “that’s how the previous manager did it”.
Process and tools were all pain inducing, with little to no regards of what the team actually needed to succeed, what their own pains were, how they could solve those pains or mitigate them.
And so, I did exactly what anyone with no previous management experience tends to do: I made the team work exactly like we worked in a previous team I had been a part of… a team were things just got done and quality was always a concern… a team of senior engineers with almost zero things in common with this new team except for the fact that we were building something.
I was looking at process as a series of steps instead of a framework that helps us achieve what we need.
I was thinking of the process as a thing we would have some day in the future, not the thing we already had. It was messy and undocumented, but we had a process, and you can’t really push for something new without understanding what came before.
Somehow, the new process took. It became “how we work”, and we were vocal about it. We would argue with other teams when they looked down on us for doing code reviews. We would suggest using git and explain why we wanted every release to be tested and tagged. From time to time one of us would mess up, and we would try to adjust how things worked, and step by step things would get better.
Years later, that process had been tweaked by many others, and it was ours instead of mine. It had grown and learned, and it was no longer “Romina’s thing”, it was our thing. It was cause for many disagreements and valuable discussions, for many issues that could have been prevented if we had seen the error in our ways, but also of many moments of joy, many innovations, many attempts to make it better, shinier, more useful, and for that I’m grateful.
Your team having a process is a journey, not a goal. Your team already has a process. It may be messy, undocumented, and maybe they don’t know it exists, but it’s there.
To create a process, you need to first find the one that already exists. You can’t dismantle something you don’t understand. I mean, clearly you can, but believe me, it’s a lot harder.
Your shiny new product development process is not very useful until it’s collectively owned, and it’s definitely not useful until people who have been there a while stop needing to constantly go to documents to figure out how it works.
It should be simple, it should prevent errors, it should help you identify issues when they happen.
A good process makes your work feel easier, I almost want to say it should bring some joy.
PS: Imposing a process on that team worked, at a surface level, because people were genuinely scared of what would happen if we didn’t change things fast. It wasn’t successful, and it certainly wasn’t easy until we had gone through many iterations and collectively changed it for the better. While it was “my” process, it felt forced and awkward. When it finally became our process, things got increasingly better, and it no longer depended on me to make it happen.
@rowasc! 