BI Developer Job Description Template 2026

Last updated: September 4, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

A BI developer job description has to say which layer of the stack the seat owns, what condition the existing report estate is in, who arbitrates metric definitions, and the salary band. Skip those and the posting describes a dashboard builder, a data engineer, and a report migration specialist with equal accuracy, which is why the applicant pool comes back looking like a lottery. Published US figures for the title run from roughly $112,000 to $153,000 depending on which source you read, and the spread is telling you something.

The tell was in the nice-to-haves.

A client sent me a req last spring for a second look before it went live. Nine hundred people, regional distribution, decent internal analytics team. Not a chaotic place. The posting was competent. Title, summary, eleven bullets of responsibilities, a skills list with Power BI and DAX and SQL and a nod toward Azure. Second-to-last line under “preferred qualifications,” almost an afterthought: experience with SSRS a plus.

I asked how many SSRS reports they were running.

Nobody knew. It took their DBA about a day to come back with a number, and the number was 340. Roughly a hundred of those had not been opened by a human in over a year. The rest fed month-end close, three regional sales reviews, and a compliance packet that went to a board committee every quarter.

Not a dashboard job. That is an inheritance, and it needed to be in the second paragraph of the posting instead of buried in the preferred section as a plus.

They had already run this search twice. Two hires, two departures inside a year, and both exits were polite versions of the same sentence: this was not the job I thought I applied for. Twice. Same sentence.

My angle, so you can discount for it. I co-founded KORE1 in 2005 and I still spend a lot of my week with clients whose searches have stalled. We run a BI developer staffing desk inside our broader IT staffing practice, and we only get paid when somebody actually hires. Most of this page is about writing a better posting, which costs you nothing and involves us not at all.

Say Which Layer of the Stack the Seat Owns

Four layers wear this title. Almost nobody says which ones are theirs.

Under the reports sits a warehouse, and under that sit the pipelines pulling from your ERP and your CRM and whatever else. Above the warehouse there is usually a semantic model, the thing that decides that revenue means this and not that. On top of all of it, the reports and dashboards people actually look at.

Some BI developers live entirely in the top layer. They get clean, governed tables and they build on them. Others own everything from the source system up, which in a smaller company is genuinely one person and in a larger one is three. One title, though. The title does not distinguish between those people. Your posting has to.

That last row is where postings quietly go wrong. Platform administration is real work. Gateway ownership, capacity throttling, license math, and who gets a workspace and who does not. It never makes the job description, because nobody files it under job. Then your new hire spends a third of the first quarter on it and you wonder why the reporting backlog has not moved. It happens constantly.

Two sentences fix this. Name the layers this person owns and name the ones they do not, then say who owns those instead. If the honest answer is that nobody owns the warehouse yet and this hire is expected to build it, say that out loud, because it is a completely different candidate and about twenty thousand dollars of a different band.

A Lot of These Are Migration Reqs That Do Not Say So

Microsoft ended the line. Starting with SQL Server 2025, all on-premises reporting consolidates under Power BI Report Server, and no new versions of SSRS will ship. SSRS 2022 gets security updates through January 11, 2033, which sounds far away and is not, given how these estates actually get modernized.

So there is a large population of companies sitting on hundreds of RDL reports with a clock on them. Plenty of them have a req open today. Their job descriptions rarely mention it. Almost never.

Here is what the work actually involves, and it is worth being blunt about because it changes who is qualified. RDL reports carry expressions written in VB.NET. Those do not survive a move to Power BI. They get rewritten in DAX or Power Query, one at a time, by somebody who understands both what the old expression was doing and what the business thought it was doing, and those two things are not always the same. Add report inventory and triage. Add the political work of telling a VP that the report they asked for in 2019 has eleven views this year and is not getting rebuilt.

An engineer who has run one of these migrations end to end is a different hire from a strong dashboard developer. Better in this seat. Scarcer. More expensive, and worth it, because the alternative is a talented Power BI person discovering in month two that most of the work is archaeology. Good archaeology. Still archaeology.

Put the estate in the posting. Count first. “We run 340 SSRS reports and expect to retire or migrate them over the next 18 months” is one sentence and it does more filtering than your entire requirements section. It also does something subtler, which is that it attracts the specific engineer who likes this work. That person exists. They are never out of work for long, and they will not find you if your posting reads like a greenfield dashboard role.

Who Gets to Decide What a Metric Means

This is the omission that costs the most and appears in almost no job description I read.

A BI developer builds the layer where a number becomes official. Once “active customer” is a measure in a semantic model, it stops being a debate and starts being a fact that five departments plan against. Somebody has to decide. In a well-run shop it is a data governance function with the BI developer implementing. In most shops it is nobody, so it becomes the BI developer by default, at the exact moment finance and sales disagree about a figure with a bonus attached to it. Which happens.

Your posting should say which of those two worlds this person is walking into. Say which one.

The candidates who are good at the second version are not identifiable from a resume. They have a particular temperament. They will sit in a room with a controller and a VP of sales and get to a definition everyone can live with, then write it down somewhere durable, then hold the line when somebody wants a one-off variant for a board deck. Not a Power BI skill. It is closer to a diplomacy skill with SQL attached, and it is the single biggest predictor of whether the hire is still there in two years.

You can screen for it. What that looks like question by question is worked through in our guide to BI developer interview questions. What matters for the posting is simply saying it exists. One line under responsibilities: “Own the definition of core business metrics in partnership with Finance and Operations.” Candidates who want that job will tell you so in the first screen. The ones who do not will self-select out, which is the entire point of a job description.

What the Published Averages Are Measuring

Compensation data for this title is a mess, and the mess is the finding rather than a nuisance.

Forty grand of daylight between the top and bottom of that table. Every figure is accurate. They are counting different people.

The O*NET data for business intelligence analysts puts the 2025 median at $120,230 with projected growth of 7 percent or higher through 2034, and lists Power BI as the top in-demand technology for the code alongside Snowflake, SSRS, and Alteryx. Move one code over to data warehousing specialists and the 2025 median jumps to $139,500 on employment of about 66,900. Same broad function. Nineteen thousand dollars apart, because the second code assumes the person owns the layer underneath.

Which is the whole argument of this page, arriving from a different direction. The band you should post follows from the layers you assigned two sections ago. Assign the semantic model and the warehouse, price against the higher code. Assign reports on top of governed tables, price lower and be honest about it in the posting so you are not wasting a senior candidate’s afternoon.

The Built In figure deserves a caveat. It samples tech companies and startups, and if you are a 900-person distributor in Ohio you are not bidding against that number for most candidates. You might be for a few. Remote work made the ceiling portable in a way it did not used to be.

Post the band. Colorado, Washington, New York, and Illinois all require a pay range in the posting itself, and California makes any employer with 15 or more people do the same, remote roles that could be filled in the state included. Compliance aside, a posted range filters harder and faster than any screening question you could write. Our BI developer salary guide breaks the numbers apart by level, stack, and city, and the salary benchmark assistant will price a band against your actual scope for free.

The BI Developer Job Description Template

What follows is meant to be edited, not admired. Bracketed text is yours to replace, and the notes inside brackets explain why the line earns its place. Delete the notes before you post.

Job Title

[BI Developer, Power BI / Senior BI Developer / BI Developer, Reporting Modernization] [Put the platform in the title. Job boards weight titles far more heavily than body text, and so do candidates scanning a results page. “BI Developer, Power BI” beats the bare title on qualified applications every time we have tested it with a client.]

About the Role

[Company] is hiring a BI developer to own [the semantic model and reporting layer / reporting end to end] for [finance, operations, and commercial teams]. We run [Power BI on Fabric F64 capacity / Tableau Cloud / Power BI Report Server on premises] against [Snowflake / Azure SQL / a SQL Server warehouse we built in-house], with [Azure Data Factory / SSIS / Fivetran] moving the data. You will report to [role] and work day to day with [the specific stakeholders this person will have to negotiate with, by function].

Where the Reporting Estate Stands Today

[This section does not exist in most postings and it is the reason most of these searches restart. Be specific and be honest.] We currently run [340] reports across [SSRS, Power BI, and a lot of Excel]. [Roughly a third are actively used. Part of this role is deciding what happens to the rest.] [Our warehouse exists and is reasonably clean / We do not have a warehouse yet and building one is in scope / We have a warehouse nobody trusts and fixing that is the first project.]

What You Will Own

• The semantic model. Star schemas, DAX measures, row-level security, and the documentation that lets somebody else understand what you built
• Definitions of core business metrics, in partnership with [Finance and Operations]. [Leave this line in. It is the highest-signal sentence in the posting.]
• [Migration of [N] RDL reports from SSRS to [Power BI / Power BI Report Server], including the triage call on which ones do not get rebuilt]
• Report performance. When a page takes nine seconds to render, you are the person who finds out why
• [Refresh scheduling, gateway health, and workspace governance, roughly [X]% of the role. If somebody else owns the platform, say so here and name them.]
• Intake. Turning “can I get a report on churn” into a specification that produces a number people will act on

What We Need to See

• [3+] years building production BI on [Power BI / Tableau], with real dimensional modeling behind it and not just visuals on flat extracts
• SQL that goes past joins. Window functions, query plans, and enough instinct to know when a problem belongs upstream
• [DAX at the level of time intelligence, calculation groups, and context transition. A candidate who can explain why a measure behaves differently in a matrix than in a card has told you most of what you need.]
• [If migrating: demonstrated SSRS or RDL experience, including rewriting VB.NET expressions as DAX or Power Query]
• Evidence they have disagreed with a stakeholder and kept the relationship. Ask for the story in the screen
• [If your warehouse work is in scope: [dbt / Snowflake / Synapse] and ETL ownership, which changes the band. Price it before you post it.]

Nice to Have

• Second platform exposure, since most companies end up mixed whether or not anyone decided to
• [Your industry.] Healthcare claims, manufacturing cost accounting, and subscription revenue each carry their own data model traps that take a year to learn
• Version control and deployment pipelines for BI artifacts, still rare and still a strong signal
• Python or R for the reporting work that does not fit in a dashboard

Tools, Access, and Licensing

[Underrated section. Say what they get.] You will have [Power BI Premium Per User / capacity access], [admin rights or not] on [the tenant / the gateway], and [a Snowflake role with rights to X]. [If this person needs to request access through a ticket every time they touch a source system, say that here rather than letting them find out in week two.]

Compensation and Logistics

[$115,000 to $145,000] base, plus [bonus], [benefits], [equity if applicable]. [Onsite / hybrid [N] days in [city] / remote within [states]]. [If the band moves for warehouse ownership or migration scope, say what moves it.]

Lines Worth Cutting

Most BI developer postings are too long, and the excess is load-bearing in the wrong direction. Some candidates read a twenty-bullet requirements list as a company that does not know what it wants. They are frequently right.

Cut “strong analytical and problem-solving skills.” It filters nobody.

Cut the tool list that runs to nine items. If you list Power BI, Tableau, Qlik, Looker, SSRS, SSAS, SSIS, Python, and R, an experienced candidate reads that as either an unclear scope or a job that is three jobs. Name the two that matter and put the rest under nice to have. Two. Maybe three.

Cut “bachelor’s degree in Computer Science, Information Systems, or related field required” unless you will genuinely reject a strong candidate over it. A meaningful share of the best BI developers we place came in through finance or operations analyst roles and learned the engineering on the way. The degree line quietly removes them from your pool before you ever see a resume.

Cut the warnings. “Must thrive in a fast-paced environment” and “ability to manage competing priorities” are how postings say the word chaos without saying it, and the candidates you want have learned to translate. They translate fast.

Before You Hit Post

Our posting says Power BI and we keep getting analysts. What is pulling them in?

Usually the responsibilities section. If the bullets are mostly about building reports and answering questions, you have described an analyst, whatever the title says at the top.

Add modeling language. The filter fixes itself. “Design and maintain the semantic model” and “own DAX measure definitions” are phrases an analyst reads and skips. The other adjustment is the tool list. Listing Excel next to Power BI as though they are peer skills reads as an analyst posting to anyone senior, and they are gone before the second bullet.

We are trying to get off SSRS. Do we still put SSRS in the posting?

Leaving it out to look modern is the version of this that backfires. The engineers who can actually run your migration search that exact term, and a posting without it never reaches them.

Frame it as the mandate rather than the maintenance. “Lead the migration of 340 RDL reports to Power BI” and “maintain existing SSRS reports” describe the same estate and attract completely different people. One is a two-year project with a visible finish line. The other sounds like being the last person in the building who knows Report Builder.

Should the title say BI developer or analytics engineer?

Different jobs. The split is where the transformation happens. Analytics engineers build models in the warehouse, usually in dbt. BI developers build the semantic layer and the reports above it.

There is real overlap in smaller companies where one person does both, and if that is your situation say so plainly rather than picking a title and hoping. Both terms get searched heavily. We staff both desks, and a fair amount of the early work in any search is figuring out which one a client has actually described. If it helps to compare, our analytics engineer job description template and our data analyst job description template sit next to this one on purpose.

We have no warehouse. Can one person build it and the reports?

Sometimes, for a while. It works at small data volumes with a patient stakeholder group, and it stops working the moment either of those changes.

The risk is not capability. It is sequencing. Someone building a warehouse has nothing to show for four months, which is a long time to hold executive patience when the reason you hired them was that the CFO wanted a dashboard. If you go this route, write the sequence into the posting and into the first review cycle so both sides are looking at the same calendar. Otherwise you get an unhappy engineer in month five doing warehouse work at night to keep the report requests moving during the day.

Three months in and the pipeline is thin. Is that the req or the market?

Nine times out of ten it is the req. Genuine BI developers are in short supply but they are not rare, and a well-scoped posting in a mid-size metro gets qualified applicants inside three weeks.

Run the diagnostic in order. Look at the title, then the salary band, then the first hundred words. If the title is “Business Intelligence Developer III” you are invisible to search. If there is no band in a state that requires one, you are also possibly out of compliance. If the first paragraph is about the company rather than the work, you lost the scroll. Our average time to hire across the desk runs about 17 days and twelve-month retention on placements sits at 92%, and neither of those numbers comes from sourcing harder. They come from fixing the req before the search starts. The full process view is in our guide on how to hire a BI developer.

Contract or direct hire for a reporting migration?

Both, in sequence. Migration work is a curve with a peak and an end. The seat that owns reporting afterward is permanent, and conflating the two is why the second search starts late.

Bring in contract BI developers for the migration push while a parallel direct hire search runs for the person who will own the estate once it lands. The permanent hire then arrives while the migration team is still in the building, which is worth considerably more than any handoff document you will ever be given. If the platform decision is still open, we staff both Power BI developers and Tableau developers, and the honest answer usually comes down to what your finance team already has on their desktops.

What to Fix First

Name the platform in the title. Say which layers of the stack the seat owns and who owns the rest. State how many reports exist today and what is supposed to happen to them. Count them first. Say whether this person defines metrics or implements definitions somebody else owns. Post the band.

Five things. Ten minutes of typing once you have the answers, and getting the answers is the part that takes a week, which is the actual reason most postings skip them.

That distributor eventually reposted. Same company, same budget, a rewritten req that led with the 340 reports and the migration mandate. They had a signed offer in five weeks with a candidate who had done exactly that work at a healthcare system in Columbus and specifically wanted to do it again. Nothing about the market had changed. The posting had.

If you want a second read on a req before it goes live, or you are three months into a BI search that is not converging, talk to our data team. We run data and analytics searches across 30+ US metros, and the req review costs nothing whether or not you ever run a search with us.