DEV Community: Issam Fathi

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.

Building serious tech from outside the tech hubs

Issam Fathi — Fri, 17 Jul 2026 19:12:01 +0000

There is a quiet assumption in tech that real products come from a handful of cities. San Francisco, London, Berlin, maybe a few others. Everywhere else is treated as a place that consumes technology, not one that builds it. I build from Tetouan, in northern Morocco, and I think that assumption is not just wrong, it is expensive for the people who believe it.

I work on an AI platform used by people who own buildings and infrastructure. The work is not a lite version of what a team in a big hub would do. It is the same work. The models are the same models, the standards are the same standards, and the users do not care where the team sits as long as the product earns its place in their day.

What building from outside the hubs actually changes is not quality. It is a few habits, and most of them are advantages.

You cannot coast on hype. In a hub, proximity to money and noise can carry a mediocre product further than it deserves. From the outside, none of that is available. The product has to be genuinely useful or it is nothing, because there is no scene to prop it up. That pressure makes for better products.

You build for the real world by default. The pristine, high budget, everything works environment is not the water you swim in. You are closer to constraints, to users who cannot tolerate fragility, to the ordinary conditions where most software actually has to run. That is not a handicap, it is the correct starting point.

And you learn to work across distance and difference, because you have to. Different languages, different markets, different time zones. That is not a limitation on the team, it is training for how the world actually works.

I am not romanticizing it. Being outside the hubs has real friction, less local capital, fewer people who have done it before, more that you have to figure out alone. But the idea that serious technology can only be built in a few zip codes belongs to the past. The tools are global now. The talent always was. The only thing still catching up is the assumption.

I build from Tetouan. The work speaks for itself.

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.

Every AI feature is a new attack surface

Issam Fathi — Fri, 17 Jul 2026 19:12:00 +0000

Every time you add an AI feature, you add a door. Most teams are so focused on whether the feature works that they forget to ask who else can walk through it.

I sit across product and security, and the pattern I see is consistent. A team ships an AI capability, a model that answers questions, summarizes documents, or acts on user data, and treats it purely as a product win. Meanwhile it quietly became one of the softest parts of the system.

The reasons are not exotic. An AI feature usually takes untrusted input, often free text, and does something meaningful with it. That is the classic shape of a security problem. Prompt injection is just untrusted input reaching a powerful interpreter, the same category as the injection bugs we have fought for twenty years, wearing new clothes. If your model can call a tool, read a file, or hit an internal service, then whoever controls its input has a lever on your system.

So here is the discipline I try to hold.

Treat model input as hostile by default. The same way you never trust a form field, never trust what reaches the model, especially if the model can then act. The convenience of "just pass it through" is exactly where the hole is.

Constrain what the model can reach. A model that can only read the one document it was given is a small risk. A model wired into your internal tools with broad permissions is a large one. Scope its access like you scope a service account, least privilege, not most convenience.

Log what it does, not just what it says. When something goes wrong with an AI feature, you need to reconstruct the actions it took, not only the text it produced. If you cannot answer "what did the model actually do at 3am," you are flying blind.

None of this slows real products down. It is the same instinct that separates engineers who ship things that survive contact with the real world from those who ship demos. AI does not get a security exemption for being new and exciting. If anything, new and exciting is exactly when people stop checking the locks.

Build the feature. Then ask who else it just let in.

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.

Building AI tools for people who don't trust AI

Issam Fathi — Fri, 17 Jul 2026 18:45:42 +0000

Most conversations about AI products assume the user is excited. They assume someone who wants the magic, who will forgive a rough edge because the technology is cool. In my world, that user does not exist.

I build for people who own buildings, roads, and infrastructure. Practical, experienced professionals who have watched a parade of software promise to change everything and then waste their time. When AI shows up, their first reaction is not excitement. It is suspicion. And they are right to be suspicious.

That changes how you have to build. When your user does not trust the technology, every easy shortcut becomes a landmine.

The first rule is that a confident wrong answer is worse than no answer. A skeptical user will forgive "I am not sure about this one, take a look." They will never forgive being told something false with total confidence, because the first time it happens you have lost them for good. So the product has to know the edge of its own knowledge and say so. Certainty you have not earned is not a feature, it is a liability.

The second rule is show your work. A number on a screen means nothing to someone who does not trust where it came from. Let them see the image, the evidence, the reason. Trust is not built by hiding the machinery, it is built by making the machinery inspectable. The goal is not to make the user believe the AI. It is to make the user able to check the AI in five seconds and move on.

The third rule is earn the next step. You do not get to automate someone's whole job on day one. You get to save them ten minutes on one annoying task. If that ten minutes is real, they come back, and the relationship grows from there. Skeptical users do not convert with a pitch. They convert with a small, repeated, undeniable win.

None of this is specific to buildings. Any time you put AI in front of someone whose profession predates the technology, whose reputation is on the line, and who has been burned before, the same rules apply. Be honest about uncertainty. Make yourself checkable. Earn trust in small pieces.

The irony is that building for the skeptic makes a better product for everyone. Honesty about limits, visible evidence, and value that compounds are not concessions to a hard audience. They are just what a good tool 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.

The drone was never the hard part

Issam Fathi — Fri, 17 Jul 2026 18:45:41 +0000

When people picture a drone inspecting a building, they picture the flight. The aircraft rising up the facade, the camera sweeping across the roof, the pilot on the ground. It looks like the drone is the technology. It is not. The drone is the easy part.

I work on AssetEye, an AI platform that turns drone and 3D data into structured insight for the people who own buildings and infrastructure. The thing I keep relearning is that flying a drone over an asset was solved years ago. Anyone can capture thousands of images of a roof. The hard part starts the moment the drone lands.

Because a folder of five thousand photos is not an inspection. It is a problem. Somebody still has to look through all of it, decide what matters, find the crack that will cost real money next winter, and turn that into a decision the owner can act on. That is where the work actually lives, and that is where most of the value hides.

Here is the shift that matters. The question was never "can we see the asset." Drones answered that. The question is "can we understand it, at scale, without a human staring at every frame." That is a data problem and an AI problem, not a flying problem.

So when we build, we spend almost no time on the capture and almost all of it on what happens after. How do you take raw imagery and 3D geometry and surface the three things on this roof that need attention, out of the thousands that do not. How do you make that trustworthy enough that an owner will spend money based on it. How do you make it consistent, so the same defect gets flagged the same way on building one and building four hundred.

Get that right and the drone becomes almost boring, which is exactly what you want. The technology that matters is the layer that turns pixels into a decision. The flight is just how the pixels arrive.

There is a wider lesson here for anyone bringing new tech into an old industry. The flashy part, the part that looks futuristic in a demo, is usually the part that is already solved. The value is downstream, in the unglamorous work of turning capability into something a busy professional can trust and use. Chase the boring part. That is where the moat is.

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.

Most companies don't have a technology problem. They have an adoption problem.

Issam Fathi — Fri, 17 Jul 2026 18:36:30 +0000

Every few months a company buys a powerful new tool, announces a transformation, and quietly goes back to the old way of working within a quarter. The software was fine. The rollout was the failure.

I see this from a specific seat. I am the product manager of AssetEye, an AI platform that turns drone and 3D data into structured insight, so the people who own buildings and infrastructure can actually see their cost, their risk, and their CO2 instead of guessing. The hard part of that work is almost never the model. The model works. The hard part is getting a traditional industry to trust it and fold it into how they already operate.

That gap, between a tool that works and a team that uses it, is where most transformation money dies. So here is how I think about closing it.

Build for the user's reality, not for the demo

A demo is designed to impress in five minutes. Real work is messy, interrupted, and done by people who did not ask for a new system. If your product only shines in the perfect case, you have built a trade show prop, not a tool. I would rather ship something that survives a bad day on site than something that dazzles in a boardroom.

Adapt the workflow, not just the tool

Dropping AI into a broken process gives you a faster broken process. The real question is never "where do we add the model," it is "what decision is this person trying to make, and what is slowing them down." Sometimes the answer is not more technology at all. Knowing that is the job.

Grow by winning one real problem first

Nobody adopts a platform because of its roadmap. They adopt it because it solved one painful, concrete thing this week. Prove value on a single problem the user actually feels, earn the trust, and expansion takes care of itself. Trying to transform everything at once is the fastest way to transform nothing.

None of this is about being anti technology. I love the technology. It is about respecting the distance between capability and use, because that distance is where every real result lives. Companies do not fall behind because they lack tools. They fall behind because they cannot get their people to trust and use the tools they already have.

Build for reality. Adapt the workflow. Grow from one real win. That is not a strategy deck. It is just what works.

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.