Devs don't care about business!!

Talking to an entrepreneur friend of mine last night and he was complaining about the fact that given a choice, devs will choose to work on the more technically challenging thing than on the thing that makes the most business impact.

Here’s what I told him.

one simple reason

There is one simple reason why devs do not seem to care about the business - their reward mechanisms are wired differently.

And when one goes up against a hard-wired reward mechanism, no amount of wishing for things is going to make that reward mechanism suddenly change its behaviour. In the developers mind, nothing comes close to the dopamine hits from writing code. Now compare this to their experience of the ‘business side’. All they get is negative vibes ie the constant wringing of hands and complaining that ‘devs don’t care about business’.

Heard about the Pygmalion Effect? People will consistently strive to meet your expectations from them, low or high. So when you wring your hands and complain that devs are not good at business, that’s precisely what you get.

Add to this the fact that no one has really taught devs how to ‘do business stuff’. So you get a situation where devs are struggling and in return for their struggles all they get are bad vibes.

Add to this the fact that these ‘business types’ in their sharp suits and trendy haircuts are a pretty alien species to the developer, and if they are familiar with this species it is generally in terms of the fact that it was precisely kids like these that made their childhood a living hell and had them retreat into their nerd shell.

Not a great recipe for a good dopamine high.

In fact, the average dev in the average company is trapped in a negative feedback loop. Result? Devs retreat further and further into their shell.

To get the devs interested in business, we have to reverse this feedback loop so that it feeds them dopamine instead of cortisol and for that we have to change the environment.

rewiring the circuitry

It is possible to build a team that is extremely aligned with business outcomes, but in order to do that, we have to understand how the brain works. This post does not allow us to go into details but here’s excellent videos for you to watch.

(shameless self plug)

I talked about this and other issues at RubyConf India in 2018 or so.

But in essence what we need to do is understand why devs don’t care about the business, or in other words, why are their reward mechanism the way they are. The answer is actually pretty simple.

devs are not bad at business. they just haven’t practiced.

If you’re an entrepreneur, that ‘business’ vibe you have has been with you for a long, long time. At some point you immersed yourself in business literature, studied business models, understood how money works, developed a relationship with these concepts that went well beyond intellectual understanding. You have forgotten how hard you had to work on these skills. You live and breathe business just like your devs live and breathe code.

Expecting devs to just ‘get better at business’ is like expecting business folks to just get better at coding.

No. It will not happen fast and it will not happen for free. But it can be made to happen through a process of, for lack of a better word, hypnosis.

mesmerizing metrics

One way to do this would be to start would be to start on familiar ground. Metrics.

All engineers understand metrics. We’re just going to get them familiar with metrics besides API latency times and memory/CPU usage. We’re going to feed them Product Metrics. Product metrics look just like engineering metrics — see the same charts and graphs and what not! No big deal. Easy!

Read on to see the magic of mesmerizing metrics 👇

low grade, constant metric exposure….

Keep these product metrics easily accessible by the team. In fact, place these metrics in their environment such that they cannot help but look at them several times a day.

There is a whole series of posts possible on dashboarding for product orgs, but for the purposes of this essay, suffice to say that if you do not have excellent and easily accessible dashboards for product metrics including A/B tests, that’s the problem you need to fix first.

One of the big losses of the move to remote work is that we no longer have TVs in the office showing the product metrics. This ‘information radiation’ was a very reliable way to steep the developer teams in the product metrics. You can try and recreate it by piping dashboards into Slack 4 - 6 times a day.

When they spend so much time around these metrics they start to get a feel for the product metrics — their seasonality and rhythms, their reaction to major world events or advertising pushes, and so on.

It is this constant exposure to metrics that causes the hypnosis. Constant, low-grade, subconscious exposure to metrics.

…in a supporting environment…

Here it is critically important that the business and product people gently guide the devs as to which metrics are important, which ones have changed with which release, why they changed in this particular way, what the goals are and so on. Devs are going to feel like noobs when it comes to this stuff and reducing the anxiety they feel by supporting them in their learning goes a long way to accelerating the process. If the devs feel trusted and supported they will do all they can to live up to that trust.

…connected emotionally…

With enough exposure to metrics, patterns start to emerge. The subconscious cannot help it. It notices things and wants to tell a story around them. Now that these patterns start to emerge, we can start to put some ‘feels’ into the metrics. For a product like shaadi.com it was messaging like ‘so many thousand skipped heartbeats today’, or at rBus we would calculate the number of ‘trips to the moon’ that our kilometerage on the buses represented — which is a way to anchor the boring metric of ‘connect requests sent’ or ‘kilometers travelled’ in a more evocative story, a more emotional story in order to connect the devs with the actual outcomes of their work.

…yields dopamine

Pretty soon, the devs start to see the effects of their work on these dashboards. “Whoa! I did that? This is cool!!” they exclaim. This is their first hit of dopamine from a business metric. This is where you need to get to!

Pretty much my entire philosophy of management can be summarised as ‘get people to the a-ha moment and then get out of the fucking way’

Now they want more, so every release is sent out with its own dashboards and the devs check it incessantly. It’s almost as if they now don’t think of their job as writing code, they see their job as improving those metrics, and code is just how they do it. The dopamine hit has gone from the ‘check in the code’ to ‘see metrics move’! Imagine that. The same devs who used to ship broken builds to QA and think their work was done are now huddling together with the QA and urgently pushing fixes because they just can’t wait to see the result of their work on a dashboard somewhere.

Once devs got hold of the dashboards, amazing things started to happen — the Mean Time to Repair a Bug crashed.

Earlier, the PM would pull metrics from a data warehouse twice a week and then share the results with the devs, by which time the devs would have moved on to the next ticket.

Now devs ship, come back the next morning, check the metrics and immediately spot any anomalies and the bugs they might point to.

Add to this some attention from the business side — the CEO praising the team, for example — and you start to already rewire the reward mechanism of the team!

Celebrations will start to break out all the time as one or the other metric milestone was passed, further anchoring the dopamine hits from the actual business outcomes.

All of this I have seen happen over and over again just by changing the environment, providing the correct encouragement (and discouragement) and being alert to the pain/pleasure ratio.

be careful what you wish for.

Now that the dev team is really cooking, gone are the days when you could just hand them a PRD and expect them to comply silently.

Now that they understand this shit, they’ll dig into it in some detail because they don’t want to waste time on stuff that might not work. But you get something magical in return, if you allow it. When they understand the ‘why’ behind the PRD they will propose cheap and fast ways of testing assumptions. They will start aligning guild work with the intention of making that next product change easier. Their entire reason for doing anything will be business metrics. And stabilising this intent is a lifelong love for coding. The perfect balance.

A team of devs that feels the business metrics in their bones is a very worthwhile investment indeed.

Now toss in a hackathon — get the devs to team up with whoever they like and bring their creative ideas to the fore. You will be surprised at the result! Suddenly you will realise that the devs have been creative people with a product sense and an incredible ability to ship fast! Why had you never seen this before? Because you wanted it for free. You wanted it to ‘just happen’.

nothing ‘just happens’.

Nothing ‘just happens’. It has to be made to happen. It requires time and investment. Then anything can happen. Including getting a dev team that gets dopamine hits from business impact.

Crossing the Chasm

In the previous post we saw how the business side came to understand the compulsions of the developers and crossed the first chasm.

And in this post we saw how devs can cross the second chasm over to the business side.

Do this enough and you’ll have a team where the various functions take each others’ problems as their own and work together to do what’s best for the user. Such a team is a solid competitive advantage and very much worth investing in.