At some point, every BI team lead whose team has grown past three or four developers hits the same moment. Deployment coordination is eating senior time. Incidents are creeping up. The process that worked fine with two developers does not work with six. You know something has to change.
The question is not whether to fix it. It is how to present the fix to leadership so it gets approved, rather than filed under “nice to have, maybe next year.”
This is a framework for that conversation. Three arguments that work, one that does not, and a way to keep the ask small enough to say yes to. It is written for the person who has to walk into their director’s office and make the case.
Leading with time savings is the most common mistake, and it is a trap.
When you tell leadership “we will save ten hours a week,” they hear “minor efficiency gain.” Time savings are hard to quantify precisely and easy to challenge in the meeting: someone asks how you measured it, and the conversation stalls. Worse, it frames CI/CD as a cost optimization, which puts it at the bottom of the budget queue behind everything that drives revenue. And the natural response writes itself: “we have managed fine so far.”
Hours saved is a true benefit. It is just not a compelling enough one to move a budget. Save it for after the decision is made, not before.
The frame: we have no change management for our most visible reporting system.
Every production incident in Qlik traces back to the same root cause: a change nobody knew about. No diff, no audit trail, no way to compare yesterday’s working app to today’s broken one. You troubleshoot by guessing.
What to say in the room:
“When a production dashboard breaks, we have no way to see what changed. We troubleshoot by guessing, while the business waits.”
“We cannot roll back cleanly. Our recovery plan is finding a backup file and hoping it is current.”
“Every other critical system we run has change management. Qlik is the gap, and it is the system leadership looks at most.”
Why this works: risk is a language budget holders already speak. It moves CI/CD from “developer convenience” to “risk mitigation,” and it connects to compliance and governance conversations that are probably already happening somewhere in the organization.
Numbers that make it concrete, if you have them: how many production incidents in the last twelve months came from untracked changes, how long the average incident takes to resolve without a diff or a rollback, and how many of your Qlik apps now feed downstream systems like automated reports or AI workflows.
The frame: our most expensive talent is doing work a pipeline handles automatically.
A senior Qlik developer is an expensive hire. A meaningful share of their week goes to work that does not need them: coordinating who deploys what and when, investigating what changed after an incident, manually moving apps between environments, and being the single point of failure for every production deployment.
What to say:
“Our senior developer spends a real share of each week on deployment coordination instead of data modeling and architecture, which is what we actually hired them for.”
“When that person is on vacation, we effectively cannot deploy.”
“This is not a tooling problem. The tooling exists. It is a process gap we have not prioritized.”
Why this works: it reframes the spend from cost saving to getting your most expensive people onto the work only they can do. “Our most expensive person is doing our lowest-value work” is a sentence leadership understands immediately. It also connects to retention, which leadership cares about more than tooling: senior engineers get restless on teams that still operate like it is 2010.
The frame: every other team in the engineering organization has CI/CD. We are the exception.
Lay it out plainly:
What to say:
“We are asking leadership to invest in data and AI strategy while the analytics layer those initiatives depend on has no version control.”
“As more systems start consuming Qlik output, an unversioned change stops being an operational annoyance and becomes a strategic risk.”
“Adopting CI/CD for Qlik aligns us with the engineering standard the rest of the organization already follows.”
Why this works: it connects to initiatives that already have budget and attention, like AI and data strategy. It frames the BI team as catching up to a standard, not asking for something exotic. A director hears “my team wants to operate at the level I already expect from engineering,” which is a request that is easy to back.
Leadership approves phased approaches, not big-bang transformations. A request to “transform how we do BI” sounds expensive and risky. A request to “test one thing for two weeks” sounds safe. Ask for the second one.
Phase 1, weeks one and two: pilot with one app. Pick a non-critical app with two or three developers. Set up version control by decomposing it to Git. Practice the workflow: branch, change, review, merge. No pipeline yet, just source control.
Phase 2, weeks three and four: add the pipeline. Set up automated deployment for the pilot app, DEV to TEST to PROD, with a manual approval gate before production.
Phase 3, months two and three: expand. Onboard the remaining apps, train more developers, and formalize the process.
What to say: “The pilot needs one app, two developers, and two weeks. If it does not work, we have lost very little. If it does, we have proof for the full rollout instead of a promise.”
Keep the ask small and specific. Three things:
Do not ask for a DevOps transformation. Ask for a two-week pilot to see whether structured deployments work for your team. The smaller and more reversible the ask, the easier it is to approve.
If you are at the point where this conversation needs to happen, the hardest part is usually just framing it. The arguments above work because they speak leadership’s language: risk, talent, and strategic alignment. Not tooling features, and not hours saved.
If you want help preparing for that conversation, or want to see what a two-week pilot actually looks like on your own apps, we run 15-minute walkthroughs. Book one here.
No comments yet.
Leave a comment