In the startup world, there’s frequently conflict between developers and other project stakeholders. If I were to make a list of reasons I’ve been relatively successful, I’d put my ability to say no to stakeholders near the top. In fact, I’m usually thanked for it. When I say no, it’s not to be rude, cynical, or confrontational. It’s not to avoid hard or complex work, or to push my own agenda. I say no when the long-term effects of saying yes put the product and/or company at risk.

Well, great, Garrett. That’s pretty obvious. Why do I care?

Many developers haven’t figured out how to say no. Let’s get one thing out of the way: “saying no” does not look like a blanket refusal. Usually, it’s leading the stakeholder to their own decision by revealing how their request conflicts with business priorities. If I can’t ask questions that identify a conflicting business priority, it’s time for me to rethink my position, my ability to communicate, or both.

So how do we know when it’s time to “say no”? We don’t. “Growth hacker” gurus will advocate putting out feelers with long-form A/B-tested landing pages, collecting huge amounts of survey data, and generally determining that the universe favors your decision. I’m in a startup, man…ain’t nobody got time for that.

Don’t get me wrong: when possible, inform your decisions by analyzing data and running A/B tests. In my experience, however, nine out of ten times you won’t have the leeway. It’s difficult convincing stakeholders to delay every decision while you spend precious resources building your case. In most stakeholders’ minds, they are the customer – no research needed.

Let’s talk about some common characteristics of the typical startup stakeholder for a minute. They

  • are big picture people,
  • think of themselves as the customer,
  • don’t care about technical details,
  • have priorities that frequently shift with their current source of pain,
  • have difficulty saying no to customers (most people do, it’s hard),
  • don’t understand the complexity of programming tasks,
  • are often excitable, sometimes unfocused – important points must be repeated frequently because the stakeholder was thinking about some other feature,
  • often don’t understand implications of the decisions they’re agreeing to (as developers we necessarily have a much closer view of the product and its intricacies, which allows us to foresee downstream effects).

When a person with these characteristics makes an ill-advised request, the typical developer’s response ranges from acquiescence (with internal resentment) to extreme frustration. Not that frustration isn’t warranted at times; it certainly can be. Unfortunately, neither reaction resolves the personality and knowledge mismatch. To start working productively with stakeholders, you have to start with empathy.

The convincing arguments for a stakeholder are those justified by business concerns:

  • “This feature/decision only applies to 5 percent of our paying/target customers and would introduce extra complexity for the rest, thus potentially reducing overall satisfaction and revenue.”
  • “We can do this, and it might be a good idea, but it will delay our ability to do X important thing.”
  • “If we do this, it will have X cascading effects, which will impact revenue.”
  • “If we change priorities right now, it will stall X in-progress revenue-generating feature by at least three weeks.”

Notice any trends?

There’s no mention of concerns like development complexity. Is it a factor? Of course it is. Do they care? No. To the stakeholder, “development complexity” could mean:

  • “Our developers are shit.”
  • “Our codebase is shit.”
  • “I’m lazy.”
  • “Oh, this might actually be hard to do.”

Now the first three might be true, in which case other conversations are needed. Still, the important aspect of development complexity to a stakeholder is its side effect on revenue.

Occasionally, stakeholders will be incredulous at your time estimates for a given task, at which point you can cite complexity. It’s important to be aware that challenges to developer estimates indicate a lack of trust within the organization. When a lack of trust exists, it’s sometimes helpful to increase the confidence you display in your communication. As developers, we often hedge because we’re aware how quickly simple tasks can turn into day-long source diving. Be clear you can perform the task, and also be clear when risk takes the form of uncertainty; sometimes we don’t know how long a task will take but we know it contains unknown unknowns.

As developers, myself included, we are a self-righteous bunch. We’re smarter than everybody else, we work harder than everybody else, we produce more real value than everybody else. At least that’s the internal narrative. Coming into conversations with this perspective isn’t a great foundation for productive relationships. I have definitely been wrong my fair share, and I’m betting if you strain yourself you can think of one or two occasions when you were mistaken as well.

If you want to have great working relationships with the business side of house, start explaining things exclusively in their vocabulary. Don’t talk about development complexity, architecture changes, refactoring, or adding tests. Talk about new revenue, lost revenue, opportunity cost, and target markets. Don’t assume you know best, either: gather supporting data and ask questions to see if there are factors you haven’t considered. You might even collaborate to gather data so the process is less antagonistic. Break bad interpersonal cycles by giving respect even when it isn’t being returned. If nothing changes after considerable effort on your part, consider directly (and respectfully) addressing your concerns about the relationship. Sometimes healing starts with a little discomfort.