If you work for a company that builds primarily consumer software, there are, hopefully, three groups of humans who believe they are accountable for the product. They are:

• Engineering. They build the product.
• Design. No, they build the product.
• Product Management. No, really… they build the product.

Do you see the issue? You have three different groups with different skill sets, each of whom firmly believes their decisions are the decisions that allow the product to exist. They are each directionally correct. You can build a good product in a perfect world where each constituency is equally capable of doing its job. This includes a complicated process where these constituencies capably disagree, debate, and learn from their differences.

Problem is, the world is not perfect, and you need to build great product. Now.

Disclaimers: For every hypothetical engineer, designer, and product manager that I’m about to implicate as incompetent, there is an equal number who are not just capable, they are an absolute inspiration. There are additional roles that I don’t discuss that are essential to your burgeoning product company. Quality, marketing, sales, support. They are essential, but that’s a different article.

Gosh, I want to describe all the interesting failing configurations of Engineering, Design, and Product Management that I’ve personally observed sucking the life out of a good product, but let’s start with the greatest hits:

Scenario #1: Product Managers as CEO. In this variant, your product managers think they are the CEO of the Product. If you think about this configuration as voting rights, the product managers would suggest — trying to be helpful and fair — that they’ll serve a tie-breaking vote when we can’t agree.

They honestly claim this voting structure not because they want all the power; they want to cast the tie-breaking vote when there is gridlock occasionally. And, ya’know, sometimes someone needs to decide, ya’know, just to keep moving things along.

Bullshit. They do want the power. These power structures are counter to great product design and development. They amplify individual opinions over the hard work of building great decisions. Those painful impasses where no one can agree? Those are hard-earned decisions that will make your product great. Yes, they are hard. Yes, it’ll feel like you’re wasting precious time swirling around a decision, but this is critical work. This is when you discover a feature’s truth, value, and essence.

Product Managers CEOs with the tie-breaking vote will eventually make unilateral decisions with insufficient cross-functional debate because they believe they are “moving us along.” They will do this precisely when you and your team could learn the most. They believe that because the title is Product Manager, they are the Product.

In my experience, the attributes I value in a good product manager are:

• Understand the current feature set deeply and how new features complement and enhance the future product.
• Can speak for the customer because they’ve taken the time to understand the customer deeply.
• Know the critical decisions that were made that resulted in the current state of the product. They know what is broken and how it became so.
• Are capable of making reasoned decisions and explaining their thinking to anyone.
• Are curious and willing to learn about anything relevant to the product whether it’s their domain or not.

Scenario #2: Uncompromising Designers. If you want to trigger a designer, here’s a simple approach. Ask them, “Why are we spending so much time on this inconsequential color, typeface, layout, or other trivial thing?” At this moment, they hear three thoughts at the same time:

1. “This person thinks my work is inconsequential.”
2. “This person doesn’t understand that small bits of work elegantly and thoughtfully combined is the big thing elegantly working.”
3. “This person believes that because the decision appears easy to make, it does not require work.”

Designers hear some small version of this critique a lot during their careers. When you combine this with the fact that Design teams are small relative to Engineering, they must choose their product design battles carefully. Often, after years of losing these battles to Engineers who belittle their craft as inconsequential or Product Managers who state product ideas as design ideas, these designers transform into the Uncompromising Designer.

These humans (or teams) politically move to an independent metaphoric island where design is produced. They then put this design on a little ship that travels to the mainland, where Engineering and Product Managers live. Designs are reviewed, commented on, and returned via the same little ship where wait for it, all feedback is ignored with the unspoken rationale, “They don’t understand what we’re trying to achieve. They aren’t on the island.” (Note: No one is ever invited to the island.)

In this nightmare scenario, Product Managers and Engineers are picking and choosing from the designs (without the designers in the room — I’m not kidding — it’s terrifyingly common) and implementing random features based on an uninformed feel. Customers who see this haphazardly designed product think, “It looks kind’a like what I want to do, but I struggle to understand the product. I click… this?”

This is most software, I’m afraid.

Good designers I’ve worked with:

• Understand that how a user feels about a product dramatically influences their use.
• Are comfortable in the depth of their craft. They can deftly explain how their choices of layout, color, and typography affect the approachability of the product.
• Will defer to their professional peers when the time is right after everyone’s been heard and if the winning argument is sound.
• Obsesses about the details because the details work together to define how the user feels about the product.
• Are curious. Willing to learn. Doesn’t matter if it isn’t their area of expertise.

Scenario #3: Disconnected Engineers. Our final failure case is a reaction to our prior two scenarios, and this is the primary scenario I want to discuss because, as an engineer, it’s the one I want to fix.

The Disconnected Engineer has spent the last six years of her life working to become a good engineer. This started in high school when she first discovered Python and saw computers as a tool for bringing ideas to life. Four years in college, becoming a computer scientist along with two internships, and now she’s hired into her dream: a full-time software engineer. A company she respects.

Problem is: Product Management thinks they’re the CEO, are drunk with power, and are adept at tossing impressively sounded bulleted lists over the fence to Design and Engineering. These lists have no context and littered with meaningless MBA-speak designed to sound official but do nothing to explain a coherent product strategy.

Meanwhile, over on the island, Design is musing about whatever the hell because they know those bullets from Product Management are whatever occurred in their last three meetings and have no strategy or substance. Design has heard we’re going to do Feature X and has produced stunning designs in a vacuum that will be delivered whenever the next ship leaves the island. Our engineer wants to engage with this design and discuss it, but Design is on that island far, far away.

Extend this passive-aggressive product-hostile situation over a few years, and our bright and eager Engineer becomes the Disconnected Engineer. The human accountable for building the product with their hands exists as a semi-motivated engineer who is grabbing bullets as they come over the fence and combining them with misaligned and misinformed design from the island, which results in strangely constructed features that… work. I mean, they look like features, but when I asked this engineer why she chose this approach, she said the thing that crushed my soul, “They told me to do it this way.”

Unacceptable.

The Product Engineer

I am not the first person to slap these two words together, but I want to introduce a concept of a different type of engineer: the Product Engineer.

As a starting framework, a Product Engineer:

• Has a deep knowledge of how the product is built. If the product is not yet built, they can scribble how it should work on a whiteboard.
• Able to explain to anyone with the motivation to understand how each product feature works. They are likely more knowledgeable regarding certain feature sets in larger products, but their understanding of the complete product is vast.
• Actively use the product and report bugs when they happen upon them.

Do you know what bad product managers do to engineers (and designers)? They suck the air out of accountability. Their existence creates the impression that someone other than the human responsible for building the product with their hands is better at designing and building products. That someone else has a plan.

What?

Bad product managers are an active hindrance to developing software. This is the reason I’m picking on them in this piece. With no product management function¹, someone else must do the work, which organically falls on engineering and design. My definition of Product Engineer expands to include all the responsibilities of the Product Manager (and a little bit of Design).

A Product Engineer:

• Uses the product every day and reports bugs aggressively when they find them.
• Intimately knows how the products work and can explain any feature or inner workings to anyone. When they find a gap in their knowledge, they fill it.
• Have a deep understanding of how users perceive their features and how their changes would affect their perception. They can wear the customer mindset.
• Remember the debates around the most complex decisions and why we chose this path.
• Have living breathing code in the product — right now.
• Can effectively argue with anyone on the team regarding the product. Will defer to their team members when the argument is sound, but they will continue to argue until there is product clarity.
• Communicates well in every direction because they’ve developed professional relationships in all those directions.
• Are aggressively curious and willing to learn anything relevant to the design and development of the product, especially when it’s outside of their area of expertise.

A Product Engineer is accountable for the product.

Accountability is not responsibility. Accountability means you are required or expected to justify your actions and decisions. You are required to give an account to share the story of how we decided to build this feature, why we chose it over many other features, and how we iterated on subtle design tweaks for months to deliver what we believe is the best possible version.

Somebody Else’s Job

Any number of organizational configurations involving engineers, product managers, and designers can produce successful products. Over the past three decades, my observation is that the companies that have let the builders — the engineers and the designers — own significant parts of the role of Product Manager produce stronger products.

You want the humans building the product to have an equal voice in product decisions. You want the hard decisions to painfully earn their resolution through long hours of informed humans staring at the problem from every angle. You want humans who build.

Years ago at Borland. My first real gig. I was poached from an internship into a full-time QA gig. When I accepted the offer, they sent me a box of Borland schwag, t-shirts, notebooks, and pens. I was elated. No more hourly wages, I was full-time.

Six months in, my manager sat me down at her desk and slid a piece of paper over. She was quiet and, in hindsight, nervous. I read the paper and realized she was documenting how I had failed at my job. She asked me to sign the piece of paper I’d barely read.

I did. Next to my signature was a date. It wasn’t today; it was 90 days from today.

Disclaimers

I wrote a piece about performance management a few years back. This was entirely for managers. This piece is for the individual contributor on a performance plan, but I need to set two initial conditions to make this helpful.

First, there are bad managers who use performance management not to address a performance issue but to let go of an employee as quickly as possible. Sorry. These managers suck. For this article’s sake, we assume the manager intends to address the performance issue.

Second, I’m assuming this is a fixable situation. You are in a job you can do, and through a combination of your and your manager’s focused effort, it is possible to succeed.

The First Challenge: Acceptance

“I had no idea I was failing.”

I thought this when my manager slid the paper over to me. I’ve heard this when I was the manager, and I hear this over and over via the recap when my managers deliver a performance plan.

This is the overwhelming first reaction to a performance plan, and the contributing factors for this reaction are:

• Humans really don’t like to give negative feedback. In fact, we’ve rebranded this type of feedback as constructive feedback because we are so profoundly uncomfortable delivering it. Because we avoid giving it early and often, this is likely the first time you’ve heard it in a focused and direct way.
• Humans really don’t like to receive negative feedback. It’s a self-preservation thing. It’s pride. We effortlessly twist the story to hear the narrative that best suits our worldview.

Your first of four challenges is entertaining the idea that you can fail. You’re not going to wholesale believe this right now, but if you can’t consider the possibility of failing, you certainly won’t be able to address it.

The Second Challenge: Clarity

After your initial reluctant acceptance of the situation, the second challenge is clarifying the current state and remediations. Assuming you have a competent manager, this data should be sitting right in front of you in a written form, but here’s what you need to do, preferably during this first meeting:

• Read the description of the situation. Forgetting your instinct to holler, “This is a total surprise” does the description make sense? Is it fair? Does it describe reality? If you declare, “Everything here is wrong, and this is a travesty,” you fail the first challenge. Clarifying misperceptions, adding critical missing data, and asking for more detail are the first healthy steps in resolving this situation, and they demonstrate your willingness to do so.
• Read the expected next steps. This is a description of the work you need to complete. Like the description of the situation, the goal is understanding. What work do you need to complete? Is it obvious how success will be measured for these tasks? How often will we be meeting to review progress?
• Finally, there’s that date at the end of the document. What does it mean? Delicate topic here because it could mean, “We’ll check-in on this date” or “This is when we’ll decide on your status at the company.” Understanding what this date means is critical data you need.

The time you take to review this document the moment it lands is essential. Yes, it’s okay to sleep on it and have additional questions later, but at this first moment, you are setting expectations with your manager about how you will approach this work. Constructively engaging in the conversation sets a starting constructive tone.

The Third Challenge: Do the Work

Once everyone agrees on what actions to take and what success looks like, we begin the third challenge: do the work.

The challenge here is focus. Remember that piece of paper she slid over and had me sign? I asked about that date, which was 90 days in the future. The answer was, “If we don’t fix this by this date, then we will take action.” The date exists to give the plan structure, but it feels like a threat. It sounds like an angry clock ticking in the back of your head, and if all you do is obsess about the ticking, you won’t do the work.

Focus on the work. Back at Borland, I was so new to the industry that I didn’t understand the gig. Borland was experiencing rapid growth, so my manager didn’t spend sufficient time with me, and I was all over the place.

The work:

• Write test plans that exercise new features.
• Find defects by executing these test plans and performing ad-hoc spot testing.
• Report these defects in a manner that is helpful to the folks who will be fixing these defects.
• Carefully confirm when these defects are reported closed.

That’s it. That was my job. Why was I failing? My memory is hazy, but I think we were many months (years?) away from having a testable product, so I was tinkering. Writing little throw-away automation scripts. Goofing around with a partially implemented product. Waiting for someone to tell me what to do. The features weren’t close to done, so no test plans and no defects were filed, so I tinkered. I goofed around, probably until the paper slid across the table.

Time to work.

Test plans. Yes, the feature was still being built, but two conversations with the engineers in the hallway quickly described what was and wasn’t working. Great, here is the first draft of the test plans for the working portions of the feature. Yes, they would change once the complete feature landed, but a partial test plan both framed my initial thinking and could confirm what was even partially working for engineering.

Find, report, and confirm defects. From the test plan. Yes, most of these defects were never fixed because the product changed so much, but the defects I filed demonstrated that I understood the current state of the product. When the defects were particularly heinous, they were fixed quickly.

And I asked for help. With the angry clock tick tocking in your ear, it’s easy to narrow your focus to what you can do right now, but the clarity you defined in the first challenge will only take you so far. You need help, and while asking might feel like admitting weakness, it builds strength. Your request for help tells those you ask that you care about their opinion and are serious about the work.

The Final Challenge: Exceed Expectations

You will succeed at this performance plan by achieving what your manager describes in the document. The final challenge might be optional, but I think it’s critical. I’ve repeatedly reminded you to face this situation stoically, calmly ask for clarification, and purposefully attack the work, but…

… it’s still a hit. An ego hit. I thought I was doing ok until I wasn’t. I was embarrassed when I realized what was written on the paper and ashamed while considering my next steps that weekend.

The final challenge isn’t just to do the work but to exceed expectations. My approach at Borland and whenever a helpful someone gives me constructive feedback is to hear it, address it, and act on it in a fashion that demonstrates that I am the expert.

My testing area back at Borland was database creation and editing for Paradox for Windows. The user interface to create a database and later change its structure. When I arrived, the user interface did not exist. Databases were being created and edited via the command line or the prior DOS-based version of the product.

My goal: become an expert in this area. Develop a deep understanding of the database’s characteristics, the different record types, performance, and storage characteristics. There was much to know, and little was written down, so I wandered the halls. I badgered the engineers for any data they could share. Yes, just scribble on the whiteboard. That’s fine. Product management? Tell me what you think. Hopes and dreams are fine. Here’s a piece of paper — scribble away. This is useful because, amongst the chaos of developing a 1.0 product, I began to have the clearest view of our goals for creating and editing a database.

Months later. Long after the performance plan was complete, I remember the head of product, an engineering director, and the engineer responsible for the feature walked into my office with a floppy disc. I grabbed the disc, installed the root, and hammered on the latest bits. No automated testing, just me running an ad-hoc smoke test — from memory — to assess the quality of these close to final bits. Took five minutes, and halfway through, the director smiled and looked at the head of product and said, “Told you. He’s the guy.”

I finished, spun around in my chair, and said, “It’s good.” Each of these humans was here because of the relationships I formed when asking endless questions about the product for which I was accountable.

The hardest part of a performance plan isn’t stoicism, understanding, or doing the work. It’s recovering from the gut punch that comes with recognized failure. Exceeding expectations isn’t about doing extra work but building confidence in one’s capabilities.

90 Days and Signature

You’re reading a recap of a performance plan that occurred decades ago, told as an idyllic tale of success designed to educate. I did eventually succeed at Borland, but I’m confident that I said nothing when the paper slid over. I was ashamed. I was depressed that weekend. I didn’t jump into Monday with vim and vigor. I was confused and spiraled into self-pity.

I don’t remember how I turned it around, but it started when I signed this paper that defined a deadline. It started when I accepted the failure of my prior work. I’ve used this practice over and over again through the years because I fail quite a bit. It’s never fun and often embarrassing, but it’s always an opportunity to start a learning process.

I do vividly remember one moment from the following week. I was sitting in a conference room that had been converted into cubes. I was staring dumbly at my screen when my manager walked in, sat on the edge of my desk, and stared at me momentarily before asking, “How are you?”

I responded, “I’m good. Let’s do this.”

So we did.

My problem with the phrase “Managing Up” involves a hard-earned historical observation regarding its weaponization. The helpful version of this practice is a clear understanding between you and your manager that there are uncommon, intriguing, or worrying developments that you — without hesitation — share with your manager.

Isn’t that their responsibility, as well? It is. Also, wouldn’t you expect them to have significantly more of these observations because their observational blast radius is larger? They do. Do we call this “Managing Down”? Gross. No, we call this bi-directional effective communication, which is a mouthful. This is also only half of a correct strategy.

“Managing Up” is problematic because it often describes a subset of humans who perform this task, believing, “I am artisanally selecting the most important bits of information to share upwardly because my judgment is incredibly sound.”

This is not what they are doing. What they are doing is manipulating perception. They have a specific selfish narrative they want their manager to build, so they carefully select a subset of the truth and market it as the complete picture. They believe their manager is so busy and soup tasting that their interpreted version of the story will become canonical.

Bad news, truth tweakers. A competent leader will source their facts. They will share that partial story with a trusted other not because they don’t trust you but because a story must defend itself, stand up to scrutiny, and prove its worth. They don’t do this because they don’t believe you; they do this because it’s perfectly reasonable communication hygiene. When they discover you’ve delivered half the story, they will quietly ask themselves, “Why half? Are they trying to save me time, or are they trying to lead me astray?” One occurrence of this behavior is no big deal. A small error. Two occurances? Is this a pattern? Probably not. Wait, three? Ok, why are they deliberately choosing to tell me a dubious version of the truth?

Managing up. If you were drawing a word cloud of dubious management-related phrases, chances are, “Managing Up” would be proximate to “Kissing Ass.” To me, “Managing Up” has that “your boss’s job is more important than yours” feel, which pisses me off.

Your boss isn’t more important than you; it’s different. You are responsible for yourself and the professional well-being of your team of seven engineers and your product. Your boss is responsible for her job, you, your six peers, their 57 respective employees, and the four products. That’s 72 humans and five products if you’re keeping count.

As you move “up” the organization chart, the amount of responsibility that weighs on a manager increases significantly, and, yes, this does mean they often make more money than you, but that is often because they have more years of experience. This experience allegedly means they can complete a more diverse set of work at vaster scale because they are you in 5-10 years, but — I remain steadfast — it’s different work.

But each of you has equal responsibility for sharing information.

Essential Information

Okay, thanks for letting me vent. With that out of the way, let’s get practical.

The amount of aggregated information you need to do your job increases as a function of the magnitude of your responsibility. This means you must become adept at finding, confirming, understanding, and passing it along in the correct direction.

That’s what you’re looking for — information that has passed through the bright minds of your team, where they’ve coalesced the vast amount of information they see into informative, crisp narratives. One challenge is they know you have six other leaders doing precisely the same thing, so they need to prioritize and choose which narratives to share.

What’s important to share? I’m glad you asked. There are three areas where the information requires constant vigilance:

• Projects — the things you build, the large tasks you complete, and the significant work involving many humans.
• People — all the humans around you in every direction helping you complete the projects.
• Politics — the connective communication that binds all the humans together — easily manipulated for good and evil.

In this piece, I will explain the projects, people, and political developments you always want to share — no matter what. While I will strive to make this complete, there is one type of development you must always report:

Unexpected developments. A situation appears in front of you, a non-threatening one but unexpected. Strange. Something is up, but you can’t discern the backstory story or the intent. It is unfamiliar. Tell your manager. Now. Just a brief note. A heads up. It’s probably nothing — it usually is — but there is a chance your manager’s context plus your suspicions equals additional clarity.

I want to start by acknowledging a fundamental professional tension. Your managers want you to believe you can do your job without them (which everyone wants, by the way), but when you fail to keep them informed about important developments within the team, it looks like you don’t know how to do your job (which no one wants, by the way). Confusingly put, neither you nor your manager is doing your job correctly when you’re sharing too much or too little information.

Here are the areas:

People

• A significant unexpected change for a key individual on the team. Life situation, odd conversation that doesn’t add up, or, again, a perception that something is up.
• Major successes. It needs to be communicated even if it was supposed to happen like this for them. Exceeding expectations is worth noting. Every time.
• For humans on your team, with an agreed-upon growth plan you’ve shared with your manager, you report minor successes against this plan. Failures, too.
• Anytime ever that anyone ever thinks about saying the words or phrases “Human Resources,” “People Team,” or “Legal.” Even if they claim to be joking, the fact they are thinking of these teams is a fact that must be shared.

Projects

• A significant positive or negative development on a critical project. Not the resolution but the observance of the development at first sight. This is even more critical when your manager has a professional stake in the project’s outcome.
• Projected-related gossip from external high-trust parties. Might be gossip. Might be an early warning system. Could be political. Keep reading.
• Achieved milestones. Missed milestones. Contributing factors and recommended fixes are appreciated for those missed milestones, but waiting until these are perfectly defined is often a tactic motivated by not wanting to share bad news. The sooner I hear bad news, the more I can help.
• Impending doom. Just the hint of it. A slight smell in the air.

Politics

• Interesting developments on external teams where we have a project dependency.
• Gossip, rumors, and lies about the project. Yes, much of this information is false, but the fact these rumors are wandering the hallways is news. Folks are spreading this misinformation for a reason that is worth discovering. True story: there are humans out there who insert lies into the organizational bloodstream to see the reaction. They call this pressure testing, and these humans are jerks.
• Just. Plain. Weird. Yeah, it’s a catch-all. Yeah, it’s the hardest to define, but sometimes people say the darndest, strangest things, and rather than scratching your head and staring at the ceiling, tell someone else this weirdness and see what happens.

Do all this consistently with your manager and team; again, you’re working with half the information.

Managing Sideways

My actual problem isn’t with “Managing Up” or “Managing Down”; if you do this well, you’re still only working with half the necessary information. You and your manager collectively represent half the information required to do your job. HALF.

Look to your right. Look to your left. That’s the other half, and you’re probably ignoring much of it. It took me a couple of decades to properly value horizontal relationships and their context. Why? Because everyone kept asking me if I was “Managing Up”. [facepalm] My manager told me what to do; they set my compensation, so I managed the relationship because they managed me.

People, projects, and politics. Your relationship with your manager represents half the information you need, half the context. It doesn’t mean you can’t do your job, but it’s not a stretch that you are missing critical developments because of the absence of this context.

If you don’t believe me, it’s because the lesson hasn’t been hammered into you by the path of senior leadership, where you become increasingly distant from the measurable familiarity of hands-on work and become adept at building a sense of satisfaction and productively finding, confirming, understanding, and passing along critical information.

And you are not doing this alone.