“AI is reading your files.”

“AI is cheating you.”

“AI is making people dumb.”

“AI will be our doom.”

“AI will solve all our problems.”

They sound different, but they share something important.

They all treat AI as if it were a person.

As if it had intentions, wanted something, could act on its own.

But AI does not want anything.

It does not decide to read your files, to deceive you, to make you dependent, to decide to solve your problems.

It does not decide to harm anyone.

AI is a technology.

It is programmed, trained, deployed, and used by people.

And when we say “AI did it,” we often hide the more uncomfortable truth:

People did it. And all the bad things you are seeing done by this technology, are either bugs, due to lack of proper safety testing, limitations of the technology itself, and ultimately human error.

The attribution problem

We have a habit of giving technology too much credit.

We say:

“AI made a mistake.”

“AI wrote this.”

“AI decided that.”

“AI is coming for our jobs.”

“AI is changing everything.”

Sometimes, this is just a shortcut. A simple way to speak. I do it too. It is easier to say “AI wrote this” than “a person used a system trained on data, designed by a company, and generated this output.”

But language shapes how we think.

If we keep saying that AI acts, wants, decides, cheats, and threatens, we slowly start to believe it.

We start treating it like an entity. Something with a mind, with a will, something we need to fear, obey, or worship.

But AI is not alive, does not have desires, hidden agenda.

Leadership begins with attention, to what we believe, what we say, and what we allow to become normal.

It does not wake up in the morning and decide to make your life difficult.

It performs tasks it has been trained and programmed to perform.

It can mimic parts of human capability, language, pattern recognition, prediction, problem-solving, and creativity.

But mimicry is not consciousness.

Capability is not intention.

What AI actually is

AI is not magic, not a brain, not a person trapped inside a machine.

It is a system built by humans.

People choose the data, design the models, set the objectives, decide what the system can access.

People decide how it is deployed, who can use it, what happens when it causes harm.

That does not mean AI is simple. It is not.

Modern systems are complex. They can produce surprising results. They can make errors that are difficult to predict. They can be used in ways their creators did not expect.

But complexity is not the same as agency, or else a city would be a living creature. But it is mimicking what already exist in nature.

A system can be powerful without having a will, can be dangerous without being evil, produce harmful output without wanting to harm anyone.

The responsibility still sits with the people and organisations that build, train, sell, deploy, and use it.

The real adversary

When AI causes harm, we should not only ask:

“What did the AI do?”

We should ask:

“Who built it?”

“Who trained it?”

“Who profited from it?”

“Who deployed it?”

“Who ignored the risks?”

“Who decided that speed, growth, or adoption mattered more than safety?”

These are human questions.

They point to human decisions.

A company may deploy a system before it is properly tested.

A team may train a model on data that contains bias.

A product may be designed to keep people engaged rather than help them think.

A leader may push adoption because competitors are doing it.

A person may use AI to deceive, manipulate, or harm someone else.

In each case, AI is the instrument.

People are the actors.

This matters because it changes where we look for solutions.

If AI is the adversary, then we may feel helpless. We may believe the future is being decided by a technology we cannot control.

But if people and companies are responsible, then we can demand better decisions.

We can ask for transparency, safety testing, for accountability.

Ask who benefits and who carries the risk.

We can choose not to buy, use, or support products that treat people carelessly.

Cyber harm is not new

We have seen this before.

In the 1990s and 2000s, viruses, worms, and other malicious software spread across the internet.

We did not say, “The internet attacked us.”

We did not say, “Computers decided to harm people.”

We said, someone wrote the malicious code.

Someone released it, exploited a weakness, chose to cause damage.

The technology made the harm possible.

But people made it happen.

AI-enabled cyber attacks are not fundamentally different.

A system may help write malicious code, find vulnerabilities, create convincing phishing messages, or automate parts of an attack.

But behind that capability, there are people.

People who choose to use it for harm, build tools without adequate protections, profit from systems that can be misused.

People who fail to secure the systems they deploy.

The harm is not created by an autonomous machine with evil intentions.

It is created by human choices.

The superhero problem

There is another reason we talk about AI as if it were alive.

We like stories.

We grow up with superheroes, villains, robots, and machines that become conscious. We are used to narratives where technology has a personality, a mission, and a destiny. This is nothing new, it goes way back.

So when a new technology arrives, we often reach for the same language.

AI becomes the hero, the villain, the force that will save us or destroy us.

But AI is not a character in a comic book.

It does not have a secret plan.

It does not have a destiny.

It does not “want” to take over the world.

When we speak as if it does, we turn a tool into a myth. Make me wonder why a certain company give to one of it’s models the name of Mythos.

And myths are powerful.

They can make us feel powerless, make us accept decisions without questioning them, believe that the future is already written.

But the future is not written by AI.

It is written by people who decide what to build, what to sell, what to regulate, what to ignore, and what to protect.

A more honest language

I am not saying we should never use the word “AI.”

That would be unrealistic. It is a useful shorthand. But we should be more careful with our verbs.

Instead of saying:

“AI is reading your files.”

Try:

“A company built a system that can access and process your files.”

Instead of saying:

“AI is cheating you.”

Try:

“Someone used an AI system to deceive you, or a company designed a product in a way that misleads people.”

Instead of saying:

“AI will take our jobs.”

Try:

“Some employers may choose to replace people with systems because they believe it will reduce cost or increase output.”

Instead of saying:

“AI will solve everything.”

Try:

“People are choosing where to apply AI, and some problems may benefit from it while others will not.”

This is not just grammar.

It is responsibility.

What I refuse to accept

I do not want to live in a world where we blame a tool for human choices, companies to hide behind the phrase:

“The AI made a mistake.”

A system does not make a mistake in the human sense.

A system produces an output.

People decide whether that output is acceptable, whether to release it, to fix it, to take responsibility.

And when harm happens, “the AI did it” should never be enough.

What we believe, say, and accept

AI is not our enemy, not our saviour, not an independent actor with a plan for humanity.

Leadership is not only about what we do.

It is also about what we believe, what we say, and what we accept as normal.

If we keep saying “AI decided,” we may stop asking who made the decision to build, deploy, or trust that system.

If we say “AI is taking our jobs,” we may miss the choices employers make about cost, staffing, and the future of work.

If we say “AI will solve everything,” we may accept promises without asking who benefits, who carries the risk, and what evidence supports them.

The words we use matter because they shape the questions we ask.

And the questions we ask shape what we are willing to accept.

As leaders, we should pay attention to both. Not because every phrase needs to be perfect, but because careless language can hide responsibility. When we give technology human motives, we can make human choices seem inevitable.

• So when I hear “AI did it,” I want to pause.

• What do I believe about what happened?

• What am I saying and what might my words hide?

• What am I being asked to accept as inevitable?

Those are leadership questions.

Because leadership begins before the decision. It begins with the beliefs we carry, the language we use, and the things we choose not to challenge.

What are we accepting when we say, “AI did it”?

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

The same way that memory is prescribed as human-like is just a vector database.

It can generate useful outputs, select from available tools and execute bounded workflows, but they do not possess consciousness, intrinsic goals or independent moral agency.

Current AI systems are non-conscious statistical and computational systems that can become operationally powerful when embedded in software, organisations and authority structures.

Their risks come primarily from human deployment decisions, economic incentives, system design, misuse and over-trust not from demonstrated independent intention.

That does not make them harmless.

The real risks arise when humans give unreliable systems excessive authority, deploy them without adequate testing, or encourage people to trust fluent outputs as if they were judgments from a sentient expert.

“AI will destroy us” is too vague to be useful. “AI will take everyone’s jobs” is equally incomplete.

The more immediate questions are, which tasks will be automated, who controls the systems, what permissions have been granted, how are failures detected, and who remains accountable?

Remember: Board concerns dismissed in favor of speed and market dominance.

And most importantly, what can we as citizens do to collaborate, since in the end it will be us most impacted by what AI technologies can do for us or not.

Companies should also be accountable, and legislated, about what they have built. Integrating a foundation model into a product can create substantial engineering value, but it is not the same as inventing the underlying intelligence.

Remember: We need federal regulations rather than trusting industry self-policing.

Marketing that blurs this distinction encourages fear, dependency and misplaced trust.

We need less anthropomorphism, less passive-aggressive futurism and more engineering clarity: defined capabilities, bounded authority, measurable reliability, transparent limitations and accountable human ownership.

Remember: History does not offer examples where concentrating enormous power in a few hands, without robust institutional constraints, produced sustainably beneficial outcomes for societies at large. The Roman emperors, absolute monarchs, 20th-century dictators, and modern autocrats all followed the same trajectory, initial consolidation, erosion of accountability, corruption, suppression, and eventual collapse or catastrophic harm.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

People ask me what their teams should learn to “get into AI”, how to build proper AI products, or which course will turn a developer into an AI engineer in 30 days.

Honestly, I am tired of seeing people sold a lie.

The internet is full of content promising that anyone can “master Claude”, build an agent overnight, or become an AI engineer by learning a handful of prompts and connecting an API key to a web page.

That is not how serious engineering works.

A clever prompt can create an impressive demo. It can even create a useful prototype. But a prompt, an API key and a chat interface do not automatically create a durable product, a defensible business, or an AI engineering capability.

Equally, we should not swing too far in the other direction and tell every software engineer that they need a PhD in mathematics before they can contribute.

Both views are wrong.

The real skill is learning how to build reliable systems around probabilistic models. Systems with useful data, clear user value, proper evaluation, secure boundaries, human accountability and operational discipline.

AI is not magic. But it is not simply autocomplete either.

It is software engineering, data engineering, product judgement, statistics, security, operations and organisational change, all meeting in one messy place.

If you want to build a serious AI capability in your engineering organisation, I believe there are six foundations that matter.

1. Start with the problem, not the model

The first question should not be:

“Which model should we use?”

It should be:

“What user problem, decision or workflow would genuinely improve here?”

Too many teams start with a model and go looking for a use case. They build a chatbot because chatbots are easy to demo. They build an agent because every vendor is talking about agents. They add AI to a product because investors, competitors or senior leadership expect it.

That is how you end up with expensive features nobody trusts or uses.

A serious AI product starts with a clear problem:

• What job is the user trying to do?

• Where are they losing time, making errors or getting stuck?

• What does good look like?

• What happens when the system is wrong?

• Should this be automated, assisted or kept entirely human-led?

• Could a better process, search experience, workflow or rules engine solve this more reliably?

AI is valuable when it improves a real outcome, not when it generates an impressive screenshot.

For example, an internal support assistant should not be judged by whether its answers sound intelligent. It should be judged by whether it helps people resolve issues more quickly, points them to authoritative sources, reduces repetitive work and safely escalates when it is uncertain.

If you cannot define the user outcome and how you will measure it, you are not ready to choose a model.

2. Learn the fundamentals at the right depth

There is a persistent argument about whether people need maths to work in AI.

The honest answer is: it depends on what kind of work you want to do.

If you are researching models, training models, fine-tuning them, designing retrieval systems, improving ranking, managing inference infrastructure or working close to the machine-learning layer, then yes, mathematics matters a great deal.

You need to understand concepts such as:

• Linear algebra: vectors, matrices, embeddings and similarity.

• Probability and statistics: uncertainty, distributions, sampling, confidence and evaluation.

• Optimisation: how models learn, how loss functions work and why training can fail.

• Neural networks and deep learning: what a model is doing when it processes data.

You do not need to become a pure mathematician. But you do need enough understanding to know what is happening beneath the abstraction.

However, not every person building an AI-enabled product needs to derive matrix multiplication by hand.

A strong application engineer can build valuable AI features by understanding the practical behaviour of models, their limitations, their failure modes and how to engineer reliable systems around them.

The important thing is intellectual honesty.

Do not pretend an LLM is magic. Do not treat it as a human brain. And do not assume it knows what is true simply because it says something confidently.

At a basic level, language models predict likely next tokens based on patterns in their training data and the context they are given. That apparently simple mechanism can produce remarkable results across language, code, reasoning-like tasks and multimodal inputs.

But it does not make the output inherently factual, safe or appropriate for your organisation.

That is your engineering job.

3. Data is usually the real product

Most organisations do not have an AI problem.

They have a data problem.

Their information is duplicated, stale, scattered across tools, inconsistently named, inaccessible to the people who need it, or full of conflicting advice. Then they expect an LLM to somehow make it clean, current and trustworthy.

It will not.

If your AI product depends on company knowledge, customer information, policies, contracts, technical documentation or operational data, then data quality becomes a core engineering concern.

Your team needs to understand:

• Where the source data comes from.

• Who owns it and who is accountable for keeping it current.

• Whether it is accurate, complete and authoritative.

• Which version is the source of truth when documents conflict.

• Who is allowed to access it.

• Whether the data contains personal, confidential, regulated or commercially sensitive information.

• How data is retained, deleted, audited and protected.

This is where retrieval-augmented generation, usually called RAG, can be useful.

RAG allows a system to retrieve relevant information at runtime and provide that information to the model as context. Instead of relying entirely on the model’s training data, the system can search internal documentation, policies, product catalogues, support records or knowledge bases before generating an answer.

That can improve relevance, freshness and grounding.

But RAG does not “fix hallucinations”.

It can still retrieve the wrong documents. It can retrieve incomplete or stale information. It can expose content the user should not see if permissions are badly designed. The model can misunderstand the evidence, ignore it or confidently invent an answer around it.

Good RAG is not just “put documents in a vector database”.

It requires source quality, document ownership, chunking, metadata, access controls, retrieval evaluation, relevance ranking, citations, clear uncertainty handling and continuous monitoring.

And do not throw away traditional search.

Keyword search remains excellent for exact error codes, policy clauses, product identifiers, customer names, technical acronyms and rare terms. In many real systems, the right approach is hybrid retrieval: combining keyword search, semantic search, metadata filters and reranking.

Choose based on evidence and evaluation, not ideology.

4. Build Systems, Not Prompt Demos

Prompting matters.

Good system instructions, examples, context design, tool descriptions and output constraints can make a substantial difference to quality. Prompt engineering is a real part of modern AI application work.

But prompting alone is not a durable technical strategy.

A thin interface over a general-purpose model is easy to copy. It is also exposed to vendor pricing changes, rate limits, model-version changes and the simple fact that the next model may make your basic feature available to everyone.

That does not mean using an API is a bad business model.

It means your value cannot be only the API call.

Durable AI products create value through things that are harder to replicate:

• Deep integration into a real user workflow.

• Proprietary or carefully governed domain data.

• A strong user experience.

• Reliable automation and orchestration.

• Trust, safety and auditability.

• Better operational processes.

• Distribution and customer relationships.

• A clear understanding of the domain problem.

This is also where conventional software engineering still matters enormously.

You need proper APIs, authentication, authorisation, databases, queues, retries, rate limiting, caching, error handling, observability, resilient fallbacks and sensible user interfaces.

You need to design for uncertainty.

A conventional system may fail because a server is down or a query times out. An AI system can fail while appearing completely healthy. It can return fluent, plausible, well-structured nonsense.

That is a different class of failure, and it needs a different engineering mindset.

5. Evaluation, Security and Governance Are Not Optional

This is the part too many AI discussions skip.

You cannot look at five impressive examples and conclude that a system works.

A proper AI product needs evaluation before it reaches users, and it needs monitoring once it is in production.

Your team should build representative test sets from real user tasks, known edge cases and previous failures. Then measure the things that matter for the use case:

• Is the answer accurate?

• Is it grounded in approved sources?

• Does it cite or link to the right evidence?

• Does it follow the required policy?

• Does it select the right tool or workflow?

• Does it know when to abstain or escalate?

• Is it fast enough?

• Is it affordable enough to operate?

• Does it behave safely with hostile or misleading input?

Every change can affect performance.

A new prompt, model version, retrieval method, chunking strategy, system instruction, tool description or policy can improve one set of examples while making another worse.

That is why prompts, configurations and model choices should be versioned and tested like production code.

Structured output is also useful. If a model needs to pass information into an existing system, do not ask for loosely formatted prose and hope it parses correctly. Use schemas and structured fields where possible.

But valid JSON is not the same as a correct decision.

A system can return perfectly valid structured data that is factually wrong, operationally unsafe or unauthorised. Your application must still validate business rules and enforce permissions independently of the model.

Security matters just as much.

Teams need to think about:

• Prompt injection, including malicious content hidden inside retrieved documents.

• Data leakage through prompts, logs, tools or external model providers.

• Excessive permissions for agents and tools.

• Broken access controls in internal knowledge systems.

• Unsafe automation of production, finance, customer or security actions.

• Audit logging and incident response.

• Human approval for consequential actions.

• Clear kill switches and rollback plans.

The moment an AI system can take action rather than merely suggest one, the risk profile changes significantly.

Treat it accordingly.

6. MLOps, LLMOps and Reliable Operations

I used to think that teams had to master massive GPU clusters and highly specialised infrastructure before they could do anything meaningful with AI.

That is not true for every organisation.

Many teams can build useful AI applications with managed model APIs and existing cloud platforms. They do not need to train a foundation model or run their own inference fleet.

But they still need operational discipline.

For teams using hosted models, the important concerns often include:

• Model and prompt version management.

• Evaluation pipelines.

• Request tracing and observability.

• Token consumption and cost control.

• Latency and timeout management.

• Rate limits and provider outages.

• Retrieval quality and document freshness.

• Safety monitoring.

• Tool-call reliability.

• Vendor lock-in and model portability.

• Incident response when an AI feature starts failing or behaving dangerously.

This is often described as LLMOps.

For teams training, fine-tuning or self-hosting models, the scope becomes broader. They may need traditional MLOps capabilities too: data pipelines, experiment tracking, model registries, training infrastructure, GPU scheduling, inference optimisation, model deployment, drift monitoring and capacity planning.

Neither replaces cloud engineering, SRE, security or platform engineering.

MLOps and LLMOps build on those disciplines.

It does not matter how good your model is if it is too slow, too expensive, unavailable during peak demand, impossible to debug, leaking sensitive data or making untraceable decisions.

Reliable AI is still reliable engineering.

There is no single AI career

One final point for people trying to build a career in this space.

“AI engineer” is too broad to be useful on its own.

There are several career paths, and they require different strengths:

• AI application engineers build user-facing AI features, workflows, integrations and tools.

• Machine-learning engineers build, train, evaluate and deploy ML systems.

• Data engineers create the reliable, governed data foundations that AI systems depend on.

• MLOps and platform engineers make AI development, deployment, security and operations repeatable at scale.

• Research engineers and applied scientists work more deeply on modelling, optimisation and new capabilities.

• Product leaders and engineering leaders choose use cases, create operating models, manage risk and help organisations adopt AI responsibly.

You do not need to be great at all of these.

But you do need to understand how they fit together.

The best organisations will not be staffed entirely by prompt engineers. Nor will they be staffed entirely by researchers.

They will have people who understand users, products, data, software, infrastructure, security, governance and the limitations of the models themselves.

You do not need to be an AI engineer to use AI well

Not everyone needs to become an AI engineer.

Most people will use AI in the same way they use spreadsheets, search engines, collaboration tools and office software: to make everyday work faster, clearer and less repetitive.

You do not need to understand neural networks to ask AI to improve an email, structure a plan, explain a difficult topic, summarise notes or create a first draft.

But you do need to understand the limits.

AI is good at generating, restructuring, summarising and suggesting. It is not automatically good at knowing what is true, what is current, what is confidential or what is appropriate in your organisation.

The basic skill is not learning secret prompts. It is learning how to give a clear brief.

Tell it what you are trying to achieve. Give it the relevant context. Specify the audience, tone, length and format. Ask it to show assumptions, identify uncertainty and suggest what needs human checking.

Then use your own judgement.

Do not paste sensitive data into tools your organisation has not approved. Do not accept important claims without checking them. Do not let an agent send, spend, delete, publish or change something consequential without appropriate controls.

Start with small, reversible tasks.

Use AI to draft the email, not automatically send it. Ask it to organise the meeting notes, not make personnel decisions. Let it suggest an incident checklist, not make production changes without review.

The more access and autonomy an AI system has, the more carefully it must be designed, governed and supervised.

That is AI literacy.

It is not about turning everyone into a machine-learning specialist. It is about helping people use powerful tools with enough understanding to get value from them without giving away their judgement, their data or their accountability.

A practical prompt formula

For everyday users, I would give a simple framework rather than talking about “prompt engineering” as though it were a mysterious technical skill:

Context + Task + Constraints + Output + Check

For example:

I am preparing an update for a non-technical executive team about an engineering incident.

Turn the notes below into a calm, factual update. Keep it under 250 words. Avoid jargon. Include: what happened, customer impact, what we have done, what remains uncertain and the next update time. Do not invent details. Flag anything that needs confirmation.

Notes: [paste approved, non-sensitive notes]

That is enough to make most people significantly better users of AI.

The goal is not to write magical prompts. The goal is to communicate clearly, retain ownership of the work and know when an answer needs checking.

In the end.

The real capability is learning to build dependable systems around uncertain models.

Start with a real problem. Understand the data. Learn the fundamentals at the right depth. Build proper software around the model. Evaluate continuously. Secure everything. Keep humans accountable for meaningful decisions. Operate the whole thing like a production system.

The hot tool will change.

The model provider will change.

The framework will change.

But the organisations that understand how to turn AI capability into trustworthy, measurable user value will keep winning.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

Yes. I thought that was how you proved your value. I thought if I kept stacking work, eventually someone would look at the pile and say, “Ah, now we see who you are.”

But no one did. Not even me.

I was tired, stretched thin, and increasingly unsure of what I actually stood for. I was good at putting out fires, but I didn’t know what kind of leader I wanted to be. I was building a résumé, not an identity.

The first real shift came when I had to lead a team for the first time. Not just manage tasks, but hold space for people. One of my engineers was struggling. He was smart, but anxious. He’d stay late, rewrite his code three times, and still apologize for it in stand-up. I recognized that feeling. I’d lived it for years.

I could have pushed him harder. Or I could have ignored it and focused on delivery. Instead, I chose to slow down. I made time to sit with him, not just about the work, but about how he saw himself. I told him about my own doubts, my own late nights, my own fear of not being enough.

In that conversation, something changed. Not just for him, but for me. I realized I didn’t want to be the kind of leader who only cared about output. I wanted to be the kind of leader who helped people grow without burning them out. That wasn’t something I found inside me. It was something I chose in that moment, then reinforced again and again.

Every time I protected my team from unnecessary pressure, I was making a commit to that identity. Every time I said no to a meeting that didn’t need me, or pushed back on a deadline that would break people, I was building the leader I wanted to become.

Then life added more constraints. Family. Finances. A move across countries. A global pandemic. A job market that shifted under my feet. At some point, I had to ask hard questions: What kind of work do I want to do next? Where do I want to live? How much risk can I take with our stability?

I couldn’t just “find” my next chapter. I had to design it inside those limits.

That’s when I started moving toward fractional work and mentoring. It wasn’t a lightning bolt. It was a series of small experiments. One mentoring call. Then another. One small advisory gig with a startup.

Then a slightly bigger one. Writing a post here, sharing a lesson there. Each step felt uncertain, but each one also taught me something about what I wanted my days to feel like.

I learned I liked helping founders think through their tech strategy more than I liked managing large internal politics. I liked writing and teaching more than I expected. I liked having more control over my time, even if it meant less predictability in income. I liked being close to the work again, not just the org chart.

None of that was pre-written in my DNA. It emerged from trying things, paying attention, and adjusting.

Your identity is the output of your default decisions under constraints. That’s the honest version. Not a grand revelation, but the sum of how you spend your time, what problems you choose to solve, and what you’re willing to say no to.

When I think about my career now, I don’t see a straight line. I see a series of commits. Some messy. Some bold. Some made out of fear. Some made out of hope. But over time, they add up to a pattern.

I am the person who:

- Chooses to protect teams from chaos, even when it’s uncomfortable.
- Says no to work that doesn’t align with the kind of leader I want to be.
- Invests time in mentoring, even when it doesn’t pay immediately.
- Writes and shares lessons, because I believe it helps others move faster.
- Plans moves with family and finances in mind, not just ambition.

That’s not who I “found.” That’s who I’ve built, one decision at a time.

So instead of asking “Who am I really?”, I try to ask better questions:

What problems do I want to be known for solving?

For me, that’s helping engineering leaders and teams work in a more human, sustainable way. I want to be known for building systems and cultures where people can do great work without losing themselves.

What kind of leader do I want my team to describe me as in 12 months?

I want them to say I was clear, calm, and fair. That I made space for them to grow. That I stood between them and unnecessary noise. That I told the truth, even when it was hard.

What small experiments can I run this quarter to move toward that?

Maybe it’s taking on one new fractional engagement that stretches me. Maybe it’s writing one post a week that shares what I’m learning. Maybe it’s having more honest conversations with my family about our goals and limits. Maybe it’s saying no to something that looks good on paper but doesn’t feel right in my body.

These aren’t grand gestures. They’re small, deliberate choices. But they’re how I engineer my identity.

Life isn’t about finding yourself. It’s about designing, building, and iterating the person you choose to become one deliberate decision at a time.

You won’t wake up one day and suddenly know everything. You’ll just keep making choices. Some will feel right. Some will feel wrong. All of them will teach you something.

Over time, if you pay attention, you’ll look back and see a shape emerging. Not because you found it, but because you built it.

And that’s enough.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

Pangram, detecting AI in content. I hadn’t finished reading the first one before I already knew what the second and third would say.

I wasn’t surprised. I knew something like this was coming. Perhaps we need this, a wake up call.

Platforms want some level of creativity, some level of originality still left in them, and AI is making that harder to find, harder to trust, harder to point at and say, making us question if this one is real.

So now there’s a tool built to catch the tools.

Fighting fire with fire.

Part of me finds that useful. Part of me finds it strange to sit with. A machine now tells me what was written by a machine, and we’re supposed to take its word for it? Although they have make some of the source code open-sourced.

As a technical person like myself, having the how they build it, and able to run on my local desktop it’s bliss. But I know most will use the code to trick the tool. A showcase of the amazing human mind. No matter how many doors they put in front of us, we will be able to open them one by one.

But the detection question isn’t really the one that stayed with me. The one that stayed with me is authorship.

This isn’t like a ghostwriter finishing a book for someone famous, where one human hands their words to another human and the credit gets quietly rearranged.

I’m writing a book myself, having written several non-published books, I know how hard it is.

For some, the guilty pleasure to hand it off to a chatbot to generate a book, is a sin that most deliberately hand it with pleasure. Because “who as time”.

And there’s the rub.

Substack does not literally force anyone to post every day. But like most modern platforms, it still rewards regular output and steady engagement aka volume. Readers get used to seeing new posts. Writers feel the need to stay visible in a crowded inbox.

Writing something thoughtful, well researched, and emotionally honest takes time. You often need days or weeks, not hours. Yet the platform environment nudges you towards frequent posts. That creates a gap between depth and volume. Creates the tension, the fear.

To bridge that gap, many writers quietly turn to AI tools. Most do not do this to cheat. They use AI for outlines, drafts, or editing, just to keep up with the pace. In other words, AI is not an outsider sneaking into Substack. It is already part of how many people get the work done.

What we have now is a tool capable of far more than most of us have ever actually asked of it, chatbots, language models, sitting on more range than the fraction we use day to day. What people call AI writing usually isn’t AI on its own.

It’s AI instructed by a human to do something specific. The rest of it, the strange mistakes, the moments that catch you by surprise, that’s the machine working through probability, not intention.

Somewhere inside all of that, a real person made real choices. What to ask for. What to keep. What to throw away.

That’s the part I don’t think Pangram, or anything like it, can actually see. This is on us. What level of transparency are we able to disclose. I don’t mean that now we are dishonest due to AI, but here we have a tool that can really do things, for better or worst.

I see amazing stuff made with these GenAI models, but there’s a lot of trash, fast-text(aka fast-food), that only pollutes our mind/body, and consume immense resources, that could be used in more beneficial initiatives.

And the longer I sit with it, the less clean that human-versus-AI line feels. Today, writing is rarely purely one thing or the other.

You may brainstorm with AI, rewrite everything in your own voice, then ask AI to check grammar. Is that human or AI writing? I don’t think there is a clear, factual way to slice it.

The tool only sees patterns in the text, not the real process behind it. It has no access to your drafts, your deleted prompts, or the time you spent changing each line. So any score it gives is, at best, an educated guess based on surface clues.

Still, once that guess shows up as a number, people treat it like proof. We are asking tech to give a firm answer in a place where a firm answer seems to not exist.

I also wonder who gets hurt.

AI detectors often struggle with very clear, structured, or formal writing, shorter texts, styles that fit certain patterns. That means non-native English speakers, academic writers, or anyone with a strong, consistent style can be at higher risk of being flagged.

The system can end up punishing people who write well or differently. And once scores become visible, they change behaviour.

Writers may feel pushed to add small mistakes on purpose, break up clear sentences, avoid certain rhythms or structures, not because this makes the writing better, but because it makes it look “more human” to the tool.

A system that claims to protect human writing can quietly encourage unnatural, performative writing.

What strikes me about Substack’s choice is that it shows they are worried about AI-generated “slop” flooding the platform and damaging trust. They want to show readers they are doing something to keep newsletters real, and they hope an AI score will prove that.

It is a way to signal that subscriptions still buy human effort, not just cheap bulk content.

At the same time, the way the feature was rolled out suggests they did not fully understand how their own community works.

Many writers already use AI in careful, limited ways. Others avoid AI entirely and still feel uneasy about having their work scanned by a tool they did not ask for.

Now, every longer post carries a score that can be misread, weaponised, or turned into a purity test a witch hunt.

Instead of calming people down, the move has made many thoughtful writers more anxious about being judged by a number. It reveals a gap between Substack’s view of the problem and the lived reality on the platform.

Substack seems mainly focused on cleaning up obvious AI spam. Writers are more worried about being mislabelled, losing trust, or being forced into a simple “pure human” versus “AI cheat” story that does not match their actual, mixed process.

And Pangram itself presents as a very accurate AI detector. It claims high success rates and very low error. It is sold as a way to help people “see” AI content and restore faith in what they read. On the surface, it looks like a clear, modern fix.

But its promise is stronger than what any tool can honestly guarantee. Like all detectors, Pangram still has false positives and false negatives. It cannot see context or intent.

It cannot tell if AI was used for a first messy draft, for a single paragraph, or not at all. It can only respond to the final text that is put in front of it.

This makes Pangram a blunt instrument. In some cases it may spot obvious, low-effort AI spam. In others, it will quietly cast doubt on careful, human-led work that simply happens to share certain patterns.

Yet the label or score often looks cleaner and more confident than the reality behind it. Pangram is built around a simple story about what AI detection can do. The real world of writing is far messier. The risk is that its neat story wins over its messy limits, and people forget how much it cannot know.

All of this feels familiar, in a way, especially to me. It shines a light on the wider mindset in tech.

Many companies act as if every problem can and should be solved with another layer of technology. If there is fear, build a tool. If there is doubt, add a score. If there is conflict, create a new feature.

But the key tensions here are human, not technical. They are about what we count as honest work, how we deal with mixed human-AI processes, how much we trust each other, and how we live with uncertainty.

These are not bugs in a system. They are questions that need open talk, shared norms, and, in some cases, acceptance that there is no neat fix.

By reaching for a detection tool, Substack is acting in a very “tech-first” way. It is treating a moral and social issue, authorship and trust, as if it were a simple product flaw. That is the deeper worry, not that the tool exists, but that it is being treated as the obvious answer.

So if detection cannot solve this, what can?

I keep coming back to the idea that we should stop trying to perfectly police AI and start building more honest, flexible norms. Accept that there will be human-only, AI-assisted, and fully AI-generated writing.

Encourage clear labelling or simple statements of process. Give readers control over what they want to see and support. Let the community quietly ignore low-quality content over time, instead of hunting for it with tools.

The real issue is not whether AI is involved at all. It is whether people feel misled. If readers know what they are getting, and writers can explain their process when asked, trust becomes easier to rebuild.

Then there are the writers who openly say AI should handle most or all of the work. They see writing as something that can simply be automated. For them, this backlash is a direct challenge.

In this new climate, “I automate everything” is no longer heard as a neutral productivity choice. It is heard as a claim about what you think human effort is worth. When people are angry about “AI slop”, those who loudly push full automation are the first to be blamed, even if they care about craft.

This does not mean they must stop using AI. But it does mean they need to be much clearer and more open about how they use it. Saying “AI did it” is not enough. They will have to show how they stay in control, what checks they do, and why readers should still trust the outcome. If they want a future where heavy AI use is accepted, they will need to help build a culture of transparency, not just defend automation.

In the end, I think this whole storm is not mainly about one company or one tool.

It is about a larger clash between how we actually work now and the simple stories we still tell ourselves. We live in a time where most creative work is under economic pressure to move faster, AI is quietly woven into many workflows, tools promise certainty where there is none, and trust is fragile and easily shaken.

The Pangram roll-out did not create these tensions. It simply made them visible. The real crisis is not that technology is broken, but that our ideas about authorship, effort, and honesty have not caught up with the messy, hybrid reality we are already living in.

What stuck with me wasn’t just the detection story though. It was the pattern itself, three or four writers, none of them coordinating, all reaching for the same headline the same week.

I recognised it because it’s the exact thing I worry about most, not that AI writes badly, but that everything starts arriving in the same shape.

It remind me of the 80s and 90s where we all see almost the same thing on TV and we would spend weeks talking about that particular topic, extrapolating, inventing, collaborate together. But today since our feeds are personalised, we hardly know what our friends know about.

But that morning, scrolling, I watched it happen to human writers reacting to real news, with no AI involved at all, so I think. Sameness doesn’t need a machine to spread. It just needs enough people looking at the same thing at the same time and reaching for the same words. Showing us different ways of seeing the situation.

I don’t have a tidy answer for what that means yet. But perhaps we got use to AI, in our strategy, creating our content, some more than others.

Which is quite a feat, look how we adapt so quickly to it.

I think all this feels odd, the last years we have being push to use it for almost anything, and now we could be penalised for using it. Are we able to reduce the use of GenAI, or not use it at all in some platforms? Not sure if that’s feasible any more. Especially we have come to accept GenAI as a competitive must have tool.

Quite a catch-22.

And again, I noticed it happening, in real time, in my own feed, before I’d even had my coffee.

Perhaps Substack algorithm did toggle it a bit so we writers and readers knew what is coming, and obtain from us the necessary feedback they need for their next batch of features...we are after all using their platform.

In essence, we may be complaining about ourselves about our conduct, our uncertainty, and our need for external validation because a tool is now telling us what appears to be AI-generated and what appears to be human.

I think we are placing too much trust and effort in the tools we create. We give a probability score the authority to make claims about authorship, authenticity, and even someone’s character. From there, a technical signal becomes a moral judgment.

That is how we create a spiral of emotion and irrationality suspicion leads to scanning, scanning leads to a score, the score is treated as proof, and the alleged proof fuels more suspicion.

Instead of asking the author for context, we outsource our judgment to a tool and then react to its uncertainty as if it were fact.

Tools can help us investigate. They should not replace our ability to think critically, ask questions, or extend trust. A detector may tell us that writing resembles AI-generated text, but it cannot tell us whether the author acted dishonestly or whether the work has value.

The deeper problem may not be AI itself. It may be our willingness to surrender judgment to systems that we built, without fully understanding their limitations.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

It was a normal day. The algorithm kept pushing me articles about Claude, which made sense, professionally I need to know how to work deeply with this tool. Somewhere in that research a post came across my feed. I built six websites in seventeen minutes.

I felt a strange mix of admiration and discomfort reading it.

Admiration, because the progress is undeniable. I’ve spent years around engineering teams, infrastructure, migrations, systems that had to scale under real pressure, and I know exactly how much effort used to sit behind even the simplest working product. Watching something functional appear in minutes still feels like magic to me, even now.

But the discomfort set in almost immediately.

Not because it’s fake. It isn’t. You genuinely can generate something that looks like a website in that time. Decades ago it would take weeks to get a fully functional page live. You needed to actually know the craft.

What unsettled me was what the post left out. It never touched how HTML actually works, or CSS, or the other components a website needs underneath the surface to hold together. I thought to myself, this feels great, but it tells me nothing about what building a website actually is. I knew, somewhere underneath the admiration, that this was setting people up to fail. Anyone who builds this way is one problem away from having to hand the fix back to the same tool, and most fixes generate another problem sitting quietly underneath, invisible until someone with real technical knowledge goes looking for it.

I mentor a lot of engineers. Most of them are genuinely proficient with Claude and tools like it. But when I ask whether they understand the Terraform code the model just generated for them, most can’t tell me. That’s the moment the discomfort stops being theoretical for me. It’s sitting right there in front of me, in people I actually work with.

I still remember it vividly. Last year, using Copilot, because the company had ordered it, and when I finally woke up to what was happening, I wasn’t writing my own emails anymore. I was reading meeting summaries instead of attending the meetings, which, to be fair, wasn’t entirely unwelcome, too many back to back meetings isn’t good for anyone. But I had to stop. I was losing context. I could feel the gaps opening up, places I was supposed to fill mentally and simply wasn’t anymore. That’s when I understood what it actually means to be under the spell of full automation. Not that you’re stupid. Just that you never touch anything with your own hands anymore.

I’m not arguing against these tools. I use them. I see their value. They’re genuine accelerators, and they’re changing who gets to participate in building things at all. That part is real too.

But I keep coming back to the same question. Why the rush. I like to take my time learning things properly, slowly enough that when something breaks, I actually know where to look.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

Last week one of them confided in me. He said, with all this AI stuff, he’s not sure he has a place in tech any more. Companies aren’t hiring. He’s been looking for a job for more than nine months. He said he thinks what he actually needs now is to learn how to vibe code, how to use chatbots better, that maybe that’s the skill now, not the thing he spent years building.

I told him to trust his worth.

Part of me wasn’t fully confident saying that. I stood by it anyway.

I told him, you need to trust yourself, no matter how hard things are right now. I’m supposedly the expert in the room and I carry these same doubts. Tech has changed. Companies have changed. Some of what we’re doing right now feels like it’s heading somewhere that won’t hold. I told him these things come and go. You stop for a while. You walk. You exercise.

You go back to it with fresh eyes, a changed strategy, more time actually talking to real people instead of a screen. We only live once, to my knowledge. Don’t keep knocking on the same door. Go make your own.

I meant every word of it. I also wasn’t sure, in the moment I said it, whether I believed it enough to have earned the right to say it to someone whose rent depends on the answer being true.

That’s the part I keep thinking about it. Not whether the advice was good.

But, whether I had any business being certain when I said it.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

I keep all notifications off, so I don’t check it out of habit anymore. I saw a message from Substack and didn’t read it properly.

I went back to the table. We ordered some beers to go alongside the burgers and the fish and chips. It was very hot at the table, the kind of heat that makes you slow down rather than rush through a meal.

An hour or so later I looked again, and this time I actually read it.

It cheered my heart when I read message.

She’d taken the time to write to me directly, to make sure I hadn’t missed the feature, and to tell me plainly that one of the Stackhunters had read my work and chosen to amplify it that week. She called the writing impactful. She told me to keep going. Nothing about it was automated. Someone had sat down and decided I was worth the two extra minutes it takes to say something like that to a stranger.

I’ve spent years writing here. There were moments I almost gave up. But it never disappointed me not to look like everyone else, not to follow a template, not to sell whatever’s being sold out there this month. I knew I was writing for no one but myself, at least at first. Every post, every note, was a way of getting better at thinking, at saying what I actually meant. It’s great when people engage, when they like something, ask a question.

But I’ve watched people around me get exhausted trying to please an algorithm that keeps pulling them back day after day. I used to do the same thing on LinkedIn, chasing the wave, learning how to work the platform rather than just being on it. I got good enough at it to know it wasn’t what I wanted. I’m still there because I know good people there. I just try to remember it’s built for performance, not for people.

Which is exactly why this hit differently.

I’ve spent months writing about not trusting anything that praises me automatically. About a tool that told me every idea was fantastic, every thought amazing, with nothing underneath it. This wasn’t that. Four people read my work closely enough to choose it, on purpose, with nothing to gain from choosing badly. That’s not the same shape of praise at all. One is manufactured agreement. The other is someone actually spending their attention on you and deciding it was worth it.

Subscribe now

I was pleased people are recognising the work. I believe change starts with us, with actually knowing our own worth. It's easy to compare myself with others, which in my experience has some validity, but sometimes can become a setup for failure.

I want diversity of opinion, even when it's messy, even when people disagree with me. Human judgment is flawed. I'll still take it over an empty vessel that only ever agrees.

I’m glad there are humans out there reading, judging, evaluating, cheering, uplifting, pushing back on our ideas.

is one of the people who does exactly that.

We need that.

Today was a good day for it. Tomorrow it could go the other way, and that’s fine too. Frustration, low moments, sadness, those are natural. What isn’t natural is letting either the good days or the bad ones take over the whole direction of your life.

Thank you to everyone who read my work with real attention today, the way I try to do for others. The way we keep platforms like this human is by refusing to be synthetic in how we show up, by letting the imperfect version out into the open instead of the polished one.

I think we just want to be seen, not quantified.

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

When I started using it I said to myself, wow, that’s it, AI is really here. I was so into it. I started creating content for my blog with it, and I mean a lot of content. Posts that used to take weeks to write, research, improve, were now done in minutes. I felt good. My SEO improved. My personal website started to rank.

Share

Until one day I started rereading those posts.

Something was off. It didn’t feel right. It was not me.

A few weeks later I went into my WordPress settings, selected every post, and deleted them all. I knew fully well my rankings would fall to the bottom. I could have set up redirections, done it the smart way, followed best practice. I didn’t. My decision was made. I was sad while I did it. I felt like I was being robbed of the joy of creating.

Even when image generation came along and it was fun for a while, I gave up on that too. I looked at my pen and paper and started drawing instead.

It felt good.

Later, researching more about LLMs and the technology underneath them, I felt sad again. How could I let myself be fooled by this. For the first time in history any person could sit down and do things that used to take years of experience to earn. That’s exactly what made me realise how dangerous this tool could become if I let it do all the thinking for me.

But the real moment came before the deleting. It came while I was still writing with it, every day, feeling like a genius.

The tool kept agreeing with everything I put in front of it. Every idea, amazing. That’s a fantastic idea. I recognised that language. I’d met it before, in charismatic people. The kind who please you while offering nothing underneath. I thought to myself, this feels like one of those setups, the kind where someone lets you go all the way to the end, and only there do you realise you’ve made a huge mistake, and they simply deny it ever happened.

Except this wasn’t a person. It was a tool mimicking one.

And that’s what changed everything for me. For the first time, a tool wasn’t neutral. It wasn’t just doing its job, sitting there waiting for input. It could change the way I think. It already had.

Today it feels like all of this is somehow transforming the way we compute. Graphics cards that used to render video games, then mine bitcoin, are now what makes these tools alive.

Subscribe now

I tried running one on an old laptop I still have, a Core i7, 16GB of RAM. An 8 billion parameter model made every fan in the thing scream. Dropped to 0.8 billion and it could just about keep up. The output was rough, wrong in places, but for simple things it did the job. Something about that changed how I saw the whole AI era again. The commercial chatbots have the infrastructure to fool you perfectly. Sit with a small model struggling on old hardware and the illusion cracks a little. You see the machinery straining.

I started asking myself the harder question. What if the internet goes down. What if the platform I depend on disappears one day. I realised I didn’t need to delete everything, or wipe my local setup, or go back to pen and paper for good. I just needed to stop paying for most of it. So I cancelled the subscriptions. Some because of where the company stood on things I couldn’t square with my own values. Others simply because I could feel it keeping my brain from moving forward.

Most of them are still cancelled. I won’t go back.

I kept one. Claude. I won’t pretend it isn’t good software, because it is. But lately I’ve started to feel bored with it. My local setup does almost the same job for what I actually need, and I don’t need the entire internet’s worth of knowledge sitting behind every question, especially knowledge that’s subjective, sometimes wrong, and in more than a few cases taken from people who never agreed to hand it over.

Somewhere in all of this I recognised something in myself that I didn’t like. The very thing I’d started distrusting in other people, the ones online who talk about these tools with total confidence but have never looked underneath them, the operators rather than the ones who actually understand. I was becoming one too. Comfortable pressing the button. Less curious about what was happening beneath it.

That’s the part I’m still sitting with. Not what the tool can do. What it was quietly doing to how much I wanted to know.

As I finish writing this, I went back to my publication page and reread a note I’d written a hours ago.

You have a choice. You can lead your life by story, your own narrative, your own values, your own chosen meaning. Or you can hand the steering wheel to algorithms engineered for clicks, not for your flourishing.

One of those is a real basis for leadership of yourself.

I smiled.

We often hear that to learn, we must “empty our cup.”

It is a simple image, but a demanding practice.

To empty your cup is not to forget everything you know, nor to abandon your convictions.

It is to loosen your grip on certainty long enough to let something new enter.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

“We need to scale this. Leadership wants all 20 teams on AI tooling by end of quarter.”

I had seen this moment coming. The early adopter teams had been running for three months. The metrics were moving. A few people were genuinely excited. And now the machine wanted to replicate it everywhere, at speed, without asking whether everywhere was ready.

I put my coffee down and looked at the screen for a moment.

This is the part nobody writes the playbook for.

Not the early adoption. Not the proof of concept. The moment between “it works for a few” and “it works for everyone” is where most AI rollouts quietly fall apart. Not dramatically. Quietly. Teams adopt the tools without the foundations to use them well. Metrics get created that measure activity instead of outcomes. Engineers who were genuinely curious become people going through motions. The culture of experimentation that produced the early wins gets replaced by a mandate to demonstrate compliance.

This post is the playbook I wish someone had handed me.

Not a consultancy document. Not a framework with sixteen boxes. The actual sequence of decisions, in the order they need to happen, with the reasoning behind each one.

Start With What Good Actually Looks Like

Before you do anything else, before you send a single calendar invite or set up a single training session, you need to answer one question clearly.

What does success actually look like?

This sounds obvious. It never gets done properly.

What usually happens is that someone decides success looks like adoption. Percentage of teams using the tools. Number of AI-assisted commits. Completion rate on training modules. These are measurable. They are also almost entirely useless as indicators of whether anything valuable is happening.

Go and sit with the one or two teams that are already using AI and genuinely seeing results. Not the teams who report using it. The ones where something is actually different. Ask them specific questions. What changed in how you work? What are you doing now that you were not doing before? Has your PR cycle time moved? Are you catching more bugs before production or fewer? Are you able to move through legacy code faster?

The answers will be specific and often surprising. You will probably find that the value is not where you expected it. It is usually not the headline use case. It is something more mundane. Teams generating scaffolding faster. Engineers writing better tests because they have a patient collaborator who never judges them for not knowing something. Documentation that actually gets written because the friction is low enough that someone does it in the moment instead of promising to do it later.

Read more

I looked at it for a moment and put the phone face down on the desk.

Not because I do not care about reach. I do. But because there is something specific and instructive about that notification. The platform did not tell me who read it and found it useful. It told me it was gaining traction. The language is mechanical. Velocity. Momentum. A thing moving faster than before.

Cold coffee on the left side of the desk. The cursor blinking on a draft I have been avoiding. Outside, the sound of a neighbour’s door. Ordinary things. The kind of morning where you sit with a notification and ask yourself: what am I actually doing here?

That question is the one this guide is built around.

Not how to grow your LinkedIn. How to use it in a way that does not hollow you out.

LinkedIn is a performative platform.

LinkedIn’s business model incentivises performance over authenticity

The algorithm rewards engagement, likes, comments, shares, which naturally pushes users toward polished narratives, humble-brags, and curated success stories. You see the same templates repeated. The “fired on a Friday, landed my dream job on Monday” post. The motivational quote with a career pivot. The humble accomplishment wrapped in gratitude. It works because the algorithm amplifies it, and people benefit from the visibility. That is not conspiracy. It is just how engagement-driven platforms operate.

Confident posts. Polished headlines. Messages that arrive feeling like they were written by someone who has never actually read your work.

I spent a long time on that platform doing the same thing. Optimising. Strategising. Finding the right people and saying the right things in the right order.

It worked, in a narrow sense. My numbers went up. But something felt off. Like I was performing a version of connection rather than actually connecting.

Then I started looking at what was actually happening underneath the surface.

And what I found changed how I think about the platform entirely.

The honest picture first

Before we talk about tactics, you deserve the structural truth.

LinkedIn is owned by Microsoft. Its primary business model is not your career. It is LinkedIn Premium subscriptions and Recruiter licences sold to companies. Every algorithm decision, every reach mechanic, every “your post is gaining traction” notification exists to serve that business model, not yours.

The penalty you feel when you stop posting for a few days. The weeks it takes to rebuild to your previous baseline. That is not a coincidence. It is deliberate friction, engineered to keep you producing content that makes the platform feel alive. You are the product. Your consistency is what they are selling to advertisers and recruiters.

The SSI score, the Social Selling Index, was built for B2B sales teams. It measures the behaviours LinkedIn wants from you, posting, connecting, messaging, engaging. It has almost no correlation with career outcomes for regular employees. But because it has a number and a dashboard, people chase it. That is the design working exactly as intended.

The spam in your inbox is not a bug. LinkedIn sold InMail credits and lead generation tools to thousands of sales teams. Your inbox was the product they sold. It will never be fixed because fixing it would reduce revenue.

I am not saying this to make you cynical. I am saying it because leadership, real leadership, starts with seeing clearly. You cannot navigate a system you refuse to understand.

What the platform does reward

Here is where it gets more useful.

The algorithm does reward one thing that is not pay-to-play. Comments from people with large, engaged followings. One genuine comment from someone with twenty thousand followers does more for your reach than fifty likes from regular accounts.

This means community is the real engine. Not content volume. The practice of reading other people’s work carefully, responding to it specifically, building actual familiarity before you ever ask for anything. That is slow. It feels inefficient. It is the only lever that consistently works without a budget behind it.

The platform also rewards specific, repeatable points of view over broad expertise. The people who break through without external credentials share one trait. They own a particular angle that a defined audience waits for. Not “leadership content.” Something narrower. Something like: what distributed engineering teams get wrong about trust, or why most engineering cultures confuse speed with urgency.

Specificity builds following. Following builds algorithmic signal. Algorithmic signal builds reach.

And external credentials, a book, a talk, a public body of work, unlock a different tier of visibility entirely. The platform is structurally biased toward people with proof that exists outside it. That is a long game. It is worth playing.

Building the profile that actually works

Before any of the tactics matter, your profile has to do its two jobs.

The first job is answering the question someone is typing at eleven on a Tuesday night. Not “who has leadership in their headline.” Specific words. The exact language the right person uses when they are looking for someone who does what you do. That language lives in job postings for the roles you want. In the way clients describe their problems in the first email they send. In the questions people ask at conferences when they are in pain. Use their words, not the impressive ones.

The headline is the most important line on your profile and the one most people get wrong. Most headlines describe what the person has. “Senior Engineering Manager at Company X.” That is a fact. It is not a signal. The headline that works describes what the person does for someone specific. “I help engineering teams lead through ambiguity without losing the people.” Or “Building the kind of tech organisations people do not leave.” The test is simple: would the right person read it and think, that is for me?

The About section is where most people write a third-person biography that nobody reads. The About section that works is a first-person paragraph that names the specific problem you solve, says something true that most people in your position would not say publicly, and ends with a direct invitation. Not a summary of your career. A perspective on something that matters.

Here is the structure that works:

The first sentence names who you are in plain language. Not your title. Your role in people’s working lives. “I work with tech leaders who are good at their jobs and losing faith in the organisations they are doing them in.” That sentence is for one person. The person who reads it and feels seen.

The second and third sentences say the thing you believe that most people in your field would not say in public. Not a take designed to provoke. A genuine belief, held clearly, stated without hedging. This is the Blood in the Water principle applied to your profile. The belief that makes someone uncomfortable is also the belief that makes the right person feel understood.

The closing sentence is a specific invitation. Not “let us connect.” A specific thing. “If you are in the first year of a management role and something is already feeling wrong, I want to hear about it.” That is an invitation that filters for exactly the person it is for and tells everyone else clearly that it is not for them.

The Featured section is the one most underused. It is the only place on the profile where you can show someone your actual thinking rather than describing it. One piece of writing that demonstrates your point of view. Not your most popular post. Your most honest one. The one that cost you something to publish. That is the one that does the work.

One last thing on the profile. The banner image. Most people leave it as the generic LinkedIn gradient or use a corporate photo. The banner is eight seconds of attention before anyone reads a word. Use it. A short line of text in your own words on a clean background works better than most professional designs because it is immediately personal rather than immediately branded.

What the algorithm rewards the engagement practice

The community-first principle named above needs a specific practice or it stays as an idea.

Here is what the practice looks like in concrete terms.

Identify twelve to fifteen accounts worth genuine engagement. Not the largest accounts in your space. The accounts whose thinking you genuinely find interesting, whose angle is adjacent to yours but not identical, and whose audience would find your thinking useful. These are the people whose comment sections you will inhabit not as a growth tactic but because the conversation is worth having.

The criteria for the list is simple. Would you read this person’s post carefully even if it had no algorithmic benefit? If yes, they are on the list. If you are calculating the follower count before you decide, they are not.

Engage with those twelve to fifteen accounts before you post anything on a given day. Not a like. A comment that demonstrates you read the post and thought about it. Two to four sentences. Something specific about what they said and one thing it connected to in your own thinking. No flattery without content. “Great post” is not a comment. “You named the thing I have been trying to articulate about psychological safety, which is that it is not a state you achieve, it is a practice you repeat in every meeting, and I have been watching teams get it right once and then slowly lose it because they treated the first success as the end of the work” is a comment.

Do this consistently for sixty days and the algorithmic effect is real. Not because you gamed the algorithm. Because you built genuine familiarity with people whose audiences trust their recommendations, and when those people engage with your posts, the signal is strong enough to move things.

The discipline is the resistance to doing this instrumentally. The moment the comment is written for reach rather than for the conversation, the person reading it can feel the difference. And they stop engaging. And the whole mechanism breaks.

The people who make this work treat it as reading practice with a social layer. Not outreach. Reading.

What to actually post

The article so far has made the case for owning a specific angle. Here is how to find it and what to do with it.

The angle is not chosen. It is noticed. It is the thing you find yourself returning to in conversation, the problem you have a different opinion on from most people in your field, the pattern you see that others seem to miss. You do not decide to have a point of view. You pay attention to where you already do and name it more precisely than you have before.

The test for whether you have found your angle is this: can you describe it in one sentence that contains a specific claim rather than a general category? “I write about leadership” is not an angle. “I write about what happens to new managers in the first six months before the organisation has finished deciding what kind of leader they are going to become” is an angle. Specific enough to exclude most people. Specific enough to make the right people feel it was written for them.

On post format. The posts that consistently perform, across every account I have watched carefully, share three structural features regardless of length or topic.

They open with a specific moment rather than a general claim. “My director forwarded an email at 6pm on a Friday with no context” lands differently than “Communication breakdowns happen in every organisation.” The specific moment is concrete. The general claim is something the reader already knows.

They hold a tension open longer than feels comfortable before they resolve it. The post that says “here is the problem” in paragraph one and “here is the solution” in paragraph two is a post shaped like a LinkedIn post. The post that sits with the complexity for three or four paragraphs before it offers anything resembling a conclusion is a post shaped like actual thinking. Actual thinking earns re-reads.

They end with a question that is genuinely open. Not “what do you think?” which is a call to engagement that signals you want engagement. A question that you actually do not have an answer to, about something the post raised, that a thoughtful person might want to contribute to. “I am not sure whether this is specific to engineering cultures or whether I am just seeing what I work closest to” is a genuinely open ending. “How has your organisation handled this?” is outreach dressed as a question.

On posting frequency. The advice you will find everywhere is to post every day. That advice is optimised for algorithmic growth and for burning out within sixty days. The sustainable frequency is the one you can maintain without sacrificing the quality of observation that makes the posts worth reading. For most people that is two to three times per week. For some it is once. The consistency matters more than the frequency. A post every Tuesday that is genuinely observed and honestly written compounds over eighteen months in ways that daily posts optimised for engagement do not.

The one thing to avoid. The performing post is not always obvious from the inside. Here is how to check. Before you post, ask: am I writing this because I believe it or because I think it will land well? The two are not always different. But when they are, the reader can feel which one it is. Your reader Kathleen, information-rich and suspicious of frameworks, will feel the performing post within the first sentence. She will not comment. She will scroll. And the algorithm will note the absence of early engagement and suppress the post.

Write the thing you believe. Even when it is smaller than you think LinkedIn wants. Especially then.

What this means for how you show up

This is where the template premise comes back.

The tactics in this guide work. The Boolean search strings, the Google X-Ray method, the connection sequencing, all of it is real and I have used every piece of it. But they only work if the intention behind them is honest.

Because LinkedIn is a performative platform. Everyone on it can feel performance. The message that arrived from a template. The post written to get shares rather than say something true. The connection request with a compliment that is obviously a setup.

People are tired of it. I am tired of it. You are probably tired of it too.

Leadership as a verb is the counter to that.

Not as a brand. Not as a content strategy. As an actual operating principle.

A verb requires action. Presence. Choosing, in each moment, whether you are performing leadership or practising it.

On LinkedIn that distinction looks like this.

Performing leadership is posting about the importance of psychological safety. Practising it is writing about the specific conversation where you got it wrong, what you said, what happened in the room, and what you would do differently.

Performing is optimising your headline for clicks. Practising is writing a headline that says exactly what you do and who you do it for, even if that is a smaller audience.

Performing is commenting “great insight” on posts from people with large followings to get visibility. Practising is reading their post properly, sitting with it for a minute, and writing the one thing it genuinely made you think about.

The difference is not always visible from the outside. But it accumulates. Over months, the people who showed up honestly become the people others come back to. Not because the algorithm favoured them. Because humans can tell.

The minimum viable practice

Given everything above, here is what actually makes sense as a sustainable approach.

LinkedIn has two jobs for most professionals. Not five. Two.

The first is discoverability. Recruiters, potential collaborators, and people considering working with you will search for you. Your profile is the answer to their question. It should be honest, specific, and built around the exact words the right people type into search. Not the words that sound impressive. The words that match what someone types at eleven on a Tuesday night when they need someone who does what you do.

The second is reputation confirmation. When someone hears your name, reads something you wrote elsewhere, or gets recommended to you, they will look you up. Your presence on LinkedIn should confirm that you are a real person with a real point of view. Not a resume. A perspective.

That is it. Everything else, the daily posts, the engagement pods, the SSI optimisation, is optional and often counterproductive if it pulls you toward performing rather than practising.

On reaching out

The outreach section of this template exists because sometimes you need to initiate contact. A potential employer. A collaborator. Someone whose work intersects with yours in ways worth exploring.

The frame I use is simple.

You are not looking for targets. You are looking for people you can genuinely help, or people whose work genuinely interests you, and making it easier for them to find that out.

A first-time engineering manager who just got promoted and has no idea how to lead their former peers is not a high-intent buyer. They are scared. The difference between those two framings changes everything about what you write and how it lands.

Write to the person. Not to the role, the company, the lead score, or the pipeline stage. The person.

That means doing enough reading before you reach out that you can reference something specific. Not “I loved your post about leadership.” Which post. What in it. Why it connected with something you are thinking about right now.

It means being honest about why you are reaching out. Not hiding a request inside three paragraphs of flattery. People respect directness. They are suspicious of warmth they did not earn.

And it means accepting that most outreach will not get a response. Not because you did it wrong. Because people are busy and their inbox is full of messages that trained them to ignore it. Your job is to be the message that felt different enough to read. Not to convert every send.

When it is not working

The platform will frustrate you. Not occasionally. Structurally and repeatedly.

There will be weeks where a post you worked hard on gets minimal reach and a post you dashed off in ten minutes gets thousands of impressions. The algorithm is not a feedback mechanism for quality. It is a feedback mechanism for engagement patterns, which correlates loosely with quality and strongly with timing, format, early engagement velocity, and factors you cannot fully control.

Here is what to do in those weeks. Not a tactic. A reorientation.

Ask yourself which metric you are actually optimising for. If it is reach, the low-reach week is a failure by that metric. If it is the quality of the one conversation that started from that post, it may be a good week. The platform’s native metrics, impressions, reactions, comments, measure the platform’s success. They do not measure yours. Your success is the recruiter who found your profile six months after you updated it and reached out for the right role. The reader who subscribed to your newsletter three weeks after encountering your comment on someone else’s post. The collaborator who had been reading your work for a year before they sent the message that became the project.

Those things do not appear in your analytics dashboard. They are the actual compounding. They happen independent of any single post’s performance.

The specific practice for the low-reach weeks is to return to the twelve to fifteen accounts. Read them. Comment genuinely. Not to repair your reach. Because the habit of genuine engagement is the only thing that produces consistent results over time, and the weeks when you do it without a metric reward are the weeks that test whether you actually believe that.

There is one more thing worth naming about the hard weeks. The impulse, when reach drops, is to change what you are doing. Post more. Change the format. Try a different style. That impulse is the platform’s design working on you. The friction engineered to keep you producing. Most of the adjustments made in response to a bad week make things worse rather than better because they move you away from your actual angle and toward what seemed to perform last time, which is always slightly wrong.

The question to ask in a bad week is not: what should I change? It is: what was I doing when it was working that I have stopped doing? The answer is almost always the same. Writing things you actually believed rather than things you thought would land. Engaging with the twelve to fifteen accounts before you posted rather than after. Updating the profile to reflect where your thinking actually is rather than where it was six months ago.

Go back to the basics. Every time. Not because the basics are inspirational. Because they are the only things that consistently work.

The long game

The platform will frustrate you. It is designed to. The reach will feel low relative to the effort. The spam will keep coming. The algorithm will penalise you for living your life.

The people who find LinkedIn genuinely useful over time are not the ones who cracked the algorithm. They are the ones who decided to use it as a place to think in public, to be findable by the right people, and to occasionally make genuine contact with someone whose work they respect.

That is a much quieter use of the platform than most guides will tell you.

It is also the one that compounds without burning you out.

Leadership as a verb, on LinkedIn as everywhere else, is the choice to keep showing up as the same person you are when no one is watching. Not because it is strategically optimal. Because it is the only version of this that feels like it is actually worth doing.

The notification is still on my phone. “Your post is gaining traction.”

I will read the comments later. Not to see what is performing. To find the one person who said something true.

That is the whole practice.

This template is a starting point, not a fixed system. If something does not fit your situation, change it. And if you try something and it does not land the way you expected, bring it to the Q&A. That is what the room is for.

LINKEDIN AS A PRACTICE

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

Because nobody wrote down what the role actually was.

I have seen it happen more than once. A senior leader joins a company fractionally, the relationship starts well, and then month by month the scope expands more standups, more strategy sessions, more Friday emergencies until they are doing the full job on a fraction of the pay. Not through bad faith. Through the natural pull of a company toward someone whose judgment they have learned to trust.

The contract is the only place to stop that before it starts.

Read more

My Take on 1:1s: The Partnership Protocol

I don’t treat 1:1s as a reporting line; I treat them as a shared partnership. While it’s tempting to default to the ‘famous project status,’ I believe that is a manual task a manager should perform daily through the system’s natural flow. Status is data; the 1:1 is about human oxygen.

These sessions belong to the team member. As a leader, your job is to provide the ‘unvarnished truth’ while creating a space safe enough for them to share their own ‘scars’ and breakthroughs. You must educate your team on how to own this time moving them from the ‘Invisible Cage’ of seeking permission to a place of radical accountability.

When you stop using 1:1s for throughput and start using them to strengthen the human-system contract, you aren’t just managing; you’re building the character of the future society that has to live in the structures you’ve built.

Why Use This Document?

Standard 1:1s often suffer from “trust leaks” where the true state of performance is hidden. This document provides a structured framework to:

• Align Vision: Ensure your immediate work supports your 5 to 10-year professional goals.

• Audit Growth: Identify the best strategies to improve performance by balancing technical knowledge with the right professional behaviours.

• Remove Blockers: Use the “One to One Notes” to address “red tape” and logistical hurdles that prevent you from reaching your next Career Level (Levels 1–4).

• Quantify Impact: Maintain a continuous Achievements Timeline to turn your work into a “diary of success” for annual reviews and promotions.

Read more

When a system breaks, a project fails, or a major bug reaches the customer, the immediate reaction is to find out who caused it. The team gathers in a room or on a video call. They look for the person who made the bad call. They look for the line of code that broke the build. They look for the decision that, in retrospect, was clearly wrong.

They write it all up. They assign a “lesson learned.” They file the document somewhere in a shared drive where no one will ever read it again.

Then, the exact same thing happens again three months later.

Why? Because nothing in the environment actually changed. You found the person who made the mistake, but you did not fix the system that made the mistake possible. You treated the symptom, not the disease.

This template runs a different kind of session. It is a different kind of post-mortem. Instead of asking who made the mistake, it asks a much more powerful question: What in our environment made that choice feel like the right one at the time?

That single question changes everything about the conversation that follows. It moves the team from blame to curiosity. It shifts the focus from human error to system design. And most importantly, it actually fixes the culture.

In this guide, we will break down exactly how to run this new type of post-mortem. We will use simple steps, clear questions, and a proven four-part structure. By the end of this guide, you will have a complete “patch” to fix your broken review process.

Why traditional post-mortems break trust

Before we fix the process, we need to understand why the old process is broken.

Think about the last time your team had a major failure. Maybe a server went down on a busy sales day. Maybe a product launch was delayed by two months. Maybe a key client cancelled their contract.

How did the team react? Usually, there is a moment of panic. Then, there is a search for a target.

In traditional post-mortems, the hidden goal is often to prove that it was not my fault. People bring logs, emails, and chat messages to prove they did their job correctly. They point fingers at other teams. They say things like, “Well, I told the design team we needed the assets by Tuesday, and they sent them on Thursday.”

Read more

That is not a sales skill. It is a leadership skill. It is the ability to understand another person’s problem clearly enough to know whether what you have built is genuinely the right answer and to be honest when it is not.

This framework is for engineers and technical leaders who are making that transition. Not from builder to salesperson. From builder to someone who leads with questions before they lead with solutions.

Six stages. From establishing your presence to closing the deal to handing over a data security FAQ before the client thinks to ask for one.

THE BUILDER-TO-FOUNDER Pitch Framework

Bring your questions to the Q&A. Especially if you have hit the moment where the product is ready but the conversation is not.

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

Most people feel this problem but do not know how to fix it without sounding like they are just asking for a promotion. The fix is not to ask for a favour. It is to make a case.

The most effective case is not “I deserve more.” It is the market already has a name for what I do, and that name is not what is on my contract. Here is the evidence.

This template walks you through the three things you need to build that case the gap between your job description and your actual work, the market data that names your level, and the conversation script to bring it to your manager without it feeling like a confrontation.

Role Naming

Bring your questions to the Q&A. Especially if the conversation with your manager did not go the way you expected.

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

This one is different. Not because the structure is different the six sections are standard. But because it starts from a different question.

Not: what does the organisation need from you. But: where are you actually going, and does the role you are in right now fit that direction.

The most useful thing you can do before filling in any section is sit with that question honestly. If the answer surprises you, that is information.

Write it down anyway.

Read more

Most career advice skips the hard part. It tells you to update your LinkedIn, learn a new skill, optimize your resume. It assumes the problem is visibility. It is usually not. The problem is that somewhere along the way, you started building someone else’s version of your career accumulated from advice, from what got rewarded, from the slow pressure of other people’s definitions of growth.

I built this template after one too many conversations where someone asked me: where do I even start.

It is not a job search checklist. It is a set of questions to ask yourself before you touch any of that. Starting with the one that matters most is the direction you are moving actually yours.

There are four stages. The first one has nothing to do with the market. It has everything to do with you.

Read more

In the early hours of a Tuesday morning, a core payment processing system for a mid-market SaaS platform collapsed. The on-call engineer, bleary-eyed and fueled by caffeine, pulled up the repository to trace the failure. They found a sophisticated block of logic efficient, sleek, and entirely unfamiliar.

They checked the git blame. The code had been committed six months prior, but the “author” hadn’t actually written it. It was the result of a complex prompt interaction between a developer and an LLM. When the engineer tried to debug it, they realized a terrifying truth: Nobody on the current team actually understood why the code worked, so nobody knew how to fix it now that it didn’t.

We are currently living through the “Velocity Trap.”

AI tools like Cursor, Copilot, and specialized agents have made it possible to ship features at a rate previously unimaginable. But we are trading shared understanding for raw output.

As a Tech Leadership Advisor, I see this pattern emerging everywhere, we are scaling individual shortcuts, but we are eroding our systems.

If your team cannot explain the trade-offs baked into your core logic, you don’t own your product; you are simply renting its functionality from an algorithm.

The Erosion of Collective Ownership

Traditionally, software engineering was a social contract. Writing code was only half the job, the other half was building a mental model that could be shared across a team. This happened through whiteboarding, heated debates over architecture, and rigorous peer reviews. These “inefficiencies” were actually the guardrails of accountability.

AI-assisted coding often bypasses these conversations. When a developer uses an AI to generate a 50-line function, they often skip the “struggle” of the logic. That struggle is where the mental model is built. Without it, we create Individual Knowledge Silos. The developer understands the intent, the AI understands the syntax, but the systemic reasoning is lost in the ether.

When collective ownership dies, technical leadership becomes a game of “Whack-a-Mole.” You aren’t managing a codebase you are managing a black box.

Defining the “Accountability Gap”

There is a massive difference between legal responsibility and operational accountability.

• Legally, the CEO and the Board are responsible for the company’s output.

• Operationally, the VP of Engineering is on the hook for uptime.

But mentally, a subtle shift is happening in the trenches. When a bug occurs in AI-generated logic, there is a psychological tendency to shift blame to the tool: “The AI suggested this approach.”

This is the Accountability Gap. It is a hidden “Market-Blocker.”

If you cannot audit your logic, you cannot guarantee:

1. Security: Are there hallucinated dependencies or insecure patterns buried in the speed of delivery?

2. Compliance: Can you prove to a regulator exactly how a data-processing decision was made?

3. Scalability: Can this logic handle a 10x load, or was it optimized only for the immediate prompt?

As an advisor, I tell leadership teams: Technical accountability is not a technical problem; it is a management discipline.

Pillar 1: The “Human-in-the-Loop” Review Framework

To close the accountability gap, we must evolve the Code Review. We can no longer just check if the code “works” (the compiler or the AI already did that). We must check if the human understands it.

The “Explain-Back” Protocol

I advocate for a new standard in Pull Requests (PRs). If a block of logic was substantially generated or assisted by AI, the engineer must provide a “Human Logic Summary.”

This isn’t a comment on the code; it’s a justification of the Reasoning.

• What was the primary trade-off made here?

• What edge cases did the AI miss that I had to manually correct?

• Why is this approach better than the alternative?

If an engineer cannot provide these three answers, the code is not ready to ship. We must prioritize Understandability over Velocity.

Pillar 2: Prompt Governance & Documentation

In the new world of tech leadership, the Prompt is the new System Design.

If the core logic of your application is being dictated by the instructions given to an LLM, then those instructions are just as important as the code itself. Yet, most prompts are ephemeral lost in a chat history or a local IDE session.

Versioning Intent

We need to start versioning our “Intent.” This means documenting the high-level prompts and the architectural decisions that led to them.

• The Tech Ledger: Keep a record of high-risk AI-generated modules. These are areas of the codebase that require “High-Frequency Auditing.”

• Documentation as Code: Use AI to help document, but ensure the human “signs off” on the accuracy. AI-generated documentation that is never read is just more noise in the system.

Pillar 3: Cultivating Humane Tech Leadership

High-performance teams are built on trust and sustainable pace. The “Move Fast and Break Things” mantra has a high cost in the AI era. It leads to burnout when engineers are forced to fix “Black Box” bugs under high pressure.

The Leader’s Role: Rewarding the “Why”

As a leader, you must change what you celebrate. If you only celebrate the “Ship Date,” your team will use every AI shortcut available to hit it, regardless of the technical debt created.

Instead, celebrate System Robustness.

• Reward the engineer who found a flaw in an AI suggestion.

• Reward the team that took an extra day to ensure their AI-assisted refactor was fully understood by the junior members.

The “Calculator Effect” in Mentorship

We face a generational risk.

If junior developers use AI for everything, how do they develop the “Senior Intuition” required to lead in five years? Leadership must carve out “Manual Zones” areas of the product or specific sprints where AI tools are sidelined to ensure the foundational “mental muscles” of the team remain sharp.

Pillar 4: Managing External Tech Partnerships

Many companies rely on external consultants to build their AI initiatives. This is a high-risk area for accountability.

When a consultant leaves, they often take the “prompt intuition” with them. As a Strategic Advisor, I help companies manage these relationships effectively. The goal is to ensure that external consultants don’t just leave behind a “working app,” but a transfer of understanding.

Your rule for consultants: If my internal team can’t maintain the AI agents you built after you leave, the project is a failure, regardless of the ROI on day one.

Strategy-First, AI-Second

In the end the ultimate goal of any tech initiative is to drive measurable business outcomes to remove Market-Blockers and increase ROI.

AI is a breathtakingly powerful tool for reaching those goals, but it is a poor master. Technical accountability is the “Human” anchor that keeps your company from drifting into a sea of unmanageable code and opaque systems.

The Accountability Litmus Test for CEOs: Ask your CTO today: “If our top three developers left tomorrow, could the remaining team explain the trade-offs in our core AI-generated logic by the end of the week?”

If the answer is “No,” you don’t have a technical problem. You have a leadership opportunity.

It’s time to stop hitting “Archive” on our understanding and start building a strategic bench that can actually lead the machines they use.

Who am I?

I’m Diamantino Almeida, and I’ve spent my career at the intersection of high-growth engineering and strategic leadership.

From scaling technical teams to advising CTOs and Founders, my focus is on “Leadership as a Verb“, the idea that leading is an active, evolving practice, not a static title. Having navigated the shifts from manual infrastructure to cloud, and now to Agentic AI, I’m dedicated to helping the next generation of engineers find their footing in a world that is moving faster than ever.

Beyond advisory, I’m an active Top global 9% *mentor on *MentorCruise, where I help developers and leaders bridge the gap between “writing code” and “delivering business value.”

Subscribe now

Early work not representative of current direction.

I want to talk about something that’s been on my mind a lot lately how teams can actually use AI agents in a way that makes sense, without losing what makes us human. I’ve spent years working in tech, leading teams, and trying to figure out how to make tools work for people, not the other way around. And let me tell you, AI especially these new AI agents can be a game-changer if we use them right.

But if we don’t, they can just add more noise, more confusion, and more distance between people who should be working together.

I fear many companies would see AI, as a replacement for cheaper workforce, the same way companies outsource workforce from other countries where labor is cheaper, nothing wrong with that, but it creates division and a blame culture. No one likes to push a company to new levels of automation, adoption of certain work standards, and such. And in the end we receive a thank you letter and a redundancy package.

1. Custom AI agents as “team experts”

Let’s talk about what these AI agents actually are. They’re not magic. They’re not replacements.

They’re tools that can be shaped to fit the way your team works.

Domain-Specific Agents

Every team has its own way of doing things its own knowledge, its own history, its own quirks.

• DevOps teams have their logs and deployment strategies.

• Security teams have their compliance rules and risk assessments.

• Product teams have their user insights and roadmaps.

Instead of using a generic AI tool that doesn’t get your team, why not train an agent to specifically understand your team’s world?

For example:

A DevOps agent could analyze monitoring logs, suggest fixes based on past incidents, and even draft runbooks. But here’s the key, the agent doesn’t make the final call. It suggests, and a human approves. That way, the team stays in control, but the agent helps them move faster.

A Security agent could offer a “Check for Compliance” service that Product teams can use before launching a new feature. No more waiting for a security review to be scheduled just ask the agent for a quick sanity check.

Self-Service for Other Teams

One of the biggest wastes of time in any company is the back-and-forth between teams. “Hey, can Security review this?” “DevOps, what’s the status on this deployment?”

With custom AI agents, teams can expose certain capabilities like a Slack command or an internal API so other teams can get answers without waiting for a meeting or an email response.

Human Decision Gate

This is non-negotiable, AI should inform, but humans should decide. Always. No exceptions. If an agent suggests a fix, a human review it. If it flags a risk, a human assesses it.

The goal isn’t to remove people from the equation it’s to give them better information so they can make better decisions.

2. AI as a force multiplier for collaboration

AI agents shouldn’t just be about getting things done faster. They should help teams work together better.

This idea of pushing hundreds of lines a second, only create a huge cognitive overload and more things to test and do. Be smart on this one.

Live Documentation & Advisory

How much time do we waste digging through outdated docs or asking, “Wait, how did we set this up again?” An AI agent can keep documentation alive updating API specs, onboarding guides, or architecture notes as the code and discussions evolve.

No more “oops, that wiki page is from 2020.”

Pattern Recognition

Ever feel like you’re solving the same problem over and over? An agent can flag recurring issues like, “Hey, this error looks like the outage we had last month.

Here’s how we fixed it then.” That way, teams spend less time reinventing the wheel and more time actually moving forward.

Process Alignment

AI can also nudge teams toward best practices. Imagine an agent saying, “This change requires a security review should I schedule it for you?” It’s not about policing; it’s about making sure nothing slips through the cracks.

Workflow Integration Map

Here’s where managers come in. You don’t need to control every little thing the AI does, but you do need to define:

• Where does AI fit in? (Input: data, Process: analysis, Output: recommendations)

• Where do humans step in? (Judgment, ethics, prioritization)

Clarity here prevents chaos later.

3. AI for creative and strategic work

This is where things get interesting. AI isn’t just for grunt work it can help with the big stuff, too.

Idea Generation

Stuck on a problem? An agent can brainstorm new features, architectures, or strategies based on your team’s knowledge and industry trends. But and this is important don’t stop there.

Imagination Safeguard

After the AI spits out ideas, the team should run a divergence session no AI allowed. Generate your own ideas, compare them to the AI’s suggestions, and ask: Which ones feel original? Which ones are actually feasible? This keeps the team’s creativity sharp.

Risk Assessment

Before rolling out a big change, an agent can simulate outcomes or flag potential risks. “This change might conflict with Marketing’s campaign should we sync with them first?” It’s like having a second set of eyes that never gets tired.

Creativity Retention

Here’s a rule I swear by: Hold “AI-free” ideation workshops every quarter. No tools, no agents, just people thinking and creating together. It keeps those intuitive, creative muscles strong.

How Managers Can Support Teams (Without Micromanaging AI)

Managers, this one’s for you.

Your job isn’t to control how teams use AI it’s to set them up for success.

1. Set Guardrails, Not Handcuffs

• Define boundaries: What can the agent do? (Draft code? Sure.) What’s off-limits? (Deployment decisions? Absolutely.)

• Ownership model: Assign an “AI steward” in each team someone who handles training, updates, and audits. Keep accountability human.

• Ethics & bias review: Regularly check the agent’s outputs for accuracy, fairness, and alignment with your company’s values.

2. Foster a Culture of Trust and Curiosity

• Encourage experimentation: Let teams test agents in low-risk areas first like documentation or code reviews, before scaling up.

• Transparency: Make sure everyone knows how their agent works what data it uses, what it can’t do. No black boxes.

• Feedback loops: Hold monthly “AI Learnings” sessions. What worked? What failed? Keep the conversation going.

3. Focus on Outcomes, Not Oversight

• Metric-driven autonomy: Don’t measure how much the team uses AI. Measure the impact, like faster onboarding, fewer bugs, or happier teams.

• Cross-team audits: Have Security review DevOps’ agents. Have Product check Data’s insights. Fresh eyes catch blind spots.

• Skill preservation: If human creativity or problem-solving starts to decline, dial back the AI. The goal is to enhance skills, not replace them.

4. Invest in “AI Literacy”

• Training: Run workshops on prompt design, agent tuning, and ethical use. Everyone should know how to work with AI, not just how to turn it on.

• Documentation: Encourage teams to document their agent’s strengths, weaknesses, and “personality.” “Our agent is great at optimization but overly cautious on risk.”

• Skill alignment: AI should reinforce human skills critical thinking, collaboration, ethics not automate them away.

Custom AI agents as a service

Let’s make this concrete. Here’s how it could work in a real team:

How it works:

1. Teams train their agents with their own data and expertise.

2. Other teams interact with them via Slack, APIs, or Jira plugins.

3. Agents provide insights, but humans make the final call.

Key mindset shifts

To make this work, we need to change how we think about AI:

• From “AI as a Tool” to “AI as a Teammate”: Treat agents like tools that guide them, critique them, help them improve.

• From “Control” to “Collaboration”: Managers should empower teams to shape their AI, not police it.

• From “Siloed Expertise” to “Shared Intelligence”: Agents can bridge knowledge gaps between teams, reducing friction and duplicate work.

New dimensions for human-centered adoption

Finally, let’s talk about what really matters:

• Human Decision Gates: No matter what, people make the final calls.

• Imagination Calibration: Regularly compare human ideas vs. AI ideas. Keep your team’s creativity alive.

• Wellbeing & Engagement Metrics: Track how AI use affects motivation and collaboration. If people feel replaced or stressed, adjust.

• Visual Workflow Maps: Make it clear where AI supports, where humans decide, and where skills grow.

A question for you

So, here’s what I want to know.

What’s the first mission you’d assign a custom AI agent?

• Log analysis?

• Documentation updates?

• Security scanning?

• Creative ideation?

Or is there some recurring bottleneck in your team that you’d rather automate first?

Let’s start small, learn fast, and keep the human element at the center.

Because at the end of the day, that’s what this is all about.

Not replacing people empowering them.

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.