Engineering Product Mindset Explained
I would like to elaborate more on my previous article. I believe that many of my readers think I put an undeservedly high focus on functional/logical architecture design without explaining what it means. Let me try to fill this gap here.
So now I am going to use the great article https://blog.pragmaticengineer.com/the-product-minded-engineer/ from Gergely Orosz as a baseline. Right, I am going to come from another side — from the common understanding of this kind of engineer. As the author said:
I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product
But I must first make a simple point: people think by models.
People Think by Models
It is a well-known fact — you can see the intellect-stack article for more details (“how it works” section). Human cognition is able to identify objects in the information flow, prioritize its own attention between the objects, build correlations, use probabilistic & connectivistic inference, and build predictions based on all of that — even for highly uncertain scenarios.
Thus, when we talk about “product-minded engineers,” from a systems point of view, we talk about a set of engineering-related mind models that some people intuitively/implicitly use.
Of course, another ingredient here is the “cultural” aspect: even if we have the skill and knowledge to do something, we need to decide to use our skill and knowledge deliberately. To illustrate this point, I can use a case when a demotivated engineer can drastically lose their performance with the same skill and knowledge. The culture is influential, but I’d rather focus on a model aspect.
The Model
Let's start with observations taken from the article I mentioned above and explain them one by one.
devs who engage with the ‘why’, actively.
This kind of question is the best one for discovering the context for engineering decision-making. Sometimes, it is suitable for technical aspects (like reverse engineering legacy decisions), but the article clearly articulates that the context here is not about tech but about customer experience:
Engineers who have the thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences.
The whole context of system operations from the customer perspective (“how it behaves?”) is what is called “functional” in systems engineering in contrast to the software craftsman perspective (“how to build it?”). I am adding the “functional/logical” synonym to emphasize the tech-neutrality of this aspect. Sometimes, we can see other synonyms like “domain” or “business” here, but all of them are about the same: how we expect our system to interact with its environment and stakeholders after we build it.
Again, the opposite aspect is “technical/physical,” sometimes “service” or “module” — all about the constructive concern: what technologies are under the hood, what API we need to define, and what code to write.
It is crucially important to understand that both “logical” and “technical” aspects must be presented in architecture design to achieve acceptable quality of the system.
let me gather more details for you from the same article, section about “9 traits of product-minded engineers”
- “Proactive with product ideas/opinions” >> That’s right because functional architecture decisions can have a huge impact on product success and on the tech complexity of the system. Example: logical design decision of having billing API
- “Interest in the business, user behavior and data on this” >> It is important to minimize uncertainty for functional architecture decisions. While the author of the original article attributes this trait to “people's curiosity”, my opinion is that it’s all about uncertainty and ADR context :)
- “Curiosity and a keen interest in “why?” >> This one is about a “soft” way to challenge roadmap and product priorities. It helps to validate the logical architecture model engineers implicitly created in their minds.
- “Strong communicators and great relationships with non-engineers” >> An efficient way to see the product from different viewpoints (see “architecture viewpoint” in ISO 42010 for more details). It helps to extend and validate functional context (QA, MArketing, CX, Sales, UX viewpoints). However, it can also help with the tech aspect (L2, SRE, Platform viewpoints).
- “Offering product/engineering tradeoffs upfront” >> Exactly how systems architects should work by balancing functional architecture design decisions with technical architecture design decisions! Unfortunately, most people still think that logical architecture is a privilege of PO, PM, or BA, so we often have inefficient and one-sided architecture decisions.
- “Pragmatic handling of edge cases” >> Worth noting a citation from this section of the original article: “…quickly map out edge cases and think of ways to reduce work on them”. It’s impressive to me how good engineers are able to find and map edge cases on the fly. I am bad at this, so I prefer collaborative modeling techniques (like DSM or “cross-validation view”) to catch all possible corner cases. But the result is usually very similar.
- “Quick product validation cycles” >> Verification and Validation (aka famous Systems Engineering “V&V,” not to be confused with “V-model” :) ) should become a part of every engineer mindset. However, it is essential to understand that the only reliable source of validation is the production env roll-out. Functional architecture has several models aiming at this aspect of product quality (acceptance metrics are one of them).
- “End-to-end product feature ownership” >> That one tells more about engineering organization processes rather than about personal traits. I would be very surprised to see any software product org that doesn’t have a formal acceptance flow defined in a way similar to what’s described in the original article. Note that “Ownership” is one of the fundamental values we need to promote to achieve overall engineering maturity, and it is closely related to the previous point (“product validation cycles”).
- “Strong product instincts through repeated cycles of learning” >> I would better formulate this one as a “domain knowledge.” It might look like “instinct” for people who learn intuitively without the right tools to perform reflection and conscious learning. I have proof that domain knowledge is possible to capture in models, learn from them, and promote better decision-making for future product evolution.
All in all, an experienced engineer with the right methodology and supporting tool can do the same (or even better) than naturally gifted, product-focused geeks.
Implicit Architecture Modeling
Unfortunately, in reality, we see most engineers have an overarching focus on the tech aspect with minimal efforts to cover functional ones in the hope that PM or BA will take care of them. Alternatively, I am seeing a widespread practice of using “user stories” as a business-oriented description, sometimes with UX mockups. It is better than nothing, but I can hardly imagine that engineers genuinely enjoy the process of gathering system context for their ADR from multiple Jira tickets :)
Why is this happening? Human cognition has some answers.
The book “Thinking, Fast and Slow” by Daniel Kahneman provides a path to understand that fast (intuitive) thinking is preferable to human being due to less energy consumed in comparison with the slow (conscious) cognition process. When working on the initial phase of system architecture design, people mind trying to build a functional/logical model in a fast way and then switch to slow thinking as late as possible — usually on technical decisions and low-level system design models.
A good illustration of this point can be seen in any out-of-context architecture discussions, like the ones happening in software architecture communities.
If you have ever joined a conversation in dedicated software architecture communities like I did, I bet you have seen the same pattern:
- Someone asks, "what tech/pattern do I need to use for my case?”
- Others start suggesting alternatives for a given case, like “use transaction outbox, or use EDA, or CQRS”
- Then, someone more experienced comes to the discussion and starts asking guiding questions about the goals and expected system behavior. That’s the moment I smile because we drive discussion from the tech design to a functional/logical design phase where the most influencing decision could be made.
The main problem is that no common discipline and tooling around functional/logical architecture design exists.
Yes, we have a context diagram in C4, almost forgotten ERD, and rarely used UML Use Cases. But looks like product management JTBD and enterprise architecture Value Stream and Capability models are closer to what we need to make engineering great again. Until then, architecture design will be fragmented and isolated by role.
Here I come the aspects of the exemplary architecture I mentioned in my inaugural post — the #collaborative #full-cycle #systems_architecture
I hope now you have a better understanding of what is behind the V-model from my previous article:
PS Replicate and Scale
What if we take these models from the mind of a single engineer, then document, share, align everyone around these models, find gaps, run continuous improvement cycles, etc.?
Stay tuned, and I will share more about that in my following writings.
