Everything Is Negotiable

There is a fundamental mismatch between how real business problems look and how we are taught to solve them. It leads to wrong expectations and suboptimal results. What to do about it?

I recently had an interesting reminder that what is obvious to me is not obvious to others. We were working with the team to define key results for the next quarter. Each time we’d settle on a metric, we would then briefly enumerate the tactics to move it. The initial discussions would be productive, but inevitably difficult edge cases would come up, and the emphasis of the discussion would shift. What would seem a simple approach, would become complicated edge-case handling. If we don’t resolve them properly - we won't move the metric enough. The discussion was going in circles.

“What if you don’t have to get it perfectly right the first time?” I remember saying, and adding: “You don’t have to solve the whole thing in one go, as long as the metric moves just a little bit, you’re showing progress and you can improve later.” Immediately, the team settled on a metric and a few tactics. Later, I received feedback that my question was pivotal to stop the dead end discussion. We made good progress on KRs too.

It was not the first time I have seen this fixation to solve all-or-nothing. I’ve done it myself and I’ve seen it in others. After reflecting on why it could be so, I came to a conclusion.

It Is A Learned Behaviour

When solving exercises at school, especially STEM subject problems, I would get a clear problem statement and apply a formula the teacher gave, to get a result. If I got stuck, the teacher would help me. All school problems were solvable by definition and results were binary. I either solved it or not, no middle ground. The final mark on an exam paper depended more on the number of problems I solved, not on how good the solution to a single problem was. 

In university things did not progress either. The complexity and the breadth of the exercises increased by a few notches, but the premise remained largely unchanged. My performance was judged by how well I knew which algorithms and formulas to apply when, and how many problems I solved for homework or exams.

During job search, when it came to the technical interviews, I got to do the same thing too. The industry standard is to get software engineers to solve algorithmic exercises (“leetcoding”). The emphasis is on identifying the correct algorithm, and edge cases. There are usually 2 or 3 passable solutions, depending on the algorithm complexity. Again, I was judged by my ability to notice patterns and apply templated solutions on problems that are by definition solvable.

By the time I was comfortably on a software engineer career path, I was primed to expect the same: solvable problems defined with surgical precision, by leads, managers, or senior leadership. Overcome one, get a reward - salary, stock, promotion. Rinse and repeat. I approached the goals at work the same way I was trained all along.

Real Problems Are Not Clear And Not Always Solvable

Issues at work are rarely clearly defined. The reality is that organisations and their collective output are as imperfect as their individual parts - humans. This usually goes unsaid and comes back as a shock. I used to get frustrated when my manager did not know what they were doing, when the project direction changed before we finished it, when it seemed like there was no clear process to achieve something.

I have largely unlearned this behaviour. Having been through a few startups and medium sized companies has helped me notice it and raise that important question to the team during our key result discussion. Here are some propositions I hold true, that I think help me operate successfully.

Businesses Do Not Care About The Implementation Details

The fact that a product is built using a specific set of tools and programming language(s) is circumstantial at best. It rarely is a business decision, and more often a result of convenience and familiarity of the early team. In other words, a concrete solution to a problem is in principle irrelevant, because some other solution might just as well do the job. It can be quite daunting to accept this fact, but it is a fact.

An example (I confess I often forget this one) is outsourcing. If you don’t have time to do something - is there a service that can be paid to do it for you? Sure, you don’t get to solve a problem, and have no clue what’s happening behind the scenes of that service (might be poor development practices), but the business doesn’t care. If it provides the right outcome - the business will pay. The corollary is that while implementation doesn’t matter - there is something that does.

Businesses Care About The Outcomes And Cost

The outcome can be revenue, user growth, speed, performance, etc. - whatever a business strategy deemed important at a specific time. Cost, similarly, can be time, latency, risk, drag, etc. or an influence on an outcome. This is why it can be difficult to convince a manager to address a specific tech debt, refactor some legacy code, or improve infrastructure. Presented on its own (“we need to rewrite this piece of code”) - it does not have a clear outcome. What matters is what outcomes the solution brings at what cost.

When someone asks us to build a feature or we want to do something ourselves, what we are talking about is a concrete solution to a problem they or we hope will give a certain outcome. If we can identify and express that outcome, we can be more creative with the solution. Instead of an all-or-nothing, we can slice and dice it as we see fit. Or throw it out, and offer something better.

No One Knows What They Are Doing (but not in a negative sense)

Most decisions are experience or intuition based projections, rather than guaranteed paths to outcomes. Might as well call it a well informed guess. Although, at the execution level - if we have to add a feature X - it is pretty clear the result is a success or not. It is easy to assume that this clarity propagates to the management or senior management. The higher in org. chart someone goes - the success becomes much more murky and probabilistic. Unless we accept this fact - we might as well be doomed to always complain about incompetent management. 

I loved this quote from Barack Obama’s book “A Promised Land.” It shows this reality goes all the way up to the president:

What I was quickly discovering about the presidency was that no problem that landed on my desk, foreign or domestic, had a clean, 100 percent solution. If it had, someone else down the chain of command would have solved it already. Instead, I was constantly dealing with probabilities: a 70 percent chance, say, that a decision to do nothing would end in disaster; a 55 percent chance that this approach versus that one might solve the problem (with a 0 percent chance that it would work out exactly as intended); a 30 percent chance that whatever we chose wouldn’t work at all, along with a 15 percent chance that it would make the problem worse.

Putting It All Together

What I learned at school, university, and interviews was to expect clear problem definitions and knowledgeable authority. The three points above show a completely opposite reality at work. Concrete solutions do not matter, outcomes do, and expected outcomes are guesses. And guesses can be discussed. Therefore, almost all outcomes are negotiable. 

This does not mean that a discussion should descend into chaos where every solution is equally valid. Not at all. It means that when we are asked to deliver on key results it is about moving the outcome needle. This empowers us to move it in small incremental steps, not grand all-at-once schemes. That is what the discussion should be about.