Building a Career in Data: What Gets You to the Next Level

Careers in data are unusual in that there is no obvious path through the profession. People arrive as analysts, engineers, developers, architects, or scientists, and a good number arrive from somewhere else in the business entirely. What they have in common is that the skills that get them started are not the skills that move them forward.

Coginiti CTO Matthew Mullins spoke with Aaron Wilkerson, Director of Data Strategy & Products at Carhartt, who has nineteen years in the field — seven as an individual contributor, twelve in leadership — about how that transition actually works. Wilkerson also organizes the Data in the D meetup, which puts him in regular contact with people trying to make the jump or get in at all.

An accidental start, then a deliberate one

Wilkerson's entry was unplanned. He graduated with an engineering degree, joined Accenture, and landed on a data team supporting a large BusinessObjects implementation at Dow Chemical. For three years he was the BusinessObjects person: stand up the environment, configure it, set up security. He did not know ETL or data warehousing.

He left consulting for a hospital, where a manager asked whether he wanted to learn this thing called ETL. He had not heard of it. The same manager later mentioned data warehousing; Wilkerson bought a couple of books.

Both participants noted what has happened to those titles since. Database developer, ETL developer, data modeler, data architect were distinct roles with distinct expectations. The industry flattened them into data engineer.

The deliberate part came later, and it started as frustration. There were strategic conversations happening that Wilkerson was not in. He would be pulled in when a report broke, thanked, and dismissed so the important discussion could continue. His conclusion was not that the system was unfair but that he had more to offer and needed to upskill to be credible in those rooms. No manager assigned that.

When technical skill stops being the differentiator

Wilkerson does not dismiss technical skill; he describes it as necessary but partial. Technical skill tells you how to do something. Delivering work that matters requires understanding the business well enough to build something people use.

His framing is blunt. You can be the most technically proficient engineer on the platform, and if you build things nobody uses because they are not relevant or nobody understands them, it falls apart quickly. He compares it to milk sitting in the refrigerator: things get made for someone to consume.

Mullins drew the parallel to software engineering, where junior through senior is largely a technical progression and the staff level is the first rung that requires influence across teams. Strong technical skills remain a prerequisite. They stop being sufficient.

Wilkerson added communication as the specific gate. As a leader, he needs to delegate stakeholder conversations, which means trusting that someone can hold one. An engineer who explains medallion architecture or context layers to a business stakeholder has produced a liability, because the leader now has to redo the conversation to find out what was actually decided. In promotion discussions, "can we put them in front of a stakeholder" is a real criterion, and it is where people get left out.

Management is a different job

Both were emphatic that the IC-to-manager move is a career change rather than an advancement, and that the industry communicates this badly.

Wilkerson's coaching method is to hand over a project he would otherwise run — schedule, team, stakeholder, milestones, updates — and then give feedback from both directions, including from the team. Did they like working with you? Did you micromanage them? He does not move people into management because they want it. He gives them a taste first, because he has watched people move into management and come straight back out.

The failure mode for new managers is retreating to what they know. Mullins described managers under pressure picking up the work themselves — taking the data architecture rather than leaving it to the engineer on the team. Wilkerson confirmed that this comes up in performance calibration, where the expectation is explicitly not hands-on-keyboard. The phrasing he returns to: what got you here will not get you to the next level, and what you excelled at before can become a detriment.

Mullins named a related anti-pattern on the management side. Organizations promote their strongest technical contributor into a lead role, which costs them that contribution and frequently produces an unhappy manager and an unhappy team, because deep technical skill and people leadership are different competencies.

Deciding whether you want it

Wilkerson observes that more people he talks to have no interest in people leadership, and the structural problem is that compensation has traditionally been tied to the management track. Not enough organizations have built a genuine parallel ladder where a principal or distinguished engineer earns what a director earns. His first suggestion is to find out whether your company has one.

The questions he suggests asking yourself are concrete. Do you want to lead people, hold a budget, run performance reviews, and take satisfaction from other people's success? Or do you want to be in the weeds, knowing the current technology and driving execution decisions? As a director, he says plainly, he is not in the weeds — he knows the names of things, not the depth of a given implementation. He knows business strategy and high-level data concepts.

If you do not know, try things before committing. He also flags the practical risk: once you move, your old role gets backfilled, and if your company has no path back you may have to leave to get it.

Learning the business

Both agreed that this is the hard part, and harder now than it used to be. Wilkerson calls it a full contact sport. Pre-remote, proximity did some of the work; you overheard things. Now it requires deliberately reaching out, asking direct questions, and building relationships with stakeholders — why does this matter to you, how would you use it, who else should we talk to.

The reassuring finding is that this almost always works. Wilkerson has never had someone refuse a request to explain their work. People are isolated enough now that genuine interest is welcome. Mullins added the framing caveat: the same question can land as curiosity or as a demand to justify a request, and only one of those gets answered generously.

There is also a structural advantage here that data people underuse. Most of an organization is siloed vertically — order management knows order management, procurement knows procurement. Someone in a centralized data function is one of very few people positioned to see across the whole business and understand how the pieces connect.

Advocating for yourself

Asked what people wrongly believe will impress managers, Wilkerson's answer was the assumption that your manager already knows what you did.

He does not, and he is honest about why: with many direct reports and a constant volume of information, he cannot keep track of everyone's accomplishments. The frustration that follows — they don't support me, they don't recognize me — usually has a simpler explanation.

His recommendation is to put it in writing and send it. Here is what I did this month, here is my role in it, here is why it mattered. Not bragging; supplying information that is otherwise unavailable. When he writes a performance review, he can pull twelve months of those updates and use them. When he argues for a promotion with his own leadership, that record is what he argues from.

He extends it into a habit: after finishing something or leaving a meeting, ask who else should know this. Mullins, who described himself as a fan of proactive communication, made the same point from the receiving end — information arriving before he has to ask for it is the thing that stands out.

Wilkerson also warned against the opposite failure, the person who generates ten ideas and completes none of them. Ideas get you nods. Taking one to completion, bringing a group along, and owning the outcome is the skill that is actually scarce. He applies the discipline to himself: he could list fifteen options, so he limits himself to the two he is prepared to own.

Prioritization, and what ICs cannot see

Every data team has more requests than capacity. Wilkerson's approach starts with published business strategy — if leadership has named five strategic priorities, work that does not connect to them goes to the bottom. Absent that, the fallback is impact on revenue, cost, or something else on the P&L. Either way, communicating the priority list broadly matters as much as setting it, so people can push back before the work is done rather than after.

On the gap between ICs and leadership, he was candid. There is information he has that ICs do not, some of it not writable down, some of it genuinely confidential. Leaders should cascade what they can and explain the reasoning behind decisions. But some of it comes down to trust.

Mullins offered the counterweight from his own first executive role, when his CTO told him he was about to see how the sausage gets made — and the discovery that sometimes you don't want to tell people what's in it. Wilkerson's version: people would be surprised how often a decision is not the product of analysis but of someone deciding to try something and see.

He also noted what he misses about being an IC — not carrying accountability home.

Breaking in

For anyone trying to enter data today, Wilkerson thinks the framing has changed. Twenty years ago data was not a career path and there were no data degrees. Now universities produce graduates with data degrees who compete against people with ten or fifteen years of industry experience, and they lose that comparison.

His advice is to stop competing on that axis. Get any job at the company you want to work for — service desk, analyst, anything — and make it a data job. Every role has data in it. On a service desk you can report ticket volumes and priority mixes, and in most organizations nobody is doing that. Then network internally and move laterally, which is dramatically easier than getting hired in from outside.

Both were emphatic about networking, and about the same failure in how people do it. Showing up once is not networking. Mullins tells students that a single meeting gives him nothing to refer them on; Wilkerson calls a one-time-meeting referral a terrible referral, and declines the LinkedIn requests that ask for one — he is not putting his reputation behind someone he does not know.

Both had the counter-example ready. Mullins, organizing a meetup, was able to point a hiring manager at two data scientists he had watched attend for months. Wilkerson connected a regular attendee at Data in the D with a data leader role in January; the connection existed only because the person kept showing up.

On credentials, Wilkerson weights experience over certificates, which are easy to accumulate from YouTube. He wants evidence of a project: have you built the pipeline, implemented the platform, shipped something. Portfolios help, with a condition — real data, not Titanic or Iris. And at Carhartt he hires for breadth rather than deep specialization, because the team works across supply chain, sales, direct-to-consumer, and marketing on thin staffing, so picking up new concepts quickly matters more than knowing one source system exhaustively.

What AI changes

Asked which parts of analytics and data engineering AI makes less valuable, Wilkerson pointed first at presentation skills, which he includes himself in — building decks used to be a differentiator and now is not. Then the technical moat more broadly: knowing a BI tool deeply, writing the SQL, the accumulated technical know-how.

What remains is business understanding. The model is not in the meetings and does not know what your organization means by its terms. Wilkerson's expectation is that data professionals will increasingly build semantic layers and curated datasets for agents to consume — which makes the question of what to build, and on what understanding, the part worth specializing in.

On career advice he thinks is wrong: follow your passion. His version is to follow what you are good at and can be paid for, and let the passion be a hobby. He is also skeptical of work-life balance as advice for the earliest career stage, arguing that establishing yourself involves an imbalance — the hours, the meetups, the side projects. He is more balanced now. He does not think he could have started that way.

Watch the full conversation

The recording runs above. Wilkerson closed with what he is reading: Influence, on persuasion — his own effort to rewire an electrical engineering background toward the communication and selling that leadership actually requires.