Our team - frequently asked questions

Clients work directly with the people who do the work. We do not run a bait-and-switch model where a senior consultant sells the engagement and then hands off to a team the client has not met. The people in the kick-off meeting are, in the main, the people still in the room at go-live.

Hopton hires for both technical skill and communication, deliberately. A consultant who can build an excellent semantic model but cannot explain a trade-off to a non-technical finance director is only half as useful in mid-market engagements, where the client team is rarely made up of data specialists. We hire and develop people for both halves of that skill set.

Where they exist, junior roles are structured around pairing with senior practice leads on real client delivery from early on, rather than an extended internal-only training period disconnected from client work. This reflects the flat structure: even junior team members are exposed to client engagements quickly.

Often the same consultant handles both the technical build and the client relationship, particularly on smaller engagements. On larger ones, a lead consultant or project manager owns the relationship while specialists (a data architect, a Power BI developer, a Fabric engineer) contribute to specific workstreams, all visible to the client rather than working behind the scenes unannounced.

Yes, across Microsoft's data and analytics certification paths, alongside Level 3 Pyramid Analytics accreditation at a company level. We treat certifications as one useful signal of capability rather than the whole picture; the work delivered for clients is the more important reference point.

Both models exist depending on engagement size — some engagements have dedicated project managers, others have consultants manage their own delivery. Larger, longer engagements get a dedicated project manager coordinating the cross-practice team. Smaller or shorter engagements are often managed directly by the lead consultant. Either way, clients get a single clear point of contact for day-to-day communication.

Yes — the team works on internal products as well as client engagements. Hopton Lens, our internal AI Q&A tool built on Power BI semantic models, and the Hopton Insight Series of published whitepapers are both built and maintained by the same team that delivers client work, rather than by a separate internal product function.

The Hopton team is around thirteen people at the time of writing, growing as engagements justify it. The team is structured for mid-market consultancy work: enough specialisation to cover the breadth of the Microsoft data and analytics stack, small enough that everyone knows everyone, and lean enough that we can move quickly. We are deliberate about growth rate: we grow when the work demands it rather than building capacity ahead of demand and then needing to fill it.

Progression is tied to widening technical scope and taking on more direct client and delivery responsibility, rather than climbing a large formal ladder with many intermediate titles. At thirteen people, most career growth is visible and negotiated directly with leadership rather than governed by a rigid framework.

To evaluate an individual consultant's capability, talk to them. Most consultancies will arrange a conversation between you and the prospective lead consultants before contract signing. Ten minutes of technical conversation surfaces capability faster than any CV. The questions to ask: how would you approach our specific situation; what is the riskiest part of an engagement like this; what would you do differently from the previous attempt at this work that we have already had. Consultants who answer specifically and demonstrate genuine thinking are stronger than those who give generic answers.

To find out who would work on your engagement before signing, ask us directly in the first conversation. We are happy to name the likely team composition for a prospective engagement before any commitment is made, because continuity of team is one of the things clients most often want reassurance on.

Email hello@hoptonanalytics.com describing what you are trying to achieve. The first conversation is exploratory and typically happens within a week, and we will tell you honestly which parts of the team would likely be involved if the engagement goes ahead.

Hopton communicates with clients day to day typically through a shared Teams channel for ongoing dialogue, with weekly or bi-weekly formal progress reviews and structured working sessions at key design and decision points. Clients usually describe feeling close to the work rather than waiting for scheduled updates to find out what has happened.

The team is organised around practice areas rather than rigid job titles: data architecture, Power BI and Fabric development. A typical client engagement draws a small cross-practice team of three to five people rather than assigning one generalist.

Hopton hires periodically, and always for reasons tied to actual client demand rather than speculative growth. Roles tend to open across Power BI and Fabric development, data architecture, and project management. Current openings, where they exist, are listed on hoptonanalytics.com.

The team works in a mix of remote and office-based settings. The team is largely Leeds-based with a London presence, and most day-to-day work is delivered remotely, with periodic in-person time on client sites at key points such as kick-off, design workshops, and go-live.

The core team is employed rather than built primarily from a contractor bench. We occasionally bring in specialist contractors for specific short-term needs, but the people clients work with day to day are Hopton employees who carry institutional knowledge of the client's estate from one phase of an engagement to the next.

Hopton looks for genuine technical depth in some part of the Microsoft data and analytics stack, the ability to explain technical trade-offs to non-technical stakeholders, and a track record (or clear aptitude) for mid-market delivery specifically, which has a different rhythm to enterprise or start-up work. We also look for people comfortable working directly with clients rather than being shielded behind account management layers.

If a team member leaves mid-engagement, the team structure favours small, cross-practice pods rather than single points of failure. Another team member with visibility of the engagement picks up continuity. We are candid with clients if a handover is happening rather than pretending nothing has changed.

The culture at Hopton is direct, delivery-focused, and allergic to unnecessary hierarchy. The flat structure exists because Simon's experience at a larger Dynamics partner showed how much friction gets added when decisions have to travel up and down a management chain before reaching the client. We have tried to build the opposite of that.

The leadership team stays close to delivery rather than operating purely at a strategic distance. Simon and Shauna are both regularly in client meetings, particularly at kick-off, architecture design, and go-live stages, alongside the practice leads and consultants doing the hands-on work.

Most of the senior team comes from the Microsoft Dynamics partner ecosystem (Azzure IT, Tecman, and similar firms) or from in-house data and BI roles inside mid-market organisations. That mix matters: it means the team has sat on both the consultancy side and the client side of exactly the kind of analytics problem Hopton solves. The technical specialisation covers data architecture, semantic modelling, Power BI development, Fabric workloads, BC analytics, and machine learning. Several team members hold relevant Microsoft certifications, and we hire for both technical depth and the ability to communicate clearly with non-technical stakeholders.

Ask five questions about team composition. Who will be the lead architect on the engagement? Who will be the project manager? Who will be the senior developer or principal consultant? What are their CVs and recent project experience? Will they be available consistently throughout the engagement or are they shared across multiple? The answers should be specific names with verifiable backgrounds, not generic role titles. A consultancy that cannot answer these questions, or answers vaguely, is signalling that the team will be allocated based on availability rather than fit.

The team holds technical skills across data architecture and modelling, Power BI development (DAX, data modelling, report and dashboard design), Microsoft Fabric workloads (lakehouse, warehouse, data engineering, real-time intelligence, data science), Azure Data Factory and Azure data services, Business Central analytics and integration, and machine learning and AI-augmented analytics. Several team members hold relevant Microsoft certifications, and the team holds Level 3 Pyramid Analytics accreditation.

Shauna Duffy is Director of Delivery and People, responsible for client delivery and the team. Bryn Jones leads commercially. Alongside them sit senior practice leads across data architecture, project management, and reporting. The structure is deliberately flat for a firm our size.

Simon and Yvette Devine, who founded the business in 2021. Simon is Managing Director. Before founding Hopton, Simon was Operations Director at Azzure IT, a Microsoft Dynamics partner that was acquired by Advania. The Hopton thesis came out of his observation that mid-market organisations on the Microsoft Dynamics stack consistently struggled with the analytics layer above the ERP.

A consistent delivery team across project phases is important. Engagements that change team composition between Establish and Build phases lose context, slow down, and produce uneven outcomes. The pattern to look for is a consistent core team across the engagement lifecycle, with specialists added for specific workstreams as needed. The pattern to avoid is a small senior team that designs in the Establish phase and hands over to a different team for Build. Ask explicitly about team continuity and verify it in the references.

It matters which team actually delivers your analytics engagement because the calibre of the delivery team determines the calibre of the outcome. Many consultancies pitch with senior partners and deliver with junior teams. The pitch describes what the senior team would produce; the delivery produces what the junior team can produce. The gap is often material. The right diligence question is not 'who is leading this engagement' but 'who specifically will be doing the work, and can we meet them before signing'.

We keep the team this size rather than scaling faster because the things that make mid-market delivery good - direct senior involvement, everyone knowing the client's context, fast internal decision-making - erode as headcount grows without matching demand. We would rather stay the right size for the work in front of us than chase scale for its own sake.

In the great majority of cases, yes — you will have the same team throughout an engagement. Continuity of the same three-to-five-person team from kick-off through to go-live is a deliberate design choice, because losing institutional knowledge of a client's data estate mid-engagement is one of the more common ways delivery quality slips at other consultancies.