In the last few chapters, we talked about the importance of Feedback and the Feedback process. We’ll follow up In this chapter and the next, by talking about the internal Feedback process, and how it changes the development process and Feedback itself. As it involves the two characters of engineers and product managers, we’ll be exploring it from both their perspectives. By that, to try and reconcile between the two.
The First to Walk the Earth
Speaking of these two, today it must be hard to imagine a world without product managers and engineers. About 65 million years after the dinosaurs went extinct, came the first engineer. His name was Imhotep and he built the first pyramid in Egypt. In 1936, merely 4,500 years later, Margaret Hamilton was born and was later known as the first software engineer (1969). Surprisingly, 35 years earlier (1931) the first product manager started working in Procter and Gamble. The Agile Manifesto, written by software engineers in 2001, gave birth to a later merging of product management into the software industry as we know it today.
So in between 1969 to 2001 there were no product managers in software. But was there no one who managed the product? Of course there was! And guess who did it? Engineers (Steve Wozniak) and designers (Steve Jobs), together! Unfortunately, I guess most companies had mostly Wozniaks, so what we call product management today was done by software engineers.
I guess some did it well, or else there wouldn’t be so many software companies in 2001. I guess some were really bad at it, as I can’t explain why almost all remote controls have so many unnecessary buttons. But even engineers who were naturally good at managing a product, they knew not enough of it. Because only later product management became an expertise, a time consuming one which requires a different experience and a different skill set. As such, it’s only natural to hire an expert to work side by side with the engineer. Whether the engineer realizes it is so, is a whole different matter.
A Division
Some relationships between product managers and engineers end up like this:
This is not a Feedback-Change cycle. It’s not a cycle at all. It’s two people pitting at each other, and pitting the work down the rabbit hole.
For an engineer, the transition to working not entirely on his own is not an easy one. He’s no longer deciding entirely on his own. It is now shared with another. An engineer now has boundaries to obey, not so clear ones. He keeps doing what he does best, only to be rejected with “it’s not your decision to make”. it’s no longer solely his product to manage and his decision to make. And on top of that, he now has to slowly realize he was not as good as he thought he was at managing the product (notice the difference between the act and the role).
A product manager may be frustrated by his success’ dependency. The hands of execution are not his, the PM himself is fully dependent on another. If the engineer fails, the PM fails. It is outside of the PM’s control and reach. The PM would just be doing what his job definition says, to come up with a design perfected by the hired expert, himself. Once handed over, the first thing he’d get are rejections.
Some would be technical rejections, because every design crosses an unclear boundary to engineering. The PM would then have to change a design he’d thought of as final, a design perfected by an expert. It would be hard to overcome such a deeply nested idea. It’s like asking Vincent van Gogh to change a color right after he was done painting it, to change his perfect work of art he has worked so hard on.
There would also be some product-wise rejections. Because the engineer also has some experience in managing a product. He has seen and been through stuff. And no one likes his experience being ignored, neither engineers nor PMs.
Tightly Coupled
Design and execution are inseparable, as they are both a part of creation itself. If the execution fails, the design would not be fruitful. If the design is insufficient, there would be no fruition to execution. The chain is as strong as its weakest link.
The above is a work process of creation, a model of it. One step after the other. And as one person “design” and another person “engineers”, a hand off is created between them. Maybe this is one reason that causes waterfalls. But creation is not a process at all. Creation is a flow.
The process of creation looks entirely different when it is within a single person. When there are no hand-offs, there is only a flow of designing and engineering within one’s single mind. Not a modeled process.
While I’m designing, I’m joined by engineering. And while engineering, I’m joined by designing. There is design in engineering and there is engineering in design. In one’s mind, not only there is no need for clear boundaries but clear boundaries can be harmful.
So it is neither the PM’s fault nor the engineer’s fault that they find themselves at each other’s throats. It’s the fault of a boundary created to creation itself. But as each one separately is a necessary expertise of his own, a boundary is inevitable. Luckily, different conditions set different boundaries. Some look more like a process, some look more like a flow. We’ll see how these boundaries are created in the next chapter.
(BTW, after googling it, the above is not “Yin and Yang”, but a Taijitu. Tomato/tomato)