FinOps Engineer

A FinOps Engineer is a technical professional who makes cloud expenditure understandable and usable for decision-making. They connect consumption data with how infrastructure operates and what the business needs. Their work helps technical, finance and business teams choose relevant optimisations, taking service performance, reliability and security into account.

Their remit covers expenditure visibility, cost allocation and actions to make better use of cloud resources. They can explain which team uses a resource, what causes a change in cost and which possible adjustments merit investigation. Accounts, tags and other metadata make this analysis possible, provided there are explicit allocation rules for shared costs.

The role combines economic analysis with technical understanding. A bill alone cannot determine whether a resource is oversized: its cost needs to be considered alongside its utilisation and the service's constraints. A FinOps Engineer also contributes to forecasts based on observed trends. This contribution does not make them responsible for the overall budget.

FinOps Engineer, cloud architect and DevOps engineer: who does what?

• A FinOps Engineer connects costs and usage to inform trade-offs and track optimisations.
• A cloud architect designs infrastructure and guides technical choices according to the business's needs and constraints.
• A DevOps engineer automates application delivery and environment management. Their skills can contribute to implementing changes.

These responsibilities complement each other. The role described here concerns cloud cost optimisation and governance, without extending to general financial operations. Its reporting line and approval authority must be defined within each organisation.

Cloud expenditure alone does not indicate whether a business uses its resources efficiently. To make decisions, managers need to understand what is being consumed, by whom and for which service. A FinOps Engineer provides this shared understanding. It enables teams to discuss technical choices using data and to take responsibility for the usage they can change.

The first challenge concerns cost allocation. A cost shared between several products can distort comparisons if allocation rules remain implicit. Conversely, documented allocation allows everyone to understand what has been assigned to them. Before asking a team to reduce costs, it is better to establish whether it actually controls the resources concerned.

Another challenge is to distinguish between two approaches. Usage optimisation addresses unused or oversized resources. Rate optimisation examines terms suited to sufficiently stable consumption. On AWS, Savings Plans and Reserved Instances illustrate this second approach. A FinOps Engineer takes usage variability into account when assessing commitments. They then monitor the utilisation and coverage of the commitments selected. Reducing consumption and choosing a pricing commitment therefore address different questions.

Fictional example: a team is considering reducing the capacity of a service whose average utilisation appears low. The FinOps Engineer compares consumption data with performance requirements. Together with the technical leads, they examine the constraints before proposing an adjustment. An expected saving does not, on its own, justify a deterioration in service.

When recruiting, selecting solely for the ability to produce expenditure tables would be a poor choice. The role must also connect analysis with decisions and their implementation. Without an understanding of the infrastructure or dialogue with those responsible for it, a recommendation may be unusable. The technical level required therefore depends on the changes the person will need to support.

• Collect and structure cloud cost and usage data to produce actionable analysis.
• Allocate expenditure to teams, projects or products using explicit rules, including for shared costs.
• Analyse trends and unusual variances to plan actions and contribute to forecasts.
• Identify unused or oversized resources based on usage and technical constraints.
• Assess pricing commitment options according to consumption stability and monitor their utilisation and coverage.
• Help technical and finance leads assess trade-offs between cost, performance and reliability.
• Support technical teams in the selected optimisations and measure their impact.
• Automate the data processing needed for regular expenditure monitoring.

Useful knowledge and skills combine an understanding of infrastructure, data analysis and the ability to work with finance colleagues. A qualification's title alone is not enough to assess these capabilities.

A background as a DevOps Engineer can provide transferable skills in environment management and automation. Understanding cloud costs and being able to discuss their implications with finance complement these skills. This transition is one option, rather than a mandatory route. For its dedicated cloud cost function, GitLab documents skills drawn from reliability engineering and software development.

FinOps training can build on this technical foundation. The FinOps Foundation offers FinOps Certified Practitioner, among other options, to establish a grounding in its practice framework. This certification can help structure knowledge and shared terminology. It does not, on its own, demonstrate the autonomy needed to analyse infrastructure or carry out an optimisation.

The foundations of GetPro's method

GetPro prepares the assessment using a framework that distinguishes between criteria verifiable from a candidate's background and those to explore further at interview. Each criterion is linked to an assessment method. Interviews explore key skills through open questions and concrete examples.

Reference checks complement this analysis by placing skills in the context of a past working relationship and asking for examples. A summary brings together strengths and points requiring attention to support the decision.

Assessment suggestions to adapt to the role

The criteria and exercises below are suggestions for assessing a FinOps candidate. They do not describe a specific protocol used by GetPro. You can adapt them to the role's responsibilities.

1. Define the criteria before the interviews

Specify the data to analyse, the infrastructure concerned and how directly the candidate will be expected to make changes to cloud resources. Distinguish between producing reports, recommending an action and participating in its implementation.

Choose observable criteria: reliability of analysis, technical understanding, quality of trade-offs and explanation to the relevant colleagues. For each, indicate the level of support available. This will give you a common basis for comparing candidates.

2. Examine a past achievement

Ask the candidate to present a cost analysis and the decisions it helped inform. Ask them to specify the data used, the allocation rules and the limitations encountered.

Explore their personal contribution: what data-processing steps did they develop, what recommendation did they make and who carried out the changes? Ask how the effects were monitored.

A positive sign is an explanation that connects the data, how the resources operate and the service's constraints. A claimed saving without usage context or a distinction between individual and collective work calls for further questions.

3. Set a practical exercise relevant to the role

Fictional example: provide cost and utilisation data for a cloud service shared by several teams. Add a change in consumption and an incomplete allocation rule.

Ask the candidate to identify missing information, propose an allocation and formulate an initial hypothesis about the change. Then invite them to explain what they would check before recommending a capacity reduction.

If the role includes rate optimisation, ask how they would examine usage stability before considering a commitment. Have them distinguish between monitoring commitment utilisation and monitoring coverage.

Assess the approach as much as the conclusion. Does the person distinguish a fact from a hypothesis? Do they connect their proposal with the expected performance and reliability? An immediate recommendation based solely on the bill is a warning sign.

4. Observe communication and coordination

Ask for a short presentation intended for a finance manager, followed by a discussion with a technical colleague. Observe whether the candidate maintains the same reasoning while adapting their explanations.

Introduce a disagreement about a proposed optimisation. Ask them to specify the constraints to clarify, the people to involve and the decision requiring approval. Look for an ability to make the choice understandable without promising a certain gain.

If the role includes management, explore a real situation involving team coordination. Otherwise, focus this stage on the cooperation needed to move an action forward.

5. Cross-check observations and references

Bring the assessors together around the criteria defined at the outset. Separate demonstrated capabilities from areas that would require support. Avoid offsetting an essential technical weakness solely with ease of presentation.

During reference checks, seek to clarify the responsibilities held, the level of autonomy and collaboration with teams. Use these conversations to shed light on interview observations.

If your company lacks the necessary cloud expertise, involve a technical expert who can examine the reasoning and infrastructure constraints. Include a finance colleague in assessing the clarity of the analyses.