<script data-pm-proxy="intercept"></script><?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Leap of Scale]]></title><description><![CDATA[Between the struggle and success in building scale, there is a space.  I write about the opportunities to take, in that space, to turn yourself, your teams and your company towards scalable growth.  ]]></description><link>https://adia.substack.com</link><image><url>https://substackcdn.com/image/fetch/$s_!41rU!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fadia.substack.com%2Fimg%2Fsubstack.png</url><title>Leap of Scale</title><link>https://adia.substack.com</link></image><generator>Substack</generator><lastBuildDate>Tue, 01 Sep 2026 07:23:44 GMT</lastBuildDate><atom:link href="/__u/adia.substack.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Adia Sowho]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[adia@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[adia@substack.com]]></itunes:email><itunes:name><![CDATA[Adia Sowho]]></itunes:name></itunes:owner><itunes:author><![CDATA[Adia Sowho]]></itunes:author><googleplay:owner><![CDATA[adia@substack.com]]></googleplay:owner><googleplay:email><![CDATA[adia@substack.com]]></googleplay:email><googleplay:author><![CDATA[Adia Sowho]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[The Business of Seasons]]></title><description><![CDATA[At MTN, revenue softened every rainy season.]]></description><link>https://adia.substack.com/p/the-business-of-seasons</link><guid isPermaLink="false">https://adia.substack.com/p/the-business-of-seasons</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 19 Aug 2026 19:04:49 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/666fe374-0a28-4fae-8a11-1a1904a302cb_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>At MTN, revenue softened every rainy season. Airtime was bought and sold hand to hand then, off kiosks and folding tables where a downpour will prevent a transaction. And in Northern farming communities the rains are the working season. So, a hand on a hoe is not a hand on a phone.</p><p>The dip arrived on schedule, every year. We received it, every year, like it was breaking news.</p><p>Anything needing a person to complete the value chain, carries this constraint on its books without naming or pricing it: identity checks, meter reads, agent banking, field sales, last-mile delivery.</p><p>This is the collective misread. When throughput falls, the search for a cause turns inward. Sales execution. Pricing. Logistics. A competitor making moves. The diagnostic energy is so focused on internal mechanics that mere mention of external cause invites disbelief.</p><p>Where infrastructure is rich, none of this reaches revenue. Covered retail, drained roads, warehousing, fulfillment that moves goods regardless of what the sky offers. The weather gets absorbed on the way in, and rain stays a scheduling nuisance. Strip that infrastructure layer away however, and the season decides what moves, when, and whether anyone can reach a door. Without that infrastructure layer, the weather enters the value chain instead of acting on it.</p><p>Does rain impact demand? In truth, it doesn&#8217;t. But it impacts people. And people carry the demand.</p><p>Every business is only as free as the least free step in its value chain. If someone must stand outside, climb a mast, move goods across a city, or carry cash between branches, then the seasons are part of the business model.</p><p>We account for those constraints eventually. We build more inventory or add more lead time or hire more people. We do the thing we can control. What we almost never question is the calendar we use to judge the results.</p><p>That calendar was inherited too. Where the quarter was invented, the boxes and the seasons agree. Four seasons, four quarters. Winter sits in Q1. Christmas sits in Q4. A soft quarter arrives already explained, and nobody calls a slow January a failure.</p><p>Two seasons do not divide into four boxes. In Nigeria the rains begin around May, run across Q2 and Q3, reach into Q4, then stop. The season belongs to no single quarter.</p><p>So the softness has no name, and in the absence of a name, it means there is a &#8216;problem&#8217; someone has to investigate needlessly.</p><p></p><div><hr></div><p><em>Have you been asked to explain rain?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><div class="captioned-button-wrap" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-business-of-seasons?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="CaptionedButtonToDOM"><div class="preamble"><p class="cta-caption">Thanks for reading Leap of Scale! This post is public so feel free to share it.</p></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-business-of-seasons?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/the-business-of-seasons?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p></div><p></p>]]></content:encoded></item><item><title><![CDATA[The Dead Still Decide]]></title><description><![CDATA[Path dependency, and the routes that outlived their reasons]]></description><link>https://adia.substack.com/p/the-dead-still-decide</link><guid isPermaLink="false">https://adia.substack.com/p/the-dead-still-decide</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 29 Jul 2026 09:05:04 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/e313853b-5f56-4d4e-84dd-ce44d0b637ec_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The first road through a forest determines which towns grow. Not the best road. <em>The first one.</em></p><p>Economists call this path dependency, and the clearest illustration is under your thumbs. QWERTY was laid out in the 1870s around the constraints of a machine that no longer exists. The machine is gone. The company that made it is gone. The layout is on the phone in your hand, and every device manufactured this year will ship with it. The switching cost of departure is simply higher than the inefficiency of staying.</p><p>Early choices calcify. The path persists not because it&#8217;s optimal but because leaving it is expensive.</p><p>It is a useful, measured term. Polite, even. What it describes is less so.</p><p>The dead are still making decisions.</p><p>The choices of people who are no longer here, made for purposes that no longer exist, still set the options available to people who had no say in them. Colonisers. Imperial extraction. You. </p><p>We must remember that in economies built for extraction, the road and rail networks were laid to move commodities toward ports, not to connect the towns along the way to each other. The administrations that ordered them are gone. The routes still decide where value flows, which markets are reachable, which are not. The banking system built around formal employment is still deciding who counts as bankable, in an economy where most work has never been formal. Nobody re-ratified any of this. Nobody had to.</p><p>Path dependency doesn&#8217;t require anyone to intend the outcome. It doesn&#8217;t require maintenance, or conspiracy, or even attention. It only requires that the initial choice be embedded deeply enough that working around it costs more than working within it.  And yes, the dead decide everywhere. Precedent, constitutions, standards &#8212; most inheritance is a previous generation solving a problem for the next one. The mechanism doesn&#8217;t need intent to work. That doesn&#8217;t mean there wasn&#8217;t any. What makes this different is not that decisions persisted. It is what they were for.</p><p>Every generator bought makes the grid slightly less urgent. Every shortcut around the broken intersection is a reason not to rebuild it. The adaptations are rational, often brilliant. They are also load-bearing. What looks like resilience is, from a distance, maintenance.</p><p>Every workaround strengthens the original design.</p><p>This is why &#8220;why don&#8217;t they just build something different&#8221; is the wrong question. The answer is not a lack of imagination or ambition. It is that the existing path exerts a gravitational pull &#8212; economic, logistical, political &#8212; that makes departure enormously expensive. Not impossible. Rare, and never cheap.</p><p>Somewhere in your business, your city, or your country is a decision that no longer makes sense. It survives because everyone built around it.</p><p>Nobody is choosing the road anymore. The road is choosing us.</p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><div class="captioned-button-wrap" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-dead-still-decide?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="CaptionedButtonToDOM"><div class="preamble"><p class="cta-caption">Thanks for reading Leap of Scale! This post is public so feel free to share it.</p></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-dead-still-decide?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/the-dead-still-decide?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p></div><p></p>]]></content:encoded></item><item><title><![CDATA[Precision is Empathy]]></title><description><![CDATA[&#8220;Empathy&#8221; is usually treated as something you say, but sometimes its something you build. It usually means: understand your customer&#8217;s feelings.]]></description><link>https://adia.substack.com/p/precision-is-empathy</link><guid isPermaLink="false">https://adia.substack.com/p/precision-is-empathy</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 15 Jul 2026 06:36:12 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/b0f27414-b6f4-494d-95ee-6b6a2b8ddadd_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>&#8220;Empathy&#8221; is usually treated as something you say, but sometimes its something you <em>build.</em> It usually means: understand your customer&#8217;s feelings. Listen to them. Build for their emotional experience. This is fine as far as it goes. But there is a version of empathy that goes further: one that doesn&#8217;t live in the messaging, the tone, or the customer service training, but in the product itself. In the decision about how the meter runs.</p><p>When Nigeria&#8217;s mobile market shifted to per-second billing, something changed for the people using it, not because the product became friendlier in any visible way, but because the billing stopped taking more than it should. A thirty-second call costs what a thirty-second call should cost. Not what a sixty-second call cost. Not a rounded-up, averaged-out approximation. The exact amount. The customer who had been quietly losing seconds &#8212; and the money attached to those seconds &#8212; suddenly wasn&#8217;t.</p><p>That precision is a form of respect. It says: your money matters enough to count properly. It says: we are not assuming you won&#8217;t notice. It says: the product is designed for your reality, not charging you as much as it can get away with.</p><p>In low-trust markets, customers notice when the meter is fair. And the feeling of not being quietly overcharged accumulates into something: a preference, a loyalty, a word-of-mouth recommendation to someone else who is also tired of being rounded up.</p><p>Every product eventually makes this decision: estimate, round, or count exactly. A payment provider deciding how to apply a foreign exchange spread is making it. So is a ride-hailing app calculating waiting time, a utility metering electricity, an API billing usage. The decision rarely gets called a values statement. It gets called pricing. But it is always a decision about whose money absorbs the rounding.</p><p>Fairness is not a value statement. In prepaid markets, it is a growth mechanism. The operator that bills accurately earns something the one that doesn&#8217;t cannot buy: the sense that the system is working for the customer, not against them.</p><div><hr></div><p><em>Where in your product or pricing does precision &#8212; or the lack of it &#8212; tell your customer whose side you&#8217;re on?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p>]]></content:encoded></item><item><title><![CDATA[Independence Changed Who Sat at the Checkpoint]]></title><description><![CDATA[There&#8217;s a version of history that goes like this: colonialism ended, and then the work of nation building began.]]></description><link>https://adia.substack.com/p/independence-changed-who-sat-at-the</link><guid isPermaLink="false">https://adia.substack.com/p/independence-changed-who-sat-at-the</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 08 Jul 2026 06:13:02 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/27e30702-6d21-4a0e-bb33-b5caa6607ffb_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>There&#8217;s a version of history that goes like this: colonialism ended, and then the work of nation building began. </p><p>We tend to remember who left. We pay less attention to what they left behind.</p><p>When political power transferred, the institutions through which power moved often transferred with it &#8212; intact, operational, and optimized for the purposes they had always served. The checkpoint that required papers to move goods across a region did not disappear because the flag above it changed. The licensing system that created dependency on official approval did not dismantle itself because the officials were now local. The bureaucratic structure that generated revenue through control did not lose its appetite for control when a new administration arrived.</p><p>What changed, in many cases, was personnel. What remained, however, was the logic.</p><p>Systems do not transform automatically when leadership changes. They transform when their underlying incentives change, when their design is deliberately altered, when the people who benefit from their current form lose the power to preserve it. Those conditions require more than a transfer of formal authority. They require a reckoning with what the authority is actually built on.</p><p>The colonial checkpoint was not just a physical location. It was an arrangement &#8212; who had to stop, who didn&#8217;t, what it cost to pass, who collected that cost. Replacing the people at the checkpoint without redesigning the arrangement preserved the arrangement. In some places, it still runs today. Renamed. Reformatted. Recognizable.</p><div><hr></div><p><em>What has been renamed, but not redesigned, in your operating environment?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[The Fastest Way to Build Trust]]></title><description><![CDATA[It&#8217;s taken as given that trust must be built slowly, transaction by transaction, over years.]]></description><link>https://adia.substack.com/p/arrive-not-as-a-stranger</link><guid isPermaLink="false">https://adia.substack.com/p/arrive-not-as-a-stranger</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 01 Jul 2026 06:37:09 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/e6a081bb-c2b6-489c-9f11-354414e5fb80_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>It&#8217;s taken as given that trust must be built slowly, transaction by transaction, over years. What&#8217;s less obvious is that trust, once built, can move to someone else almost instantly.</p><p>The years required to become a recognized participant in a market &#8212; to be known, to be vouched for, to have a track record other people can point to &#8212; aren&#8217;t always required of the person who enters through the right door. If someone already trusted introduces you, validates you, stands behind you, a significant portion of their accumulated trust transfers to you immediately. You arrive not as a stranger but as an extension of something the market already knows.</p><p>This is how agent networks actually function in markets, like ours, where direct brand trust is hard to build. The brand doesn&#8217;t earn trust in the community, the agent does. The agent&#8217;s accumulated legitimacy transfers to the brand&#8217;s products in the moment of sale: without the agent, the brand is unknown; with the agent, it arrives pre-validated.</p><p>It explains why referrals work differently in low-trust environments. A referral isn&#8217;t a lead, and it isn&#8217;t a reward sitting at the end of a good experience. It&#8217;s often the input that starts the relationship: someone else&#8217;s purchase pulls the next customer in before the brand has done anything to earn them directly. The recipient doesn&#8217;t start from zero. They start from wherever the referrer stands.</p><p>And it explains the secondary market for established YouTube channels, for existing business relationships, for market intermediaries hired specifically because their legitimacy is the asset. Building trust from scratch takes years but acquiring it from someone who already has it can take a single conversation.<br><br>Arrive not, as a stranger. </p><div><hr></div><p><em>Where in your market are you trying to build trust from scratch and is there a path to acquiring trust that someone else has already accumulated?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p>]]></content:encoded></item><item><title><![CDATA[Scarcity Always Finds the Way Through]]></title><description><![CDATA[To earn revenue directly from YouTube, a channel needs four thousand watch hours and one thousand subscribers inside twelve months.]]></description><link>https://adia.substack.com/p/scarcity-always-finds-the-way-through</link><guid isPermaLink="false">https://adia.substack.com/p/scarcity-always-finds-the-way-through</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 24 Jun 2026 06:22:54 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/8a29633c-541b-4aeb-93e4-562e930e6ae4_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>To earn revenue directly from YouTube, a channel needs four thousand watch hours and one thousand subscribers inside twelve months. The rule exists to keep the monetization system from being gamed by low-effort content. It also produces, as a side effect, two populations: channels close to eligible but not there yet, and people who&#8217;d rather buy a channel than build one. The constraint generated both the supply and the demand for a market the platform never intended.</p><p>The same pattern runs through visa systems that are slow to process and immigration consultants who charge to navigate them. Through planning permission systems that take years and property developers who have learned to read them. Through port clearance processes that accumulate delays and expeditors who sell access to faster paths through.</p><p>In each case, the constraint was legitimate to whoever built it &#8212; the platform, the ministry, the regulator. What&#8217;s legitimate for them is an artificial problem for everyone underneath the decision, and that gap is what the market forms to close: between those who could wait and those who couldn&#8217;t, between those who understood the system and those who didn&#8217;t, between those who&#8217;d accumulated the right credentials and those who needed them now. Constraint and market, produced by the same mechanism: one makes something scarce, the other sells the way through.</p><div><hr></div><p><em>What in your market is everyone quietly routing around &#8212; and who&#8217;s getting paid to make the routing easier?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><div class="captioned-button-wrap" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/scarcity-always-finds-the-way-through?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="CaptionedButtonToDOM"><div class="preamble"><p class="cta-caption">Thanks for reading Leap of Scale! This post is public so feel free to share it.</p></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/scarcity-always-finds-the-way-through?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/scarcity-always-finds-the-way-through?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p></div><p></p>]]></content:encoded></item><item><title><![CDATA[When the Workaround Becomes the Process]]></title><description><![CDATA[Spend enough time inside a broken system and the breaks stop feeling like breaks.]]></description><link>https://adia.substack.com/p/when-the-workaround-becomes-the-process</link><guid isPermaLink="false">https://adia.substack.com/p/when-the-workaround-becomes-the-process</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 17 Jun 2026 06:22:05 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/88930b17-9940-47ce-aee5-a3280b17a791_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Spend enough time inside a broken system and the breaks stop feeling like breaks.</p><p>The generator that runs four hours a day becomes the power situation. The bank that needs six forms of documentation becomes just how banking works. The two-hour detour becomes the route. The workaround becomes the process.</p><p>Normalization isn&#8217;t a decision anyone makes. Nobody sits down and defends the broken design. It just requires time, repetition, and the absence of will to do the harder thing, because fixing it properly is, conveniently, always someone else&#8217;s job. Each time the workaround gets used instead, the path gets a little more worn. Eventually it isn&#8217;t a path around the problem. It&#8217;s the only road there is.</p><p>People adapt. The adaptation becomes invisible. The original design, the thing that made the adaptation necessary, disappears from view. We forget that it was ever supposed to be different, and we lose the aspiration along with the memory.</p><p>Power is the clearest version of this. The generator gets bought. The fixing stops. We complain, loudly and often, but the complaining is its own workaround, it lets us feel like we&#8217;re doing something about a problem we&#8217;ve quietly stopped trying to solve.</p><p>It shows up smaller too, in decisions nobody else ever sees. Something urgent needs the harder option, the one that takes more effort to arrange but actually solves the problem, and somebody quietly proposes the easier delay instead, dressed up as reasonable. You go along with it. Not because you couldn&#8217;t have pushed for the harder thing. Because pushing felt like more than the moment seemed to deserve.</p><p>What we don&#8217;t talk about is what this costs us beyond the obvious. The familiarity gives us grit, and grit we&#8217;re proud of. There&#8217;s a quiet pride in surviving the workaround, in being the kind of person who always finds a way. That pride is exactly what makes surrender so easy to mistake for maturity. It&#8217;s a very real exhaustion, fighting the same battle every day, and at some point putting the fight down stops feeling like giving up and starts feeling like wisdom.</p><p>But it&#8217;s a choice. And every system you&#8217;ve ever built is full of them. The manual reconciliation nobody&#8217;s automated. The Slack thread that&#8217;s actually the approval process. The spreadsheet quietly doing the job the software should be doing. None of those started as the plan. Each one was supposed to be temporary, a patch while something better got built. Most of them never got replaced, because replacing them was never anyone&#8217;s most urgent problem, until the workaround was simply how the product worked, and nobody could point to when that happened.</p><p></p><div><hr></div><p><em>How many of your &#8220;that&#8217;s just how it works&#8221; are actually a nation, a team, a product, deciding, one invisible adaptation at a time, never to fix anything again?</em></p><div><hr></div><p>These reflections sit alongside a longer body of work in progress, <em>The Emergent Economy</em>, which explores how systems form before institutions notice them.</p><p></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p>]]></content:encoded></item><item><title><![CDATA[What Counts as Innovation]]></title><description><![CDATA[Some technologies announce their arrival with pomp and circumstance.]]></description><link>https://adia.substack.com/p/what-counts-as-innovation</link><guid isPermaLink="false">https://adia.substack.com/p/what-counts-as-innovation</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 10 Jun 2026 05:43:29 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/e415ca2c-2fac-484d-9a12-5cd133098bb3_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Some technologies announce their arrival with pomp and circumstance.</p><p>Artificial intelligence. Autonomous vehicles. Spatial computing. Cue the launch events, keynote demos, and confident predictions about where the world is going next.</p><p>Others arrive quietly, like they&#8217;re going through the back door.</p><p>USSD. Pay-as-you-go solar. Offline-first systems. Voice notes as commercial infrastructure.</p><p>These rarely get described as frontier innovation. Never by the innovation influencers anyway. Perhaps they look temporary. Improvised. Waiting to be replaced by something more sophisticated. They feel politely tolerated, not celebrated.</p><p>And yet many of them produced something the first list, for all its visibility, often struggles with: rapid, voluntary adoption at scale, in conditions where adoption is genuinely hard to earn.</p><p>A bank CEO describe USSD as innovation and I instinctively judged him for choosing the wrong word. USSD is a string of numbers and asterisks that returns a text menu. No interface. No design. It predates the smartphone by decades. From a Silicon Valley lens: primitive. From a friction lens: it works on any phone, on any network, with almost no data, even when the connection is weak. It reaches people that apps cannot reach. Calling it innovation seemed like calling a dirt road infrastructure.</p><p>He was right.</p><p>I know this because I built on it. At Migo, we deployed machine learning &#8212; instant lending decisions, real-time risk assessment &#8212; behind a USSD interface. The algorithm is still one of the most sophisticated I&#8217;ve seen. But the delivery mechanism looked, to anyone trained in innovation culture, like a step backward. What it actually was: a forcing function. Building for USSD first meant building for constraint. And building for constraint produced an architecture flexible enough to deploy across web, messaging, ATM, <em>any</em> interface that <em>any</em> market demanded. The interface that looked primitive shaped a product that was more durable than anything built from the other direction.</p><p>Nigerian operators understand this instinctively, even when it goes unexpressed. Nigeria has enjoyed instant payments since 2011. The United States didn&#8217;t launch its equivalent until 2023. Twelve years later.</p><p>Innovation culture has a test for what counts: does it introduce something new? It&#8217;s a supply-side test &#8212; it measures novelty, visible sophistication, the thing that didn&#8217;t exist before. When that test dominates, something else fills the gap where adoption should be. In startup culture it&#8217;s called vision. In certain pitch rooms it arrives as vibes. The hope that what was built will find its people. None of these are dishonest. But none of them are adoption.</p><p>The more honest test is behavioral: did people reorganise around this &#8212; voluntarily, at scale, before anyone wrote the think-piece? USSD passed that test. M-Pesa passed it. Instant payments in Nigeria passed it. Quietly. Without a launch event. Without a keynote.</p><p>Innovation born from constraint doesn&#8217;t announce itself.</p><p>It just gets adopted.</p><div><hr></div><p><em>What in your market is already passing the behavioral test &#8212; that you haven&#8217;t called innovation yet?</em></p><div><hr></div><p></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p><p></p><p><em>These reflections are part of a longer work in progress &#8212; The Emergent Economy &#8212; which explores how markets form before institutions notice them.</em></p><p></p>]]></content:encoded></item><item><title><![CDATA[Follow the Friction]]></title><description><![CDATA[The common pattern for creating a company is innovation. But we need to follow a different pattern in emergent markets - we need to follow the friction]]></description><link>https://adia.substack.com/p/the-friction-principle</link><guid isPermaLink="false">https://adia.substack.com/p/the-friction-principle</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 03 Jun 2026 05:43:58 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/70761562-3204-45c7-ba50-3e83aecd5287_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The common pattern for creating a company is innovation. Build something new. Build something better. Bring breakthrough technology to market.</p><p>But I no longer believe innovation is the right starting point.</p><p>Not because innovation doesn&#8217;t matter. But because the word quietly centers the builder instead of the customer. Developed market innovation optimizes existing participation. Emergent market innovation must often address participation itself &#8212; which means starting somewhere completely different.</p><p>Innovation asks: <em>what can we create?</em> Friction asks: <em>what is making this unnecessarily hard, and how do we make it stop?</em> One is an invention question. The other is a painkiller question. In markets where people are already in pain, the order matters.</p><p>If you start from supply-side abstractions, you end up building for the system you think should exist instead of the one people are actually navigating. In emergent markets, people are already improvising around broken systems, unreliable infrastructure, thin trust, and daily uncertainty. The workaround everyone accepts because nobody has removed it yet. The extra trip. The failed transaction. The missing trust layer. Behavior that exists &#8212; just wrapped in so much pain that participation stays low.</p><p>The real opportunity is rarely inventing new behavior. It&#8217;s removing the friction surrounding behavior that already exists. And friction is easier to see. You can hear it in complaints. Feel it in the extra steps people take to complete ordinary transactions. Once you learn to look for it, markets become far easier to read.</p><p>What appears to be a diverse set of winners begins to resolve into the same basic pattern.</p><p><strong>The companies that won:</strong></p><ul><li><p><strong>OPay/PalmPay</strong> &#8594; reduced payment friction (send money without visiting a branch, without waiting in line, without the transaction failing)</p></li><li><p><strong>Jumia/Bolt</strong> &#8594; reduced logistics and discovery friction (find what you need without knowing which market to visit or which vendor to trust)</p></li><li><p><strong>Flutterwave/Paystack</strong> &#8594; reduced payment integration friction (merchants accept payments without building relationships with five different banks)</p></li><li><p><strong>M-Pesa</strong> &#8594; reduced cash movement friction (move money without physical travel or formal banking infrastructure)</p></li><li><p><strong>MTN</strong> &#8594; reduced billing friction (per-second prepaid vs. per-month postpaid &#8212; no bill shock, no credit check, no contract)</p></li><li><p><strong>Interswitch</strong> &#8594; reduced payment interoperability friction (connected fragmented banking rails so your GTBank card works at a Zenith ATM)</p></li><li><p><strong>Agency banks</strong> &#8594; reduced bank access friction (banking services without traveling to a branch)</p></li><li><p><strong>Computer Village</strong> &#8594; reduced access, price, sourcing, and distribution friction simultaneously (all four lower than formal retail channels)</p></li><li><p><strong>Digital banks</strong> &#8594; reduced account opening friction (bank account without branch visit, paperwork, or minimum balance requirements)</p></li><li><p><strong>Ride-hailing</strong> &#8594; reduced transportation friction (reliable ride without standing roadside negotiating with multiple okada riders)</p></li><li><p><strong>Pay-as-you-go data bundles</strong> &#8594; reduced data access friction (buy exactly what you need, when you need it)</p></li><li><p><strong>Moniepoint</strong> &#8594; reduced SME banking and cash movement friction (business payments and agency banking without complexity)</p></li></ul><p>None of these companies won on superior technology. None won on stronger branding. We make those arguments anyway because they&#8217;re crowd pleasers &#8212; and because we haven&#8217;t yet found the language of our own markets. These companies won because they identified one specific thing that was unnecessarily painful and made it stop.</p><p>Friction isn&#8217;t a UX problem or a conversion metric. In emergent markets, it&#8217;s the competitive landscape.</p><div><hr></div><p><em>What would you build if you accepted that your customer isn&#8217;t waiting for innovation &#8212; they&#8217;re waiting for relief?</em></p><div><hr></div><p></p><p></p><p></p><p></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how markets form before institutions notice them.</em></p><div><hr></div><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p>]]></content:encoded></item><item><title><![CDATA[Borrowed Language, Broken Strategy]]></title><description><![CDATA[Vocabulary carries its worldview within.]]></description><link>https://adia.substack.com/p/borrowed-language-broken-strategy</link><guid isPermaLink="false">https://adia.substack.com/p/borrowed-language-broken-strategy</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 27 May 2026 06:14:05 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/ae0ba6fb-c905-420f-9b8b-529ce46819d3_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Vocabulary carries its worldview within.</p><p>The words a market reaches for &#8212; the ones that surface in pitch decks, in boardrooms, in the frameworks we inherit &#8212; reveal not just what that market values, but what it assumes. What it takes for granted. What it has never had to question.</p><p>Developed-market business language tends to assume the underlying system already works. Infrastructure is stable. Transactions complete. Institutions hold. From that foundation, the vocabulary moves upward &#8212; toward preference, experience, optimization, delight. The system is given. The job at hand is to improve it.</p><p>Emergent market language cannot make that assumption. Here, the vocabulary that actually matters &#8212; the vocabulary you need to build something that works &#8212; stays close to the ground. It must. Because the ground keeps moving. Trust breaks and the customer doesn&#8217;t return. Access disappears and participation disappears with it. The words that survive in these environments are the ones that name what is actually precisely at stake: friction, waiting, reliability, proof, cash flow, distance. Words that ask whether the transaction happens at all before asking how it feels.</p><p>This is the vocabulary of emergent markets. And it is more precise than what replaced it.</p><div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="/__u/substackcdn.com/image/fetch/$s_!DpbU!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="/__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_424, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 424w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_848, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 848w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_1272, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 1272w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_1456, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 1456w" sizes="100vw"><img src="/__u/substackcdn.com/image/fetch/$s_!DpbU!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png" width="717" height="924" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/eba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:924,&quot;width&quot;:717,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:134360,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:&quot;image/png&quot;,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:&quot;https://adia.substack.com/i/199399019?img=https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png&quot;,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="/__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_424, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 424w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_848, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 848w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_1272, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 1272w, /__u/substackcdn.com/image/fetch/$s_!DpbU!, /__u/adia.substack.com/w_1456, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feba900c6-9410-4101-b5fa-0655b522a3cf_717x924.png 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg aria-hidden="true" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><p></p><p>While a lack of sophistication is often blamed, the culprit here is the assumptions.</p><p>&#8220;Experience&#8221; assumes the transaction already works. &#8220;Friction&#8221; asks whether it works at all. &#8220;Brand&#8221; assumes institutional legitimacy exists. &#8220;Trust&#8221; asks whether people believe you enough to risk anything on it. &#8220;Choice&#8221; assumes abundance. &#8220;Access&#8221; assumes the door might be closed.</p><p>And then this: Revenue versus Cash flow. Revenue is what the company earns. Cash flow is whether the customer survives the week. These are not two measurements of the same thing. What they are is two entirely different orientations toward the same market. One starts from the company. The other starts from the person trying to participate in the economy.</p><p>The problem &#8212; and this is what this series is about &#8212; is that this vocabulary rarely makes it into the rooms where it matters most. When emergent market builders pitch, they reach for a different language. Innovation. Disruption. Technology-led growth. They&#8217;ve learned, often without noticing they&#8217;ve learned it, that the words closest to reality don&#8217;t travel well. Say &#8220;we removed the friction that stopped people from completing a cash transfer&#8221; and the room hears small, local, incremental. Say &#8220;we built an innovative fintech platform&#8221; and the room leans forward.</p><p>So you code-switch. And you keep code-switching. Until the borrowed language becomes the only language and the problem you once knew precisely disappears inside it.</p><p>The cost of that translation is real. Strategy follows language. When you spend enough time describing your business in words that don&#8217;t quite fit the mechanism, you start optimising for the description instead of the thing itself. Baby founders read TechCrunch and learn to want to disrupt. They look at Flutterwave and see technology. They look at M-Pesa and see innovation. They don&#8217;t see friction removal &#8212; not because it isn&#8217;t there, but because nobody handed them that word as the lens. So they build chasing disruption, and the mechanism that actually drives scale stays invisible. Even to them.</p><p>That&#8217;s what this series (and book) is trying to recover. A more honest vocabulary &#8212; one that names what&#8217;s actually working in these markets, so builders can do it on purpose.</p><p>In the next issue: the companies that looked for friction &#8212; and what happened when they found it.</p><p></p><div><hr></div><p><em>What have you been translating away &#8212; and what did you lose in the translation?</em></p><div><hr></div><p></p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Leap of Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how markets form before institutions notice them.</em></p><div><hr></div><p></p><p></p>]]></content:encoded></item><item><title><![CDATA[If Delay Pays, Delay Persists]]></title><description><![CDATA[Some markets look broken from the outside and function perfectly well for the people inside them.]]></description><link>https://adia.substack.com/p/if-delay-pays-delay-persists</link><guid isPermaLink="false">https://adia.substack.com/p/if-delay-pays-delay-persists</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 20 May 2026 06:41:41 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/d80a999a-ba88-4ae7-82fd-1ecc2e730d42_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Some systems look broken from the outside and function perfectly well for the people inside them.</p><p>Walk into any major port &#8212; Lagos, Mombasa, Jakarta &#8212; and ask why cargo takes three weeks to clear when the paperwork suggests three days. The easy answer is inefficiency. But look more carefully at where the fees accumulate, who the expeditors charge for access to information, which signatures are required and whose desk they land on &#8212; and the answer emerges. The delay is not a malfunction. <em>For a specific set of participants, the delay is the product.</em></p><p>The same mechanism runs through contexts that attract very different language. In the UK, planning permission systems have generated an entire professional class whose value lies entirely in knowing how to navigate them. Nobody calls this dysfunction or better still, corruption. It is called process.</p><p>Banking offers the clearest version. Settlement delays in international transfers weren&#8217;t a technical limitation &#8212; they generated float, the interest earned on funds held between sender and receiver. Then Nigeria built instant payment infrastructure in 2011. Nigeria built something that vested interests in more established markets had resisted building. The United States launched its equivalent rail in 2023 &#8212; its first new payments infrastructure in fifty years. Today, roughly 1,400 of America&#8217;s 9,000 banks have joined. Most can only receive instant payments, not send them. Several of the ten largest banks haven&#8217;t joined at all.</p><p>This reframes the persistence of the &#8220;unbanked&#8221; as more than an access problem. In many cases, it was a value judgment on what banking actually offered. What we called financial exclusion was sometimes refusal &#8212; a rational decision that the formal system offered less value than the workaround. The rise of agency banking and instant payments didn&#8217;t just expand access to banking. It made banking worth accessing.</p><p>The port. The bank. The approval process that requires three offices and two weeks. These are not different problems. They are the same problem &#8212; delay as a revenue mechanism &#8212; wearing different institutional clothes.</p><p>What you call this depends on where you&#8217;re standing. In markets perceived as developing, it&#8217;s dysfunction or institutional weakness. In markets perceived as developed, it&#8217;s regulation or legacy infrastructure. The label changes with the latitude.</p><p>Systems rarely change because a better alternative exists. They change when the people extracting value from the old system can also extract value from the new one. Until then it gets called a workaround. A risk. Development.</p><p>Anyone building in these environments runs into the same wall. Persistent friction feels like a problem to be solved &#8212; a better product, a smarter process. But friction that generates revenue for its gatekeepers is not waiting to be solved. It is an arrangement working exactly as intended. Remove one checkpoint and another appears somewhere else in the flow.</p><p>Sometimes you can make the delay irrelevant. Sometimes it&#8217;s load-bearing and won&#8217;t move. Either way, knowing who it serves changes the architecture of your response.</p><div><hr></div><p><em>If one man&#8217;s process is another man&#8217;s dysfunction, which side of the delay is your business on?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how markets form before institutions notice them.</em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/if-delay-pays-delay-persists?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/if-delay-pays-delay-persists?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p>]]></content:encoded></item><item><title><![CDATA[Where Trust Goes When Institutions Fail]]></title><description><![CDATA[When a business enters a market and finds that people aren&#8217;t adopting the product the way they expected, the first diagnosis is usually demand.]]></description><link>https://adia.substack.com/p/where-trust-goes-when-institutions</link><guid isPermaLink="false">https://adia.substack.com/p/where-trust-goes-when-institutions</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 13 May 2026 11:39:56 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/869098a5-55c3-4052-8810-dfb986cee811_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>When a business enters a market and finds that people aren&#8217;t adopting the product the way they expected, the first diagnosis is usually demand.</p><p>&#8220;The market isn&#8217;t ready.&#8221;</p><p>&#8220;The customer isn&#8217;t educated enough.&#8221;</p><p>&#8220;The infrastructure isn&#8217;t there yet.&#8221;</p><p>The diagnosis is almost always wrong in an emergent market. It is especially confounding in high population ones where needs are plentiful and diverse.</p><p>But in these markets, formal institutions repeatedly fail people &#8212; banks exclude them, systems don&#8217;t see them, services overcharge and underdeliver &#8212; even so, trust doesn&#8217;t disappear. It can&#8217;t. Because the foundation of any market is trust. It finds other routes. It moves into relationships, communities, and informal networks that earn it through sustained reliability - even if imperfect - rather than through official designation. The consistency, availability and proximity matter more than excellence.</p><p>The trader who extends credit to a regular customer isn&#8217;t operating in a low-trust environment. She is operating in a high-trust network that formal institutions struggle to replicate or even see. She is the trust infrastructure. The referral that brings a new customer to a her isn&#8217;t just a marketing channel. It carries a marketing message pre-loaded with trust. That trust is based on the accumulated confidence of one person extended to the next customer.</p><p>What formal systems read as low trust is often something more specific: low trust in formal systems. The trust itself is plentiful. It simply doesn&#8217;t flow through the channels the business built for it.</p><p>This distinction changes everything about how builders should build products, go-to-market, and partnerships. If trust is absent, you create it. If trust is routed differently, you find where it already flows &#8212; and build your product at that junction.</p><p>Most businesses that fail in these markets were looking for trust in the wrong place. It was always there. They just weren&#8217;t standing where it moved.</p><div><hr></div><p><em>Where does trust move in your market &#8212; and are you building at that junction, or waiting for the customer to come to you?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how markets form before institutions notice them.</em></p>]]></content:encoded></item><item><title><![CDATA[Emerging vs. Emergent]]></title><description><![CDATA[We use the word emerging as if it&#8217;s neutral.]]></description><link>https://adia.substack.com/p/emerging-vs-emergent</link><guid isPermaLink="false">https://adia.substack.com/p/emerging-vs-emergent</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Wed, 06 May 2026 06:15:57 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/a4316064-4819-4833-b304-639b05332faa_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>We use the word <em>emerging</em> as if it&#8217;s neutral.</p><p>It isn&#8217;t.</p><p><strong>Emerging</strong> implies movement toward something &#8212; a destination, a norm, a finished state. When we call a market emerging, <a href="/__u/adia.substack.com/p/the-language-of-limitation?r=79k33">we are quietly saying</a>: it is on its way to becoming something else. Something more like what we already know.</p><p>But spend enough time in markets like Nigeria, and the trajectory starts to feel like a fiction. These markets aren&#8217;t moving toward a Western endpoint. They&#8217;re not delayed or incomplete versions of something more developed. They have their own operating logic &#8212; their own ways of building trust, moving money, distributing goods, and absorbing risk &#8212; that have been refined over decades, not despite constraint but because of it.</p><p><strong>Emergent</strong> is a different word entirely. It doesn&#8217;t describe a trajectory. It describes a process: systems and behaviors that self-organise from the bottom up, producing order that no one designed and no institution planned for. Airtime used as currency. Agent networks that outperformed bank branches. Informal credit systems that served millions before any traditional bank noticed. None of these were transitions. They were solutions.</p><p>The distinction isn&#8217;t semantic. If a market is <em>emerging</em>, the strategy is to wait for it to mature, or to accelerate that maturation. If a market is <em>emergent</em>, the strategy is to understand the system that already exists &#8212; and work with it, not against it.</p><p>Most businesses that fail in these markets don&#8217;t fail on execution. They fail on assumption&#8212;building for a version of the market they were taught to expect, not the one that exists.</p><div><hr></div><p><em>What has your language already decided about your market?</em></p><div><hr></div><p><em>These reflections sit alongside a longer body of work in progress &#8212; The Emergent Economy &#8212; which explores how systems form before institutions notice them.</em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/emerging-vs-emergent?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/emerging-vs-emergent?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p>]]></content:encoded></item><item><title><![CDATA[The Market You Can't See]]></title><description><![CDATA[Africa Is "Rising". So why can't we see the demand hiding in plain sight?]]></description><link>https://adia.substack.com/p/the-market-you-cant-see</link><guid isPermaLink="false">https://adia.substack.com/p/the-market-you-cant-see</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Tue, 28 Apr 2026 12:38:58 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/879b21a7-8b41-41c0-9338-35d4143aa69c_2400x2400.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Most discussions about markets start from the same assumption: that demand is visible.</p><p>That you can see it in transactions, in revenue, in the number of people willing to pay. That if people aren&#8217;t buying, demand isn&#8217;t there. It&#8217;s a logical assumption. It&#8217;s also, in many markets, completely wrong.</p><p>Spend enough time trying to &#8216;find&#8217; a market in places like Nigeria, and something starts to feel off about the standard model. Products launch into markets analysts have described as large and underserved, only to find adoption that staggers, churns, or simply refuses to follow the expected curve. Investors look at category data and conclude the market is smaller than they thought. Founders look at user behavior and conclude their product needs more work. Easy dismissal.  Both are citing the wrong problem.</p><p>The issue isn&#8217;t the product. It&#8217;s not even the market size. It&#8217;s that what everyone is measuring &#8212; transactions, conversions, revenue &#8212; is only the part of demand that managed to surface. And in constrained markets, that is often the smallest part of the story.</p><p></p><p>Demand doesn&#8217;t disappear when markets fail to serve it well. It just finds another path.</p><p>Walk into any professional office in Lagos and count the iPhones. Then try to find where they were bought. London. Dubai. New York. Often our flagship &#8216;informal&#8217; market, Computer Village. Almost never from an authorised retailer in the city where they&#8217;re used every day. The easy explanation is foreign exchange &#8212; the naira, the parallel rate, the cost of importing at official prices. But FX is only part of it. Talk to the people making those purchases and a different picture emerges: they&#8217;re not buying abroad just because it&#8217;s cheaper. They&#8217;re buying abroad because the transaction feels more certain. Authenticity guaranteed. Recourse available if something goes wrong. Chain of custody visible from purchase to hand.</p><div class="pullquote"><p>The demand isn&#8217;t absent, it just&#8230;.emigrated. And it didn&#8217;t emigrate just for price. It emigrated for trust too.</p></div><p>This is <strong>Displaced demand</strong>. The consumption happens in one place, but the spending happens somewhere else.  Even if the price is right, the local transaction hasn&#8217;t yet earned the confidence of the buyer. The consequence is that the local market looks like a small market. It isn&#8217;t. It&#8217;s a market whose transactions are geographically dislocated from its actual consumption base, and the dislocation is a trust gap, which is just as, if not more, important than a price gap. That distinction matters enormously for how the solution is designed.</p><p></p><p><strong>Suppressed demand</strong> is quieter and, for that reason, easier to misread as absence.</p><p>Nigeria has one of the lowest rates of formal credit access in the world &#8212; estimates hover around five percent of the adult population. The conventional interpretation of that number is that most Nigerians are not creditworthy. The actual interpretation is more uncomfortable: most Nigerians are invisible to the traditional systems that assess creditworthiness.  This isn&#8217;t news.</p><p>The millions of Nigerians running profitable businesses &#8212; tailors, traders, logistics operators, mechanics, food vendors &#8212; cannot get a loan from a formal institution not because they can&#8217;t repay one, but because their repayment capacity doesn&#8217;t exist in a form those institutions can see. No formal payslip. No credit history. No collateral that registers in a land registry. The demand for credit is enormous and largely unmet.  Or met by non-traditional means. The system reads the silence as absence.</p><p>What changed that wasn&#8217;t a new willingness to lend. It was new data. Telcos sitting on years of mobile usage patterns, airtime top-up behavior, and bill payment history began licensing that data to lenders who could infer creditworthiness from it. The demand hadn&#8217;t grown. It had always been there, just suppressed.  With new data and technology, it became legible.</p><blockquote><p>Absence of transactions is not absence of demand. It is, more often, absence of infrastructure capable of seeing the customers in a way that makes them desirable to serve.  </p></blockquote><p></p><p><strong>Emergency demand</strong> works differently. It isn&#8217;t hidden, it&#8217;s conditional.</p><p>Under normal circumstances, many Nigerians apply rational price sensitivity to most purchasing decisions. They compare, delay, substitute. The informal market is good at accommodating this; haggling is a form of demand expression, not a friction to be eliminated. But when urgency enters the equation, that calculus collapses entirely.</p><p>Your generator fails while payroll is processing. A child&#8217;s fever spikes on a public holiday. A shipment stalls at a port and your warehouse is empty. In those moments, price sensitivity isn&#8217;t suppressed &#8212; it evaporates. Whatever it costs to solve the problem, you pay it. The willingness-to-pay curve looks almost vertical.</p><p>This is why the informal market for emergency services &#8212; repairs, last-mile logistics, urgent procurement &#8212; operates at pricing that looks irrational by standard models and makes complete sense once you understand the demand type driving it. You aren&#8217;t pricing against what something is worth in ordinary time. You&#8217;re pricing against what it costs to be without it, right now.</p><p>Most market models can&#8217;t see this, because most market models assume demand is relatively stable.  <em>Stable demand is a consequence of infrastructure, so in the absence of infrastructure, demand naturally is spiky, or visible in &#8216;recurrent&#8217; emergencies.</em>  In practice, demand in constrained markets is highly conditional: low urgency on Monday, but stable on Wednesday, driven entirely by circumstances the customer didn&#8217;t choose and couldn&#8217;t predict.</p><p></p><p><strong>Workaround demand</strong> is the most important - and probably the most common - of the four, and the one operators most consistently misread as failure.</p><p>When the formal product doesn&#8217;t fit &#8212; wrong pricing, wrong packaging, wrong distribution, wrong payment model &#8212; people don&#8217;t give up. They redesign the solution themselves, inefficiently, at cost, using whatever is available. And the cost they absorb is worth noting. These aren&#8217;t passive substitutions. They&#8217;re active, effortful responses to a formal market that hasn&#8217;t solved for them: visiting multiple sellers to verify authenticity, paying in cash and carrying goods home personally, routing purchases through trusted intermediaries, building informal quality-assurance networks that exist entirely because the formal channel hasn&#8217;t earned their confidence. The workaround is not the same as doing nothing. It is demand expressing itself through whatever channel remains open &#8212; and spending real time, money, and energy doing so.</p><p>Sachet water is the clearest example in Nigerian market history. The bottled water industry existed. It served the segments it was priced for. A significant proportion of the population had no access to clean water and no realistic way to pay for it in the form it was offered. The market&#8217;s response wasn&#8217;t to go thirsty. It was to develop a delivery format so cheap, so portable, and so widely distributed that it reached everywhere the bottles didn&#8217;t. Sachets. Ten naira at a time, sold from wheelbarrows and kiosks and roadside stands, consumed and discarded immediately. Today that segment represents billions in annual market value.</p><p>The formal market for clean water didn&#8217;t look large before sachets. It looked like a moderately served premium segment. The workaround demand was always there. It just wasn&#8217;t being captured by anything formal enough to show up in market data.</p><blockquote><p>Workarounds are not edge cases. They are the early version of the real market, before it has been discovered by the product that will eventually serve it properly. </p></blockquote><p>And the gap between what people are willing to do informally &#8212; the effort they already absorb &#8212; and what they would do if a formal channel earned their trust, is where the real opportunity lives.</p><div><hr></div><p>What makes these four types &#8212; displaced, suppressed, emergency, workaround &#8212; analytically useful isn&#8217;t just that they explain past misreads. It&#8217;s that they reveal something structural about how demand behaves under constraint.</p><p>Demand doesn&#8217;t disappear when supply is inadequate, inaccessible, or mispriced. It adapts. And the adaptations are not random. They follow a logic: when access is blocked, demand is suppressed and accumulates behind the constraint. When trust is low, demand is displaced to wherever the transaction feels more certain. When time is critical, demand becomes urgent and price-insensitive. When the product doesn&#8217;t fit, demand builds its own solution.</p><p>This means hidden demand is not actually hidden in the sense of being unknowable. It&#8217;s hidden only if you&#8217;re looking for it in the wrong places &#8212; at the formal transaction layer, where it may never appear, rather than at the behavioral layer, where it&#8217;s always present.</p><div><hr></div><p>This reframing has consequences for how we build.</p><p>When we assume demand is visible, we build only for the demand we can see. They optimise funnels, improve conversion rates, sharpen their messaging. These are reasonable responses to the problem they think they have. The problem is that the problem isn&#8217;t execution &#8212; it&#8217;s that a significant proportion of the addressable demand never reaches the funnel in the first place, because the product or the model has already made itself inaccessible to it.</p><p>Monthly subscription pricing excludes people who earn daily and manage cash on a week-to-week basis &#8212; not because they can&#8217;t afford the aggregate cost, but because they can&#8217;t guarantee the timing. A card-based payment rail excludes people who primarily move money through mobile money or cash &#8212; not because they resist digital, but because the infrastructure stack the product chose doesn&#8217;t map to their financial lives. An app-only distribution model excludes people in areas with unreliable data access &#8212; not because they&#8217;re not customers, but because the channel assumes conditions that don&#8217;t exist.</p><p>Each of these is a decision that looks neutral from the inside and functions as exclusion from the outside.</p><p>And then the analytics confirms what the model already assumed. Most business intelligence systems are built to track completed transactions. They see conversions, retention rates, cohort behavior. What they cannot see is more instructive: demand that never reached the channel because the channel required conditions the customer couldn&#8217;t meet. Willingness to pay that existed but was contingent on trust the product hadn&#8217;t yet built. Intent that expressed itself through a WhatsApp inquiry, an in-store question about something not in stock, a search that ended without purchase &#8212; signals that passed through the system and left no trace because no one designed the system to catch them.</p><p>Which means the founder who looks at their dashboard and sees &#8220;low demand&#8221; is getting an accurate read of the formal transactions their product successfully processed. They&#8217;re getting almost no signal about the demand that existed and went somewhere else, or nowhere at all.</p><div><hr></div><p>A demand-aware system is built differently from the ground up.</p><p>It doesn&#8217;t start with transactions. It starts with attempts. Every inquiry that arrives through a messaging channel and doesn&#8217;t convert is a data point &#8212; not about product-market fit, but about where the friction is. Every in-store conversation about a product that isn&#8217;t available is a demand signal that most retail operations let evaporate. Every search that ends at an out-of-stock page is a statement of intent that the standard e-commerce funnel records as a bounce and discards.</p><p>The question a demand-aware system asks is not &#8220;did the customer buy?&#8221; It asks what the customer tried to do. It tracks the channel they came through, because channel source predicts trust posture &#8212; someone who arrived through a personal referral is in a different buying state than someone who found the product through a search. It tracks what they asked for when it wasn&#8217;t available, because that is the clearest possible signal of unmet demand. It tracks how they wanted to pay, because payment method reveals how much certainty the customer needed before committing &#8212; cash at pickup means something different from a card online, and an installment request means something different again.</p><p>None of this is exotic. It requires designing for signal capture from the start, not retrofitting dashboards after the fact. The data exists in every customer interaction. Most of it is simply never collected.</p><p>A failed transaction is data. A delayed transaction is data. A workaround is data. The person who bought the sachet instead of the bottle was telling you something precise about what you priced wrong and what format would work instead. The person who bought the iPhone in London and brought it back in their hand luggage was telling you something precise about what the local transaction was still missing.</p><p>The question isn&#8217;t how large the market is. It&#8217;s how much of the demand that already exists you have made it possible for people to express.</p><p>That&#8217;s a different problem to solve. It requires different products, different pricing architectures, different distribution channels, different ways of reading what the data is actually showing.</p><p>Is the market real? Probably. But you're only seeing the part that managed to reach you. The rest is still out there &#8212; in the attempts that failed, the questions you never captured, the workarounds customers built, and the trust gaps that pushed transactions elsewhere.</p><p></p><div class="captioned-button-wrap" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-market-you-cant-see?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="CaptionedButtonToDOM"><div class="preamble"><p class="cta-caption">Thanks for reading Leap of Scale! This post is public so feel free to share it.</p></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-market-you-cant-see?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/the-market-you-cant-see?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p></div><h3></h3>]]></content:encoded></item><item><title><![CDATA[The Two F-Words Every Builder Needs to Know]]></title><description><![CDATA[The difference between "I can't" and "this sucks"&#8212;and why it matters]]></description><link>https://adia.substack.com/p/the-two-f-words-every-builder-needs</link><guid isPermaLink="false">https://adia.substack.com/p/the-two-f-words-every-builder-needs</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Fri, 10 Oct 2025 16:10:26 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/1ccc842a-ea46-460a-8914-b8e5736f485b_1536x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>There are only two words I want every builder to remember after talking to their users. Two F-words. Not the ones you're thinking. These ones are more useful: <strong>Friction</strong>. And <strong>Frustration</strong>.</p><p>They're diagnostic instruments that work especially well in overlooked, under-digitized markets where trust is earned one conversation at a time. They represent a mindset shift for product builders who want traction, not just feedback.</p><p>A market woman once told me she wanted to track her sales better. What she meant was she was tired of shouting to remember what she sold an hour ago. She wasn't asking for a feature. She was sharing a symptom.</p><h2>Why Listening Isn't Enough</h2><p>Most early-stage teams do talk to customers. But they often do it wrong. They lead with questions like "What do you want?" instead of "What's hard?" They collect requests, not realities. They transcribe quotes instead of translating needs.</p><p>The Henry Ford quote about "faster horses" gets thrown around a lot, but the real insight isn't about ignoring what users say&#8212;it's about understanding what they mean. Great product sense comes not from what users say they want, but from diagnosing where they struggle.</p><p>People don't give you product specs. They give you symptoms.</p><h2>The Two F-Words Defined</h2><p><strong>Friction</strong> is "I want to do something, but I can't." It's an internal blocker, a missing step, an inaccessible feature. The market woman wanting to track sales without shouting? That's friction. Her mental model includes sales tracking, but no system supports it.</p><p><strong>Frustration</strong> is "I've tried to do this, and it's not working." It's system failure, poor UX, unreliable tools. When someone says, "This POS is too slow and bulky. I end up writing sales by hand," that's frustration. They've attempted the digital solution and retreated to analog backup.</p><p>Understanding the distinction matters because each requires different design responses. Friction demands simplification&#8212;removing steps, reducing cognitive load, making the path clearer. Frustration demands reliability&#8212;building trust, preventing failure, creating confidence.</p><h2>Why This Matters for Design and Business</h2><p>Good products remove friction. Great products anticipate and soothe frustration. Each becomes a design cue, a sales cue, a pricing cue, and a narrative cue.</p><p>When friction is high, your UI needs to feel like home. Familiar patterns, predictable flows, interfaces that don't require new mental models. When frustration is present, your job is to rebuild trust. Consistent performance, visible reliability, systems that work when everything else doesn't.</p><p>Consider a barcode scanner designed to look like a calculator. To Silicon Valley eyes, that might seem backward. But in a market where calculators are trusted, ubiquitous tools and barcode scanners are foreign technology, the calculator interface isn't a gimmick&#8212;it's a Trojan horse for trust. It reduces friction by leveraging existing mental models while eliminating frustration by presenting technology in familiar packaging.</p><h2>A Field Guide to Listening Differently</h2><p><strong>Step 1: Categorize Every Comment</strong> After every user conversation, retro-tag every quote as friction, frustration, or filler. Friction quotes contain words like "can't," "won't," "doesn't work," or "need to." Frustration quotes include "tried," "failed," "broken," or "gave up."</p><p><strong>Step 2: Ask Diagnostic Follow-Ups</strong> If friction &#8594; ask "What do you wish could happen?" This reveals the mental model they're carrying. If frustration &#8594; ask "When did that happen? What did you do next?" This reveals their backup systems and pain tolerance.</p><p><strong>Step 3: Translate, Don't Transcribe</strong> Don't just log quotes. Write down what the user is really saying and what the system must do differently. "I want to print a receipt" translates to "I need my customer to trust the transaction happened." The receipt isn't the need&#8212;the trust signal is.</p><p></p><h2>The Emotional Return Of Getting It Right</h2><p>When users say "This helps me sleep at night," that's the goal. During one project, the team said they wanted their product to be "the kind of thing they sleep with under their pillow." That's not a joke. That's a benchmark.</p><p>Most products are tools. Products that reduce friction and resolve frustration become companions. Products that anticipate needs become partners. The evolution runs from utility to reliability to indispensability.</p><p>The path to product love runs through frustration&#8212;and ends in relief.</p><h2>The Call to Listen</h2><p>Don't wait to have the perfect prototype or brand story. Start with two ears and a notepad. Listen for the symptoms hiding inside feature requests. Categorize every complaint as friction or frustration. Build solutions that address the root, not just the surface.</p><p>In emerging markets especially, where trust is scarce and digital literacy varies, the difference between friction and frustration isn't academic&#8212;it's the difference between adoption and abandonment. Frustration is a love letter written in complaint. If you listen well, you'll be the one they talk about in the market.</p><p>The users who seem the most demanding are often pointing toward the biggest opportunities. Their friction reveals unmet needs. Their frustration exposes system gaps. Both are invitations to build something that actually works.</p><p>Listen for the F-words. Build for the symptoms. Win the trust that comes from solving what really matters.</p>]]></content:encoded></item><item><title><![CDATA[The Stories Behind Your Scale (That You Never Hear)]]></title><description><![CDATA[How Customer Stories Hide The Small Signals That Drive Big Growth]]></description><link>https://adia.substack.com/p/the-stories-behind-your-scale-that</link><guid isPermaLink="false">https://adia.substack.com/p/the-stories-behind-your-scale-that</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Fri, 19 Sep 2025 17:08:25 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/05cfca72-3b98-4f09-88cc-a11ef98afb86_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<h3>The Myth That Won&#8217;t Die</h3><p>There's a persistent myth about emerging markets that refuses to die: people here don't care about quality, they only care about price. Walk into any business, and you'll hear variations of this theme. "Nigerians are price-sensitive," they say. "They'll take anything cheap." The subtext is always the same: why bother with polish when survival economics just want everything to be cheaper?</p><p>This lazy assumption (not <a href="/__u/adia.substack.com/p/price-sensitivity-is-a-lazy-diagnosis?r=79k33">the first one I&#8217;ve written about</a>) misses something fundamental. Quality does matter&#8212;intensely. But not in the way developed-market playbooks define it. Here, quality isn't measured in awards or certifications.  Well, it is, but that is just corporate theater.  What it should be measured in is more tactical -  stories. And those stories, more than any marketing campaign, determine which businesses scale and which fade into irrelevance.</p><p>The loop is simple: Quality creates talkability. Talkability drives adoption. Adoption enables scale. Break any part of this chain, and growth stalls. Master it, and you unlock something more powerful than advertising, you unlock advocacy.</p><h2>Reading Quality Through Local Eyes</h2><p>When someone in Lagos says a product is good, they rarely describe craftsmanship or specifications. Instead, they say things like:</p><p>"This one lasts longer than&#8230;X." </p><p>"It never disappoints me." </p><p>"The delivery guy was actually polite."</p><p>These aren't casual observations, they're actually <strong>quality assessments expressed through impact and dignity</strong>. Quality reveals itself not in what something is, but in what it does and how it treats you.</p><p>This matters because in markets where formal trust institutions are weak, customers rely on these experiential signals to make decisions. They can't verify your backend infrastructure or financial stability, so they judge your entire operation by whether you got their phone number right in the first SMS.</p><h2>The Two Layers That Actually Matter</h2><p>Emerging markets evaluate quality through two distinct but interconnected layers:</p><p><strong>Functional Quality</strong> centers on reliability and durability. Does it work when I need it? Will it last until my next payday? Does the transaction actually complete? This is quality as performance&#8212;the foundational layer that everything else builds upon.</p><p><strong>Perceived Quality Signals</strong> encompass all the small details that suggest competence: clean interfaces, correct grammar, proper name formatting, punctual service, respectful customer support. These signals matter because they're visible proxies for invisible competencies.</p><p>In low-trust environments, customers can't peer inside your systems to assess reliability, so they extrapolate from what they can see. If your SMS alerts are riddled with typos, they assume your financial controls are equally sloppy. If your app feels broken in small ways, they worry it might fail in big ones.</p><p>This creates a critical insight: <strong>perceived quality signals aren't cosmetic&#8212;they're functional</strong>. They reduce customer anxiety and increase willingness to try, recommend, and stick around.</p><h2>Why UX Falls to the Baseline (And Why That's Dangerous)</h2><p>In the absence of trusted quality standards that businesses aspire to, UX standards often drift toward the lowest acceptable baseline.  <em>Yes, I&#8217;m looking at those of you who put last name before first name when that&#8217;s not your country&#8217;s convention.</em>  </p><p>If customers tolerate inconsistent service or adapt to clunky interfaces, teams deprioritize polish. The reasoning seems sound: why over-invest in areas where customers aren't demanding excellence?</p><p>This baseline thinking is dangerous for two reasons. First, it assumes customers don't notice or care about quality differences, they do, they just accept what seems achievable. Second, it misses the massive opportunity that exists precisely because expectations are low.</p><p>When everyone operates at the baseline, breaking above it creates outsized impact. Small improvements become big differentiators. Minor touches generate major talkability. The companies that understand this dynamic don't just meet expectations: they systematically exceed them in carefully chosen moments.</p><h2>Small Signals, Big Stories</h2><p>Virality doesn't happen when you meet expectations, it happens when you exceed them. In environments with low baselines, tiny signals can trigger disproportionate word-of-mouth.</p><ul><li><p><strong>Tecno</strong> built reputation not by adding features, but by delivering longer-lasting <a href="https://www.tymlova.com/blog/top-phones-with-the-longest-battery-life-in-nigeria">batteries</a>. That one functional edge drove adoption across price-sensitive segments.</p></li><li><p><strong>GTBank</strong> stood out with instant SMS alerts in a sector known for delays. Consistency in basics became their differentiator.</p></li><li><p><strong>Paystack</strong> focused on developer experience and clear error messages, turning broken transactions into solvable problems. &#8594; Trimmed &#8220;these touches weren&#8217;t expensive features&#8221; line.</p></li></ul><p>The pattern is clear: breakthrough adoption often comes not from revolutionary innovations but from consistently executing basics that others neglect. When you systematically exceed the baseline in areas customers care about, you create the raw material for stories.</p><h2>When Stories Drive Adoption</h2><p>In markets where formal trust signals are weak, people rely heavily on peer recommendations. They can't easily verify your claims about security or reliability, but they can trust their cousin's experience with your service. This makes word-of-mouth the most credible form of marketing&#8212;and the most cost-effective.</p><p>Quality creates the stories that drive these recommendations. </p><ul><li><p>A mobile money transaction that completes instantly.</p></li><li><p>A food delivery that arrives on time.</p></li><li><p>A support team that resolves problems first call.</p></li></ul><p>These experiences become stories, and those stories spread faster than ads. They carry emotional weight advertising can&#8217;t match.</p><p>The companies that scale fastest <strong>design for story generation</strong>&#8212;delivering excellence in the moments most likely to surprise and delight.</p><h2>The Investment Case for Polish</h2><p>Skeptics often dismiss UX investment as vanity in price-sensitive markets. Why spend money on pretty interfaces when customers just want basic functionality? This framing misses the strategic value of polish in low-trust environments.</p><p><strong>First, Breaking baselines creates talkability.</strong> Excellence surprises people into sharing stories, reducing marketing costs.</p><p><strong>Second, Small signals substitute for missing trust institutions.</strong> Respectful service, clean copy, neat packaging become proxies for reliability.</p><p><strong>Third, Quality compounds.</strong> Consistency builds reputational assets competitors struggle to match. Customers stick, recommend, forgive mistakes.</p><p><strong>Fourth, Polish signals legitimacy externally.</strong> Investors and partners read the same signals as competence.</p><p>This is why NPS feels hollow here&#8212;it&#8217;s gamed, mismatched, and often ignored. The real promoter score is what customers say unprompted, and that&#8217;s always driven by quality.</p><h2>What Overlooked Markets Teach the World</h2><p>Every market is becoming more like Lagos&#8212;skeptical, choice-rich, low-trust. </p><p>The lesson: don&#8217;t treat polish as luxury; treat it as growth infrastructure. Because in markets where every transaction is a trust test, quality isn&#8217;t just about better products&#8212;it&#8217;s about better relationships. And in the end, relationships are what scale.</p><p></p>]]></content:encoded></item><item><title><![CDATA[The Capability Is Not the Company]]></title><description><![CDATA[Selling Technology When the Market Isn't Buying It]]></description><link>https://adia.substack.com/p/the-capability-is-not-the-company</link><guid isPermaLink="false">https://adia.substack.com/p/the-capability-is-not-the-company</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Fri, 22 Aug 2025 10:47:19 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/9f20f4cb-d2ab-456f-b012-d9902561fe35_1186x868.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="native-audio-embed" data-component-name="AudioPlaceholder" data-attrs="{&quot;label&quot;:null,&quot;mediaUploadId&quot;:&quot;2c9a4ca3-570a-4b21-8ab4-5bdd016453cc&quot;,&quot;duration&quot;:555.1282,&quot;downloadable&quot;:false,&quot;isEditorNode&quot;:true}"></div><p><em>AI-generated podcast of the article&#8230;.</em></p><div><hr></div><p>You built the engine. Not a knockoff or MVP&#8212;an actual engine. Fast, clean, modular. A thing of beauty. It handled millions of transactions, parsed invisible signals, translated noise into insight. It was the kind of infrastructure other startups wish they had under the hood. And yet, no one cared. Not really. Not the way you needed them to. In meeting after meeting, you explained what your technology could do. Real-time scoring. Seamless integrations. Invisible infrastructure that makes credit underwriting smarter, cheaper, faster. But the questions were always the same: "Can I give someone a loan with this algo today?" &#8220;So it&#8217;s not a wallet. It&#8217;s the thing behind a wallet?&#8221; &#8220;Does it give me a diagnosis, or just raw genetic data?&#8221; "So I have to build the rest myself?"</p><p>Each question chipped away at the fantasy that building capability was enough. Because here, in this market, it often isn't. In the U.S., that same engine&#8212;possibly less elegant&#8212;would get funded off the deck. There, the story is the company. Here, the story is the outcome. What they see is what they buy. And what they buy is not potential. It's proof.</p><p>In emerging markets, engine businesses stall not because they aren't valuable, but because value has to arrive prepackaged, pre-proven, and pre-translated into something someone can use right now. Selling infrastructure in a market that lacks infrastructure means you end up having to build everything yourself anyway. </p><p>That&#8217;s why the companies that scale here often look full-stack, even if they didn&#8217;t set out to be. The capability may be your edge, but the market won&#8217;t reward it until it&#8217;s wrapped in something they can touch, trust, and transact with. You don't earn the right to sell the engine until you've given them the ride.</p><p>Emerging market customers prefer solved problems to abstract tools. They want the loan, not the score. The water, not the purification tech. The ride, not the routing algorithm. When people are used to solving problems manually, every new tool has to outperform the human workaround. If your engine demands imagination, configuration, or translation&#8212;it's already too far from the finish line.</p><p>Engine businesses also assume a broader ecosystem to plug into: identity verification APIs, digital payment rails, enforcement mechanisms, a culture of software abstraction. But in many emerging markets, these layers don&#8217;t exist, or if they do, they&#8217;re unreliable. So an engine that needs a chassis, wheels, road, and fuel becomes a burden, not an asset. Suddenly, you're not selling your product&#8212;you're selling the cost and complexity of building an entire company around it. And most operators, even the ones who believe in you, are too busy keeping their own plates spinning to sign up for that kind of lift.</p><p></p><h3><strong>Stripe vs. Paystack: Who&#8217;s the Engine, Who&#8217;s the Car?</strong></h3><div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="/__u/substackcdn.com/image/fetch/$s_!rckk!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="/__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_424, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 424w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_848, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 848w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_1272, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 1272w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_1456, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_webp, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 1456w" sizes="100vw"><img src="/__u/substackcdn.com/image/fetch/$s_!rckk!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png" width="1100" height="962" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/58c05079-975a-454b-937f-f3392d79c496_1100x962.png&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:962,&quot;width&quot;:1100,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:222507,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:&quot;image/png&quot;,&quot;href&quot;:null,&quot;belowTheFold&quot;:true,&quot;topImage&quot;:false,&quot;internalRedirect&quot;:&quot;https://adia.substack.com/i/170253798?img=https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png&quot;,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="/__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_424, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 424w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_848, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 848w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_1272, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 1272w, /__u/substackcdn.com/image/fetch/$s_!rckk!, /__u/adia.substack.com/w_1456, /__u/adia.substack.com/c_limit, /__u/adia.substack.com/f_auto, /__u/adia.substack.com/q_auto:good, /__u/adia.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c05079-975a-454b-937f-f3392d79c496_1100x962.png 1456w" sizes="100vw" loading="lazy"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg aria-hidden="true" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><p></p><p>The other friction point is emotional. When your value is abstract, you ask people to trust what they can't see. But in markets where trust is hard-won and quickly lost, tangibility becomes a proxy for credibility. Car businesses let users experience the outcome before understanding the technology. Engine businesses ask for belief before delivering results. And belief&#8212;especially here&#8212;doesn't come cheap.</p><p>Even the act of buying differs. In Silicon Valley, you might pitch to a head of innovation who has a budget and a backlog. In Accra, you're pitching to someone who is CEO, COO, and customer support all in one. They're stretched, stressed, and skeptical. They need the thing that works now, not the thing that could work later. Car businesses collapse the surface area of decision-making. Engine businesses expand it. That's the difference between "let's try it" and "we'll get back to you."</p><p>This doesn't mean engine businesses can't succeed here. But they must disguise themselves as cars first. They have to show up as complete, usable, beneficial&#8212;even if what you're really doing is gathering data, refining algorithms, or building modular rails underneath. You lead with the ride. You earn trust. And only then, once people start asking what's under the hood, do you show them the engine.</p><p>The paradox is this: in a market where selling technology feels impossible, the best technology companies often hide their tech. They don't start with the capability. They start with the result. And over time, as the market gets used to the outcome, the sophistication underneath becomes a selling point, not a stumbling block. The capability becomes visible. But only after it's already valuable.</p><p>So yes, build the engine. Make it brilliant. But don&#8217;t stop there. Because in markets like these, the capability is not the company. The company is what people believe, buy, and tell others about. And that usually starts with a car they can drive today.</p><p></p><p></p><p></p><p><em>Shout out to my friend JR, who always reminds me that I told him that &#8220;engines are not cars&#8221; and that I must tell everyone why. </em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/p/the-capability-is-not-the-company?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/p/the-capability-is-not-the-company?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p>]]></content:encoded></item><item><title><![CDATA[Tomorrow's Growth Starts with Today's Code]]></title><description><![CDATA[Why Some Companies Scale Effortlessly While Others Hit Walls]]></description><link>https://adia.substack.com/p/tomorrows-growth-starts-with-todays</link><guid isPermaLink="false">https://adia.substack.com/p/tomorrows-growth-starts-with-todays</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Sat, 02 Aug 2025 21:27:52 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/f5f918cd-17e4-4348-bf4c-05ed8134768c_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em>Here&#8217;s an AI-generated podcast on this article&#8230;</em></p><div class="native-audio-embed" data-component-name="AudioPlaceholder" data-attrs="{&quot;label&quot;:null,&quot;mediaUploadId&quot;:&quot;c60d8bdc-73af-49f3-bc30-fadfba4197de&quot;,&quot;duration&quot;:1126.6351,&quot;downloadable&quot;:false,&quot;isEditorNode&quot;:true}"></div><p></p><p>I've been the engineer, asked to "just make this change <em>quickly</em>" while silently calculating how many layers of engineering I'd have to untangle to make it work. And I've been the commercial lead, promising a new pricing plan to a partner, only to be told it would take "three sprints" because the code wasn't built to flex.</p><p>Those moments crystallize the fundamental tension between technical and commercial realities. They expose the cost of technical debt is not just in code, but hidden in the drag on commercial velocity. Having worn both hats, I've come to see that the friction between engineering and business isn't about personalities or priorities. Its from building businesses that are more rigid than the environments they serve.</p><p>Most companies build for today's feature set, not for tomorrow's growth or the inevitable change in conditions or behavior. They create their own handbrake - inflexible code that becomes the technical debt that slows them down precisely when speed matters most. Then, when scale comes knocking, they discover they&#8217;ve been driving with the handbrake on, wondering why growth feels so hard.</p><p>The question becomes: how do you build systems that accelerate instead of constrain?</p><p>The companies that scale fastest aren't the ones with the best initial product&#8212;they're the ones whose systems can pivot as quickly as their business strategy. These are the principles I've come to see as non-negotiable. They are as much about commercial flexibility as they are about clean engineering.</p><h2><strong>1. API-First Design: Making Every Feature a Building Block</strong></h2><p><strong>The Principle:</strong> Every core function should be designed as an API, even if it's initially for internal use.</p><p>At Migo, engineering built lending functions as APIs from day one. This meant we could integrate into ANY customer touch point without touching the core logic. What looked like over-engineering early on became our unfair advantage because it is still the only digital lender that borrowed over USSD, web, its own app, multiple partner apps&#8230;at one point we trialed presenting loans at ATMs.</p><p><strong>What this looks like in practice:</strong> Stripe's payment processing started as internal APIs, but this foundation let them become the infrastructure layer for thousands of companies. When you visit any e-commerce site from Shopify stores to enterprise platforms, you're likely interacting with Stripe's APIs without knowing it.</p><p>&#128161; <strong>Commercial friction removed:</strong> You don't have to tell your business team, "We'll need to rebuild this to connect to a partner." APIs make your features plug-and-play, ready for customers and partners you haven't even met yet.</p><p><strong>Impact:</strong></p><ul><li><p>Easy integrations with partners</p></li><li><p>Ability to swap out frontends (web, mobile, chatbot) without changing backend logic</p></li><li><p>Faster scaling into new products</p></li></ul><h2><strong>2. Feature Flags: The Emergency Brake That Saves Deals</strong></h2><p><strong>The Principle:</strong> Wrap every major new feature in a toggle, so you can turn it on&#8212;or off&#8212;without shipping new code.</p><p><strong>What this looks like in practice:</strong> Facebook (now Meta) famously uses feature flags for everything from UI changes to algorithm updates. When they test a new feed algorithm, they can expose it to 1% of users, monitor the impact, and either expand or kill it within hours&#8212;not weeks.</p><p>&#128161; <strong>Commercial friction removed:</strong> Sales teams can experiment without fear. You can say, "Let's test this pricing tier with 5% of users" and if it fails, no one's left cleaning up a mess.</p><p><strong>Impact:</strong></p><ul><li><p>A/B testing becomes standard practice</p></li><li><p>Gradual rollouts reduce risk</p></li><li><p>Instant "kill switch" for broken features</p></li></ul><h2><strong>3. Rules Engines: When Business Teams Stop Waiting for Engineering</strong></h2><p><strong>The Principle:</strong> Complex logic&#8212;pricing, eligibility, workflows, even site color schemes&#8212;should live in configurable rules engines, not buried in code.</p><p>In a way, this is the business-facing version of &#8220;Don&#8217;t Repeat Yourself.&#8221; Instead of embedding the same rules across multiple parts of the codebase and updating each one manually every time something changes (and risking the chance of breaking something), you centralize the logic in one place.</p><p><strong>What this looks like in practice:</strong> Amazon's pricing engine is legendary for this. During Prime Day, their business teams can adjust pricing rules, promotional logic, and inventory thresholds in real-time without a single developer touching code. The result? They can respond to competitor moves or inventory changes within minutes, not days.</p><p>&#128161; <strong>Commercial friction removed:</strong> The business side stops hearing "We'll put that in the next sprint." They can adjust policies and pricing instantly, without waiting for a developer.</p><p><strong>Impact:</strong></p><ul><li><p>Instant updates to criteria and logic</p></li><li><p>Different markets/regions can have their own rules without branching code</p></li><li><p>Business teams move at market speed, not development speed</p></li></ul><h2><strong>4. Schema-Driven Design: Building Forms That Adapt to Reality</strong></h2><p><strong>The Principle:</strong> Use metadata and schemas to define forms, tables, and data models rather than hardcoding them.</p><p><strong>What this looks like in practice:</strong> Salesforce built their entire empire on this principle. When a sales team needs to track a new customer attribute or add a field to their pipeline, they don't file a ticket with IT&#8212;they just add it through the interface. This configurability is why Salesforce can serve companies from 10-person startups to Fortune 500 enterprises with the same core platform.</p><p>&#128161; <strong>Commercial friction removed:</strong> Teams can adapt to market or regulatory changes in hours instead of weeks. You don't need to explain to a regulator that you can't add that new field they're requesting.</p><p><strong>Impact:</strong></p><ul><li><p>Dynamic UI forms that adapt to business needs</p></li><li><p>Flexible data models that grow with the business</p></li><li><p>Regulatory compliance becomes a configuration change, not a development project</p></li></ul><h2><strong>5. Event-Driven Architecture: Adding Features Without Breaking Everything</strong></h2><p><strong>The Principle:</strong> Design systems around events&#8212;"order_placed," "payment_received"&#8212;instead of tightly coupled workflows.</p><p><strong>What this looks like in practice:</strong> Uber's entire platform runs on events. When you request a ride, that single action triggers dozens of independent services: driver matching, price calculation, ETA estimation, notification systems. When they want to add a new feature, like carbon offset tracking, they just subscribe to existing "trip_completed" events. No rewiring the core ride system.</p><p>&#128161; <strong>Commercial friction removed:</strong> New features don't break old ones. You can say yes to "Can we add notifications?" without dreading the domino effect on the rest of the system.</p><p><strong>Impact:</strong></p><ul><li><p>Adding new automations becomes as simple as "listen for an event and act"</p></li><li><p>Different teams can build new features without breaking existing flows</p></li><li><p>Third-party integrations become plug-and-play</p></li></ul><h2><strong>6. Separation of Concerns: When Marketing Can Move Without Breaking Engineering</strong></h2><p><strong>The Principle:</strong> Keep user interface, business logic, and data access strictly separated.</p><p><strong>What this looks like in practice:</strong> Headless commerce platforms like Shopify Plus exemplify this. Brands like Allbirds and Gymshark can completely redesign their customer experience: new checkout flows, mobile apps, even voice commerce, while their inventory, pricing, and order processing logic remains unchanged. The result? Website redesigns that take weeks instead of months.</p><p>&#128161; <strong>Commercial friction removed:</strong> Marketing can change the user experience without derailing engineering. Engineering can refactor the backend without blocking a product launch.</p><p><strong>Impact:</strong></p><ul><li><p>Swappable frontends (new web app or mobile UI)</p></li><li><p>Backend logic reusable for future products</p></li><li><p>Marketing and engineering teams can work in parallel</p></li></ul><h2><strong>7. Domain-Driven Design: Speaking the Same Language</strong></h2><p><strong>The Principle:</strong> Structure your code around business concepts, not whatever is easiest to code at the moment.</p><p><strong>What this looks like in practice:</strong> Spotify's code is organized around music concepts that everyone understands: playlists, tracks, artists, users. When they discuss adding a new feature like "collaborative playlists," both engineers and product managers immediately understand what systems are involved. There's no translation layer between business requirements and technical implementation.</p><p>&#128161; <strong>Commercial friction removed:</strong> Commercial teams stop hearing "We can't do that because of how the code works." Everyone is literally speaking the same language.</p><h2><strong>8. Infrastructure as Code: Scaling Without Manual Bottlenecks</strong></h2><p><strong>The Principle:</strong> Define your servers, databases, and networks as code, version-controlled like everything else.</p><p><strong>What this looks like in practice:</strong> Netflix can spin up entire data centers programmatically. When they launch in a new country, they don't spend weeks manually configuring servers&#8212;they run code that provisions everything from content delivery networks to recommendation engines. This is how they expanded to 190+ countries without proportionally scaling their infrastructure team.</p><p>&#128161; <strong>Commercial friction removed:</strong> You can launch pilots, demos, or new markets without asking engineering for weeks of manual setup. Speed becomes default, not a miracle.</p><p><strong>Impact:</strong></p><ul><li><p>Faster setup of test/staging environments</p></li><li><p>Easy rollback if something breaks</p></li><li><p>New market launches become predictable, not heroic</p></li></ul><h2><strong>9. Modular Architecture: Teams That Don't Step on Each Other</strong></h2><p><strong>The Principle:</strong> Break systems into independent modules with clear boundaries.</p><p><strong>What this looks like in practice:</strong> Amazon's "two-pizza teams" philosophy extends to their technical architecture. Each service is owned by a small team that can deploy independently. When the Prime team wants to add a new benefit, they don't need to coordinate with the shopping cart team, the payment team, or the recommendation team. Each system talks to others through well-defined interfaces.</p><p>&#128161; <strong>Commercial friction removed:</strong> Different teams can move at different speeds. Sales can pitch new features without worrying that engineering will spend months untangling dependencies.</p><p><strong>Impact:</strong></p><ul><li><p>Business units (e.g., payments, notifications) can ship updates at their own pace</p></li><li><p>Reduced risk of changes breaking unrelated systems</p></li><li><p>Easier to scale teams without communication overhead</p></li></ul><h2><strong>10. Observability by Default: Knowing What Happened Before Anyone Asks</strong></h2><p><strong>The Principle:</strong> Build logging, monitoring, and audit trails from day one.</p><p><strong>What this looks like in practice:</strong> Datadog built their entire business on this principle, but the best example might be how they use it internally. When a customer reports an issue, their support team can trace exactly what happened across dozens of services, down to individual database queries. They often resolve issues before customers even finish explaining the problem.</p><p>&#128161; <strong>Commercial friction removed:</strong> No more "we're investigating" calls to partners. You know what happened, when it happened, and who did it&#8230;..because the system tells you.</p><p><strong>Impact:</strong></p><ul><li><p>Safer, faster iteration because you can see exactly what changed and why</p></li><li><p>Regulatory compliance becomes automatic documentation</p></li><li><p>Customer support transforms from guessing to knowing</p></li></ul><h2><strong>Why This Matters: The Real Cost of Technical Shortcuts</strong></h2><p>These technical preferences are the difference between systems that flex with growth and systems that break under it.</p><p>The companies that scale fastest didn't get there with better initial products. They got there with systems that could evolve as fast as their opportunities. When a partnership opportunity emerges, they can integrate in days, not months. When market conditions change, they can adapt pricing and features in hours, not quarters.</p><p>The businesses that struggle aren't failing because they lack vision or market opportunity. They're failing because their systems can't bend without breaking.</p><p>Scale isn't just a sales problem, it's an engineering philosophy problem too.  The best CEOs, CCOs and CTOs need to really get this.  </p><p>If you want to build for true scale, start with code that can bend without breaking. Because when growth comes (and it always comes faster than you expect) you might not get a second chance to catch up.</p><p>For the builders who get this&#8212;who design with APIs, events, and flexibility from day one&#8212;the real magic happens when these systems start talking to each other. That's where individual features become platforms, and platforms become ecosystems.</p>]]></content:encoded></item><item><title><![CDATA[Price Sensitivity Is a Lazy Diagnosis]]></title><description><![CDATA[Why Misreading Constraint Leads to Missed Growth]]></description><link>https://adia.substack.com/p/price-sensitivity-is-a-lazy-diagnosis</link><guid isPermaLink="false">https://adia.substack.com/p/price-sensitivity-is-a-lazy-diagnosis</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Sat, 10 May 2025 05:54:11 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/1b6e2c87-226d-471b-b41b-361498ed5eb5_1024x768.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>A woman walks into a mobile store in Ibadan and asks how much it costs to stream music. The attendant says it&#8217;s free with the app. She asks again: &#8220;No, how much data will it take?&#8221; She&#8217;s not being difficult. She&#8217;s doing math. A kind of math most product teams never see. Because they&#8217;ve already written her off as price-sensitive.</p><p>That label gets thrown around so easily&#8212;by founders, investors, and product managers alike&#8212;that it&#8217;s come to mean almost nothing. It flattens users into caricatures: people who always want things cheap, who flinch at the sight of a price tag, who churn because they just don&#8217;t want to pay. But that&#8217;s not what&#8217;s happening. Not in Lagos. Not in Nairobi. Not in Medell&#237;n or Dhaka or Soweto. And certainly not inside the minds of the users we keep misreading.</p><p>Price sensitivity is a lazy diagnosis. It misdiagnoses constraint as disinterest. It treats caution as cheapness. And it&#8217;s the fastest way to build the wrong product, price it poorly, and blame the user when they opt out.</p><p>When we say a user is price-sensitive, what we often mean is that they&#8217;re cost-conscious&#8212;but not in the coupon-clipping way Silicon Valley imagines. These users are strategic. They&#8217;re stacking resources like a game of Tetris. Airtime, cash, battery, trust&#8212;they don&#8217;t get to optimize for convenience. They optimize for survivability. It&#8217;s not that they won&#8217;t pay. It&#8217;s that they pay differently. They scan for risk, not just value.</p><p>They&#8217;re not alone.</p><p>A street vendor in Ghana who rents housing weekly, despite the markup. A mother in Kano who chooses sachet milk over bulk, even though it costs more per litre. A student in Kenya who prefers pay-as-you-go courses to university tuition. Each one has been misread by a designer convinced their reluctance is irrational, when in fact it&#8217;s just unfamiliar.</p><p>This is the <strong>UX tax of constraint</strong>&#8212;an invisible mental load carried by users who can&#8217;t afford ambiguity. They don&#8217;t just swipe and go. They hesitate, calculate, protect. They download when data is free. They listen offline to stretch a bundle. They wait for the evening to transact, because that&#8217;s when the network&#8217;s faster. Every click, a decision. Every interaction, a tradeoff. What looks like a simple choice&#8212;pay or don&#8217;t&#8212;is actually a complex equation shaped by income volatility, trust gaps, and fear of being burned.</p><p>So no, they&#8217;re not &#8220;price-sensitive.&#8221; They&#8217;re:</p><ul><li><p><strong>Cost-conscious</strong>, because every naira has a job.</p></li><li><p><strong>Surprise-averse</strong>, because fine print has burned them before.</p></li><li><p><strong>Predictability-seeking</strong>, because chaos is expensive.</p></li><li><p><strong>Resource-optimizing</strong>, because they juggle five constraints while we design for one.</p></li></ul><p>And here&#8217;s what changes when we get the diagnosis right:</p><p><strong>Cost-Conscious &#8800; Cheap. It means Strategic.</strong></p><p>So design for <strong>Configurability.</strong></p><p>Let them assemble their own value stack. Sliding-scale plans. Pause-and-resume billing. Mini-offers. A $0.50 micro-bundle might earn more trust than a $5 all-you-can-eat.</p><blockquote><p>Don&#8217;t bundle everything and assume they&#8217;ll bite. Let them build the bundle.</p></blockquote><div><hr></div><p><strong>Surprise-Averse &#8800; Unpredictable. It means Scarred.</strong></p><p>So design for <strong>Transparency.</strong></p><p>Show what&#8217;s billable. Offer clear renewal terms. Let users cap their spend. Kill dark patterns in favor of visible control.</p><blockquote><p>They&#8217;re not scared of the price. They&#8217;re scared of the aftermath.</p></blockquote><div><hr></div><p><strong>Predictability-Seeking &#8800; Rigid. It means Responsible.</strong></p><p>So design for <strong>Steady Rhythms.</strong></p><p>Daily billing. Weekly plans. Time-boxed access. Airtime-mode equivalents. Price that feels familiar, not forced.</p><blockquote><p>Every predictable unit you offer is a microdose of trust.</p></blockquote><div><hr></div><p><strong>Resource-Optimizing &#8800; Scattered. It means Systemic.</strong></p><p>So design for <strong>Cross-resource thinking.</strong></p><p>Support low-data modes. Allow downloads over Wi-Fi. Reward off-peak use. Acknowledge their hustle, don&#8217;t penalize it.</p><blockquote><p>They&#8217;re not gaming your system. They&#8217;re surviving theirs.</p></blockquote><div><hr></div><p>When you stop mislabeling, you start seeing. The mother who doesn&#8217;t subscribe isn&#8217;t rejecting your product&#8212;she&#8217;s rejecting your assumption. The vendor who downloads but won&#8217;t stream isn&#8217;t lost. He&#8217;s telling you how he lives. These aren&#8217;t failures to convert. They&#8217;re signals waiting to be read.</p><p>The cost of getting it wrong isn&#8217;t just churn. It&#8217;s missed markets, wasted CAC, and entire segments left unserved&#8212;not because they weren&#8217;t interested, but because we never took the time to understand how they decide.</p><p>A user who hesitates is not a user to dismiss. A user who optimizes is not a user to pity. These are users with tight constraint logic, not loose change. And when we meet them there&#8212;not with pity, but with precision&#8212;we design products that don&#8217;t just scale. They stick.</p>]]></content:encoded></item><item><title><![CDATA[Gardens, Gravity, and Gods]]></title><description><![CDATA[An Operator's Notes on Corporate Culture]]></description><link>https://adia.substack.com/p/gardens-gravity-and-gods</link><guid isPermaLink="false">https://adia.substack.com/p/gardens-gravity-and-gods</guid><dc:creator><![CDATA[Adia Sowho]]></dc:creator><pubDate>Sat, 26 Apr 2025 05:08:13 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/258ec477-08e2-4e6e-bce5-67e23cb2aea5_1920x1080.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p></p><div class="native-audio-embed" data-component-name="AudioPlaceholder" data-attrs="{&quot;label&quot;:null,&quot;mediaUploadId&quot;:&quot;4e331553-de27-48a4-9575-e9623738e31f&quot;,&quot;duration&quot;:1024.0784,&quot;downloadable&quot;:false,&quot;isEditorNode&quot;:true}"></div><p><br><em>Hi friends, with this article I&#8217;m trying something new and including an article voiceover as well as a companion &#8216;podcast&#8217; to this article for those who may want an alternative take to the written word. Let me know what you think in the comments.  </em><br></p><div><hr></div><p>Culture shapes companies like gravity shapes planets - invisibly but inescapably. You don&#8217;t feel it until your path is locked. Once you&#8217;re in orbit, it&#8217;s hard to course-correct. That&#8217;s why culture can&#8217;t be a vibe. It has to be a system. Left unspoken, it still pulls&#8212;just not always in the direction you want to go. The only way to change its force is to first understand it.</p><p>As entrepreneurship booms and founders build their own corporate 'nations', we've exhausted ourselves talking about what culture <em>should</em> be, neglecting the practical mechanics of how to build it well. </p><p>Culture forms&#8212;whether you design it or not. And once it takes shape, it pulls every decision, every interaction, every new hire into its orbit. That&#8217;s why naming culture matters. Not to make it pretty. But to make it legible&#8212;and therefore shapeable. What you can&#8217;t describe, you can&#8217;t redirect.</p><p>I&#8217;m not here to define the perfect culture, or hand out a toolkit. This isn&#8217;t a how-to. It&#8217;s a field guide. A reflection on what I&#8217;ve seen, what holds up under pressure, and what patterns emerge when companies grow faster than their culture can evolve. These are notes - just notes - from inside the system&#8212;shared not to prescribe, but to reveal. <em>They&#8217;re not sequenced for symmetry&#8212;just held together by the thread of lived experience.</em></p><p>Culture can be hard to define&#8212;but unmistakable when felt. For me, the work of articulating it isn&#8217;t academic; it&#8217;s practical. You can&#8217;t build what you can&#8217;t describe. As a builder, I&#8217;ve learned that the act of naming culture sharpens how we shape it&#8212;and that shaping it well is the rarest kind of competitive advantage.</p><p>In all, I&#8217;ve learned that culture cannot be copied. True culture is grown from experience, not installed. It must be tended to and not strangled. It may begin with a founder&#8217;s/leader&#8217;s intent, but it doesn't stay theirs for long.</p><p>Here&#8217;s where culture starts to show itself&#8212;quietly, and often in contradiction to what&#8217;s been written down.</p><p><strong>On Recognition and Reality</strong></p><p>Ask someone about their company's culture and you'll likely hear "integrity," "family," or "innovation" recited like a memorized prayer - in many cases unsuccessfully. But culture isn't in the saying - it's in the doing. It's in how teams handle missed deadlines, how they celebrate wins, how they navigate disagreements.</p><p>Culture manifests in three layers. First, there&#8217;s the surface&#8212;what companies say, from mission statements to values posters. Then comes the system&#8212;what actually gets measured, rewarded, or promoted. Beneath both lies the subconscious&#8212;the often-unspoken beliefs and instincts that drive decisions in crucial moments. Most culture work fails in the gap between these layers: when what&#8217;s said diverges from what&#8217;s done, and when what&#8217;s done isn&#8217;t what actually matters.</p><p>That the culture could not be &#8216;retained and recited, does not mean that it doesn't exist. Culture exists whether intentionally shaped or not. The question is never whether a culture exists, but whether the culture that people&#8217;s daily actions nurture is the one your organization needs.</p><p>Culture reveals itself most clearly in moments of tension. The clash between stated values and actual decisions illuminates true culture more clearly than any handbook.</p><p>Organizations often mistake artifacts for culture &#8211; the carefully crafted values statements, the office design, the onboarding documents. But culture lives in practice, in the small moments of choice. It's whether people actually use those meeting rooms as intended, whether the values are invoked in difficult decisions, whether the shortcuts people take align with or undermine the stated ideals.</p><p>The most telling cultural moments often come at 6 PM: Who stays? Who goes? Who apologizes for leaving? Who quietly judges? These unspoken patterns reveal the most truth. In fact, the more a company writes down its culture, the more it risks fossilizing it. Yet without documentation, culture becomes purely interpretive.</p><p></p><p><strong>On Time and Revelation</strong></p><p>Culture reveals itself in layers. The first month shows you the surface &#8211; the rituals, the tools, the obvious patterns. The second month reveals the tensions &#8211; where the ideal and real diverge. But it's the third month when you start to see the deep structure &#8211; the underlying assumptions that drive decisions.</p><p>This layered revelation explains why quick cultural fixes almost always fail. You can't change what you haven't yet seen, and you can't see it all at once.</p><p></p><p><strong>On Time and Transformation</strong></p><p>Early-stage companies have a unique opportunity to shape culture intentionally, but this window closes faster than most founders realize. By the time you hit say, 50 employees - as the common adage goes - cultural patterns have already begun to calcify. You can only fine-tune culture from this point onwards.</p><p>There's something almost religious about how culture operates in the strongest companies. They have their creation myths (origin stories), rituals (all-hands meetings), sacred texts (founding documents), prophets (veteran employees who "get it"), and heresies (behaviors that violate core values). The difference between vibrant and stagnant cultures often lies in whether they treat these elements as doctrine or dialogue.</p><p>As companies mature, culture evolves at different speeds across an organization. Engineering may still move with startup speed while Finance operates like an enterprise. This tension, though uncomfortable, drives necessary conversations about which cultural elements to preserve and which to evolve.</p><p>The best cultures don&#8217;t feel engineered&#8212;they feel inevitable. But that &#8220;inevitability&#8221; is a trick of memory. It&#8217;s what happens when small decisions compound, when habits turn into defaults, and when people stop needing to explain how things work because they just do. Ease is never accidental, it is earned. It&#8217;s the product of hundreds of shared choices, micro-adjustments, unspoken agreements&#8212;repeated until they become instinct. What feels natural is almost always the result of something deeply intentional.</p><p></p><p><strong>On Rebels and Rebellion</strong></p><p>The relationship between companies and their rebels traces a familiar arc: courtship, conflict, and often, rejection. Companies eagerly recruit for &#8220;entrepreneurial spirit&#8221; and &#8220;innovative thinking,&#8221; only to later treat those same qualities like organizational antibodies&#8212;labeling them as threats, isolating them, and ultimately pushing them out.</p><p>Some organizations develop a peculiar taste for what might be called decorative disruption. They love hiring rebels as the face of change&#8212;so long as they stay cute and contained. They want the edge without the risk. The cool hair, not the hard questions. These are the companies that want to appear bold while keeping the core untouched. In time, the rebel either becomes part of the aesthetic, part of the problem, or a misfit solution that never quite sticks.</p><p>Culture behaves like an immune system - it helps organizations recognize and reject threats to their essential character. But like an immune system, it can become either too weak (unable to maintain coherence) or too strong (rejecting necessary change). When a startup veteran joins a large corporation promising to "shake things up." Initially celebrated, they often end up isolated or exited, labeled as "not a culture fit" - a diagnosis that says more about the organization's autoimmune response than the individual's capability.</p><p>The best rebels aren't trying to burn the house down; they're trying to renovate it. But renovation makes noise, creates mess, and requires temporary discomfort - three things that organizations often resist even when they know change is necessary.</p><p>The tragedy plays out predictably: Companies hire for transformation but reward conformity. They celebrate challenging the status quo in theory but punish it in practice. The very qualities that make rebels valuable - their fresh perspectives, their willingness to question assumptions, their hunger for improvement - become listed as development areas in their performance reviews.</p><p>Wise organizations learn to look where rebels point rather than shooting the messenger.</p><p></p><p><strong>On Cultural Debt and Equity</strong></p><p>Like technical debt, <em>cultural debt</em> accumulates in small compromises. A missed one-on-one here, an overlooked value violation there. And just like technical debt, it compounds with interest - small cultural compromises grow into major dysfunctions over time. The startup that overlooks aggressive behavior from a high performer soon finds that aggression normalized across teams.</p><p><em>Cultural equity</em>, by contrast, builds through consistent deposits: the hard conversation had at the right moment, the principle upheld despite pressure, the time invested in proper onboarding despite urgent deadlines. These investments compound too, creating resilience that becomes invaluable during a crisis.</p><p>This tension between debt and equity plays out most visibly as companies scale. Each new process introduced to handle growth creates both possibility and peril. The casual "got a minute?" that once solved problems becomes a scheduled sync. The quick product iteration becomes a structured release cycle. And before you know it, the team is rallying against this as &#8216;bureaucracy&#8217;. But process is necessary for scale, therefore each formalization must be treated as a cultural investment, not just an operational necessity. A good process should amplify good culture, not replace it. Think of it like writing down a family recipe: The goal isn't to replace the chef's intuition but to make their wisdom accessible to others.</p><p>The art lies in knowing which cultural elements to systematize and which to let breathe.</p><p></p><p><strong>On Language and Power</strong></p><p>Corporate language carries hidden currents that shape behavior more than any official policy. &#8220;Strong leadership" often describes traditionally masculine behaviors, which when embodied by a female, can create unpredictable challenges. "Let's take this offline" can mean anything from "good idea, let's discuss" to "never mention this again." The fluent readers of these subtexts often gain unofficial power that no org chart captures.</p><p>Those who naturally fit the dominant culture often don't recognize it as a privilege. Like fish not seeing water, they experience corporate culture as neutral rather than as a specific cultural construct. Newer employees who are yet to or cannot fit in, may pay a constant "cultural tax" - the extra energy spent code-switching, translating their natural work style into the dominant cultural language. Like any tax, this reduces their available energy for actual work.</p><p>Meetings are a revelation here. Listen carefully - not for what's said, but for what phrases cause people to shift in their seats. Also, watch how bad news travels upward, how mistakes are discussed, how newcomers' ideas are received. </p><p></p><p><strong>On Cultural Translation</strong></p><p>Some people develop an almost supernatural ability to code-switch between organizational dialects. I certainly don&#8217;t. They understand that "move fast and break things" means something entirely different at a startup versus a mature company, even when the words are identical. This translation skill becomes increasingly valuable as careers become more fluid, global, and unpredictable.</p><p>Practical markers of strong cultural translation:</p><ul><li><p>The ability to predict unwritten meeting norms</p></li><li><p>Understanding when to push and when to wait</p></li><li><p>Knowing which victories to celebrate and which to downplay</p></li><li><p>Recognizing the difference between stated and actual decision paths</p><p></p></li></ul><p>Cultural literacy can't be rushed, especially for those looking to understand an organization before joining. It develops through attention, through countless small observations and adjustments. So, inquiries cannot be shallow and insights have to come from the right culture custodian so you can get an accurate picture. In the end, it's not about finding the "right" culture, but about understanding the nuances of different cultural ecosystems and how to move thoughtfully between them.<br></p><p><strong>In the End, a Garden.</strong></p><p>Perhaps the most telling aspect of any culture is what people feel they need permission for. The distance between what's technically allowed and what feels permissible marks the gap between official and actual culture. Some organizations require permission for sending all-staff emails; in others, junior employees regularly challenge CEO decisions in public forums. Neither approach is inherently right, but the difference matters enormously in practice.</p><p>Culture, like a garden, doesn&#8217;t shout when it&#8217;s thriving. But you feel it. In the ease of decisions. In the absence of fear. In the way people show up when they don&#8217;t have to.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://adia.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/adia.substack.com/subscribe"><span>Subscribe now</span></a></p><p></p><p><em>A special shout-out to my gang from WOP XIII - </em><span class="mention-wrap" data-attrs="{&quot;name&quot;:&quot;CansaFis Foote&quot;,&quot;id&quot;:29379686,&quot;type&quot;:&quot;user&quot;,&quot;url&quot;:null,&quot;photo_url&quot;:&quot;https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff2cac8a8-ec2b-4cb3-b874-78839f0eaee9_225x225.jpeg&quot;,&quot;uuid&quot;:&quot;7e7b55a3-8259-4603-98c0-f9d46bafde40&quot;}" data-component-name="MentionToDOM"></span> <span class="mention-wrap" data-attrs="{&quot;name&quot;:&quot;Sandhya Domah&quot;,&quot;id&quot;:2834626,&quot;type&quot;:&quot;user&quot;,&quot;url&quot;:null,&quot;photo_url&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/02da9698-1091-4b3d-80f4-7bce8c9acaec_1080x1080.jpeg&quot;,&quot;uuid&quot;:&quot;86713563-8d80-4681-a837-39c10d9cb0fe&quot;}" data-component-name="MentionToDOM"></span> <span class="mention-wrap" data-attrs="{&quot;name&quot;:&quot;Anna Reich&quot;,&quot;id&quot;:96126697,&quot;type&quot;:&quot;user&quot;,&quot;url&quot;:null,&quot;photo_url&quot;:&quot;https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9705eea5-eabb-450d-891b-016c96d4be92_2300x2300.jpeg&quot;,&quot;uuid&quot;:&quot;60a4d4bf-3194-46a0-9ca0-29824e8b1341&quot;}" data-component-name="MentionToDOM"></span>, <span class="mention-wrap" data-attrs="{&quot;name&quot;:&quot;Deborah Ineye Olaniyan&quot;,&quot;id&quot;:143865202,&quot;type&quot;:&quot;user&quot;,&quot;url&quot;:null,&quot;photo_url&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/2e704d6a-4d56-40ff-88a7-914180b847c0_930x930.jpeg&quot;,&quot;uuid&quot;:&quot;122248e2-d033-4e5e-9d32-d1767f3f0a0d&quot;}" data-component-name="MentionToDOM"></span> and <span class="mention-wrap" data-attrs="{&quot;name&quot;:&quot;Mary Elzey&quot;,&quot;id&quot;:27468642,&quot;type&quot;:&quot;user&quot;,&quot;url&quot;:null,&quot;photo_url&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/fb581eb4-2d14-4e0d-907f-5753a0cff589_3361x3361.jpeg&quot;,&quot;uuid&quot;:&quot;db5e86f9-7e63-4740-bc69-218e3e0cde26&quot;}" data-component-name="MentionToDOM"></span> for reading early drafts of this essay &#129303;</p>]]></content:encoded></item></channel></rss>