Yes, that is actually me.
Yes, that is actually me.
I hold together three things that rarely sit in the same person: a real technical foundation, delivery owned end to end, and the commercial conversation that goes with it. In practice, nobody has to translate what the team is saying for me, or explain why the client is losing patience.
I can read a costing because I have written hundreds of them. I can spot a wrong estimate because I have been the person who had to live with it. And I know how to move a release from Friday evening to Monday morning, which has saved more weekends than any tool ever did.
What that buys a company: commitments that hold because they were negotiated before they were announced, bad news that arrives early and already costed, and a team that stays.
My CV says "20+ platforms delivered on schedule". It does not say that these were multi-component enterprise programmes run by several teams across several time zones, nor how many times I renegotiated a scope to keep that sentence true.Everything below, you can also ask ABDEL.EXE directly, my pocket build. It is not a list of canned answers: type your question in your own words, in English or French, and it will understand. It answers straight away, it gets things wrong now and then, and it sends you back to me the moment it actually matters.
A CV is an optimisation document. Here is the unoptimised version of the four numbers I am proudest of.
"+35% sprint velocity."
We stopped pretending that three teams across three time zones could share a single daily stand-up. We split them, we wrote down the rules, and velocity followed. No tool fixed this. It was an organisational decision that had to be taken and owned.
"−60% post-launch defects."
Mandatory code reviews, CI/CD, Docker, and above all, nobody releases on a Friday any more. The first two are method and take a quarter to put in place. The third took six months of negotiation with people who had very good reasons to want to release on a Friday.
"95% retention on a 20+ person team."
The developer market in Casablanca is a hunting ground: my team was approached every week. That number did not come from salaries, which I did not set. It came from a way of working: listening to what each person is going through, understanding where they want to go, and supporting them like an older brother rather than a superior. Plus a lot of planning ahead, so the work arrives organised instead of as an emergency.
"Team built from scratch to 10, then 20+."
You do not recruit a team, you build one. Exercises drawn from real tickets rather than general-knowledge interviews, a role described as it actually is, and close support through the first few weeks. It takes longer at the start. It is why we never had to start over.
Six things that fit into no standard CV heading, and that are exactly what separates two candidates with the same job title.
I did not switch careers along the way: I learned development and graphic design at the same time, and I practised them together. It is a rare combination, and it earns its keep every day. When a designer and a developer disagree about whether a mockup is buildable, I can see both points of view and what each one will cost the other.
Europe, the United States, Canada, Asia Pacific. The time difference never served as an excuse for a delay: you organise the work so it moves forward while the other half of the world sleeps, with written updates clear enough to be picked up without me. That is team discipline, not overtime.
Project budgets, hourly billing rates, margin control, pre-sales. I have sat on both sides of the table: the one who sells the fixed price and the one who has to deliver it. It makes you careful with promises, and considerably more useful in a steering committee.
When a developer says three days, I know what those three days look like: the technical debt you find on opening the file, the Wednesday surprise, the Friday fatigue. I still read enough to follow a pull request, not enough to claim I could replace my lead developer. But enough to defend an estimate knowing what it rests on.
I do not list them to fill a section. I have run a steering committee in French in the morning, a stand-up in English at midday, and settled a team issue in Darija in the afternoon. The real translation work is rarely linguistic, but it helps a great deal.
I led the R&D on AI-assisted development tooling: up to 40% faster time to market on the projects concerned. This site is a direct by-product, and I explain how it was built in the FAQ below.
On the right, how my time was actually split at each step. The code never disappears entirely, it simply makes room for other things.
Web Developer & Graphic Designer
International clients: Magnetism Solutions (Microsoft partner), CareerDubai, the Mohammed VI Foundation. From scoping to deployment in PHP, MySQL, JavaScript, HTML5/CSS3, plus the wireframes, the art direction and, incidentally, the invoicing. Two years being solely accountable for everything: the best project management school I know of.
Where the time went
Senior Web Developer (Full-Stack)
Reference developer for global teams. Adobe Experience Manager platforms, PHP, JavaScript, HTML5, CSS/Sass. REST endpoints architected and MySQL schemas optimised: −40% on page load times. And still producing the UI/UX mockups on the side, because old habits die hard.
Where the time went
Tech Lead & Lead Architect
An engineering team recruited from scratch and scaled to 10. Agile sprints, code reviews, multi-regional CI/CD pipelines. Scalable web applications, REST APIs and micro-frontends (Laravel, Vue.js, React): −35% on feature deployment time. This is the step where I understood that my job was no longer to write the best code, but to make sure ten people wrote good code.
Where the time went
Manager, Delivery of Digital Solutions
The digital portfolio for Deloitte member firms, end to end: commercial scoping, estimation, build, release, run. A 20+ person cross-functional team drawn from several member firms. Project budgets and billing rates owned. +35% velocity, −60% post-launch defects, 95% retention. Plus R&D on AI-assisted development tooling, before it became a conference topic.
Where the time went
The role is a conversation
This is the only line in the table I cannot fill on my own. The rest already says a fair amount about how I commit: when the work and the team suit me, I settle in and grow what I am given. I would like the next one to look like that.
On the role, I am more open than a job title suggests. Delivery, project management, engineering management, transformation, programme leadership: from one industry to the next, the name often changes more than the work. Consulting, banking, manufacturing, software, public sector, and I would happily add a few to that list.
A word on the role
Please do not rule yourself out because the last line says "Manager". A different title, an industry I do not know yet, a smaller team: none of that puts me off. If a role comes to mind, write to me and we can talk it through, no strings attached.
Let's talkTwenty-five mockups from my freelance years. They are here for one reason: "developer and designer from the start" is the first of the six things this CV does not say, and a claim without evidence stays a claim.
These date from 2010 to 2012, my independent years. The design and the development are mine: mockups, art direction, front end, back end, deployment. There was nobody else.
They are more than ten years old and the web has changed several times since. I keep them because they show where I started, not what I would ship today. Some have aged badly, which is exactly why they are still here.
Nothing from my time at Deloitte appears here, and nothing will. That work is covered by confidentiality undertakings: I cannot show it or discuss it publicly, thirteen years of enterprise platforms included. I am happy to talk about it concretely during a hiring process, in the setting meant for that.
years of experience, 13 of them at Deloitte
large multi-component enterprise platforms, delivered on schedule
people managed across dev · design · QA
team retention in a market full of headhunters
A list of tools tells you nothing about actual depth. So here is the rule I hold myself to on this site: I only list what I can defend in an interview, or honestly explain why I no longer can.
2008 - 2009
Master's degree, University of Nice Sophia Antipolis
2006 - 2009
Engineering
& Management degree, EMSI, Casablanca
2003 - 2005
Specialised
Technician degree, ISTA
UiPath RPA: certified.
Professional Scrum Master I (PSM I): in progress.
I would rather write "in progress" than let you assume it is done. You immediately know what to verify.
The context, the decision, what it cost and what I took from it. Including the two I got wrong.
What the teams I have worked with usually discover after a few months. It seems fairer to say it upfront.
I listen before I propose. In the first few weeks I spend more time with the existing team and the users than with the dashboards. That is where you understand why things ended up this way, and what is best left alone while you improve the rest.
I ask for the assumptions, I look at the bad case, and I do sometimes send a costing back. It is not distrust of the team: it is what lets me defend their timeline later without backing down when the pressure arrives.
I raise it early, and I arrive with two costed options rather than with a problem on its own. Bad news at D−30 still leaves everyone room to manoeuvre. The same news at D−2 leaves none.
Casablanca is an hour from Paris and shares a good part of its day with North America. The rest is method: calls placed at the right hours, written updates that stand on their own, and decisions that do not wait for everyone to be online at once.
Context, above all. The people I work with know why they are building what they are building, and what matters most this quarter. That is what lets them make the right call when I am not in the room.
Technical workshops, training sessions, code reviews designed to help people improve rather than to catch them out. That is the best explanation for the 95% retention: people stay where they are learning something.
You will not find an invented glowing quote anywhere on this site. These four people worked with me at Deloitte and have agreed to be contacted. I keep their names off the public page and give them, with contact details, during the hiring process. Here is what each of them is best placed to tell you.
Ask about: delivery leadership, architecture trade-offs and keeping commitments under pressure.
Ask about: working with design teams and governing a design system over time.
Ask about: recruitment, performance reviews, career development and team retention.
Ask about: the client relationship, service quality and how I behave when things get tense.
Answered in advance, straight, including the ones that suit me less well. That is a screening call you get back.
I am leaving on good terms: four former managers, including the Head of Digital and the HR Director, have agreed to take the call. I will not spoil the whole story here: the rest tells much better over a conversation, and I would be glad to go through it with you in an interview.
Yes, whenever it helps. If a team is short-handed, if a subject needs clearing or a release is at risk, I open the editor and take a piece of it, and I enjoy it. I have kept enough to read a pull request, challenge an architecture decision and spot a fantasy estimate.
What I cannot promise is doing it all the time. Scoping, budgets, staffing and arbitration take the hours first, and pretending otherwise would be unfair to the people counting on me elsewhere.
The clean way to decide: if the role requires full-time coding, it is not me. If it requires someone who can follow the technical discussion, connect it to what the project actually needs, and put their hands back in the code when delivery depends on it, that is my ground.
Manager, with the technical foundation intact. The title matters less to me than the scope: I want to be accountable for something delivered, together with the team that delivers it.
The first is almost presentable: I am slow to accept an estimate. I send it back, I ask for the assumptions, I look for the worst case. During the courtship phase of a deal, that slows everyone down. The trade-off is that I rarely commit to a date I cannot hold.
The second is more of a problem: when something is stuck, I tend to take it back myself instead of letting someone struggle and learn. I have worked on it, and I am much better at it now than I used to be. My team will tell you about it better than I can.
The third cuts both ways: I am a highly empathetic person. When someone on the team is going through something, I feel it, and it stays with me for a while. It is part of why people stay, and part of why some weeks weigh more than they should. I gather myself afterwards, and I would rather work that way than the alternative.
I answer straight in the first conversation, provided I know the scope: team size, budget owned, seniority of the people I deal with, country of employment. It saves everyone discovering at the third interview that we were never in the same range.
My role at Deloitte ended in July 2026. So I am available immediately.
Put it to ABDEL.EXE, my pocket build. It is not a list of canned answers: type your question in your own words, in English or French, and it will understand. Same career, same opinions, no coffee dependency. It answers straight away, it gets things wrong now and then, and it sends you back to me the moment it actually matters.
Whether it is about a role, an assignment, or a second opinion on a delivery organisation, write.
© Abdeljalil Hcham 2026. Written by hand, numbers verifiable.