Engineer in the Spotlight: Mohamed Amin

From on-premise infrastructure to the cloud: meet Mohamed Amin, Platform Engineer at Wildflowers.

At Wildflowers, our engineers work on challenging projects where technology has a real-world impact. From software for agricultural machinery to large-scale banking platforms, every project brings its own challenges, technologies and opportunities to learn.
In this Engineer in the Spotlight, we meet Mohamed Amin, a Platform Engineer working on a critical banking service and helping move it from an on-premise environment to Azure.

Meet Mohamed

Mohamed chose to work with Team Wildflowers because of the combination of an interesting project and a helpful team. For him, the people he works with are an important part of what makes the experience rewarding. His current project brings him into the world of banking, where reliability, scalability and security are essential.

Building the cloud infrastructure

As a Platform Engineer, Mohamed is responsible for the platform that supports a critical banking service. One of the biggest challenges in his current project is the migration of that service from an on-premise environment to the cloud.
Moving a critical service to Azure is more than simply changing where the application runs. It requires careful consideration of the infrastructure, deployment process and reliability of the platform.
Mohamed works with technologies including Kubernetes, Microsoft Azure and Terraform to help make this transition possible.

A challenging engineering environment

What makes the project particularly interesting for Mohamed is the combination of complexity and impact. The migration involves a critical service, meaning that the technical decisions made along the way have a direct effect on the platform that the service depends on. At the same time, the environment gives Mohamed plenty of opportunities to solve complex engineering challenges. For him, that combination makes the project both rich and rewarding.

The people behind the technology

Technology is only one part of the equation. When asked what he enjoys most about working on the project, Mohamed points to the team and the impact. Working with a helpful team makes it easier to tackle difficult technical challenges together, share knowledge and keep moving forward when things get complicated. And ultimately, seeing the impact of the work makes the technical challenges worthwhile.

Life as a Wildflowers engineer

Mohamed’s story is a good example of what working at Wildflowers can look like: joining a challenging engineering environment, working with modern technologies and contributing to projects where the work has a tangible impact. Whether you’re working on cloud infrastructure, software development or another part of the engineering landscape, the combination of technical challenge, autonomy and great people is what makes the work interesting.

Curious about working with Wildflowers?

Are you an engineer looking for your next challenge? At Wildflowers, we work with engineers who enjoy solving complex problems, learning new things and building technology that matters.

Want to become part of Team Wildflowers?

Join Team Wildflowers →

A cloud platform should make work easier

Cloud engineering is not about moving everything somewhere else. It is about creating a platform that helps teams build, run and improve their work with confidence.

The cloud offers powerful building blocks. But more services do not automatically mean a better platform. Without clear choices, it is easy to replace one kind of complexity with another: unclear costs, inconsistent environments, manual deployments and a growing list of exceptions.

A useful cloud setup makes the right path the easiest path.

Start with the workload, not the platform

Every system has different needs. Some workloads need fast delivery. Others need strong controls, predictable performance or strict data handling.

That is why we start with the work itself. What needs to run? Who owns it? How critical is it? What happens when it fails? How often will it change?

The answers guide the architecture. They help us choose a level of automation and resilience that is appropriate, rather than adding technology for its own sake.

Create repeatable foundations

Teams should not need to rebuild the same basics for every new service.

A strong cloud foundation gives them clear, reusable patterns for identity, networking, observability, security and deployment. These patterns are not there to slow people down. They remove the repeated decisions that create risk and inconsistency.

The result is a platform that supports autonomy without leaving every team to solve the same problems alone.

Treat operations as part of engineering

A system is not finished when it is deployed. It needs to be observable, secure and understandable when something goes wrong.

That means thinking about logging, monitoring, incident response and cost from the beginning. Not as a separate operational layer, but as part of building responsibly.

When a team can see how a service behaves, diagnose issues quickly and deploy changes safely, it can move with much more confidence.

Keep security practical

Security works best when it is built into everyday workflows. Clear access controls, automated checks and sensible defaults are more effective than a long list of rules people work around.

The same is true for governance. Good guardrails make safe choices easier. They should give teams direction without removing their ability to solve real problems.

Build a platform people want to use

A cloud platform succeeds when teams choose it because it helps them get work done. It should reduce friction, make standards visible and support change without creating unnecessary ceremony.

That is the outcome we work towards: a cloud environment that is dependable in the background and useful in the day-to-day.

Data only helps when it changes a decision

More dashboards do not automatically create more insight. The value of data starts when it helps someone make a better decision.

Many organisations have no shortage of data. It lives in operational systems, spreadsheets, customer tools and reports. The challenge is usually not collecting more of it. It is making it reliable, accessible and relevant to the questions that matter.

That requires more than a visualisation layer.

Begin with the decision

A useful data project starts with a practical question. Should we invest in this market? Where do customers get stuck? Which process is creating unnecessary cost? What should the team act on next week?

When we start there, we can work backwards. What information is needed? Where does it come from? Is it trustworthy enough? Who needs to use it?

This approach keeps analytics connected to real work, instead of becoming a collection of reports that look impressive but rarely get opened.

Trust is built in the details

A dashboard can be beautifully designed and still create confusion if nobody trusts the numbers.

That trust is earned through clear definitions, transparent transformations and sensible ownership. People should be able to understand what a metric means, where it comes from and when it was last updated. They should also know its limits.

Data is rarely perfect. Pretending otherwise makes it less useful. Being clear about uncertainty helps teams make stronger decisions with the information they have.

Design for the people using it

Data products are products. They need to fit the context of the people using them.

A finance team may need consistency and traceability. An operations team may need an exception highlighted before it becomes a problem. A product team may need to explore behaviour without waiting for a new report.

The right solution is not always another dashboard. It might be a simple alert, a shared metric definition or a reliable dataset that lets a team answer its own questions.

Keep the feedback loop short

Analytics works best when it is iterative. Put something useful in front of people, see how it is used and improve it with them.

That prevents weeks of building around assumptions. It also helps teams learn which questions are genuinely valuable—and which ones only sounded useful at the start.

Make data part of the work

The goal is not to turn everyone into a data analyst. It is to make good information available at the moment it is needed.

When data becomes a natural part of how a team plans, prioritises and learns, it stops being a reporting exercise. It becomes a practical tool for moving forward.

Build for the change you know is coming

Good engineering is not about predicting every future requirement. It is about making the next sensible change easy to make.

Most systems do not become difficult overnight. Complexity arrives gradually: one urgent integration, one exception for a key customer, one shortcut that becomes permanent. Before long, a small change requires three meetings, five approvals and a careful look at code nobody wants to touch.

That is rarely a people problem. It is usually a design problem.

Start with the real problem

A technically elegant solution is not automatically a useful one. Before choosing tools or drawing architecture diagrams, we need to understand what is actually getting in the way.

What is slow? What breaks often? Where are people repeating work? Which decisions are hard to reverse?

Those questions create a better starting point than a predetermined technology choice. They also help us keep the scope honest. Sometimes the right answer is a new platform. Sometimes it is a small, well-placed improvement to an existing one.

Make complexity visible

Complexity is not always bad. A growing business has more customers, processes and edge cases. The problem starts when that complexity is hidden.

Clear boundaries between services, understandable ownership and useful documentation make a system easier to work with. So do automated tests and deployment pipelines that make changes routine instead of risky.

We aim for systems that are understandable by the people who will use and maintain them. Not just by the team that built the first version.

Prefer progress over perfection

There is no final version of a digital product. Customer needs change. Teams grow. The context around a platform shifts.

That is why we favour practical decisions that keep options open. A smaller first release can teach us more than a long project plan. A sensible technical compromise can be better than waiting for an ideal solution that may never arrive.

The work is not about making everything flexible. It is about being intentional about where flexibility matters.

Engineering is a team sport

The strongest technical choices are made with the people closest to the work. Product, operations, data and engineering all see different parts of the same problem.

We bring those perspectives together early. It means fewer surprises later, and it creates solutions people can actually use.

Build what lasts

Sustainable engineering is not about using the newest framework. It is about creating clarity, reducing unnecessary work and leaving a system in a better state than we found it.

That is the kind of progress we like: useful today, adaptable tomorrow.