In the previous chapter, we talked about the unclear boundary between design and engineering. That it originates from creation’s flow itself.
Because creation in software today involves both an engineer and a product manager, the flow is interrupted and a hand off is created between the two. Which changes the flow into a work process.
The work process sets clear boundaries, while creation is more fruitful with unclear ones. This may be the source of some problematic relationships between product managers and engineers. Luckily, something beneficial can be done. A Middle Way between process and flow exists. We’re going to see how different conditions create different boundaries.
Space and Time
While I was working at DealPly (2015), I saw the on-boarding of two product managers. One replaced the other. We worked at a three story building. Engineering and BI was at the upper floor, management was at the ground floor. When hired, both PMs were given the choice of place of sitting.
The first PM has decided to have his desk on the upper floor. When I asked him why, he said “That’s where the business gets done”. When he had a meeting with management, easily 2-3 times a day, he’d walk down the stairs. As there was no Slack at the time (the company had some really bad messaging app called HipChat that nobody barely used), his door was open to everyone. He was just right there, literally next door. Both for clarifying issues and to listen to our product or business driven solutions, and it went both ways. When he had even a spark of an idea, he’d just ask us because there were engineers next to him to ask. It was effortless for all of us. We’d continuously give each other Feedback, quicker and sooner. Before the designs and solutions were thought of as final.
The second PM has decided to have his desk on the ground floor, next to the management. When I asked him why, he answered the same. “That’s where the business gets done”. When he had a meeting with us engineers we had to go downstairs to him, I don’t remember how frequently it was.
But when an engineer just needed a PM’s quick glance at something, it was an effort to walk down the stairs. Personally, I love walking. I went down stairs, saw he wasn’t there and went back up the stairs. The second time I went down the stairs, he was there and we talked. The third time, I was kind of exhausted, so I just did what I thought was best and I’ll just show him later. Obviously, as I’m no expert in managing a product, my best would sometimes turn out to be wrong. The PM’s natural response was “you should have asked” and I would respond with “you weren’t there and I’ve had a job to do and a deadline to meet!”.
I guess that it was also an effort for him to go up and down the stairs all the time. I guess that when he had a spark of an idea, he naturally asked the people around him. None of them were engineers. Only sales and management.
And this is how, by just merely having two floors separating between them, a boundary is created between engineering and product management.
Distance is Measured in Hours
Honestly, barely any one is actively waiting for Feedback. To pause and wait for Feedback is unnatural for me when I’m in the flow of creation. So instead, I tell myself “I have a deadline. worst case, I’ll change it later”. And later of course I smack myself on the time wasted. Same for product managers, project managers, sales, engineers, everyone. And the more time and effort it takes to get Feedback, the more frequent the above will be.
At RapidAPI (2020) we had Slack. The product managers were quite responsive. At least when we were all available. There was an entire world between us. Engineering was in Israel, PMs in the US west coast. We only had about an hour of work together a day for only four days a week.
In the US West Coast sits a PM. Let’s presume she started her day by talking with the Israeli engineering team. She now has 7-8 hours of work to pass without them. If she needs Feedback, she looks around and no one is there because she is working remotely alone from home. She slacks someone in her timezone. It would be an hour or so before she gets Feedback, because that is how asynchronous communication works.
Just like the engineers, she won’t be actively putting herself on hold because she has a job to do. “Worst case I’ll change my work later”, she tells herself. Before Covid, she used to get Feedback faster because they were all in the office together. But there were no engineers at all in the US offices. 8 hours later, she had an almost finalized design. At the end of her day, she sends it to the Israeli team and she goes to sleep. A hand-off was sent.
Meanwhile, in Israel morning has come and a hand-off has been delivered. As the hand-off was a result of 8 hours of work, we needed a lot of clarifications. As it was my first time as a manager dealing with this situation, I’ve made the team go with the flow and we’ll change it later, assuming that later changes would be small.
At the end of engineering’s day, a hand-off was sent. A very big hand-off. It included Feedback on the design and the result of our Feedback-less 8 hours of Change/code. As the Changes were big, the Feedback we got back was big, which entailed a lot of changes to do. A waste of time for us all due to lack of Feedback and time zone differences. And deadlines were missed. Something had to be done.
Changing Boundaries
A month or two afterwards I had put a stop to this, and I had the authority to do so.
“Guys, the long delay in Feedback is causing us to go down rabbit holes. If you see it coming, just stop! Do not continue with the task! Put it on ‘blocked’ until you get Feedback. Do not waste your time on it and move on to another task.”. I held my position strong on this. To handle the pushback from management about the missed deadlines, we Planned for Change and Planned for Feedback and gave more accurate deadlines.
Later on, with support from my VP R&D and as I already had past experience doing so, I took the position of an interim product manager. I’ll deal with the consequences of making a wrong decision. I’m a manager, that’s what I’m expected to do. When an engineer inquired with me about a product related issue, I did exactly what I do with technical ones – ask back “what do you think we should do?” and give Feedback. Just by doing so, we were able to come up with feasible and valuable solutions together. And I was able to teach what I know of managing a product. And we studied when we realized we did not know enough.
The time it took to get an internal Feedback was cut short, and so were the hand-offs. As the boundaries were mostly removed, a flow was created. One that better throttled The Wheel of Change, and led to shorter and clearer fruitions. We put more emphasis on validations, which led to smaller executions and smaller Feedback. It has taken us away from the wrong rabbit holes. We ended up with more satisfied customers.
We still needed external Feedback from our customers. Luckily, the CS (Customer Success) team was sitting right next door. As it was the engineer’s responsibility, it was up to him to consult with them. So he’d learn how to get and understand Feedback on his own. When needed, we alerted the CS team that Change was coming, to give us Feedback if they saw any Feedback from our customers. Thanks to them, we knew where we were going.
We were doing “design in engineering and engineering in design” between all of us. By talking, asking one another for Feedback, asking for and sharing each other’s perspectives, experience and solutions. We had unclear boundaries, which is exactly what we needed to keep things flowing.
Honestly, as one that knows how to do both things quite well, managing products and managing engineering, I must say this: No one, no matter his experience or title, can get the right job done alone on his own. An engineer that sits entirely alone with improper Feedback, would do just as bad as a PM that sits entirely alone with improper Feedback.
Thank you for your time reading this series!
The following one would be all about Planning.