Engineering managers are technical leaders for a software product. It can be an internal or publicly facing application or a service critical for an application. Even though software engineering teams are not a product owner in the organizational structure, we're still fully responsible. If something breaks in the middle of the night, your team or you will be up to fix it.

To be an owner, you need to understand your product well, not just the technical side of things but the full picture. Only when you know everything from the high-level architecture to the business details can you be confident making important decisions and knowing what the impact is. Representing your team and the product in executive meetings, quarterly plannings, budget reviews is a big responsibility. Having a deep understanding of your product and its architecture and roadmap is the key to being a competent product owner.

End to end system design

The product doesn't exist all by itself unless it's an early-stage startup. Most architectures have layers and layers of microservices, databases, caching, and front ends. There are upstream and downstream dependencies for your product, critical and noncritical, synchronous, and asynchronous. When I join a new team, this is the first thing I want to understand. The full system diagram gives me a map of the land, and I can use it to navigate the new territory. If your team still doesn't have one, it's a great exercise to uncover hidden corners and educate some engineers on what makes the product run in production. It may be surprising to some that it's not just the code they write.

Usually, I have a few versions of the system design. A high-level document is for the quick lookup. And a detailed diagram describing all the components and how data flows back and forth. For the complete version, try to go as deep as you can. Usually, the end means a database or storage, where the data is permanently stored. Then go even deeper, ask if the data is encrypted, is it replicated, what's the access policy, is it backed up. No one person knows all this, that's why it's engineering manager's responsibility to interview architects, SREs, DBAs, software engineers to get the full picture. Once you get all the pieces together, present the complete diagram back to them to check the accuracy and fix the blind spots. It's a living document that you should be revisiting every quarter to remind your team of the product architecture and apply any changes.

Hardware and network topology

Once the system design is clear, next is the hardware and network topology diagram. This document will help you understand how the components interact, where they physically are, how many copies of each exist. The traffic doesn't hit your server directly, but it usually flows through CDN, router, API gateways, firewalls. If NOC calls you in the middle of the night about your service is down, you should know if they can redirect all traffic to another instance, where it is and if it can handle all the traffic.

The topology is more of the operations management or SRE responsibility. If your company has a department dedicated to it, start there, ask your ops engineers if they have a diagram for your product. If they don't, or it's somewhat outdated, you have an excellent opportunity to collaborate. They will appreciate having it as much as you do.

image reference https://docs.pivotal.io/platform/2-7/plan/gcp/gcp_ref_arch.html

General architecture

With all the high-level pieces in place, you can dive deeper into the software architecture. Coding may not be your responsibility as a manager, making it even more critical to understand your product architecture well. Software engineers who are making the product know the technical details well. Suppose you don't take the time to follow the architecture. In that case, you're not well-positioned to advocate for allocating time to work technical debt, long term planning, or answer questions if your product can support certain features.

Depending on programming language and frameworks, there are few common architectural patterns. Essential things to understand are how the application manages state, how it handles request/response, and authentication, component/class structure. Like anything else, balance is the key, keep the architecture diagram as detailed as needed but not more than that. It doesn't make sense to include every class or function. The goal is to outline the big picture and give you and others an understanding of how the application is architected.

Like system design and network topology, this document can be helpful not only for you but also for your team. Not every engineer may be familiar with the entire architecture, and it's an opportunity to learn how all the pieces connect.

Simplified Redux architecure

Risks and technical debt

Unless you are leading a greenfield project, there are always risks associated. They can be things like a lack of unit tests, technical debt, security vulnerabilities, known bugs, and functional limitations. As a leader, your goal is to have a plan to address and mitigate the risks.

Similar to any roadmap, I found it helpful to have a prioritized list of technical debt projects. Outlining the following for each one:

1. Overview. What this project is, and its scope.
2. Current state. What is the problem, why it exists, the impact on the product and business?
3. The solution. The proposal to address the risk, what is the ideal state when completed.
4. Resources. What resources needed to solve the problem and a rough estimate of how long it's going to take.
5. Milestones and acceptance criteria that describe the execution plan.
6. Stakeholders to signoff.
7. Terminology.
8. Technical deep dives (diagrams, architecture details, code examples).
9. Additional assets, docs, resources
10. Action items.

If you're joining a new team, keep asking your team what technical projects we need to prioritize. Chances are there will be one or two everyone will mention. Another way to spot technical debt is production issues and bugs related to one area or feature in your product, or when you keep getting reasons why it's challenging to fix certain things. Good architecture should flexible, stable, maintainable, and easy to understand.

According to Lehman's laws of software evolution, on the one side, the size and the complexity of a software system will continually increase in its lifetime; on the other hand, the quality of a software system will decrease unless it is rigorously maintained and adapted.

Keep in mind that software is never perfect, never without risks or technical debt. Always make the time to maintain the system and improve it, or its quality and stability will degrade.

Success metrics

Every product solves a need for their customers. It provides some value that people are willing to pay with money or attention. Sometimes some of the values can be invisible. Depending on your organization, you may or may not have a product manager. If you do, ask them to explain all the hidden corners of the product, strategy, roadmap, competitive analysis, and, most importantly, all critical functions. If you don't have a PM, you have some discovering to do.

The best way to learn your product is to use it. Hopefully, there is enough value for you to become its customer or, as some call it, "dogfooding." Encourage your team to use the product as much as possible too. There is a risk of getting disconnected from reality and keep building features nobody wants. Anchor yourself and your team by being the customers of your product.

It can be helpful to draw a user flow or write step by step actions your customers take to achieve the goal. Let's take, for example, a hotel booking app. The core value is to provide a way for users to make an instant hotel reservation for desired dates, compare prices, see photos, and reviews. The end goal is to book the hotel room. There are dozens of supplemental features and nice to have in this flow, but if the user can't book a hotel, your business is down. That is the critical path. Make sure you know what it is for your product.

Understanding how your customers use the product will give you a sense of what metrics you should monitor. Monitoring your product is critical for success. As soon as code is live in production, you can't tell for sure if something is working, if it's slow if there are bugs unless you have proper monitoring and alerting set up. Please don't wait for your customers to report issues. After the critical product path and success metrics are ready, you could define an SLA and measure your service performance against that.

Stakeholders

Every product has stakeholders. Even internal products that don't generate revenue have them. Anyone who has an interest in the product, who can influence decisions, or is impacted by the product is a stakeholder. The engineering team responsible for building and maintaining the product is one of the stakeholders too.

It's important to know and have good working relationships with stakeholders, decision-makers, and collaborators. It's your extended team. They will be a partner in the planning, prioritizations, and pushing for success. Most likely, you will have different opinions on how to get to success. And it's ok. Be comfortable with conflict, because the organizational structure is set up that way. Business and marketing departments have different ideas and incentives to get to success than engineering. Keep your stakeholders informed, educated, and involved.

___

Collect as much information about the product as you can, interview your stakeholders to connect all the pieces. It's an excellent opportunity to uncover hidden complexity and details together. And then keep the diagrams and documentation up to date. Once you have the full picture, share it with your team and stakeholders as a single source of truth about what the product is, its architecture, and the critical path.