There’s a meeting going on right now. It’s a cross-functional meeting, which means that not only are multiple departments in the organization represented, but multiple expertise types, attitudes, and agendas as well. The cross-functional nature of this meeting means a program manager is present and they are likely serving in their role as translator.

See, good program managers speak all the regional dialects of the company, so when engineering says, “It’s done,” they jump right in and translate: “Done pending function testing, production testing, and final documentation review,” so that product management doesn’t tell sales, “It’s done,” and they start selling something which actually isn’t done.

In this well-attended multi-lingual meeting, a decision is on the table and it’s a decision that’s happening in every single software company right this second. It’s not really a decision, it’s a negotiation, but it’s on the table and people are tense because this decision is under heavy scrutiny:

Product management: “What’s it going to take get this feature done?”

Program management: “What he’s asking is…”

Engineering: “Quiet, I know what he’s asking. The answer is, do you want to sacrifice TIME, QUALITY, or FEATURES?”

Program management: “What HE’s…”

Product management: “Yeah, I’ve heard this before and I still want it all.”

More talking. More translating. Action items are assigned, which gives everyone the illusion that progress was made. And we all return to our respective regional offices and wait until we have the same meeting again, where we attempt to communicate intelligently with each other. But all we really do is schedule meetings… when what we need to do is figure out who makes decisions.

That Damned Triangle

Time. Quality. Features. It’s usually described as a triangle, which somehow represents the state of your product or your feature. I believe the idea is that in a perfect and unattainable world, this triangle is perfect, equilateral, and seemingly at rest. There is balance among the time you have to release, the quality you are seeking to attain, and the features you want to ship.

In reality, this triangle is never at rest. It’s constantly shifting and, well, I don’t think it’s actually a triangle. It’s just a mental model that gives you just enough ammunition to lie. The conversation goes like this:

Product management: “We need this feature to be competitive.”

Engineering: “Ok. We need four extra weeks to do that feature since it’s new and you’re asking late.”

Product management: “The date can’t shift, we made commitments.”

Engineering: “So did we. Listen, something has to give. You’re adding more work or features, which means we need more time, or, if you want, less quality. Make a choice.”

These black and white arguments don’t hold water. The idea that there are three simple levers that define a feature or a product is passive-aggressive professional absurdity. There are myriad levers the team can adjust, but to understand them you need to understand the people who are actually building the software.

Bits, Features, and Truth

Let’s start with an exercise. I want you to think about the project that you’re working on, or, if your project is ginormous, I want you to think of the feature that you’re developing. Relative to this product or feature, I want you to walk up to your nearest whiteboard and draw three large circles:

Now, a name belongs inside each of these circles and it’s the name of a specific role on your team. The traditional titles for these roles are engineering manager, product manager, and program manager, but I don’t want you get to get hung up on titles. I want to you to think about the person who is best qualified to make a decision regarding the bits, the features, and the truth.

Bits: Who is the engineer who has the most influence on the bits? There are likely influencers, but who is the engineer that everyone goes to when they have a question. Your manager’s name is a good knee jerk name to put up here, but just because they have “manager” in their title doesn’t mean they know what’s going on as well as where to go. I want the name of the person who not only gets the call in the middle of the night where there is a bit-related emergency, but also the person who makes the large bit-related decisions. I want to know the name of the person who, when they say no, the debate stops. Got it? Ok, next.

Features: Who is the person who defines the content for the product or feature? This is the name of the person who is constantly asking for more without regard for cost. This is the person who can eloquently and calmly explain the need for this feature with an argument stronger than, “Wouldn’t it be cool if…?

Truth: This might be the hardest to define because it’s a role that could live anywhere in the building. While it took years to form this opinion, I believe the person who is responsible for the process is the one most likely to be the keeper of the truth.

There’s a constant ebb and flow of information in any group of people. Important decisions are made in the morning that can take hours or days to move to the other side of the building. Information is tucked away for nefarious purposes. Information is laundered, adapted, and misinterpreted.

The truth is the aggregate best set of information that exists in the building, and the person who consistently has it is the keeper of the truth. You know this person; it’s the person you go to when you’re wondering, “What the hell is going on here?” This is the person who knows the politics and the players, they know the real reason the product is late, and this is why this is usually the job of the program manager.

The complaint I hear most about program management is the same complaint I hear about managers: What do they do all day? What do they actually own? Practically, the most important part of the product they own is the schedule, but their larger contribution is information management.

Yeah, I know you start-up folk believe you’re doing just great without a semblance of program or process management. You believe that these types of folks are going to slow you down with their agendas and to-do lists. Here’s the deal: just because no one has the title in your garage doesn’t mean the role doesn’t exist. In any group larger than one, someone has taken the role of keeper of the truth and their key skill is information wrangler. They constantly gather the information from the group, synthesize it, translate it, and, sometimes forcibly, present this information to the folks who are busily lying to themselves.

Me: “We have six weeks to shipping, we’re good.”

Keeper: “Feature complete was two weeks ago and we’re still writing code.”

Me: “But the team is fired up, working weekends, and…”

Keeper: “Steve and Ryan are on vacation for two weeks starting tomorrow.”

Me: “Oh.”

A good program manager cares about the program and the product, but they also have a calm professional ambivalence. They have to — they’re always uncovering and then surviving the worst-case scenarios. These discoveries often give them the most complete picture of how the product is doing. Their ability to survive them has made them unflappable – they don’t freak out because they’ve lived through it and know there’s always a way out… somehow. All of this experience is why they usually end up owning the schedule. I’ll explain why when we get to analysis.

So, who is this calm, truth-oriented, well-informed person on your team? Who is the person who doesn’t lose it? Who is the person you go to to understand the intent of the other parts of the organization? They very well might not have the title of program manager, but they are there.

Circle of Comfort

Before I analyze your circles, I need you to do one more pass where you ask yourself two questions.

Great, you’ve got a name in each circle. Maybe the same name is in two circles. We’ll talk more about that in a moment. My first question is: for each name, what’s the person’s circle of comfort? It’s fine that you put Ryan in both Bits and Features, but where does his heart lie? What is his professional background? Which circle is he going to instinctively optimize for? For each circle, if you think the occupant’s natural circle is different, write that name underneath their circle.

My second question is: have you picked leaders? Look at the Bits circle. The name you put in there is the brightest engineer in the building, and any time anyone needs someone to explain the architecture, he’s the guy paraded across the building, but is he the leader? Does he make decisions about the direction of the product? He has incredibly strong and informed opinions about where it’s going, but when it comes down to the commit, is he the guy? No? Ok, who is?

Leaders have deep experience in their circle. It’s not chutzpah, it’s not spin; it’s the knowledge and analytical skills developed from doing the job. It’s because you can walk up to them, present a hard problem, and have an immediate, informed, and comforting answer. That’s the name that belongs in the circle.

Leaders make decisions. Sometimes it appears they’re doing it with little data. Some decisions are great, others are crap, but for the purpose of this circle exercise, you need to identify the three leaders relative to the Bits, the Features, and the Truth.

Circle Analysis

Ok, what’ve we got? Let’s walk through different circle scenarios:

– Something is empty. We don’t have program management, nor do we have any product managers. Again, don’t get hung up on titles. Just because your company hasn’t hired these folks doesn’t mean the work isn’t happening. Someone is picking features. Someone is designing the schedule. In fact, if you’re really small, there’s a chance the same name fills all three circles. Let’s talk about that.

– Same Name. All three circles. Edgar is the man. He’s our one-stop decision machine. It’s awesome. While I appreciate your velocity as well as your enthusiasm, I have concerns.

I believe an effective team eventually needs each of these roles clearly defined and owned by three separate people. Rands, where’s QA? What about design? HELLO SALES. These are essential parts of the business. WHERE ARE THOSE CIRCLES? This model is not about describing an effective business; it describes an effective team. Sales, design, QA, marketing, customer support — the list goes on. You need some version of these in order to have a business, and yes, they feed essential data into the product, but my assumption is that one of the reasons you wrote Mitchell’s name in the Feature circle is that he has a solid relationship with the design team; he knows that an essential part of his features is the design.

Three leaders. One who makes decisions regarding the bits, another who is responsible for the features, and another who cares about the truth. The theory is, these leaders are sitting in these circles because they have the ability to make good decisions relative to their expertise and the reality is these folks do not get along.

Program management believes engineering will never ship, product management believes the product would be nothing without them, and engineering thinks everyone else is useless because they don’t know how to code. It sounds pretty hostile, except when it comes to these three leaders. See, in addition to decision-making authority, these folks have healthy tension with their circle peers.

I divide healthy tension into two equal and opposite beliefs:

– First, there’s the reality-affirming belief that most everyone in the building shares. It’s the belief that my job is the most important job in the building and in my absence it’ll just fall apart. It’s a quiet belief that we tell no one, but it’s a silent strengthening belief that gives folks the confidence to make a decision. I’m an expert, I’m brilliant, and I’m right.

– Second, and specific to our circle denizens, there’s the grudging respect for the other circles and the trust of their expertise. This is a tenuous arrangement given the first belief, but part of leadership within the circle is the ability to step back from a massive decision and say, “He knows better than I”.

The idea is that the ability, skills, and experience that define each of these leaders are fundamentally different. An engineer who has seven years of coding experience has a vastly different perspective regarding features and products than a product manager who has transformed an MBA into a product management gig. You can fake it — an engineering leader can have a passionate opinion about a feature or a product — but there is a skill to defining, explaining, and justifying a feature that years of development won’t give you.

If you’re staring at your three circles and the name is the same in all three, I have two questions:

Are they all that? Can they consistently make correct bit-related decisions along with feature decisions while realistically balancing the truth? Really? If it’s the two of you in that garage, I get it, but if it’s 100 of you and one person is responsible for all three circles, I bet they are optimizing for their circle of comfort and that means two other circles aren’t being represented.

Who do they argue with? Without the healthy tension between Features and Bits, there’s no debating feature roadmaps and technical realities. A diversity of opinion takes any idea and hopefully shapes it into something unpredictably better. We can see good examples of this by looking at two other circle configurations.

– Bits and Features are the same. So Ryan, an engineer by training, is making both engineering and feature decisions. Great. That gets rid a lot of those pesky feature prioritization meetings, right? What other meetings aren’t happening? Where else is the feature set of your product not being debated because Ryan is making unilateral decisions as owner of the bits and the features?

Again, I’m being an alarmist and I’m exaggerating, but I believe you cannot effectively (and don’t want to) remove yourself from what you do to make a well-informed decision outside of your circle. Think of it like this: is Ryan the customer or does he have direct access to the customer? If the features are for engineers, there’s a solid argument that he could make decisions for both the bits and the features, but if the product or features aren’t targeted for engineers, why do we believe Ryan can make informed decisions about them?

I’m not saying that anyone outside of the feature circle can’t have an opinion about the product. You want a culture that encourages everyone to care deeply about the product you build, but if you’re developing software for regular human beings then you need a regular human being to speak to their needs.

Let’s look another variant.

– Truth is the Same as Features. Tony the business guy owns both the features and the schedule. This is a pretty common configuration because the belief is that those who make feature decisions for the user should also make scheduling decisions. We need feature X in May. What’s the hitch?

Well, you’ve got the truth bundled with the features and I’m uncomfortable with that because the truth needs to be neutral. The truth needs to be unbiased, and with Tony’s name in both circles, you’ve got the guy who is calling the shots for the features almost making the schedule decisions. He might have solid healthy tension with your Bits circle, but how is Bits going to argue with the guy who owns the levers for both content and time?

The healthy tension created by having three distinct leaders creates diverse debate about your product. Yes, this is the same debate I talked about at the beginning of this article, but the difference is when you have three leaders equally representing a well-defined viewpoint along with a sense of ownership, it’s a balanced debate where the needs of the technology are weighed against the desires of the customer and the realities of the schedule. When one leader is representing two circles, their two votes are pushing decisions in their favor.

Let the Negotiation Begin, It’s About the Debate

This is just another model. I’ve replaced the Time/Quality/Features triangle with circles. There are just as many ways to screw up and misrepresent this model with politics, inexperienced people, and poorly defined features. The difference here is I believe this model not only realistically describes the forces that pull your product in different directions, it also gives those forces a proper name.

Let’s go back to the endless debate where the Bits, Features, and Truth are equally represented:

Features: “I want feature X and I want it on the same schedule.”

Truth: “We need more time and since I know all the moving parts, I know that we’re ahead of schedule of one feature. I think we’ve got two weeks of wiggle room.”

Bits: “Two weeks isn’t enough. Can we cut this one feature that we haven’t started and no one cares about in half?”

Features: “I can live with that.”

Truth: “Sold.”

Software is built by people. The best Gantt chart only tells you half the truth about the schedule; the most complete marketing requirements document can never describe why a feature is compelling; and the most detailed technical specification will never tell you what makes for beautiful code. These are only tools and they tell little about the people who are building the software.

These people have names and they’ve earned them by not only making consistent great decisions for their area of experience, but also knowing when to ask someone else for advice.