From Requirements Writer to Process Automation Driver

A few months ago I was helping someone prepare for a Senior Business Analyst interview. We went through the job description together. The standard sections were all there — stakeholder management, requirements elicitation, Agile experience. But tucked between them were things that didn’t exist in similar postings eight years ago: “design and optimize business processes end-to-end,” “identify automation opportunities,” “work closely with system architects on integration decisions.”

My candidate looked at those lines and said, essentially, that wasn’t what she was hired to do in her current role. She was right. And that gap — between what companies now expect from Senior BAs and what many analysts actually do day-to-day — is the thing I want to talk about here.

What changed between 2018 and 2026

I remember looking at BA job postings in 2018 when I was building out an analysis team. The requirements were essentially variations on the same list: write clear requirements, facilitate workshops, manage stakeholders, understand Agile. If you could produce a solid BRD and work well with developers, you were a Senior BA.

That baseline still matters. But it’s no longer sufficient.

The companies hiring today — at least the ones worth working for — have already digitized the obvious things. Their core processes exist in some form in some system. The question they’re wrestling with now is different: how do we make these systems work together, and where are humans still doing what a machine could do?

This is a fundamentally different problem than “document the requirements.” And it requires a fundamentally different kind of analyst.

The shift from documentation owner to automation driver

I’ll be honest about something: for a long time, the value a BA delivered was primarily in translation. You took what business stakeholders wanted, made it legible to developers, and prevented misunderstandings. That translation function remains important. But it’s become table stakes, not differentiation.

What companies increasingly need is someone who doesn’t just translate existing intent — but who can look at a process and see where it’s broken, where automation is possible, and how to get from here to there.

I think of this as the difference between a requirements writer and a process architect. The requirements writer documents what is asked for. The process architect asks whether what’s being asked for is actually the right solution — and whether there’s a more efficient path to the underlying goal.

The problem is that most BA training, and most BA culture in mid-sized companies, still optimizes for the first thing. It produces analysts who are very good at capturing requirements and not particularly equipped to redesign processes or understand the technical landscape they’re working within.

The three skills that actually matter now

In my experience, the analysts who make this transition successfully tend to build capability in three areas. Not necessarily deep technical expertise — but genuine working knowledge.

Decomposition. Not in the user story sense, but in the systems sense. The ability to look at a business process and understand how it maps to technical components: what data moves where, what triggers what, where the boundaries between systems actually are. This is different from writing acceptance criteria. It requires understanding the architecture at least enough to ask the right questions.

Integration awareness. Most enterprise systems today don’t live in isolation. They connect to other systems via APIs, webhooks, data pipelines. An analyst who has never read an API specification — even at a high level — is working with a significant blind spot. You don’t need to write code. But you need to understand what a system can expose, what another system can consume, and where the technical constraints actually lie. This changes what you put in your requirements.

Knowledge management. This one is underrated. Most organizations have enormous amounts of institutional knowledge trapped in the wrong places — in people’s heads, in old Confluence pages nobody updates, in email chains nobody can find. The analyst who knows how to build structures that make knowledge findable and durable is doing something more valuable than documentation. They’re building organizational infrastructure. I’ve seen this make a measurable difference in how fast new team members become productive and how consistently decisions get made.

What to actually do — five concrete things

I’m generally skeptical of “here are the five things that will change your career” articles. But I do think there are specific, actionable steps that push analysts toward this new operating model, and I’ll try to be concrete rather than vague.

Learn to read API documentation. Pick any public API — something your current product integrates with, or something well-documented like Stripe or Twilio — and spend two hours reading their docs. Not to code anything. Just to understand what it exposes, what the data model looks like, what the limitations are. This builds the mental model that lets you have real conversations with developers about integration constraints.
Shadow a developer for a day. Ask to sit in on a sprint where integration work is happening. Watch what questions come up. Notice where the requirements you or your colleagues wrote turned out to be underspecified or ambiguous. This is uncomfortable, but it closes the gap between what analysts think they’re communicating and what developers actually receive.
Map one process end-to-end with automation in mind. Take a process you know well. Map every step. Then mark every step where a human is doing something a system could theoretically do. Don’t worry about whether automation is currently planned — just identify the potential. This exercise changes how you look at future processes.
Build your own knowledge system before you try to build one for anyone else. Start using something like Obsidian, Notion, or even well-structured markdown files to capture what you know about your domain: key integrations, data definitions, process quirks, decisions and their rationale. If you can’t build a navigable knowledge system for yourself, you can’t build one for a team.
Ask “what could be automated here?” in every project kickoff. Not as the primary question, but as a standing item. It changes the conversation. It positions you as someone thinking about efficiency, not just documentation. And occasionally, it surfaces something important that nobody else was looking at.

Where this leaves you

The market is already ahead of a lot of practitioners. The job descriptions I see for Senior BA roles in 2026 reflect where companies need analysts to operate — even if the mentoring infrastructure and training programs haven’t caught up to that expectation yet.

The analysts who recognize this gap and deliberately work toward closing it will find themselves increasingly in demand. The ones who don’t will keep doing solid work, but will find themselves plateauing at mid-level in organizations that are looking for something different.

I don’t think this transition is technically difficult. I think it requires intellectual curiosity about adjacent domains — system architecture, automation, knowledge design — and a willingness to go beyond the traditional BA operating model.