If you ask a data analyst what they spend their day doing, they will probably tell you about queries, dashboards, and models. If you watch them work for a week, the answer is more uncomfortable. Most analysts spend more than half their time writing English, not SQL. Slack threads explaining a number. Confluence pages documenting a metric. Ticket replies pushing back on a vague request. Stakeholder emails translating analysis into a recommendation. The actual analysis is the smaller half of the job.
This is where voice to text changes the math. The query is rarely the bottleneck. The writing around the query is. Analysts who adopt dictation reclaim hours every week, often without realizing how much of their day was being eaten by typing.
Where the Writing Time Actually Goes
To see the opportunity, it helps to break down what an analyst's day looks like. A typical week might include:
- Three to five Slack threads explaining results to product managers, each one running 200 to 500 words
- Two ticket replies asking for clarification on ambiguous requests
- One full analysis writeup with executive summary, methodology, and findings
- Half a dozen comments on dashboards or metrics
- Documentation for a new ETL job or dbt model
- A weekly report or summary for the team
- Code review comments on teammates' SQL or notebook PRs
That is easily 5000 to 8000 words of original prose every week, on top of any actual analytical work. None of it is repetitive enough to template, and most of it cannot be skipped without consequences for how stakeholders perceive the data team.
Why Dictation Is a Better Fit for Analysts Than Most Knowledge Workers
Analysts have a few habits that make voice to text especially useful for them.
The first is talking through reasoning. Good analysts already verbalize their thought process. They rubber-duck queries with teammates, walk stakeholders through findings, and explain numbers verbally before they ever write them down. Voice typing turns this natural verbalization into the writing itself.
The second is the explanation tax. Every analytical answer comes attached to a why. "Revenue is down 8% this week, but it is mostly noise from a single enterprise customer's billing cycle, and once we exclude them the trend is flat." That kind of nuance takes longer to type than to speak, and it is exactly the kind of writing that suffers when an analyst is rushed.
The third is the cost of vague writing. A poorly worded Slack message about a number leads to a follow-up meeting, a wrong decision, or a lingering question that resurfaces three weeks later. Dictating gives analysts the bandwidth to write the thorough version the first time, instead of the terse version that creates more work later.
Specific Workflows That Get Faster
Slack Replies in Data Channels
The classic data team Slack pattern: a PM asks a question, the analyst pulls a quick query, then has to write a reply that explains both the number and the caveat. The query takes 90 seconds. The reply takes 5 minutes. With dictation, the reply also takes 90 seconds. Multiply by every Slack thread an analyst handles in a week, and the savings compound fast.
Documentation in Confluence, Notion, or dbt Docs
Documentation is the part of the job that everyone agrees matters and almost everyone postpones. The reason is simple: it is slow to type, and the reward is delayed. Dictating documentation in the moment, right after running the query or shipping the model, is fast enough that the friction disappears. An analyst can dictate a metric definition in 30 seconds instead of typing it in 4 minutes.
Stakeholder Email and Memo Writing
The hardest writing an analyst does is for non-technical stakeholders. The translation work, turning a finding into a recommendation, is genuinely creative and benefits from speech. When you say a sentence aloud, you can hear whether it sounds clear to a non-analyst. When you type it, you cannot hear it. Many analysts find their stakeholder writing improves measurably once they start dictating drafts.
Code Comments and PR Descriptions
Pull request descriptions are notoriously skimpy on data teams because writing a thorough one takes too long. A 30-second dictation produces a PR description with motivation, approach, and caveats, all of which make code review faster and reduce the likelihood that a future analyst has to reverse-engineer your intent six months later.
Office Hours Notes
If your data team holds office hours or intake sessions, capturing notes during the conversation is hard. You cannot make eye contact and type fluently at the same time. Dictating between asks, or right after a session ends, captures the context while it is still fresh and lets you stay present during the conversation.
What About SQL and Code?
Voice typing is not the right tool for writing SQL. The syntax is dense, the punctuation is everywhere, and naming a column with a dictated string is rarely faster than typing it. Keep your hands on the keyboard for the actual querying. The opportunity is in the writing that surrounds the query, not the query itself.
The exception is comments. Inline comments explaining why a CTE exists, why a join was structured a particular way, or what a window function is doing are perfect for dictation. They are prose, not code, and they are exactly the kind of thing analysts skip when they are typing because adding them feels like a tax.
Privacy Concerns for Analysts
Data analysts handle sensitive information. Customer names, revenue numbers, internal metrics, and unreleased product details all routinely show up in the writing they do. Choosing a dictation tool that respects privacy matters more for analysts than for almost any other role.
The concrete questions to ask of any tool: Does it record audio after the transcription is complete? Does it train on your voice or your text? Does it send any data to advertising partners? An analyst who dictates a stakeholder email containing customer revenue does not want that audio sitting in a vendor's training corpus.
Voice Keyboard Pro for Mac is built with this in mind. Audio is processed transiently, transcripts stay on your machine, and there is no training pipeline using your data. The hold-to-speak interaction means the microphone is only ever active while you are intentionally pressing a key, which removes the ambient-listening risk that always-on dictation tools introduce.
How to Get Started in One Afternoon
If you are a working analyst and you want to try this, here is a low-stakes way to start. Pick the most repetitive writing you do in a week. For most analysts, that is Slack replies explaining numbers. Install a dictation tool, set the hotkey somewhere comfortable, and use it for that one category of writing for a week. Do not try to convert your entire workflow at once. Just learn the muscle for one task, then expand from there.
By the end of the week, most analysts find that dictation has spread to documentation, ticket replies, and PR descriptions on its own. The speed advantage is too obvious to keep to one channel.
The best analysts are not the ones who write the most queries. They are the ones whose stakeholders trust them. Trust is built in writing, not in SQL, and writing is exactly where dictation gives an analyst the most leverage.