No one likes a new process. It’s work to memorize, it’s work to do, and it removes your own autonomy from a situation, keeping you from just doing whatever you want to do.
But working without a process leads to chaos. Missed deadlines. Solutions that don’t actually solve the problem. Angry customers. Angry managers. Angry developers.
(Just your average confused developer and/or product manager)
Processes exist to streamline our inputs and outputs when working with each other. It makes results predictable, repeatable, and, most importantly, changeable.
When I work as a product manager, I’m concerned about communicating bugs and features, timelines and deliverables. I worry about being able to quickly pivot the direction of development when business conditions change or when a customer asks for something unexpected.
When I work as a developer, I want to know exactly what the constraints of the problem are, so I can fit it into existing solutions as best as possible. I want to keep disruptions of my workflow to a minimum, since every distraction makes it more difficult to come up with that simple, maintainable solution that works for everyone.
As both, I want know as quickly as possible when conditions change. I want to know if something isn’t going to work the way I expected. Maybe it will take more time and effort than expected, or maybe we started something that simply won’t fit the customer’s needs.
But I rarely wear both hats at the same time. Like most of us, I work with other teams and other priorities, and these things all need to be communicated. That’s where processes come in.
So, we need a process. We can’t get around it. But how do we get one that everyone can at least tolerate?
The first step in any negotiation is communication. Product managers and developers have to talk to each other and figure out the primary requirements of each group.
For example, I can take my experiences and list them like this:
As a product manager: I need to know how long a request will take to implement, because I need to set customer and stakeholder expectations. I need to be able to quickly communicate changes in vision, because sometimes the changes of business change the requirements.
As a developer: I need to know what the root problems are, because otherwise I can’t come up with the best solution. I need to understand what the expectations of a request are, so I can warn you I can’t meet them. And I need to know how well the solution worked (or didn’t work), so I can do even better next time.
When you start negotiating your process with the other team, keep in mind which of your requirements are necessary and which are flexible. Find something as simple as possible that solves as many of those requirements as possible, but don’t expect to solve all of them.
If you’re working with someone more senior than yourself, listen to their advice, but make sure you let them know when you don’t see the purpose of a particular process, or if you think it’s too heavy. Part of negotiating is understanding the other group’s viewpoints. You’ll likely find they have good reasons for their preferences and may not even realize you don’t see the point of them.
If you’re working with someone more junior, be prepared that many of the things that concern you are completely new problems to them. You may have to manually handle some tasks rather than make them part of the initial process or tools in order to keep things simple while they learn these new skills.
And if you’re both senior, be prepared to disagree on many points. Be prepared to compromise. Look for your common concerns and requirements and start from those.
Luckily, you don’t have to dream up a process from scratch. There are plenty of example processes and tools, especially in the software development world, for communicating these exact things.
Specifically, “Agile” methods were designed exactly for these sort of problems.
Now, I don’t recommend you leap directly into something like SCRUM unless everyone is already familiar with it. (At which point, you probably don’t need this blog post.)
Instead, keep your process as simple as possible. You want everyone to understand the purpose of each piece of the puzzle. When everyone understands the reasons why something is required, they’re much more likely to use it and want it to succeed.
I personally like simple in-person, physical processes, where initial ‘gaps’ in the flow are filled with people talking and making decisions.
For a starter example, checkout: A Simple Starter Process
After you read the previous section, your first thought was probably “But I really do need that calendar feature, I can’t just not have it!” or something similar.
An important thing to keep in mind is that processes can be improved just like software.
Schedule times for retrospectives, where everyone talks over how things are going. Review the features and bugs, the successes and failures.
Determine if changes are necessary to the process. Is a failure going to happen again and again in a way that’s fixable by a simple change in the current process? Could you repeat a success by doing the same?
(Yes, a process for improving your process)
This might sound like a pain to convince people to do regularly, but luckily people enjoy solving problems, especially when it’s something that affects their day to day working life. Keep communication open and honest, and you’ll be amazed how well things can work out.
Finally, I want to emphasize that a process requires everyone to be fully involved in it. You can’t simply assign one and expect perfect results. The individuals that make up teams and companies are all different. These differences are a good thing, because they lead to new and creative solutions to difficult problems.
But that range of experience means that no process will ever be one-size-fits-all. There is always a human element that has to be allowed for. Work with it, grow it, emphasize it, and go out and create something cool.