Behind the work
Mohsen Zarei
Not just what I’ve built — how I actually get there.
The Work page shows what I’ve shipped. This one is the evidence behind how I operate — patterns pulled from real projects and real messages, each one traceable back to something that actually happened.
Built from an evidence-based review of my own work communications (Outlook & Teams), privacy-checked before publishing.
Evidence from real work
Modernizing a Safety-Reporting Platform
An established safety-reporting environment needed modernizing — better reliability, revised reporting, controlled access, and a clean handover between the old and new versions. Recurring quality problems and unclear ownership kept resurfacing across the period.
What I did
- Wrote the requirements, calculations and operational checks, and asked the user-impact questions nobody else was asking.
- Proposed an archive-and-replace transition model: keep the old version as an archive, replace the live one, link both, and check whether the displayed data was genuinely live.
- When it broke — repeated refresh failures, missing API fields, stale data, access issues — pushed it to top priority, coordinated the recovery, and worked through historical-data correction and workspace-access cleanup.
Team context
The platform itself was delivered collaboratively — this isn’t a one-person build.
Outcome
Progressed from troubleshooting stale or crashed reports through release coordination to an actual operational-ownership model, with at least one incident explicitly confirmed fixed. Balanced against that: quality and ownership problems persisted across several periods, and stable adoption with full operational closure remains unproven.
Defining a Site-Safety Incident & Observation Solution
Stakeholders needed a coherent approach to incident and observation management, with immediate needs, strategic direction and security implications all still unresolved.
What I did
- Framed the problem and scoped a minimum initial solution rather than waiting for the full picture.
- Requested a high-level design and resource plan; prepared process and success-criteria material, including a one-pager and a draft requirements document for senior review.
- Distributed requirements ahead of workshops and structured the management conversation around interim vs. strategic options.
Team context
A completed implementation isn’t evidenced — this covers the framing and decision-readiness work, and delivery responsibilities stayed contested or unclear even after the review.
Outcome
Moved a broad, unresolved need to specific decision-ready questions and an alignment path.
Dashboard Migration & User Support
A project application and its dashboard were being migrated while users raised access, data and change-impact questions.
What I did
- Published the dashboard to its correct production location, removed the test version, and ran a procurement-report beta ahead of full rollout.
- Explained, in plain terms, how a column rename or data-type change breaks a dashboard versus a same-type value addition, which doesn’t — and worked through the same constraints for a planned physical-display version.
- Asked users to consolidate their questions and requirements instead of trickling them in, and set up a clearer feedback process.
Team context
The underlying application changes involved other contributors.
Outcome
A cleaner production setup and a more auditable requirement-intake process. Long-term adoption data isn’t available.
Applied AI Adoption & Enablement
Repeated, hands-on exploration of where AI could actually help — delivery, analysis, design, learning, and eventually broader organizational adoption — alongside a recurring internal-enablement offer built around it.
What I did
- Organized follow-up on an AI-team proposal and planned a broader AI-adoption discussion for senior stakeholders.
- Proposed embedding practical AI training into onboarding and ran recurring one-hour clinics, pitched around a quantified (but unverified) time-saving estimate.
- Used AI-supported learning to get into unfamiliar tools quickly — semantic-model experimentation, dimensional-modelling examples, a temporary approved development assistant while waiting for an enterprise alternative — and iterated on AI-assisted presentation and web-design work.
Team context
Formal adoption decisions aren’t visible in the evidence — this is the exploration, enablement and case-building work, not a signed-off program.
Outcome
A consistent pattern: test it on something real first, build a concrete (if unverified) case for the benefit, then push for wider use. Automated technology digests in the evidence show information availability, not proof of personal application — that distinction is kept rather than blurred.
Integrating a New Dataset Instead of Duplicating a Dashboard
A new project dataset needed somewhere to live, and the default path on offer was another standalone dashboard.
What I did
- Proposed integrating the new dataset into an existing dashboard rather than building a duplicate.
- Added it to the backlog, delegated the construction work, and proposed the project-level filtering it needed.
- Granted access and asked the intended users to confirm it worked for them.
Team context
Construction was delegated to another contributor — this covers the intake, architecture decision and access work.
Outcome
Access was granted to the intended users. Usage, satisfaction and completion of the full change list aren’t evidenced yet.
Learning-Content Modernization
Handbook material needed to move into an interactive learning format, with licensing, content-ownership and procurement questions all unresolved.
What I did
- Coordinated the move of handbook material into the new format and tracked two training items through to completion.
- Worked through the licensing, content-ownership and procurement dependencies that were blocking it.
- When a related in-person development event lost its logistics to an external disruption, replanned it as an online delivery rather than cancelling it.
Outcome
Progressed from tool and licensing uncertainty to a formal kickoff. Completion rates, published-module counts and learner feedback aren’t available yet.
Cloud Data-Platform & API Modernization
A legacy data environment needed retiring in favor of a consolidated cloud platform, with missing API fields, access permissions, stale data and unclear operating ownership all in play.
What I did
- Participated in API-ingestion planning, data-cleansing discussions and model-consistency work.
- Helped make production promotion conditional on side-by-side comparison and validation rather than a straight cutover.
- Worked missing-field escalation and data-access troubleshooting as they came up.
Team context
A participatory role in a team decision to retire the legacy environment — not a solo call.
Outcome
A validation-first migration path. The constraints — missing fields, access gaps, stale data, unclear ownership — were being worked through as they surfaced, not fully closed out.
Achievements
Managed a Low-Risk Platform Transition
Situation
A replacement reporting platform needed to go live without losing access to the previous version.
Action
Proposed archiving the old version, replacing the active one, linking both, and checking whether the displayed data was genuinely live.
Result
A clear, lower-risk deployment approach.
Turned Access Requests into an Access Model
Situation
Different audiences needed access to different safety-information areas.
Action
Requested area-specific visibility, clarified access ownership, and explored automating access from an already-authorized population.
Result
Access treated as an operating model, not one-off requests. Final implementation isn’t confirmed.
Detected and Escalated Reporting Problems
Situation
Reports had stopped refreshing, crashed, or showed unavailable information.
Action
Identified the symptoms, brought in the right specialists, requested checks, and confirmed fixes.
Result
At least one issue explicitly resolved; the rest given clear ownership and follow-up.
Converted an Ambiguous Need into Decision Material
Situation
Stakeholders had no alignment on a site-safety solution.
Action
Scoped a minimum solution, wrote a concise requirements view, requested technical planning, and framed the decision around interim vs. strategic options.
Result
A broad need became specific, answerable questions.
Reduced Fragmented Feedback Cycles
Situation
Dashboard feedback arrived as repeated, isolated questions.
Action
Asked users to explore the solution first, combine their requirements, and check previously documented fixes before raising something new.
Result
A more efficient, auditable feedback process — the efficiency gain itself is inferred, not measured.
Converted a Duplicate Request into an Integrated Data Product
Situation
A new project dataset needed a home, and the default path was another one-off dashboard.
Action
Proposed folding it into an existing dashboard instead, added it to the backlog, delegated the build, and confirmed access with the intended users.
Result
One consolidated product instead of a duplicate. Usage and satisfaction aren’t measured yet.
Moved a Learning Initiative from Licensing Limbo to Kickoff
Situation
Handbook material needed to become an interactive learning format, blocked on licensing and content ownership.
Action
Tracked the dependencies, resolved the procurement questions, and pushed it to a formal kickoff.
Result
A stalled initiative became a running one. Completion and learner feedback aren’t visible yet.
Set the Rules for an Internal Knowledge Tool
Situation
Contributors were submitting terms with no shared standard for what belonged or how it should be classified.
Action
Defined eligibility around organizational relevance and pushed back on a mandatory classification that didn’t fit every entry.
Result
Lightweight governance and a taxonomy the tool could actually run on. Usage isn’t measured.
Made Validation the Gate for a Platform Migration
Situation
A legacy environment needed retiring, but promoting the new one on trust alone was a risk.
Action
Made production promotion conditional on side-by-side comparison and validation, not just a cutover date.
Result
A safer migration path. Missing fields, access gaps and stale data still had to be worked through as they surfaced.
Turned a Disrupted Event into an Online One
Situation
An in-person development event lost its logistics to an external disruption.
Action
Replanned it as an online delivery rather than cancelling it.
Result
The event still happened, in a different format.
Pitched a Benefit It Hadn’t Proven Yet
Situation
An internal enablement offer needed a reason for people to show up.
Action
Framed it around a quantified time-saving estimate — presented as a hypothesis, not a measured result.
Result
A concrete, persuasive pitch, made honestly: the saving was proposed, not verified.
Working-style patterns
Action-oriented ambiguity reduction
When something is unclear, I ask one sharp question, find what’s actually missing, and move straight to a concrete next step — an owner, an option, or a meeting.
A short clarifying question, then a request — not a longer open discussion.
Some short delegations assume shared context rather than defining the issue outright.
Iterative rather than perfection-first
I’d rather ship a working intermediate version than wait for a theoretically complete one — betas, staged releases, and revisions over a single big-bang launch.
Useful progress now, refine later.
Repeated versions and fixes sometimes lack a visible, documented final closure.
Automation and simplification mindset
A repeated instinct to automate access instead of rebuilding it by hand, and to integrate a dataset into an existing product instead of duplicating it.
Reduce the manual step before adding a new one.
Several of these remain proposals, and measured simplification isn’t visible yet.
Operational ownership
I notice stale data, missing content, or unclear ownership before anyone reports it — and I follow up on it directly rather than just flagging it and moving on.
See it, own the follow-up, don’t just report it.
Ownership is occasionally handed off without a visible confirmation that the work was actually closed.
Stakeholder-inclusive execution
I bring other people in to review, test, or propose alternatives — collaboration speeds up the decision, while I keep visible ownership of getting it done.
Ask others to confirm; don’t decide alone in a corner.
Under real time pressure, communication can turn highly directive, leaving less room for discussion.
Practical learning
I learn new tools by using them on a real problem — examples, demos, and direct experimentation rather than reading documentation cover to cover first.
Learn it by building something small with it.
Sustained learner uptake and changed working practice aren’t visible in the evidence.
How I solve problems
- Check the current state
- Define the discrepancy
- Identify who actually owns the fix
- Propose a practical option
- Request testing or validation
- Escalate for broader alignment — only when it touches strategy, security, governance, or several teams
I’m decisive on reversible, operational calls — troubleshooting, deployment, support. I widen the circle only when a decision carries long-term, cross-functional, or governance weight. Either way, I say the uncertainty out loud and pair it with a proposed way forward, rather than leaving it open.
How I communicate
Peers & technical specialists
Brief and direct — check, add, publish, remove, deploy, assign, review. A proposed solution usually rides along with the problem statement. Uncertainty gets admitted directly, followed by a referral to whoever actually knows.
Managers & senior stakeholders
More structured, more context. Framed around options, implications, and the decision actually required. Meetings get used for alignment, not routine status.
Nontechnical stakeholders & users
Cause-and-effect explanations, no unnecessary depth. Ask people to test and give written feedback. Set a boundary when requests turn fragmented.
Team & community
Warmer, more appreciative, inclusive language, the occasional emoji. Credit goes to the group, not converted into individual credit.
Urgent operational moments
Shorter messages. The issue, the requested action, and who owns it — all up top. Still polite, just with less ceremony.
Writing fingerprint
Teams messages run one to three short sentences. Emails follow a stable shape — greeting, purpose, context or request, thanks, a short close. Lists appear when several things need coordinating, and a question is usually doing double duty as an action trigger.
Direct but not confrontational — disagreement usually acknowledges the other position before naming the concern. Confidence shows up as a concrete recommendation, not emphatic language.
Anonymized examples from historical professional communication. Wording is preserved as written, informal phrasing included.
Very short Teams message
“Thanks mate”
Comfortable using concise, friendly language with close colleagues.
Challenging a design from a user’s perspective
“my general question is what is the message you (data Analyst) want to give to the audience there? I am not sure how the can use this dashboard 1st how they can find if there is an issue 2d how they can solve it?”
Focus on practical outcomes and decision-making, not visuals for their own sake.
Technical implementation call
“Thanks [colleague], I think we need to create the measures in PBI Desktop since Fabric might not be able to accommodate it”
Concise technical reasoning with awareness of platform constraints.
Persuasion with a quantified benefit
“Give me 1 hour and I’ll assure each team member saves 15 minutes daily. Here’s what that means Assuming an hourly rate of 400 DKK, the savings are: Per Person: Monthly: 5 hrs”
Uses measurable benefits and confident language to build support. The stated saving is a proposal, not a verified outcome.
Disagreement
“I understand your concern. However, as a data engineer, there are times when you'll need to solve problems without assistance or documentation, relying only on the final results.”
Acknowledges the other view before stating a firm professional expectation.
Escalation under pressure
“[core reporting solution] needs our full attention right now & #1 priority. Please make this your top priority and focus on resolving the issues as quickly as possible.”
Decisive prioritization during operational pressure.
Sequential technical instructions
“1 - Try to delete all Cache in Power BI: After all numbers shows 0 then: 2 - Close the Power BI”
Gives concrete, ordered actions rather than abstract advice.
Admitting uncertainty
“I am not sure I am the right person to help with this. If you can let me know what you need, Maybe I can try to find the right person for you.”
Honest about a limitation without simply rejecting the request.
Seeking executive review
“Hi [senior stakeholders], I have drafted a one-pager and a new URS for [solution]. Please take a look and let me know if there is anything that should be added.”
Summarizes work at the appropriate level and actively invites governance input.
Recognizing the team
“Hi team, Congratulations to everyone on this great achievement! Fantastic work bringing the [internal practice] to completion and release. 🎉”
Publicly credits the team and communicates enthusiasm.
Communicating a missed commitment
“Hi [senior stakeholder] [colleague] got sick today. We cannot deliver it today”
States the failure and immediate cause directly, without concealing it.
Formal governance request
“To streamline [solution] governance and avoid ambiguity when we make changes, could you please help confirm the following Roles & Responsibilities (R&R) and SME ownership”
Anticipates organizational ambiguity and seeks explicit accountability.
Direct, practical request
“can you please share an screenshot on what we have on that db?”
Practical, action-oriented requests without unnecessary formality.
Initiating a direct conversation
“HI [colleague]. Let's have a talk I think we need to address the issue and have an open & Honest conversation.”
Willingness to confront difficult matters directly.
What this evidences
Strong evidence
Moderate evidence
Ideas along the way
Archive-and-replace deployment
Keep the old version as an archive while replacing the live one and linking both, so nothing is lost and nothing is irreversible.
Selective, role-based visibility
Show people only what’s relevant to their responsibility, not everything.
Automated access migration
Reuse an already-authorized population instead of rebuilding permissions by hand.
Minimum-viable safety solution
Cut a broad ask down to its essential function, with a separate track for the long-term version.
Consolidated requirement intake
Combine questions and requirements up front instead of processing them one at a time.
AI as a creativity tool, not just productivity
Frame AI as a source of new problem-solving approaches, not only faster typing.
Integrate instead of duplicate
Fold a new dataset into an existing product rather than standing up a parallel one.
AI training folded into onboarding
Practical AI skills taught as part of joining, not as a separate program to schedule later.
Recurring one-hour clinics
Short, repeatable working-practice sessions instead of a one-off training event.
A temporary, approved way of working now
Use a sanctioned interim tool or process rather than waiting for the enterprise-standard version to arrive.
Leadership & collaboration
Delegating access responsibilities, clarifying who owns what next, coordinating release and handover, asking for backup coverage, setting expectations for how requirements get submitted, and preparing workshop participants. This doesn’t establish a formal reporting line — read it as coordination, not people-management.
Spotting the operational problem nobody else flagged, proposing a workable path, connecting the technical and business sides, sharing what I’ve learned, and giving credit where it’s due. Facilitative rather than command-and-control — including outside core delivery work, where I’ve organized an employee community event end to end (announcements, logistics, ticket support) in the same practical, detail-first register.
Feedback
Formal professional recommendation.
“He is a highly appreciated colleague, and I give him my strongest recommendation for future leadership opportunities.”
Strong evidence of professional standing and perceived leadership potential.
Assessment of work on digital solutions.
“His leadership and vision were particularly evident during the development of [solution] and other digital solutions”
Directly attributes visible leadership and strategic direction.
Senior colleague reflecting on collaboration.
“I genuinely appreciate the collaboration we have had. At the same time, I know you will bring your project mindset, execution focus, and energy into your new roles”
Recognizes collaboration, project discipline, delivery focus and energy.
Immediate response after receiving help.
“You are an angel - thank you”
Highly positive spontaneous recognition, although informal and nonspecific.
Confirmation after an access or technical issue was addressed.
“It works now. Thank you.”
Confirms the intervention produced the required result.
New colleague responding to a welcome.
“Thank you for the warm welcome! The first couple of days have been great.”
Indicates a positive onboarding experience and approachable communication.
Stakeholder responding to detailed project feedback.
“First off, the feedback is much appreciated — and the level of detail even more so.”
Supports the value of detailed, actionable feedback — team-level, not solely personal recognition.
Stakeholder reacting to an implemented change.
“Fine thank you (although I am still not completely happy with the change), I hope you are doing well in your new position.”
Feedback was not uniformly positive — the stakeholder remained dissatisfied despite the change.
No safe, clearly attributable evidence of direct personal feedback criticizing leadership or attributing a delivery failure solely to me. Project-level concerns aren’t represented here as personal performance findings.
Timeline
- Sep – Dec 2024
Early cloud data-platform retirement planning and the first internal-enablement proposals.
- Jan – Sep 2025
Enablement clinics continue; abbreviation-knowledge-tool governance takes shape; groundwork for later projects.
- Oct – Nov 2025
Learning-content modernization kicks off; the equipment-KPI-tracker feasibility request comes in.
- Dec 2025
Operational coordination, reporting calculations, early AI-initiative discussion, team appreciation.
- Jun 2026
Platform stabilization, deployment, access control, operational ownership.
- Jul – Aug 2026
Data-platform validation, dashboard and equipment-data integration, AI-assisted design, cross-functional solution planning, structured requirement governance.
Read this as a widening evidence window, not a complete one. The record now reaches back to September 2024, but no single month is fully captured, and a few stretches — October–November 2024, January–July 2025 — have no dedicated search at all.
That’s the pattern, not the pitch.
The pattern that holds up across all of this: I turn an unclear operational problem into a scoped action, an owner, a test, or a decision — and I’d rather ship the reversible next step than wait for the perfect one. I pull in the right specialist without giving up ownership, and I adjust how I say things depending on who’s listening and how urgent it is. None of it is a straight line of wins — the evidence keeps its own contradictions, on purpose.
Every line above traces back to something I actually did. The work itself is on the Work page.
Back to the portfolio