About
Technology and cybersecurity leadership, built on 25+ years in enterprise and regulated environments.
My background spans enterprise infrastructure, technology leadership and cybersecurity governance, largely in BFSI and other regulated environments. Today I apply that experience to digital transformation and product strategy, using AI-enabled development where it genuinely helps.
- Experience
- 25+ years in technology leadership
- Sectors
- BFSI, healthcare, education and professional services
- Focus
- Technology leadership, cybersecurity, digital transformation and product strategy
- Based
- Mumbai, India — working with clients in the UK, US and EMEA
Profile
Jordan Dias
Technology & Cybersecurity Leader
- Mumbai, India
- diasjordan@gmail.com
I am a technology and cybersecurity leader. My career has been spent inside enterprise technology, infrastructure and security functions, where systems are judged on availability, evidence and auditability.
Experience across regulated and technology-intensive environments, including BFSI, cybersecurity, enterprise infrastructure and digital platforms. 25+ years in technology leadership across BFSI, healthcare, education and professional services. Each stage still shows up in the work: architecture decisions are made with cost and risk stated plainly, and access control, evidence and auditability are designed in rather than added later.
More recently I have applied that experience to product strategy and development — most visibly leading product and technology for GradNextSteps — using AI-assisted development and modern cloud architecture as supporting tools, with judgement, architecture and security review kept senior and human. Based in Mumbai, India — working with clients in the UK, US and EMEA.
The short version
Four questions, answered directly
Everything else on this page is detail behind these four answers.
Who is Jordan Dias?
A technology and cybersecurity leader with more than 25 years spent inside regulated and technology-intensive environments — first building and running enterprise infrastructure, then leading technology functions, then owning cybersecurity and governance. More recently that experience has extended into digital transformation, product strategy and AI-enabled product development. The core of the work is senior technology and security judgement applied to decisions that are expensive to reverse.
Why build software at all?
Because in most businesses the constraint is not effort, it is coordination. Work waits on a person to move it, records live in inboxes and spreadsheets, and nobody can answer a simple question about the state of things without asking three people. Software is worth building when it removes that coordination cost permanently. When it will not, I say so.
What makes the approach different?
Most build engagements start with a feature list. Mine start with the decision the business is trying to make and the evidence it needs to make it. Discovery is short and produces a costed plan, a prototype and a defensible architecture. Security, access control and audit trails are specified at design time, because they cannot be added to history that was never recorded.
Why should a business trust this?
Because the same person who writes the architecture has sat on the other side of enterprise security reviews, procurement questionnaires and audits, and has been accountable for the answers. Scope, trade-offs and the things I would not build yet are stated in writing before work begins, and delivery happens in increments you can review rather than a single reveal at the end.
Professional journey
Infrastructure, then leadership, then cybersecurity and governance, then transformation
Not a pivot. Each stage answered a question the previous one raised, and every stage still shows up in the work.
- 01Early career
Enterprise infrastructure
Datacentre, network, systems and continuity work inside banking and financial services, where downtime is measured in money and every change has a paper trail. This is where the habit of designing for failure rather than for the demo was formed.
Carried forward: Operational realism: systems are judged on the bad day, not the launch day.
- 02Mid career
Technology leadership
Accountability shifted from systems to outcomes — budgets, vendors, delivery standards and the sequencing of technology work against commercial milestones. Sitting in the room where spend is approved changes how you scope work.
Carried forward: Commercial framing: every technical decision stated as a business consequence.
- 03Regulated years
Cybersecurity and governance
Ownership of security posture, access control, supplier assurance, policy and the evidence that satisfies auditors and enterprise buyers. Governance stops being paperwork once you are the one signing the response.
Carried forward: Evidence by design: controls and audit trails specified before the first line of code.
- 04Now
Digital transformation and product development
Applying that experience to digital transformation and product strategy, including platforms and products where AI does specific, testable work inside a reviewed workflow. The infrastructure, leadership and governance experience is what makes this responsible rather than speculative.
Carried forward: Applied AI: used where it improves an outcome, declined where it cannot be verified.
Personal philosophy
How I think
These positions decide scope and architecture long before they decide code, and they are the reason some proposals get smaller after the first conversation.
Technology exists to solve business problems
If a decision cannot be traced to a commercial outcome in one sentence, it is usually premature. Architecture diagrams are not the deliverable; a business that works differently is.
Building less software is usually better
Every feature is a permanent liability — it has to be supported, secured, explained and eventually replaced. The strongest contribution I make on most engagements is removing things from the plan.
Architecture decisions outlive technology choices
Frameworks and vendors get replaced without much pain. Data models, boundaries between systems and the way permissions are expressed do not. Those get the disproportionate share of the thinking.
Security and governance belong in the design
Access control, data separation and audit trails cannot be backfilled, because history that was never recorded cannot be recovered. Designing them in costs days; retrofitting them costs quarters.
AI should improve outcomes, not automate inefficiency
Applying a model to a broken process makes the process faster and no better. The useful question is which judgement is expensive, repeatable and verifiable — and only then whether a model can do part of it.
Adoption is the only honest measure
A platform nobody uses is a failed platform regardless of its test coverage. Onboarding, migration and handover are part of the work, not a phase that follows it.
My approach
How the work actually runs
In the order it happens on a real engagement, from framing the constraint to handing over something another team can maintain.
- 01
Business-first framing
The engagement opens on the constraint and the commercial decision behind it, not on a feature list or a technology preference.
- 02
Strong discovery before development
A short, fixed-scope discovery produces a validated scope, a costed delivery plan and a defensible architecture — separable enough to be taken elsewhere.
- 03
Rapid prototyping
Something clickable early, while changing direction is still cheap. Opinions about a screen are more reliable than opinions about a specification.
- 04
Practical architecture
Boring, well-understood components chosen for the load that actually exists, with the seams placed where growth is most likely to arrive.
- 05
Iterative delivery
Reviewable increments on a predictable cadence, so scope can be corrected while it is still inexpensive to correct.
- 06
Built for maintainability
Written so another team can take it over: documented decisions, conventional patterns, no cleverness that needs its author present.
- 07
Clear stakeholder communication
Progress, risk and cost explained in the language of the business, in writing, without needing an engineer to interpret it.
What to expect
Six things that hold in every role
Stated here so they can be held against the work rather than discovered at the end of it.
Strategic thinking
Work sequenced against commercial milestones, with cost, risk and dependency stated plainly rather than discovered later.
Honest recommendations
Including when the answer is a smaller build, an existing product, or not yet. Saying so early is more useful than agreeing and finding out afterwards.
Executive communication
Board-ready summaries and direct written updates. Nothing important is left to be inferred from a ticket board.
Security-conscious architecture
Access control, data separation and audit evidence specified at design time, and defensible in front of a security review.
Product ownership mindset
Accountability for whether the thing works in the business, not only for whether it was delivered to specification.
Efficient execution
AI-assisted development compresses build time. Judgement, architecture, review and security standards stay human and senior.
Experience timeline
Capability, not employers
Which capabilities were built when, and where each one still applies. Nothing here has been retired — later work is layered on top of earlier work.
- 2003 onwards
Enterprise infrastructure
Networks, systems, datacentre operations, resilience and continuity in BFSI environments with real availability obligations.
- 2009 onwards
Technology leadership
Owning budgets, vendors, delivery standards and technology roadmaps, and defending them to non-technical decision makers.
- 2013 onwards
Cybersecurity
Security architecture, identity and access, threat and vulnerability management, incident response and enterprise security review.
- 2016 onwards
Governance and compliance
Policy, control frameworks, supplier assurance, data protection obligations and the evidence auditors and enterprise buyers require.
- 2019 onwards
Product strategy
Discovery, scoping and validation: deciding what to build, what to defer and what to decline before budget is committed.
- 2021 onwards
Product and technology execution
Leading product and technology for new platforms, including GradNextSteps — small teams, real constraints, decisions made with incomplete information and owned anyway.
- 2023 onwards
AI products
Designing, evaluating and shipping AI-enabled features with tested prompts, measured outputs and human review where the result matters.
Working principles
Working principles
Short enough to be held to. These are the tests a proposal has to pass before I put my name on it.
- Solve the right problem before building
- Most failed platforms were built competently against the wrong problem statement.
- Business outcomes over technical complexity
- Sophistication that no commercial outcome depends on is cost without return.
- Keep products simple
- Fewer concepts, fewer screens, fewer states. Simplicity is what makes software teachable.
- Build for maintainability
- Assume the team that inherits this does not have access to whoever wrote it.
- Design for scale, build for now
- Leave the seams where growth will arrive; do not pay for that growth before it does.
- Measure success through adoption
- Usage by the people whose work it was meant to change is the only result that counts.
Areas of expertise
Where the experience is concentrated
These reinforce one another. A platform built without governance fails security review; governance without delivery capability produces documents nobody uses.
- Technology leadership
- Senior accountability for architecture, delivery standards, vendors and technology risk, explained in commercial terms.
- Cybersecurity governance
- Access control, evidence, supplier assurance and the documentation enterprise buyers and auditors ask for.
- Enterprise IT and infrastructure
- Networks, systems, datacentre operations, resilience and continuity in environments with real availability obligations.
- Technology strategy
- Sequencing technology work against commercial milestones, with cost, risk and dependencies stated plainly.
- Custom business platforms
- Replacing manual processes, spreadsheets and disconnected tools with systems the team adopts because they remove work.
- Privacy and compliance
- Turning data protection obligations into tracked work with owners, evidence and deadlines held in one system.
- BFSI and regulated environments
- Senior accountability for delivery and security standards in organisations where evidence and auditability are non-negotiable.
- Product discovery and MVP development
- Turning an idea or mandate into a validated scope, a costed plan and a first version real customers can use.
- AI-enabled product development
- Selecting, evaluating and shipping AI-enabled features that are tested against real data and reviewed by a person where the output matters.
Questions
Frequently asked
The questions asked most often, answered without qualification.
What types of businesses do you work with?
Regulated organisations in financial services, healthcare and education, growing mid-sized businesses, private equity portfolio companies, professional services firms, and early-stage teams shaping a product. The common factor is a decision that is expensive to get wrong, not a company size.
Do you build products from scratch?
Yes. Discovery, architecture, design, build and launch of new platforms and products, including AI-enabled ones. Engagements usually start with a fixed-scope discovery that produces a validated scope, a prototype and a costed delivery plan before any build commitment is made.
Can you work with existing engineering teams?
Yes. That is a common arrangement: I provide architecture, delivery standards, security posture and technical review while the in-house or outsourced team builds. The intent is to raise the team's ceiling, not to replace it.
Do you provide technology strategy?
Yes — technology leadership covering architecture, roadmap sequencing, vendor and build-versus-buy decisions, security posture and board-level reporting.
Can you help validate product ideas?
Yes. Product discovery is a distinct, fixed-scope engagement ending in a validated scope, a working prototype and a costed plan. It is deliberately separable, so the plan can be delivered by another team if that is the better commercial choice.
Do you build AI products?
Yes, where the model does specific, testable work inside a reviewed workflow — extraction, classification, drafting, summarisation and assisted review. Where output cannot be verified against real data, I recommend against using a model rather than shipping something unaccountable.
Do you work internationally?
Yes. Engagements are delivered remotely for clients in India, the United Kingdom, the United States and EMEA, with working hours agreed to give a reliable overlap.
How do engagements typically begin?
A short written summary of the business context and the constraint, then a 30-minute call. If it is a fit, the first commitment is a fixed-scope discovery rather than an open-ended build.
Current focus
Current thinking, decisions and delivery detail are published as Insights and case studies.
Let's discuss a technology, security or transformation challenge.
Share the context and the challenge you are working on. I will reply personally.