DEV Community: Issam Fathi

Plan your roadmap the way an attacker plans an intrusion

Issam Fathi — Fri, 28 Aug 2026 08:17:02 +0000

I spend time on the security side of technology as well as the product side. For a long time I kept those two halves of my thinking separate, because they felt like different disciplines with different temperaments.

They are not. Offensive security is a planning discipline, and it is a considerably more rigorous one than most product planning I have seen. The people who are good at it have habits that would improve almost any roadmap.

Here are the four that changed how I plan.

One. Start from the objective, then work backwards through what must be true

An attacker does not begin with a list of things they could try. They begin with an objective, and then they work backwards: to reach that, I need this; to get this, I need that.

Product roadmaps almost never work this way. They are usually forward looking lists of things the team could build, sorted by some blend of effort, enthusiasm and whoever asked most recently. The connection between any given item and an actual outcome is asserted rather than traced.

Working backwards is uncomfortable because it exposes items that connect to nothing. Take your roadmap, name the outcome you are actually chasing, and draw the chain from each item to that outcome. In my experience a third of the list has no chain at all. Those items are not necessarily wrong, but you should know they are there for another reason, and you should be able to say what that reason is.

Two. Find the path of least resistance, not the impressive one

Attackers are lazy in a disciplined way. They do not look for the most elegant route. They look for the cheapest one that works, and it is very often unglamorous. A forgotten account. A misconfiguration. A person who will hold a door.

Product teams have the opposite instinct. Given a goal, we gravitate toward the substantial build, partly because substantial builds are more satisfying and easier to justify as work.

The discipline is to ask, every time: what is the cheapest thing that would achieve this outcome, including things that are not software at all? A manual process. A partnership. A change to the pricing page. A conversation. If the honest answer is that a week of unglamorous work gets you most of the outcome, the six month build needs to justify the difference, and often it cannot.

Three. Assume you will be wrong and plan the blast radius

Assume breach is the phrase in security. The mature position is not that defences will hold, but that some of them will fail, so the real work is limiting what a failure reaches.

Product planning almost never does this. Plans are built on the assumption that the bets are right. The occasional risk register is a list of things that might go wrong with no structural consequence for how the work is sequenced.

Planning blast radius means asking, for each significant bet: if this is wrong, what else falls over? Sometimes the answer is nothing, and you can move fast. Sometimes a single assumption sits underneath four quarters of work, and discovering that after two quarters is expensive.

This changes sequencing in a specific way. You do the thing that tests the load bearing assumption first, even when it is not the most valuable item, because its purpose is to reduce how much depends on being right.

Four. The map is not the territory, so go and look

The single most consistent finding in offensive work is that the documented environment and the real one differ. There is always a system nobody mentioned, an old integration still running, a process people abandoned but never removed.

Product roadmaps are built on documented environments too. On how the workflow is supposed to work, what the support tickets say, what the customer described in a call.

The habit worth stealing is verification by observation. Not asking people what they do. Watching what they do. Every time I have done this properly I have found something that changed the plan, and it is usually not subtle. People describe their idealised process and then work around it constantly, and the workaround is where the real product opportunity lives.

Where the analogy stops

I want to be careful, because pushing this too far produces something unpleasant.

Attackers have one objective and no obligation to the system they are entering. Product teams have many objectives, and an obligation to the people they build for. A roadmap planned with purely adversarial logic tends to produce short term extraction: the cheapest path to a metric, which is very often a path that makes the product worse.

The transferable part is the rigour, not the ethics. Work backwards from an objective. Prefer the cheap route. Assume you are wrong somewhere and limit the damage. Verify reality rather than trusting the diagram.

The part that must not transfer is indifference to the outcome for everyone else. The whole reason the discipline is worth borrowing is to build something that holds up, and something that holds up has to be worth having in the first place.

One exercise

If you take one thing from this, take this exercise. It takes an hour.

Take your current roadmap and, for each item, write the sentence: we are building this because we believe X. Then, for each X, write down what would have to happen for you to discover you were wrong, and how long that would take.

Anything where the answer is longer than a quarter is a load bearing assumption you cannot currently test. Those are the items that should move to the front, not because they deliver the most value, but because they cost the most to be wrong about.

That is the whole method, really. Not paranoia. Just refusing to let an untested belief sit underneath a year of work.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Why the physical world still runs on paper, and why that is rational

Issam Fathi — Wed, 26 Aug 2026 08:17:02 +0000

There is a particular tone software people use when they encounter paper in a real industry. Slightly amused, slightly appalled. Still using clipboards. Still faxing. Still keeping a binder.

I used that tone myself once. Then I spent enough time in property and in building maintenance to notice that the people using paper were not confused about the existence of computers. They had made a choice, and when I finally asked why properly, the answers were better than my assumptions.

If you want to digitise a physical industry, you should understand what paper is doing for it first. Otherwise you will remove something load bearing.

What paper is genuinely good at

It has no dependencies. A form works in a basement, on a roof, in rain, at minus five degrees, with no signal and a dead battery. Every digital alternative carries a chain of dependencies, and the chain breaks at exactly the moment the work is hardest. The people who chose paper have watched a tablet fail on a cold morning and lost a day. You have not.

It is trivially interoperable. Anyone can read it. No account, no licence, no version. When six trades, an owner, a surveyor and an insurer all need to see the same thing, a document that requires no onboarding has an enormous advantage over one that requires seven.

It does not update. This sounds like a weakness and in evidence terms it is a strength. A signed page is fixed at a moment in time. A database row is current, which means it has quietly lost its own history unless someone deliberately built versioning. For anything that might be examined later, immutability is the point.

It carries authority. A signature on paper means something legally and socially that a checkbox has spent thirty years trying to replicate. This is cultural rather than technical, and culture is not a bug you can patch.

Its failure mode is visible. A wet, torn, illegible form is obviously damaged. Corrupted data looks exactly like good data until the moment you rely on it. People who work in high consequence environments have a strong preference for failures that announce themselves.

That is not nostalgia. That is a list of engineering properties, and any replacement has to match most of them.

The real reasons digitisation stalls

When a digital system fails to take hold in a physical industry, the reason is almost never that people are resistant to change. In my experience it is one of four things.

It added a step instead of replacing one. The classic pattern: the crew now fills the form and enters it into the system. The paper never went away because the system does not work where the work happens. Everyone learns that the digital layer is overhead, and they are right.

It moved the burden onto the person with the least incentive. Data entry usually lands on the operational staff, while the benefit lands with management, insurers, or head office. When capture is a chore performed for someone else's benefit, it gets done badly, and the resulting data is worse than the paper it replaced.

It did not survive the environment. Designed in an office, deployed on a roof. Gloves, glare, cold, height, no signal. Reality removes about half the interactions your design assumed.

It could not be handed over. Building work is done by rotating parties. If your system requires every subcontractor to have an account, you have built a system that stops at your organisational boundary, which is precisely where the information most needs to travel.

Every one of those is a design failure, not a user failure. Paper survives because it does not have them.

What actually replaces paper

The things I have seen succeed share a shape.

They capture at the moment of work with less effort than writing. Not slightly less. Obviously less, immediately, to the person doing it. A photograph beats a written description on effort and detail simultaneously, which is exactly why photographic evidence spread through inspection work without anyone running a change programme.

They work with no connection and reconcile later. Offline first is not a nice to have in the physical world. It is the whole requirement.

They produce something anyone can read without the system. This is the part software companies resist, because a readable exportable artefact feels like giving away leverage. It is the opposite. It is what lets your data cross the organisational boundaries where paper currently wins.

They preserve history rather than only current state. If a record cannot show what it said last year, it has lost the property that made paper trustworthy.

Match those four and paper goes away on its own, without a mandate. Miss them and no amount of training will hold.

The lesson beyond paper

I keep coming back to this because it generalises well past clipboards.

When a competent group of people persist with something that looks obsolete, the useful assumption is not that they are behind. It is that the old thing is doing a job you have not identified yet. Find the job before you remove the tool.

I have been on the wrong side of this. Early on I would have described paper based inspection as the problem to be solved. It was not. The problem was that the information died, either in a filing cabinet or in somebody's memory. Paper was not causing that. Paper was one of the few things partially preventing it.

The goal was never to get rid of paper. It was to make the record durable, portable, and comparable over time. Paper does the first of those quite well, the second surprisingly well, and the third not at all.

That third one is the actual opening, and it is a much more honest pitch than telling people their clipboard is embarrassing.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Procurement is where good technology goes to die

Issam Fathi — Mon, 24 Aug 2026 08:17:01 +0000

Every founder eventually has the same experience. You win the room. The people who will actually use the thing are enthusiastic, the demo went well, the problem is real and you clearly solve it.

Then the process starts, and nine months later a competitor you consider inferior has the contract.

The usual explanation is that the buyer was incompetent or the incumbent had relationships. Sometimes true. Mostly it is neither. Procurement selected exactly what it was designed to select, and it was never designed to select the best product.

Understanding what it is actually for is the difference between raging at it and winning inside it.

What procurement optimises for

A formal purchasing process exists to manage risk and to be defensible. Not to maximise value. Those goals overlap sometimes, and diverge often.

Defensibility is the key idea. Someone in that organisation must be able to explain, months or years later, possibly to an auditor, why this supplier was chosen. That explanation has to survive scrutiny by people who were not there and do not understand the domain.

Which means the decision must be reducible to criteria that can be written down and scored. Anything that cannot be reduced to a scoreable criterion effectively does not exist in the process, however important it is.

This single constraint explains most of what looks irrational from the outside.

Your product is more pleasant to use? Not scoreable, so it counts for little. Your support is genuinely better? Everyone claims that, so it collapses into a checkbox that all bidders tick. Your architecture will age better over five years? Requires judgement to evaluate, therefore risky to defend, therefore quietly discounted.

Meanwhile things that are trivially scoreable dominate. Years in business. Number of employees. Certifications held. Reference customers of a certain size. Whether a feature exists as a yes or no, regardless of whether it works well.

None of that is stupidity. It is a system built to produce defensible decisions, faithfully producing defensible decisions.

The three ways good products lose

They arrive after the requirements are written.

This is the big one and it is nearly fatal. By the time a formal document reaches you, the criteria are fixed, and they were shaped by conversations you were not part of, frequently with a supplier who was. If your differentiator is not in the criteria, you cannot score for it. You are being measured on someone else's definition of the problem.

The implication is uncomfortable for anyone who prefers building to selling: the decisive work happens months before the process is visible, in conversations that do not look like sales at all.

They optimise for the user and ignore the risk owner.

Enthusiastic users do not carry the decision. The person who carries it is whoever will be blamed if it fails, and that person is optimising to not be blamed. Their questions are about what happens when things go wrong, not about how good it is when things go right.

If your entire pitch is upside, you have given that person nothing to hold. Give them the failure modes, the exit path, the reference who will speak candidly. Make it safe to choose you.

They win the pilot and lose the standard.

A successful pilot proves your product works. It does not answer the question the organisation actually has, which is whether this can be supported, renewed, audited, and lived with by people who did not choose it. Teams celebrate the pilot and then lose on questions they never thought about, because they treated the pilot as the finish line rather than the qualifying round.

What actually works

I have sold in enough contexts to be sceptical of anyone with a system for this. But a few things reliably help.

Be present before the requirements exist. Not pitching. Being useful. If you help shape how an organisation understands its problem, the eventual criteria will reflect that understanding. This is slow and it does not fit a quarterly pipeline, which is exactly why it works, because most competitors will not do it.

Write the section they cannot write. Buying teams are often required to specify things they do not fully understand. A supplier who hands them clear, honest, vendor neutral language for a technical requirement is doing them a genuine favour, and that language tends to survive into the final document.

Make the risk answer easy. Whoever owns the risk needs one page they can forward. What happens if you go out of business. Where the data lives and how it comes back. Who is accountable when it breaks. Have that ready before it is requested.

Ask what the last supplier got wrong. The most informative question available, and almost nobody asks it. Every unusual clause in a procurement document is a scar. Understanding the injury tells you what the process is really protecting against, which is usually a specific bad experience nobody has written down.

The part I have made peace with

Some deals cannot be won and it has nothing to do with you.

The incumbent is embedded, the process exists to document a decision already taken, the budget is committed. Recognising these early is a commercial skill worth more than any technique, because the cost of losing is not the deal. It is the months.

I have learned to ask directly and to accept the answer when it comes. Who else is bidding, what would have to be true for us to win, and has anyone already done work on this. People will tell you far more often than you expect, and a fast honest no is worth considerably more than a slow maybe.

Procurement is not the enemy of good technology. It is indifferent to it, which is worse and much easier to plan around once you stop taking it personally.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Insurance is the quiet buyer behind most proptech decisions

Issam Fathi — Fri, 21 Aug 2026 08:17:02 +0000

If you want to understand why a technology gets adopted in the built environment, do not study the technology. Study who carries the risk.

I came to this slowly. Selling property, then building tools for building inspection, I kept noticing that the arguments which actually moved decisions were almost never about capability. They were about liability, cover, and what happens when something goes wrong. There is usually a party in the background who never appears in the sales process and yet shapes the entire decision.

That party is the insurer.

Why risk carriers drive adoption

Insurance is, at its core, a pricing function applied to uncertainty. An insurer takes on a possible future cost in exchange for a premium, and the premium reflects how uncertain that cost is.

The important word is uncertain, not high. Insurers price predictable risk perfectly well. What they charge heavily for, or refuse entirely, is risk they cannot characterise.

That gives any technology which reduces uncertainty an unusual property. It does not need to prevent anything to have value. It only needs to make the risk more legible. A building whose condition is documented and dated is not necessarily in better shape than one that is not. But it is better understood, and understanding is the thing being priced.

This is why adoption curves in physical industries so often look strange from the outside. A tool sits unused for years despite being obviously useful, then spreads quickly across a whole sector. Usually what changed was not the tool. It was that a risk carrier started asking for it, or started charging differently for its absence.

The three questions that actually matter

When I evaluate whether something we build has commercial weight, I have learned to ask questions from the insurer's perspective rather than the user's.

Does it reduce the frequency of a loss, the severity, or only the uncertainty?

All three have value and they are worth very different amounts. Frequency reduction is the strongest and the hardest to prove. Severity reduction, catching something early so the eventual repair is smaller, is easier to demonstrate. Uncertainty reduction is the weakest sounding and often the easiest to sell, because it requires no claim about the physical world at all, only about the quality of the information.

Is the evidence portable?

This is the one technical teams underestimate. Evidence that only exists inside your product is nearly worthless in a risk conversation. It has to be exportable, dated, attributable, and comprehensible to someone who has never used your software and never will. If a loss adjuster or a lawyer cannot read it without your interface, it is not evidence. It is a screen.

Does it survive a change of owner?

Risk attaches to the asset, not to the account. A record that vanishes when a subscription lapses or a building changes hands has no value in an underwriting decision, because underwriting looks at the history of the thing, not the history of the customer.

What this changes about who you sell to

The uncomfortable implication is that the party who benefits most from a documented building is often not the party you are selling to.

An owner deferring maintenance may prefer that the condition is not documented, for reasons I have written about elsewhere. A facilities manager may see documentation as evidence that could be used against them later. Neither is being unreasonable. Records create accountability, and accountability is uncomfortable for whoever stands closest to the work.

Meanwhile the parties who benefit unambiguously are the ones with no operational role at all. The insurer pricing the risk. The lender assessing the collateral. The buyer's surveyor two years from now. The court, if it ever comes to that.

That gap between who benefits and who buys is, I think, the central commercial problem in this whole category. It explains why adoption is slow despite obvious value, and why it accelerates suddenly when a risk carrier makes documentation a condition of cover rather than a good idea.

What I would not do

There is a tempting shortcut here which I think is a mistake: build for the insurer directly.

The failure mode is that you end up building a compliance artefact. Something whose only purpose is to satisfy a requirement, which means it gets produced as cheaply as possible, resented by everyone who touches it, and quietly degraded until it satisfies the letter of the requirement and nothing else. Plenty of industries have safety documentation that fits this description exactly. It exists. It is filed. It describes nothing real.

The better path is harder. Build something the operational people genuinely want to use, because it makes their week easier, and make the output of that daily usefulness happen to be exactly what a risk carrier needs.

That is a design constraint, not a marketing one. It means the evidence has to be a byproduct of doing the work rather than a separate task performed for someone else's benefit. If capturing the record is a chore laid on top of the job, it will be done badly and the data will be worthless. If it falls out of the job itself, it will be honest, because nobody was performing for an audience.

The summary

In any industry involving physical risk, ask who pays when it goes wrong. That party has more influence over what gets adopted than any buyer, any user, and certainly any product feature.

Then build the thing people want to use anyway, and make sure its exhaust is legible to that party.

Get both right and you are not selling technology at all. You are selling a better price on uncertainty, and that has a market whatever the software does.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Trust is a feature you build, not a claim you make

Issam Fathi — Wed, 19 Aug 2026 08:17:02 +0000

I spent part of my career in e commerce, in the years when online retail was still arguing with itself about whether people would ever hand over card details to a stranger.

The industry solved that. Not with reassurance, and not by getting better at saying trust us. It solved it by building trust into the mechanics of the product, in ways that cost real money and gave up real control.

I now work in B2B software, and I watch teams make the exact mistake retail outgrew two decades ago. They treat trust as a messaging problem. It is a product problem, and the difference shows up in what you are willing to sacrifice for it.

What retail actually did

Look at what changed in online shopping and almost none of it was copy.

Returns became free and easy. That is not a marketing decision, it is an expensive operational commitment that transfers risk from the buyer to the seller. It works because it is costly. A promise that costs the promiser nothing carries no information.

Reviews became public and unfiltered, including the bad ones. Retailers fought this initially, for obvious reasons. Then they discovered that a product with only five star reviews reads as fake, and that visible criticism makes the praise credible. Giving up control of the narrative bought more trust than controlling it ever did.

Order tracking became granular to the point of absurdity. Knowing your parcel has reached a depot does not help you. It changes nothing you can act on. But uncertainty is the actual discomfort in waiting, and visibility removes it even when it removes no delay.

Prices became total, including delivery, before the final step. Because the industry learned that a surprise at checkout does not just lose that sale. It costs you the customer.

Every one of those is a product decision with a cost attached. None of them is a claim.

The same four moves in B2B

Now hold enterprise software up against that list, and the gaps are uncomfortable.

Exit. Retail made returns free. Most B2B software makes leaving as hard as it can, and treats that friction as retention. It is not retention, it is captivity, and buyers have become extremely good at detecting it during evaluation. Being able to say clearly how a customer gets their data out, in what format, on what notice, is a trust feature. It costs you something, which is exactly why it works. I would rather lose a customer who wanted to leave than sign one who noticed the trap.

Public failure. Retail published bad reviews. The equivalent here is the status page and the incident write up. Teams that publish honest post mortems, including what they got wrong and how long it took to notice, are consistently more trusted than teams with suspiciously clean histories. Nobody believes the clean history. They assume you are hiding it, and they are usually right.

Progress visibility. Retail obsessed over tracking. Software still routinely leaves customers in silence between the sale and the value. Onboarding that shows where you are, what remains, and what is currently blocked reduces anxiety even when it does not reduce time. This is nearly free to build and it is skipped constantly.

Total price. Retail killed the checkout surprise. B2B reinvented it as implementation fees, mandatory onboarding packages, usage overages, and the tier where the feature you actually came for turns out to live. Every one of those is a checkout surprise wearing a suit.

Where the analogy breaks

There is one real difference, and it cuts against B2B.

In retail, the buyer is the user. The person who takes the risk feels the outcome themselves, and their exposure is a single purchase.

In B2B those are different people and the exposure is career sized. A buyer choosing a system is putting their judgement in front of colleagues who will remember. If it fails, the failure has their name on it for years.

Which means the fear is not really about the product. It is about being visibly wrong. Everything that reduces the personal cost of being wrong is a trust feature: a genuine pilot rather than a demo, a clean exit, references who will speak honestly, a small first commitment that proves something before anyone stakes a reputation on it.

That is why the pilot is not a sales tactic. It is the single most effective trust mechanism available in B2B, and teams undermine it constantly by making pilots too smooth to be informative. A pilot where nothing goes wrong teaches the buyer nothing except that you can control a demo.

The test I use

When I am unsure whether something we are considering builds trust or just claims it, I ask one question.

Does this cost us something if we are lying?

A security page that lists certifications costs nothing to write and is trivially inflated, so it carries almost no weight beyond the compliance checkbox. A published uptime history costs you every time you have a bad month, so it carries real weight.

Free returns cost money. Honest post mortems cost pride. Easy export costs leverage. Public roadmaps cost flexibility.

Trust is built almost entirely out of things that are expensive to fake. Everything else is decoration, and buyers stopped reading the decoration a long time ago.

Where to start

Pick the one your customers would most want and you would least like to give.

For most software companies it is the exit. Write down exactly how a customer leaves. What they get, in what format, how quickly, at what cost. Publish it.

If writing that down makes you uncomfortable, you have learned something important about your product, and so has every prospect who ever quietly wondered the same thing and did not ask.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Climate is quietly rewriting the maintenance calendar

Issam Fathi — Mon, 17 Aug 2026 08:17:02 +0000

Ask why a building is inspected every five years and you will rarely get a technical answer. You will get a regulatory one, a contractual one, or most often a historical one. That is how it has always been done.

Maintenance intervals feel like engineering. Mostly they are convention. Somebody, at some point, decided that a given interval was reasonable for a given material in a given climate, and the number outlived every assumption that produced it.

That would be fine if the assumptions were stable. Increasingly they are not.

The intervals were never physics

Building materials do not degrade on a calendar. They degrade in response to what happens to them. Water getting in and freezing. Ultraviolet exposure. Thermal expansion and contraction. Wind loading. Salt. Movement in the ground beneath.

A five year interval is a bet that a certain amount of that will accumulate in five years. It is a reasonable bet when the weather that drives it is roughly consistent across decades.

The mechanism that does most of the damage to masonry and render in temperate climates is a good example. Water enters a small crack, freezes, expands, and widens the crack. Next time more water enters. The damage is driven by how often the material crosses the freezing point while wet, not by how cold it gets.

That is a subtle distinction with real consequences. A winter that is milder overall but crosses zero more often can be harder on a facade than a colder, more stable one. Warming does not simply mean less frost damage. In some places it means more cycling, which is worse.

Three shifts that break the schedule

I am not a climate scientist and I am not going to pretend to model this. But three shifts are well enough established that anyone responsible for a building should be thinking about them.

Rainfall is arriving in heavier bursts. The annual total matters far less to a building than the intensity. Drainage, gutters, and flashing are sized for a rate. When more of the year's water arrives in fewer, harder events, systems that were adequate begin overflowing, and overflow puts water where the design never intended it to go.

Heat is stressing materials that were specified for a narrower range. Sealants, membranes, and joints have working temperature ranges. Roof surfaces in particular reach far higher temperatures than the air around them. Wider daily swings mean more expansion and contraction cycles, and it is the cycling that fatigues a joint, not the peak.

The freeze pattern is changing, not simply weakening. As above. In regions where winters used to stay reliably below or above freezing, more crossings mean more of the exact cycle that damages porous material.

None of these produce a dramatic failure. They accelerate the ordinary ones. Which is precisely what makes them dangerous to a fixed schedule, because the schedule assumes a rate that is quietly no longer true.

The problem with finding out late

Here is what worries me most about this as someone who works with building data.

If a maintenance interval is too long for the conditions, you do not discover it through a warning. You discover it through a failure, and you discover it once. A single facade repair after a failure typically costs several times what the same repair would have cost when the defect was small, before you count scaffolding, access, disruption, and whatever legal attention a failure attracts.

Worse, one building failing tells you almost nothing about the others. You get one expensive data point and no way to know whether it was an outlier or the first of many, because nobody has the condition history that would let them compare.

That is the real gap. Not that the schedules are wrong, but that almost nobody has the data to tell whether theirs is.

What a condition driven schedule actually requires

The obvious answer is to stop inspecting on a calendar and start inspecting on condition. Everyone in the industry says this. Very few do it, and the reason is not stubbornness.

Condition based intervals need three things that most portfolios do not have.

A baseline. You cannot detect change without a first measurement. Not a report saying the building was satisfactory, which is an opinion, but a documented state with evidence attached, so that a future inspection can be compared against it rather than starting from zero.

Comparability. Two inspections only produce a trend if they measured the same things the same way. Most building inspection is prose written by different people using different vocabulary in different years. That is not a dataset, and no amount of software will turn it into one.

Somewhere for it to live. The condition history has to outlive the surveyor, the facilities manager, and the owner. It usually does not. The caretaker retires, the binder goes into a basement, the building is sold, and the record restarts at zero.

Get those three and the interval stops being a guess. A defect that has not moved in four years can wait. A defect that moved measurably in one year cannot, whatever the schedule says. That is a far better use of a maintenance budget than treating every building in a portfolio identically because they share a category.

What I would do this year

If you own or manage buildings, I would not start with climate models. I would start with something much more boring.

Find out what your inspection intervals are actually based on. Ask directly. If the answer is regulation, that is a floor and not a ceiling, and it is worth knowing whether the regulation was written with current conditions in mind. If the answer is that it is how it has always been done, you have found an assumption worth testing.

Then check whether you could detect change at all. Pull the last two inspection reports for one building and try to answer a simple question: is this defect worse than it was? If you cannot answer that from your own records, the interval is not your most urgent problem. The record is.

The climate part of this is slow and uncertain. The record part is entirely within your control and you can start it this quarter.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

What a bazaar taught me about negotiation

Issam Fathi — Fri, 14 Aug 2026 08:17:02 +0000

Before software, before marketing, part of my working life was spent in tourism and the bazaar trade in Morocco. It is not a background that shows up often in technology, and for a long time I did not mention it much.

That was a mistake. It taught me more about negotiation than anything I have read since, because in a bazaar the theory gets tested several hundred times a day by people with no obligation to be polite about the result.

Here is what actually holds up.

Negotiation begins long before the number

The single biggest misunderstanding people have about haggling is that it is about numbers. It is not. By the time two people are exchanging figures, most of the outcome has already been determined.

What determined it was everything before. How long the buyer stayed. What they touched. What they asked about. Whether they came alone or with someone whose opinion they clearly valued. Whether they were on a schedule.

A skilled seller in a bazaar is not calculating margins during the exchange. They are reading how much this person wants the object and how much time they have, both of which were established well before anyone said a price.

The business equivalent is obvious once you see it. The negotiation over a contract was largely settled during discovery. If you find yourself fighting hard over price at the end, the real failure happened weeks earlier, when you did not establish what the buyer actually wanted or what would happen to them if they walked away with nothing.

The first number is not an offer, it is a frame

Anchoring is discussed in every negotiation book, usually as a trick. In a bazaar it is understood as something more basic: the first number defines what kind of conversation you are having.

A very high first price does not mean the seller expects it. It means they are declaring a category. Everything after that gets measured against it, including the sense of victory the buyer eventually feels.

The part books get wrong is the emotional function. The buyer is not only trying to pay less. They are trying to have won. A negotiation that lands at a fair price with no movement often satisfies people less than one that lands slightly higher after real back and forth. I watched this play out constantly.

I am careful with this in business, because there is a line between framing and manipulation, and crossing it burns relationships you need to keep. But I no longer pretend the first number is neutral. It never is. If you do not set it deliberately, the other side will.

Walking away is a real position, not a bluff

In a bazaar, walking away is the most powerful thing a buyer does, and everyone knows it.

What is interesting is what it reveals about the seller. A seller who lets you walk without a word has told you the price was real. A seller who calls after you has told you it was not. Either way you have learned something true, which is more than most negotiation tactics deliver.

The lesson that transferred is this: your leverage is not your argument. It is your genuine willingness to not do the deal. If you cannot walk, no technique will save you, and experienced counterparties can sense it almost immediately.

Which means the actual work happens before the room. Having a real alternative, and knowing precisely what it is worth, is ninety percent of negotiating strength. Everything else is presentation.

Never insult the object

There is an amateur move that tourists make constantly. They criticise the item to justify a lower price. The stitching is poor, the colour is wrong, it is not really handmade.

It never works. It usually makes things worse, and I watched sellers become noticeably less flexible after it.

The reason is that you have just told the seller you do not want the thing very much. If it is that flawed, why are you still here? You have destroyed your own credibility, and you have insulted work that someone may have done personally.

Say instead that you love it and cannot afford it. That is a completely different negotiation. Now the seller is solving a problem with you rather than defending against you, and they will often find a way, because a buyer who genuinely wants the object is worth keeping.

I see the business version of this every week. Buyers who trash a product to get a discount, vendors who dismiss a competitor to win. Both signal weakness. Respect the thing, be honest about the constraint. It works far better, and it happens to be true more often.

The relationship outlives the transaction

The final thing, and the one that reframes everything above.

In a market where the same people trade beside each other for decades, a seller who wins too hard today loses tomorrow. Reputation is the real currency and it moves faster than any individual deal. I saw sellers deliberately leave money on the table with a customer they expected to see again, and I saw others extract everything possible from a passing tourist and then wonder why their business never grew beyond passing tourists.

That is the whole lesson, honestly. Most business negotiation is with people you will meet again, in an industry smaller than it looks. Winning a deal on terms the other side later resents is not a win. It is a debt.

The bazaar is often described as adversarial. The best operators in it were not adversarial at all. They were extremely good at reading what someone wanted, honest about what they could do, and playing a much longer game than the person in front of them.

I have never found a better description of good sales than that.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

How to price something that has never existed

Issam Fathi — Wed, 12 Aug 2026 08:17:02 +0000

Pricing an established product is comparison. You look at what the market pays, you decide whether you are cheaper or better, and you position accordingly. It is not easy but it is bounded.

Pricing something genuinely new is a different problem, and most teams handle it the same way: they pick a number that feels defensible, present it with confidence, and quietly hope. I have done this. I have also watched it go badly enough to want a better method.

Across marketing work in several industries and now in software, I have ended up with five reference points. None of them gives you a price. Together they give you a range narrow enough to be a decision rather than a guess.

One. Price the alternative, including the ugly one

Every new product replaces something, even when there is no competing product. The alternative might be a spreadsheet, a phone call, an agency, an employee's Tuesday, or doing nothing at all.

Doing nothing is the one people forget, and it is usually the market leader.

So the first exercise is to cost the alternative honestly. Not the version where you assume your buyer is inefficient, but the real one. If a task currently takes a competent person four hours a month, that is your reference, and you should compute it at their actual salary, not the number that flatters you.

This does not set your price. It sets the ceiling of easy argument. Above it, you are asking someone to believe something. Below it, you are having a much simpler conversation.

Two. Find the number they already have a budget line for

This is the single most useful thing I learned selling in a commercial environment, and it is underused by technical founders.

Organisations do not evaluate spending in the abstract. They evaluate it against existing categories. A cost that fits an existing budget line gets approved by one person. A cost that requires a new line gets approved by a committee, next quarter, maybe.

So before you set a price, find out what your buyer already spends money on that yours could sit beside. Not because you should match that number, but because knowing it tells you which approval path you are walking into. I have seen a lower price take longer to close than a higher one, purely because the lower one did not fit any existing category and the higher one did.

Three. Test the shape before the number

Buyers react as strongly to how they are charged as to how much. Per seat, per site, per use, per year, per asset. The shape carries a claim about what your product is.

Charging per user says this is a tool for individuals. Charging per building says this is infrastructure attached to a property. Those two options can produce identical revenue and completely different customer behaviour, because the shape decides who inside the organisation feels the cost, and therefore who inside the organisation argues about it.

Get the shape wrong and your customers will fight you at renewal even if the total is fair. Get it right and the total becomes much less contested, because it scales with something they already believe should cost money.

I would test the shape in conversations long before I tested the number. It is far harder to change later.

Four. Ask what it would have to cost to be irresponsible not to buy

This is a question from sales, not from finance, and it has served me better than any pricing model.

You are looking for the point where the decision stops being an evaluation and becomes obvious. Everyone has that threshold, and most buyers will tell you roughly where it is if you ask directly.

The answer is not your price. Pricing at obvious is usually leaving money on the table and, worse, it signals that the product is minor. But it locates your floor, and it tells you something more valuable: how far away from obvious your current thinking is. If your intended price is ten times that number, you do not have a pricing problem. You have a value communication problem, or the wrong buyer.

Five. Decide what you want the price to say

Price is the loudest piece of positioning you will ever ship. It arrives before the demo, survives every conversation, and gets repeated by people who have never used the product.

A low price on a serious product does not read as generous. It reads as unproven. In categories where the cost of being wrong is high, and building maintenance is very much one of those, an unusually low price actively creates doubt. Buyers reason that if this really prevented what you claim it prevents, it would cost more.

A high price makes a promise. It says this is meant to be relied upon, and it invites scrutiny you had better be able to survive.

Neither is right. But you should choose deliberately, because your buyers are reading the number as a statement about the product whether you intended it or not.

What I would not do

Two things I have learned to avoid.

I would not price off cost. Cost tells you whether you have a business. It tells you nothing about what the thing is worth, and for software the marginal cost is close to meaningless anyway. Cost plus pricing on a new category is how genuinely valuable products end up priced like commodities.

And I would not survey people on price. Asking someone what they would pay produces a polite fiction, every time. People are unreliable about hypothetical future spending and extremely reliable about past spending. Ask what they have actually paid for the alternative, what that came out of, and who signed it. That is real data. What they say they would pay is not.

The honest summary

You will not get it right the first time. Nobody does, and the good news is that you do not have to, because early pricing is a hypothesis and the market will correct it faster than any analysis.

What you must get right is the shape and the story, because those are expensive to change and they train your customers in how to think about you.

Pick the shape carefully. Choose what the number says. Then set the number, watch what happens, and be willing to be wrong in public.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Deferred maintenance is a financing decision, not a failure of care

Issam Fathi — Mon, 10 Aug 2026 08:17:01 +0000

There is a story the maintenance industry likes to tell about owners who put off repairs. In that story the owner is careless, short sighted, or cheap. Someone eventually writes an article about how a small fix would have prevented a large one, and everyone nods.

I sold property before I built software, and I no longer think that story is true. Most owners who defer maintenance are doing something entirely rational within the constraints they actually have. They are borrowing.

Once you see it that way, almost everything about how repairs get sold, budgeted and delayed starts making sense.

The invisible loan

When an owner delays a repair, they receive money today. Not from a bank. From themselves, by not spending. In exchange they take on an obligation that grows over time, because the underlying problem does not pause while they wait.

That is a loan. It has a principal, which is the cost of fixing it now. It has interest, which is the rate at which the damage worsens. And it has a maturity date, which is whenever the problem becomes unavoidable, either because something fails, a regulator asks, or a buyer's surveyor finds it.

What makes this loan dangerous is not the interest rate, although that is often brutal. Water damage in particular compounds viciously, because a small breach does not stay a small breach, it becomes a structural problem, then a health problem.

What makes it dangerous is that no statement ever arrives. A real lender sends you a monthly reminder of what you owe. This one is silent until the day it is due in full. So the balance grows entirely out of sight, and the owner has no ongoing signal that would let them price the decision they made.

Why the constraints are usually real

The uncomfortable truth for anyone selling maintenance is that the deferral is often the correct call given the owner's actual position.

Repairs are capital expenditure. They are large, lumpy, and they come out of a budget that is fought over annually. Meanwhile the alternative uses of that money are not frivolous. They might be a tenant improvement that keeps a building occupied, a compliance upgrade with a hard legal deadline, or debt service that cannot be missed.

Add to that the ownership horizon. An owner planning to sell in two years has a genuinely different calculation from one holding for twenty. Every finance person understands this instinctively. If the cost lands after you exit, and the buyer does not detect it, you have successfully transferred the liability. That is not a moral position I would defend. It is an accurate description of the incentive, and pretending otherwise makes you bad at selling to these people.

There is also the structure of who decides. In a lot of buildings the person who experiences the problem, the person who pays for the fix, and the person who owns the asset are three different parties with three different time horizons. Deferral is often not a decision at all. It is the default outcome of three parties not agreeing.

What this changes about how you sell

I have watched a lot of well meaning proposals fail because they argued the wrong point. If you approach a deferral as though it were ignorance, your entire pitch is education. You explain that water spreads and small problems get bigger. The owner already knows this. They have known it for years. You have not given them anything.

The argument that actually moves is financial, and it has three parts.

Price the balance, not the repair. Do not tell an owner what a fix costs. Tell them what the obligation is worth today and what it will be worth in three years if nothing changes. Owners are extremely good at comparing two numbers over time. That is their native language. They are much worse at acting on a vague warning about deterioration.

Make the interest visible. The reason this loan is mispriced is that there are no statements. So send statements. A documented condition, revisited on a schedule, with changes tracked between visits, turns an invisible balance into a visible one. The moment an owner can see a defect getting worse across three dated inspections, they are no longer choosing between spending and not spending. They are watching a number climb.

Give them a way to defer deliberately. This is the part almost nobody offers, and I think it is the most valuable. Not every repair should be done now, and an honest supplier should say so. If you can tell an owner which items genuinely can wait, for how long, and under what conditions to revisit, you have made deferral into a managed strategy rather than an accident. Owners will pay for that, and they will trust the urgent items far more because you were honest about the rest.

Why the record matters more than the recommendation

I build tools that document building condition, so I have an obvious bias here. But the bias came from the observation, not the other way around.

A recommendation is an opinion at a moment in time. It has almost no power in a budget meeting, because everyone in that room has a competing opinion backed by an equally confident supplier.

A record is different. A record shows the same defect, on the same building, across dated inspections, with evidence attached. That is not an opinion. That is a trend, and a trend is the only thing that reliably survives contact with a finance function, because it lets someone model it.

The shift I want to see in this industry is from telling owners what to do toward showing them what is happening. The first is advice, and advice is cheap and contested. The second is data, and data compounds. Every year of record makes the next decision easier and the loan harder to hide.

The reframe

If you sell repairs, stop calling deferral negligence. It is financing, and your customer is better at finance than you are.

Meet them there. Show them the balance, show them the rate, and be honest about which items they can afford to carry.

You will lose a few jobs you would have won by scaring people. You will win the relationship, which is worth considerably more.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

What working with a national airline taught me about operations

Issam Fathi — Fri, 07 Aug 2026 08:17:01 +0000

Of all the places I have worked, the one that changed how I think about running things was not a technology company. It was an airline.

I spent part of my marketing career working with a national carrier. I was there for the commercial side, not the operational one, but you cannot sit inside an airline for long without absorbing how it actually functions. And what struck me had nothing to do with aircraft. It was the discipline underneath.

An airline is a company where being roughly right is not good enough, where thousands of independent things must happen in sequence every day, and where the cost of a small failure is visible to the public within minutes. Most businesses never face that pressure. Which is precisely why most businesses never develop the habits.

Four of those habits have followed me into every team I have run since, including the one building AssetEye at Dronetjek.

One. The checklist is not for beginners

The first thing that surprises outsiders is who uses checklists. Not the trainees. The most experienced people in the building, every single time, without exception, out loud.

In most industries a checklist is treated as scaffolding for the inexperienced. You use one while you are learning and you graduate from it. In aviation it is the opposite. Seniority does not exempt you. It obliges you.

The logic is simple once you hear it. Checklists are not there to compensate for lack of knowledge. They are there to compensate for lack of attention, and attention fails independently of expertise. In fact an expert doing a familiar task is the most likely person in the room to skip a step, because familiarity is exactly what stops you from noticing.

I have carried this into software. Our release process has a written sequence and the most senior person follows it in the same order as the newest one. Every time someone suggests that we are too experienced for it, I take that as evidence we need it more.

Two. Time is a shared resource, not a personal one

Airlines think about turnaround. The window between an aircraft arriving and departing again, during which cleaning, fuelling, catering, baggage, boarding, and checks all have to happen, largely in parallel, mostly by different teams.

What makes that work is not that everyone is fast. It is that everyone knows precisely when they are the constraint and when they are not. Being early is not virtuous if the person before you is late. Being fast in your own task while blocking someone else is not performance, it is noise.

Most companies have no shared sense of this at all. Every team optimises its own segment, reports its own speed, and nobody owns the gaps. The gaps are where all the time goes.

When I plan work now, I care far less about how long each task takes and far more about the handoffs between them. In practice almost every delayed project I have investigated was not slow work. It was fast work waiting.

Three. Report the near miss, not just the crash

This is the one I think is genuinely transferable to every industry on earth, and the one almost nobody copies.

Aviation built a culture where the things that almost went wrong are reported, systematically, by the people who almost caused them, without that report ending their career. The entire safety record of modern flying rests on this. You cannot learn from events that did not become disasters unless people tell you about them, and people only tell you if telling you is safe.

Now compare that to a normal company. What happens when someone nearly ships a serious mistake and catches it themselves at the last moment?

Nothing. They fix it quietly and say nothing, because there is no upside to raising your hand and no established way to do it. So the organisation learns nothing, and the same near miss keeps happening until one day somebody does not catch it.

I have tried to build the reporting habit into my teams, and I will be honest that it is the hardest of these four to establish. It requires you to visibly reward someone for telling you about a problem they created. The first time you do that badly, you never hear another one.

Four. Standardise the interface, not the person

Aircrews are frequently assembled from people who have not worked together before, and they function immediately. This is remarkable if you think about how most teams behave when you reshuffle them.

It works because what is standardised is the interface. The language, the sequence, the division of responsibility, the specific phrases used to hand over control. Individual style varies enormously. The protocol does not.

Most companies attempt the reverse. They try to standardise people through culture decks and shared values, while leaving the actual interfaces between roles completely improvised. Then they are surprised that every new joiner takes three months to become useful.

Standardise how work is handed over, how decisions are recorded, how a problem is escalated. Leave personality alone. You get consistency without turning people into copies of each other.

The part that does not transfer

I want to be careful here, because there is a version of this article that argues everyone should run their company like an airline. That would be wrong.

Aviation's discipline is proportionate to its consequences. The reason the process is heavy is that the failure mode is catastrophic and irreversible. Most of what most of us do is neither. If you apply aviation grade process to a marketing campaign you will produce a slow, joyless, expensive marketing campaign.

The judgement is knowing which parts of your work are actually irreversible. Almost every business has a small number of genuinely one way doors and a large number of things that feel serious but can be undone by Thursday. The mistake is treating them the same. Heavy process on reversible work is waste. Light process on irreversible work is how people get hurt.

The airline taught me to tell them apart, and to spend my discipline where it buys something.

Look at your own operation and find the handful of steps that cannot be undone. Put real process there. Everywhere else, get out of the way.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

The cost of a wrong number

Issam Fathi — Wed, 05 Aug 2026 08:17:02 +0000

Somewhere in every organisation there is a number that nobody can source.

It is in the budget. It is in the deck. Someone quotes it in a meeting and heads nod. Ask where it came from and you get a chain of shrugs that ends, four people later, with a spreadsheet built by someone who left two years ago.

I have watched this happen in real estate, in e commerce, in marketing, and now in software. It is the most consistent pattern I have seen across completely unrelated industries, and it is almost never treated as a serious risk. We audit money. We audit code. We almost never audit numbers.

How a wrong number survives

A wrong number does not survive because people are careless. It survives because of how numbers travel.

An estimate is created under uncertainty. The person who makes it knows exactly how soft it is. They would tell you, if you asked, that it is a rough figure with a wide range and several assumptions baked in.

Then it gets written down. Writing strips the uncertainty. A range becomes a midpoint. A midpoint becomes a figure. The figure goes into a slide, and slides have no room for caveats.

Then it gets quoted by someone who was not there. This is the moment the number changes species. It stops being an estimate and becomes a fact, because the person repeating it has no idea it was ever soft. They did not remove the uncertainty. They simply never received it.

Then it gets defended. Once a number has appeared in a board pack, revising it costs someone credibility. So it hardens. I have seen numbers defended for years by people who were not in the room when they were invented.

Four steps. No villain anywhere in the chain.

The compounding part

A wrong number in isolation is a small problem. Numbers are rarely in isolation.

In my e commerce years, we planned a season on an assumed return rate. The figure was a couple of points off. That sounds harmless. It was not, because the return rate was an input into four other things: how much stock we bought, how we priced, how much warehouse space we committed to, and how we staffed the returns desk.

Each of those decisions used the wrong figure as a certainty. Each one was individually reasonable. Together they produced a season where we were simultaneously overstocked, underpriced, paying for space we did not need, and understaffed exactly where the pressure landed.

Nobody made a bad decision. The system made a bad decision, because a soft number entered it as a hard one and then multiplied.

This is the thing people miss about estimate error. It does not add. It compounds through everything downstream that depends on it. A figure that is ten percent off does not create a ten percent problem. It creates a problem the size of every decision that trusted it.

Where I see it now

In physical assets the same pattern shows up with a longer fuse and a bigger bill.

A property is assessed. A condition is estimated. That estimate feeds a maintenance budget, a valuation, sometimes an insurance position and a sale price. If the original assessment was optimistic, every one of those is optimistic, and the correction does not arrive for years. When it arrives it does not arrive as a spreadsheet revision. It arrives as a repair invoice, a failed sale, or a dispute.

The gap between when a number is wrong and when anyone finds out is the real danger. In advertising I could be wrong on a Monday and know by Friday. In buildings you can be wrong for a decade.

That gap is exactly why documentation matters more in slow industries than fast ones. When feedback is quick, bad numbers get corrected by reality. When feedback is slow, the only thing standing between a bad number and a bad decade is whether anyone wrote down where the number came from.

Four habits that actually help

I do not have a system for this. I have four habits, and they are cheap.

Carry the range, not the midpoint. When someone gives me an estimate, I write down the range and the date. A number without a range is a claim. A number with a range is information. It costs nothing to keep both and it changes how people use the figure downstream.

Record the source at the moment of creation. Not the department. The person, the method, and the date. Most bad numbers are not wrong, they are stale. They were correct about a business that no longer exists. A date on a figure tells you when to stop trusting it.

Ask what breaks if this is wrong by half. Not by ten percent. By half. If the answer is nothing much, stop refining it and move on, because you are polishing something that does not matter. If the answer is that four other decisions collapse, you have found a number that deserves real work. Most teams spend their precision on the wrong figures entirely.

Name the decisions that depend on it. This is the one nobody does, and it is the one that stops compounding. When a number is created, list what will consume it. That list is your blast radius. When the number later changes, and it will, you know exactly what to revisit instead of hoping someone remembers.

The honest conclusion

You cannot eliminate wrong numbers. Estimating under uncertainty is most of what management is. The goal is not accuracy, which is often impossible, but traceability, which is always possible.

A wrong number you can trace is an inconvenience. You find it, you revise it, you rerun the decisions it touched.

A wrong number you cannot trace is a permanent resident. It will outlive the person who made it, the project it was made for, and quite possibly the strategy it justified.

Go find one this week. Take a figure everyone in your organisation repeats without hesitating and ask three people where it came from.

If nobody knows, you have not found a number. You have found a belief.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

The org chart is a lie. Find the real one.

Issam Fathi — Mon, 03 Aug 2026 08:17:02 +0000

I have been handed a lot of org charts. As a marketing chief across nine companies, and now as the product manager of AssetEye by Dronetjek, I have collected them the way other people collect business cards.

Almost none of them described the company I actually worked in.

The chart is not dishonest. It is a map of reporting lines and salary bands, and for those two purposes it is accurate. The problem is that people treat it as a map of power. It is not. Reporting lines tell you who signs a performance review. They tell you almost nothing about who can stop a project, unblock a budget, or quietly kill an idea in a corridor.

Every organisation runs two structures at once. The drawn one, and the real one. If you plan a change against the drawn one, the real one will eat it.

How I learned this the expensive way

Early in my marketing career I ran a campaign that needed sign off from a marketing director. I got it. Fast, enthusiastic, in writing. On the chart, that was the whole approval path.

The campaign died anyway.

It died because a finance manager two boxes to the left had spent eleven years at that company, sat next to the founder at lunch every day, and thought the idea was reckless. He never blocked it. He never had to. He asked one sceptical question in a room I was not in, and the enthusiasm around me evaporated over a week. Nobody told me it was dead. It just stopped having meetings.

That man was on no path of mine. On the chart he was irrelevant to my work. In reality he was the single highest leverage person in the building for anything involving money, and everyone except me knew it.

The four questions that map the real structure

Since then I have started every new company, every new client, and every new team the same way. Not by reading the chart, but by asking four questions and listening to who comes up.

Who gets called when something breaks at night?

Not who is supposed to be called. Who actually is. That person holds operational trust, which is the most durable kind. They usually have far more informal authority than their title suggests, because everyone has personally watched them save something.

Whose approval do people seek even when they do not need it?

This is the clearest signal of real power that exists. When someone routinely walks a decision past a person who has no formal say, that person is a gate. Watch for it in the small stuff. People show you their real hierarchy in how they hedge.

Who can say no and make it stick without escalating?

Formal authority has to escalate. Real authority does not. If someone can end a discussion with a shrug and nobody appeals it, you have found a load bearing wall.

Who explains the company to new people?

Every org has one or two unofficial narrators. They tell newcomers what the company is really like, which rules matter, which are theatre. They are shaping culture more than any values document, and they are almost never senior.

Four questions. Ask them of five people and the real structure draws itself. It rarely looks like the chart. It is usually flatter in some places, far more centralised in others, and it always contains two or three people whose importance would surprise their own managers.

Why this is not cynicism

It would be easy to read this as office politics, something distasteful you tolerate. I think that is exactly backwards.

The informal structure is not a corruption of the formal one. It is the organisation compensating for the formal one being too slow, too coarse, or simply out of date. Companies change faster than their charts. The real structure is the company routing around its own diagram, and it usually routes toward competence.

The finance manager who killed my campaign was not playing games. He had eleven years of watching money get wasted and he had earned, informally, the right to be listened to. The organisation was smarter for listening to him than it would have been if it had strictly obeyed its own chart. My mistake was not that I failed to fight him. It was that I never knew he existed.

What I do differently now

Three things, in every team I run.

I map the real structure before I propose anything significant. Not to manipulate it, but because a proposal that has not been tested against the people who actually decide is not a proposal. It is a wish.

I bring the informal gates in early, on purpose. If someone has earned the right to be sceptical, they should hear the idea while it can still change, not after it is built. Almost every objection I have ever received early would have been a disaster if it had arrived late.

And I try to notice when the two structures have drifted too far apart. A small gap is healthy. A large gap is a symptom. When the chart and the reality have nothing to do with each other, it usually means the formal structure has stopped doing its job and people have quietly built a parallel company to get work done. That is not sustainable. Somebody eventually leaves and takes an entire undocumented function with them.

The uncomfortable part

If you are senior, there is a version of this that stings. You may be on the chart and not in the real structure. Title without traction. It happens constantly to people brought in from outside, and it is the reason so many senior hires fail in their first year despite doing nothing wrong.

The fix is not more authority. Authority you have to invoke is authority you do not have. The fix is the slow work that earns informal standing: being right in public, being useful when it is inconvenient, and being the person who gets called at night.

Draw your team's real chart this week. Not the one in the handbook. The one where the arrows point at the people who actually decide.

You will learn more in an afternoon than the handbook has told you all year.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.