Job Titles Flatten Careers
Job titles flatten careers. They collapse years of context into a single label and reduce the richness of lived work into keywords. Those keywords absolutely matter—we should bold them on our résumés so the skills are evident and not overlooked.
But that flattening is a real problem for job seekers. Both AI tools and human screeners scan résumés for keywords that hold some truth, yet they often miss the real story.
A résumé is a list. A career is a professional life—upwards of 2,000 hours every year—not including the time invested in keeping up with technology and industry trends. A meaningful career timeline shows not just what we know, but how we apply it to create solutions, solve business problems, and provide the technological foundation that enables companies to grow and thrive.
Dark Matter
The invisible hours are never captured on a résumé. Technology professionals spend enormous time keeping up with trends, releases, and shifting platforms. Reading 1,000-page certification guides, studying execution plans after hours, building lab environments, replaying migrations, or testing new features—these are all investments outside the 40-hour work week.
Over the course of a career, this “dark matter” adds up to thousands of hours of learning. It’s the unseen gravity that shapes expertise, ensuring we’re not just repeating yesterday’s patterns but preparing solutions for tomorrow’s problems.
Time and Focus Tell the Truth
Careers don’t happen in neat, non-overlapping boxes. Roles rise and fall in intensity. Some stay constant in the background, others spike with incidents, migrations, or projects.
This is also why keyword scanning—whether by AI or human—is so incomplete. It forces us to bold every noun that’s ever crossed our keyboard, as if each one deserves equal weight. Should I boldface PuTTY on my résumé just because I used it to execute SFTP? Of course not. I’m not fluent in it; I simply needed a tool to solve a problem.
The same was true when I needed a powerful way to parse very large data files that had been processed in the wrong place, creating massive delays and unaudited points of failure. I turned to Python, which reduced preprocessing time from days to hours. But did that suddenly make me “proficient in Python”? Not really. At the time, I didn’t think it belonged on my résumé. Over the years I’ve become more capable with it, but like many tools and languages, my strength lies in figuring things out and applying them where they deliver business value.
The same principle applies to programming languages. Many of us in data and application roles aren’t “C# developers” or “Python developers” by title—we’re problem solvers who understand how languages work and apply them pragmatically. Sometimes that means building a pipeline, automating a process, or integrating systems. Each language is a tool in service of the larger solution, not a headline that defines an entire career.
And then there are the job descriptions themselves. Too often they read like a buffet of buzzwords and unrealistic expectations: dozens of tools, frameworks, and platforms crammed into a single role, as if one person is supposed to embody an entire IT department. We may touch each of those areas at different times in a career, but rarely in the same role, and never with equal intensity. These inflated lists flatten careers just as much as job titles do—they obscure the real value of depth, judgment, and the ability to solve problems under pressure.
The reality is that no serious DBA spends their day configuring routers, writing React apps, and tuning queries all at once. Yet many job descriptions are written as if one person should. They read like three or four jobs compressed into a single listing.
Take a real example: a “MS Full Stack Technical Lead” posting I recently came across. The role expects deep SQL Server and SSIS development for ETL pipelines, and advanced C#/.NET backend development, and modern front-end frameworks like Angular and React, and even operational work like supporting web servers during OS upgrades. That’s not one role—that’s at least three specialized disciplines.
Hardcore C# developers are rarely SSIS developers. Front-end engineers who live in React don’t usually spend their nights debugging execution plans. And DBAs who know how to build enterprise ETL pipelines don’t necessarily want to spend their day writing JavaScript. These are valuable skills, but they don’t overlap at the depth implied.
When companies write descriptions like this, they don’t just overwhelm candidates—they flatten careers. They make it look as if serious professionals should be masters of every layer of the stack, when in reality the best results come from teams where each person brings depth in their own lane, and overlaps enough to collaborate effectively.
A timeline solves this problem. It shows where the real intensity lived. Dev is my through-line—always present. DBA work spikes during incidents and migrations. ETL comes in waves. Analysis runs in the background. Time and focus together tell the truth.
Titles Overlap — Reality Is Messier
Honestly, having held the title Senior DBA, I can tell you: unless you’re in a very large enterprise (Choice Hotels comes to mind), it’s not really a full-time job once the environment is stable. When you’ve automated the vast majority of administrative duties, the work changes character. At Choice, for example, our database team of seven had a nightly rotation. Byron and I ended that rotation by building out a project that stored every step of the process in code, with documentation, well-written T-SQL, and execution plan analysis to keep it performant. We didn’t just automate the process—we also added a presentation layer that made performance and outcomes visible at a glance.
At that point, the work became almost effortless: operate the app, monitor, and respond. And that app? It was “appsolutely” complete—no bugs, because we wrote and tested it end to end. Applications without bugs are possible when you approach them with rigor and automation from the start. Yet none of this shows up in a résumé keyword search—except, maybe, for the single word automation.
Automation is always my mindset. As both a DBA and a developer, I don’t trust manual routines to catch every issue—automation doesn’t miss a fragmented index or overlook a recurring error pattern. At Mellon Financial, I modeled tenants’ financial data profiles in DTS for re-use, and suddenly what looked like endless work became simple. At Choice, we built AIMS with thresholds, notifications, and reporting. We even added DefCon levels to make it fun. Observability came through SSRS at the time, and today we’d push it further into Power BI.
The truth is, DBAs must also be developers. We don’t just maintain servers—we write code, enforce standards, and step into the application layer when needed. At Choice, I wrote a standards document that required AppDevs to structure SPs and UDFs in a way that we, as DBAs, could tune effectively. That wasn’t busywork; it was a safeguard for the business, ensuring we could step in quickly when performance issues arose. Query tuning isn’t optional—you look at every execution plan, verify that indexes are in place, correct, non-overlapping, and include the right columns where needed, then make adjustments.
The point: titles overlap. DBA work includes development. Developer work includes database design. Director-level work at OnePoint Patient Care included hands-on coding—beginning with the CREATE DATABASE statement—along with infrastructure decisions and leading a top-performing development team.
The best results happen when those walls blur.
And yes, Director has always sounded like a cool title. But in reality, it often functions more as a tier in the salary ladder than a clear description of the work. I once “stepped down” from Director to Data Architect when the opportunity was right—because Data Architect encompassed what I believe it should, and it paid better elsewhere. Titles are sometimes just shiny names. The inconsistency itself proves the point: job titles flatten. What matters is not the label but the lived work—designing, building, automating, and sustaining solutions end to end. And end-to-end doesn’t mean one person is simultaneously the ETL developer, C# .NET back-end developer, database developer, and front-end Angular/React developer.
Tim Rankel and I could be all of those job titles wrapped into two people—but that’s risky for any business. We worked together at OnePoint Patient Care and later at MeMD, and I’ve always admired his depth and judgment. He’s a long-term friend, now leading Enterprise and Solutions Architecture – Software Engineering – DevOps at Grand Canyon University. They’re in good hands.
The Graphic Is the Story, Not the Titles
This chart isn’t about decoration—it’s the true shape of the story and a way to reclaim narrative. Résumés compress, job titles distort, but time and focus reveal the truth. Visualizing my own career made something clear: the shape of the work matters more than the label attached to it.
The point of this chart isn’t precision, it’s transparency. It draws on signals—incidents, migrations, projects, artifacts, on-call rotations—to show where intensity lived. It’s a framework anyone could apply to their own career. If you’ve ever felt flattened by titles, I’d encourage you to map your own time and focus.
In the end, it isn’t the title on the business card that defines us—it’s the time, focus, and outcomes that shape our careers. Scannable résumés are insufficient in my opinion. The next step is finding better ways to represent the richness of lived work—through timelines, artifacts, and stories that show not just what we did, but how and why it mattered.
Takeaway
Résumés and job titles flatten. Keywords mislead. The truth lives in time, focus, and outcomes.
I built a chart to visualize this journey—Dev continuous, DBA spiking, ETL intermittent, analysis always present. The picture tells the story better than any list.
The Chart & Rules
Heights show independent role intensity per year; overlaps are expected and totals aren’t forced to 100%. A stacked-percentage view would imply trade-offs that don’t reflect this work. Dev continuous; DBA ends 2021 (drops to zero 2014–2015 at Schwab, all Dev); ETL intermittent; analysis thin band; dashed Dev 2021–2025. Dev continuous; DBA ends 2021 (drops to zero 2014–2015 at Schwab, all Dev); ETL intermittent; analysis thin band; dashed Dev 2021–2025.
📊 Clarity note: The chart uses independent intensity bands—each role’s height is its own “how much focus” scale. Bands can overlap and don’t need to add to 1.0. Forcing them to stack to 100% would imply trade-offs that don’t exist (Dev can stay high while DBA spikes).
Signals and Evidence
What makes this kind of representation honest (and auditable)?
- 📅 Dates & titles (normalized)
- 🛠️ Artifacts: code repos, SSIS projects, scripts, runbooks, dashboards, tickets
- 🚨 Signals of intensity: on-call weeks, incidents, migrations, releases
- 🔑 Tech nouns & verbs that leave evidence (“index tuning,” “AlwaysOn,” “SSIS error handling”)
Why This Matters for Hiring
Whether scanned by AI or skimmed by a human, résumés too often flatten into keyword bingo. But the real signal comes from time, focus, and outcomes.
For recruiters and hiring managers: ask candidates for evidence per year (artifacts, outcomes, migrations). For developers and DBAs: keep your evidence—repos, scripts, reports—so you can show intensity, not just titles. That’s how you see the true arc of a career.
Closing Thoughts
Careers are not flat lists. They are lived timelines of focus, intensity, and problem-solving. Job titles flatten, but time and focus tells truth.
How about you?
- For DBAs and developers: how does your intensity shift over time?
- For recruiters and managers: what would you want to see beyond keywords?
⬆ Back to Top #SQLServer #DBA #DataEngineering #ETL #SSIS #CareerTrajectory #DataOps #AI #Hiring #TimeTellsTruth