A spectator sports company in the EU is hiring a remote Director of Software Engineering to own high-volume, near real-time status systems. The posting asks for strategy, architecture, team leadership, Continuous Delivery, embedded AI, and developed engineering managers. It's a beautifully detailed description for a role that is half-automatable today and three-quarters automatable by the time the successful candidate finishes onboarding.
The actual cognitive labor — deciding architecture, unblocking teams, reviewing plans, aligning engineering to business priorities — is exactly the kind of systems-thinking current AI handles enough to shrink the role, and next-generation tooling handles enough to eliminate it.
What the role actually does
Strip away the leadership language and a Director of Software Engineering at a data company does five things:
- Architecture decisions for high-throughput, low-latency data pipelines. Which message broker, which storage layer, how to partition, how to handle late-arriving events, how to reconcile conflicting data sources.
- Delivery orchestration — making sure teams ship reliably, that CI/CD pipelines are healthy, that observability is in place, that incidents get resolved.
- People management — hiring, growing engineering managers, resolving interpersonal friction, performance reviews.
- Cross-functional alignment — translating product and commercial priorities into engineering roadmaps, and translating engineering constraints back into language executives understand.
- Technical judgment calls — the "should we rewrite this or patch it" decisions, the "is this SLA realistic" calls, the "which trade-off do we accept" verdicts.
Three of those five are automatable now. One is automatable with effort. One survives — for now.
What automates first: architecture and technical judgment
High-volume ingestion of structured events, enrichment against reference data, and distribution to downstream consumers via APIs is a well-understood problem domain. The architecture patterns are textbook: Kafka or equivalent for ingestion, a stream processor for enrichment, a low-latency read store for queries, and a caching layer for hot paths.
An AI system doesn't need to invent this architecture. It needs to select and adapt it. Feed a well-prompted model the constraints — event volume, latency targets, consistency requirements, existing infrastructure — and it produces a credible architecture document with trade-offs enumerated. It won't be perfect. It will be better than the median human director's first draft, and it will arrive in minutes instead of weeks.
The harder part — the judgment calls about when to accept technical debt, when to rewrite, when to patch — is where experienced engineers earn their salary. But most of those calls follow patterns. "Should we rewrite the legacy enrichment service?" Almost always: no, not yet, not unless the maintenance cost has crossed a threshold visible in your incident data. "Is this SLA realistic?" Check the p99 latency distribution against the proposed commitment. "Which trade-off do we accept?" Model the cost of each option against revenue impact.
An AI system with access to your observability data, your incident history, your codebase, and your business metrics can make these calls with a defensible paper trail. It won't be right every time. Neither is the human director. The difference is the AI system reviews every decision against all available data; the human reviews against what they remember and what their two favorite engineers told them in the last standup.
What automates next: delivery and cross-functional alignment
This is the part that feels most human — the "soft" work of herding engineers and translating between engineering and business. It's also the part that's most ritual.
Delivery orchestration is already heavily automated. CI/CD pipelines run tests, deploy code, and roll back on failure. Observability platforms detect anomalies and page humans. What the human director adds is prioritization: which incident matters most, which technical debt item to schedule next, which team needs help. That's a ranking problem with inputs from your issue tracker, your monitoring stack, and your roadmap. An AI system that reads all three and produces a weekly priority list with reasoning is a pipeline you could build today with an LLM, access to Jira, access to Datadog, and a prompt that says "rank these by business impact and engineering effort."
Cross-functional alignment is the translation layer. Product wants feature X. Engineering says it takes six weeks. Product asks why. The director explains: the schema change requires a migration, the migration requires a dual-write period, the dual-write requires coordination with three downstream consumers. That explanation is a function of the codebase, the architecture, and the dependency graph. An AI system with codebase access can generate it. The negotiation — "can we do it in four weeks if we cut scope?" — is a constrained optimization problem. The AI proposes the cut scope. The human product manager says yes or no.
What about developing engineering managers? Coaching humans, reading their emotional state, knowing when someone is burning out? That's the part that doesn't automate. Not because it's complex — emotional intelligence isn't computationally harder than architecture — but because it requires trust, and trust requires a human on the other end. An AI can tell you that an engineer's commit frequency dropped 40% and their PR comments became terse. It can flag burnout risk. It cannot have the conversation that follows.
The pipeline that replaces this role
The system:
Architecture layer. A reasoning model with access to the existing codebase, infrastructure-as-code templates, and a library of reference architectures for real-time data systems. Input: business requirements and constraints. Output: architecture proposals with trade-off analysis, cost estimates, and migration plans. A human reviews — for now.
Delivery layer. An orchestration agent that reads from the issue tracker, the CI/CD system, and the observability platform. It produces sprint plans, flags blocked work, identifies flaky tests, and generates weekly status reports. Engineering managers review and adjust — for now.
Decision layer. An analysis agent that queries incident history, latency distributions, and business metrics to answer questions like "should we migrate the enrichment service?" or "is our p99 latency acceptable for this customer?" It produces decision memos with recommendations and confidence intervals. A human director signs off — for now.
Translation layer. A model that converts engineering constraints into business language and vice versa. Input: "we need a dual-write period for the schema migration." Output: "we can ship the new field in two weeks, but it'll take six weeks before we can deprecate the old one, and during that window we're paying double storage costs." Product managers read these and make trade-off calls.
People layer. This is where the human survives. One person — maybe called a director, maybe called something else — reads the burnout flags, has the conversations, makes the hiring decisions, and handles the interpersonal dynamics that no model can reach. But this person manages people. The systems run themselves.
Where it breaks
Status data is messy. Sources report delays inconsistently. Changes propagate through different systems at different times. Timezone handling for international events is a horror show. A model can architect the pipeline, but the edge cases — the weird data quality issues that require deep domain knowledge — need someone who has seen the patterns over years. An AI can learn those patterns from historical data, but only if that data has been labeled and structured, and most of it hasn't. The first year of this AI system's life will be spent building the training data that makes it competent. A human director with a decade of experience will outperform it on edge cases until that data exists.
And there's the trust problem. Customers buy this data for decisions that cost millions. When the system gets it wrong — and it will, because the data is inherently probabilistic — someone has to explain the failure to the customer. That someone needs credibility, a face, and the ability to say "we're fixing it" in a tone that reassures. An AI can generate the post-mortem. It cannot deliver it to an angry executive over a video call and make it land.
The verdict
The company is hiring a director to lead teams that build a real-time data pipeline. The pipeline is automatable. The team structure is automatable. The architecture decisions are automatable. The cross-functional translation is automatable. What's left is people management and domain expertise — two things that could be a single person, not a director with multiple teams.
But the job posting asks for someone to "develop engineering managers" and "build high-performing teams." That's the tell. They're not hiring someone to automate the work. They're hiring someone to manage the humans who do the work that could be automated. That's not a strategy — it's a holding pattern.
The AI system that replaces this role won't be called a Director of Software Engineering. It'll be called a pipeline. And the one human left will be called whatever the company names the person who talks to the angry executive.
