Support Your Local Product Owner

I've been searching for a software architect position (or something similar). Job titles aren't always the best indicator of what a company wants out of a role. Many of these roles involve some aspect of product ownership. I'm usually a bit cautious because in order to be successful as a product owner there are five things needed:

• Bandwidth
• Having enough time to work with the Scrum team, manage the product, and work with the users, customers, and stakeholders.
• Power
• Having the authority to manage the stakeholder needs, order and refine the product backlog and product needs, and the ability to accept the product increments.  
• Knowledge
• Having a deep understanding of the product, who the users and stakeholders are, what they find valuable, and what the organization’s goals are for the product.       
• Interest
• Having a strong desire to be the product owner and being able to maximize the value of the product.
• Vision
• Having a great understanding of what the product is, where it should be going, and the goals for the product.

These attributes are a pretty big deal and an employer needs to make sure that each one of them is supported to ensure success of the product owner and to improve the odds of the product's success.

Community Adoption of New Practices

Community adoption of new practices can mean a lot of things.  From getting a small team to try a new methodology or tool to convincing the world that a product or service is needed.

In 1996, Robert Metcalfe was awarded the IEEE Medal of Honor for "exemplary and sustained leadership in the development, standardization, and commercialization of Ethernet." The story of how Ethernet came to be follows the 8 steps of essential practices below. I've added headings for what departments typically handles each practice in a large company. You don't have to have different people or departments. I find it helpful to get into the mindset of each role when implementing a specific task.

• Product Management
• Sensing -- giving voice to a concern over a breakdown in the community
• Envisioning -- design a compelling story about a future without the breakdown
• Development
• Offering -- committing to do the work to produce that feature
• Sales
• Adopting -- gaining commitments from early adopters to join the innovation for a trial period
• Sustaining -- gaining commitments from majority adopters to join the innovation for an indefinite period
• Implementation
• Embodying -- working with the community until the new practice is fully embodied, ordinary, and transparent
• Navigating -- moving ever closer to the goal despite surprises, contingencies, and obstacles
• Marketing
• Mobilizing -- building a network of supporters of the innovation from within dispersed communities

Many times over my career I've been assigned the job of getting multiple software development teams to adopt a practice; coding standards, secure coding practices, SOX requirements, architectural guidelines, etc. Eventually, the above 8 practices were performed but not always in an order that was useful. I got better with experience, but my life would have been easier if I would have had those practices written down to guide me. To make notes against. And to revisit when progress was slow or stopped. I hope you'll save the above list and use it for your future innovations.

References

Denning, P., "Avalanches Make Us All innovators," Communications of the ACM, Vol. 63, No. 9 (Sept 2020), 32 - 34.

Sorry, I don't have a reference for Metcalfe's Ethernet story. I heard him talk about it at a conference in 2015 or 2016.

Top 10 Project Management Risks

As a software architect, I've assisted in project management and filled the role of product owner. For all of these roles it is important to be familiar with the situations that most often cause software disasters. These are your most likely risks, but not all of them:

• Personnel shortfalls
• Unrealistic schedules
• Not understanding the requirements
• Building a poor user interface
• Trying to gold-plate when the customer doesn't want it
• Not controlling requirements changes
• Shortfalls of reusable, interfaced components, or microservices
• Shortfalls in externally performed tasks
• Poor response time
• Attempting to exceed the capability of current computer technology

If you don't already have one, this list is a good starting point for a project planning checklist. Additionally, you should add risks unique to your environment, industry, and project then develop plans on how to mitigate them.

Reference:

Boehm, B., "Software Risks Management: Principles and Practices," IEEE Software, January 1991.

Allocate Appropriate Resources

Artificially constrained schedules and inappropriate budgets will doom a project regardless of the quality of the people or the availability of tools, languages, and process.

If you try to compress either schedule or budget, the engineers working on the project will not work efficiently, there will be no wiggle room when the inevitable slippage occurs, morale will suffer, and the project will probably cost more than what would otherwise be considered reasonable anyway.

In short, tightening a schedule or budget to land a contract or to get stakeholder sign-off will only ensure your failure to deliver. The goal isn't to get project approval. The goal is to get approval for a project that can actually succeed.


Reference:
DeMarco, T., "Why Does Software Cost So Much?" IEEE Software, March 1993.

Problem Solving

Beware of the person who knows all the answers:

Suppose two politicians are running for president, and one goes through the farm section and is asked, "What are you going to do about the farm question?" And he knows right away - bang, bang, bang. Now he goes to the next campaigner who comes through. "What are you going to do on the farm problem?" "Well, I don't know. I used to be a general, and I don't know anything about farming. But it seems to me it must be a very difficult problem, because for twelve, fifteen, twenty years people have been struggling with it, and people say that they know how to solve the farm problem. And it must be a hard problem. So the way I intend to solve the farm problem is to gather around me a lot of people who know something about it, to look at all the experience that we have had with this problem before, to take a certain amount of time at it, and then to come to some conclusion in a reasonable way about it. Now, I can't tell you ahead of time what solution, but I can give you some of the principles I'll try to use - not to make things difficult for individual farmers, if there are any special problems we will have to have some way to take care of them," etc., etc., etc.

Now such a man would never get anywhere in this country, I think. It's never been tried, anyway. This is in the attitude of mind of the populace, that they have to have an answer and that a man who gives an answer is better than a man who gives no answer, when the real fact of the matter is, in most cases, it is the other way around. And the result of this of course is that the politician must give an answer. And the result of this is that political promises can never be kept. It is a mechanical fact; it is impossible. The result of that is that nobody believes campaign promises. And the result of that is a general disparaging of politics, a general lack of respect for the people who are trying to solve problems, and so forth. It's all generated from the very beginning (maybe - this is a simple analysis). It's all generated, maybe, by the fact that the attitude of the populace is to try to find the answer instead of trying to find a man who has a way of getting at the answer.

 —Richard Feynman

And make sure that person is not you.

Developing Great Product Management and Engineering Relationships

A healthy relationship between Product Management and Engineering is critical to build successful products. It’s also essential in creating a team where people want to work.

When it goes well, we’re two partners working shoulder to shoulder towards a shared mission. Each is grateful for the contribution of the other. When it goes badly, there’s finger pointing, ignored input, wasted work, frustrating processes, and resentment.

Here are the 4 keys to a healthy engineering and product management relationship.

Share Leadership and Credit

One of the top ways Product Managers damage relationships with engineers is by hoarding all the credit. They claim that they thought of all the ideas and make sure they’re always the ones presenting to executives, leading meetings, or announcing results. They act like they’re the most important person on the team.

Explicitly share leadership between product managers, engineers, and designers. Each role has a clear responsibility, but we all work together to share our points of view and come to better solutions together. We have different points of view, but we all know we’re on the same team working towards shared goals.

One specific way to share leadership responsibilities is through the concept of Program Lead (PL), who can be either a Product Manager or an Engineer on the team. PLs own communicating progress, establishing the rhythm for the team, and team unity. The Program Lead can be the same person as the Tech Lead, but on some teams, they are different engineers — one person is responsible for running the team, while the other person is responsible for the technical direction.

Another way to share leadership and credit is with Key Results. These are team goals that get shared across the company. We assign them to the person who contributes the most towards their success, whether it’s an engineer, PM, designer, user researcher, or data scientist.

With this system, more people get to take on leadership roles and everyone gets recognition for their work.

Include Engineers in Product Decisions

Some PMs think it’s their job to have all the ideas and do all the product thinking. They’ll go off with their designers and come up with a grand vision to toss over the wall to the engineers for implementation. If an engineer comes up with a proposal, they’ll quickly dismiss it — either out of a lack of respect or being territorial.

Engineers need to be involved and can lead product direction from the beginning of the product lifecycle. Gather input from across the company when planning a roadmap and include all the engineers on a team in research and design brainstorming at the beginning of each project.

Engineers appreciate understanding the reasoning behind product decisions. PM’s love when engineers come up with valuable ideas enabled by creative technical solutions. We know that aligning everyone on the team around a shared purpose and shared understanding will help achieve bigger and better things together.

Clarify Roles and Reinforce them with Mutual Respect

An easy way to muddle any work relationship is with unclear roles and lack of respect. PMs insult engineers by trying to tell them how the code should work, or endanger the schedule insisting on frivolous features with outsized costs.

Focus on clarity of purpose, plan, and responsibility. PMs own the problems and Engineers own the solutions. For team leadership responsibilities that can vary from team to team, go a step further and fill out a checklist so it’s clear for each responsibility whether the PM or Program Lead will take it.

Mutual respect is really in the cultural norms. Never have a PM sign an engineer up for a deadline without their buy-in. Engineers take the time to explain technical challenges to PMs and really care about the customer impact of our work. Consider providing all new employees with some training that reinforces the idea to approach situations with curiosity rather than a need to be right.

Clear Away Inefficiency and Help Your Teammates Succeed

Some engineers think that PMs just add bureaucracy and inefficiency. They’ve worked with PMs who try to solve every problem with more meetings and who burden engineers with work about work without convincing them that it’s worth it. Even worse, those PMs thrash projects in the middle because they’ve changed their minds, wasting weeks or months of work.

PMs need to be a productivity multiplier. Encourage them to look for every kind of creative way to help our teammates be more efficient and effective. Develop a product process to ensure everyone really understands the customer problem you’re going after and are all on the same page about goals at the beginning to avoid unnecessary changes later.

Healthy relationships between PMs and Engineers are critical to the success of any project. With shared leadership, inclusive decision making, mutual respect, and a commitment to helping each other succeed, you can build a team that delivers results and attracts great people.

Change During Development Is Inevitable

Software will change during development! The changes might be refactoring code, adding new tests, changing requirements, or adding new requirements. The changes could be as simple as fixing bugs, or general improvements.

Prepare yourself for changes by making sure:

• that all software development is appropriately cross-referenced,
• Record Why Requirements Were Included
• Trace Design to Requirements
• Trace Tests to Requirements
• that change management procedures are in place, and
• Establish SCM Procedures Early*
• Give Every Intermediate Product a Name and Version*
• Rank and Schedule Change Requests*
• that budgets and schedules have enough leeway so that you are not tempted to ignore necessary changes just to meet budgets and schedules.
• Don't Set Unrealistic Deadlines*
• Avoid the Impossible*
• Avoid Standing Waves*

Reference:
Bersoff, E., V. Henderson, and S. Siegel, Software Configuration Management, Englewood Cliffs, N.J.: Prentice Hall, 1980, Section 2.2.

The More Seen, the More Needed

"The more functionality (or performance) that is provided to a user, the more functionality (or performance) that the user will want."

Which supports:

• Give Products to Customers Early
• Grow Systems Incrementally
• Software Will Continue to Change
• The System's Existence Promotes Evolution

More importantly, you must be prepared for the inevitable requests for more.

• Documentation should be organized in such a way that it is easy to update and add to.
• Establish SCM (Software Configuration Management) Procedures Early.
• Systems and processes in place to handle the users' requests.
• Design so that configuration is quick and easy.

Reference:
Curtis, B., H. Krasner, and N. Iscoe, "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, 31, 11 (November 1988), pp. 1268--1287.

Quality is #1

A product with poor quality should not be tolerated. Delivering a product at the cost of quality should only be accepted in the short-term. If you are using Agile Methodologies, in the span of a sprint, it is acceptable to deliver what you have at the end of the sprint. This will allow for continued progress and enable the gathering of valuable feedback. However, it is political suicide to continue to deliver a product with poor quality. If there is a quality issue then change your roadmap and milestones to address the quality issue.

From Sensing An Opportunity To Implementing An Idea

That's when you know -- you can't sleep because you're thinking about this idea incessantly. -Mona Bijoor, Founder of Joor

The above quote was listed under the heading "On Sensing An Opportunity" in the November 2014 issue of Inc. magazine. I completely agree that always thinking about an idea is an indicator that you are sensing an opportunity. Great! You have sensed an opportunity now what should you do about it?

Write down your idea. It is time to stop just day-dreaming and get to work turning the idea into a reality. Writing down your idea will make it easier to improve, share, and implement. Before trying to improve, share, or implement your idea you need to start thinking about it with purpose.

What is needed to make the idea a reality? How much would it cost? Be sure to break down the costs. One grand sum may be useful for a bottom line but everyone who is serious about your idea will want the details. How will the idea either make money (business venture) or pay for itself (charitable effort)? What percentage of people really want this? Etc.

I can't list out all the questions because many will be specific to your idea. The point is that once you sense an opportunity it is time to stop thinking about how great the idea is and start thinking about how to get it implemented.

Managing Technical Debt

Technical debt is all the shortcuts that save money or speed up progress today at the risk of costing money or slowing down progress in the future. It is inevitable, and can even be a good thing¹ as long as it is managed properly, but this can be difficult. The difficultly comes from many causes, usually has hard-to-predict effects, and almost always involves a gamble about what will happen in the future. Managing technical debt is similar to risk management, and similar techniques can be applied. If technical debt is not managed then it will tend to build up over time until a crisis results. It can be the catalyst to system failure, or a multiplier of failures.

Technical debt can be viewed in multiple ways and can be caused by all levels of a company. It can be managed properly only with the understanding and assistance from all levels. It is extremely important to help nontechnical parties understand the costs that can arise from mismanaging that debt.

1. Releasing code early to get feedback sooner rather than later can save a company from investing heavily in something that is not desired. Fast feedback helps development stay on track with the customer's desires.