This is a translation (yes, with an LLM's help) of a series of essays I wrote in Russian in 2023. Things have changed since then, but I guess there's still some truth in these stories.

Who are you, and why should I listen to you?

I'm a data analyst. I have been working in this profession since 2015, in various roles (from an individual contributor to a manager), domains (from digital products to urban planning) and company sizes (from small teams to big tech). Although my perspective is shaped primarily by CIS countries' work culture, I believe the IT industry is inherently international, so the differences should be minor.

Those notes grew from my mentoring experience. I have consulted more than 50 people over the last few years, and the same questions tend to come up. Below are answers to the most common ones.

How to choose between data analytics and data science? What's the difference?

Imagine two problems.

In the first one, it's clear what needs to be done, and the problem is stated precisely. Say, the website has a recommendation system, and you need to lift the conversion from site visit to purchase. Or you need to spot customers who are about to churn. Or teach a support bot to answer the people writing to it. There are success metrics: the accuracy of churn prediction, or the share of people who were satisfied with the bot's answer and didn't escalate to a live operator.

It's roughly clear how to solve such a problem — but it's hard. There are different approaches suited to different problems, and you need to know your way around them. You have to sit down, study the approaches, get familiar with the data, experiment, pick the best fit out of a dozen paths. Then squeeze the maximum benefit out of it. Write code, read textbooks and papers, learn, try things. Then show it to the client, implement it, ship it to production.

In the second problem, it's unclear what to do — or even where to start. A manager comes to you and says: I want to reward our loyal customers, give them a discount or something. Wait — why reward them? Which customers count as loyal? What good will it do, how do we measure that, with which metrics? How do we compute those metrics, and where do we get the data? How do we actually hand out the discount — which lists get uploaded where in the product? So many questions.

Or this: there's a big, murky part of the business or product. Say, user acquisition and retention. It's never been measured; how much we spend on it — nobody knows (yes, that happens even in big companies!). Someone has to go and figure it out. Talk to the managers who own it. To the engineers who wrote those parts of the product. Understand how it all works. And once you understand — invent how to digitize these processes. Which indicators are key, how do they depend on one another? How does it all affect the business as a whole, and is the game worth the candle? Which metrics are sagging the most, or promise the juiciest fruit? Explain it to the client and come up with a plan of action together. Compute the plan's effect on the data and check whether it's really that good. And be around when the plan goes into motion.

Which one is closer to your heart?

A data analyst makes the unclear clear. They work in chaos and put it in order. A strong analyst finds worthwhile problems themself, can tell a worthwhile one from a dud. They can translate a problem from the fuzzy language of business into the precise language of math and statistics — and, having solved it, translate the solution back into the language of business. Their models are simple and interpretable (in Einstein's words, "as simple as possible, but no simpler"). They may contain heavy math or none at all — the problem dictates that. A data analyst talks to people a lot: they have to get their findings and vision across to those who make decisions.

A data scientist makes the impossible possible. When the client says, "If only I could wave a magic wand and such-and-such would happen," the data scientists step in. Like developers, they build systems — but there's "magic" inside those systems. Look at ChatGPT or Midjourney — isn't it magic? A data scientist understands how that magic works. What it's for and how it will be used — a good DS will find that out too, but strictly speaking it's not quite his job. And it's certainly not his job to discover the need for the system or figure out how to sell it.

A data scientist is an engineer; a data analyst is a scientist (yes, the names are confusing like that). A data scientist is closer to answers; a data analyst — to questions.

I got rejected at three places — am I done for?

I have a friend who turns every job change into a research project: he goes through several dozen employers and interviews before choosing anything. There's a lot to learn from him.

If time allows, run your own study. Tell yourself that landing a job is not your obligatory task. Go to interviews with the mindset: "I'm not desperate; I'm researching the market." Nothing will tell you better than the market which skills you need to brush up on. And companies will assess you for free. At Avito, for instance, candidates go through 2–3 interviews with practicing analysts of mid level and above.

You will get rejections — that's normal; that's what you set this whole thing up for.

After a rejection, always ask them to tell you what you fell short of for an offer. Not all employers bother to volunteer this, but at most companies interviewers write up reviews of candidates for internal use, so if you ask, they'll share it with you. If you don't get that feedback, consider the interview wasted — you learned nothing from it.

After a dozen interviews you'll already have a rough idea of what's expected of you and where you're out of your depth.

Here I should warn you about a thing called the ban. The thinking goes: if you didn't pass today, your level is unlikely to change in less than six months to a year. So many large companies don't let you interview with them too often. Fail, and you may not be allowed another attempt for a while. The rule isn't always enforced too rigidly: if a company badly needs specialists, you can count on some flexibility.

If you've strategically set your sights on changing professions or moving to another company, this ban is nothing scary. Right now you're researching the market and your skills; in six months or a year you'll interview for real. After your research you'll need time to patch the weak spots. Six months fly by. Besides, there are lots of companies. Banned at one — try the others.

One last story. I had an analyst colleague; I'd seen him work and knew him as a strong researcher. He was also writing a math textbook. Later I left for another company, started interviewing people, and happened to see that our folks had talked to him too. I was stunned to learn the guy had failed the math section — his answers just weren't crisp enough. A couple of months later I ran into him, and it turned out he'd safely landed a data analyst job at Google.

Don't take rejections too seriously. Hiring decisions are subjective even at big companies that have spent years earnestly polishing their processes and evaluation criteria. And a rejection at a small company may simply mean the "chemistry" with the team lead didn't happen.

I finished courses at Yandex Practicum, Skillbox and the like, but can't find a job. What should I do?

Imagine you're the head of a team of analysts.

You supervise two or three streams with several projects in each, and you're personally on the hook for the quality of analytics in all of them. Your calendar is 50–80% meetings. You have a team: someone's burning out, someone's not coping, someone's doing great and you need to prepare their promotion. Someone has a difficult relationship with clients — you help them build the communication. Someone's stuck on a hard problem — together you look for the key to it.

On you are the team routines: scrum, the task tracker, dailies, retros. Plus planning, weekly and quarterly. Maybe the strategy of your area, maybe the team's compliance with corporate standards and requirements. On you is fighting for resources, justifying headcount. On you is spotting the team's weak points and growth areas, launching projects to fix them. On you is talking to neighboring teams — data engineers, say, or developers — so they build the things you need. You don't have enough hands for the current work, and there are still so many ideas.

And now you decide to hire a junior. What does that mean for you? For the next three to six months (let's be realistic), it will pull three to five hours a week out of your already packed calendar. What will you think about first?

You'll think about whether the investment will pay off. You'll worry a lot about whether your new analyst will grow from a junior who needs supervision into an independent mid who owns whole areas and takes responsibility — and how fast that will happen. Of course you'll never have guarantees (even hiring a senior with references, you can't know 100% it'll work out), but you want to place the best bet possible. What will you base it on?

Nothing helps like an actually solved problem. That's why I'm a big fan of take-home assignments you have to wrestle with for several days — with production data and a problem adapted from real practice. But this method isn't proof against "a friend's help," and on top of that, such assignments are expensive to create and to grade.

(A lighter version of the same check: give the candidate an analytical case right there in the interview.)

Second, experience. If a candidate is moving into analytics from another profession, they may have already distinguished themselves somewhere. Maybe there's even a pet project on their GitHub. You can talk about that, dig into details, ask specific questions. Or collect references — though that's rare for junior positions.

And third, education. Education is a good predictor of the ability (and the inclination) to dig into hard things and get to the bottom of them. To check it, you won't look at which university the person graduated from — you'll just ask something basic at the interview from calculus, probability, statistics. Say a candidate briskly explains how to apply Student's t-test but can't explain what a probability distribution is — you'll conclude the person settled for the recipe but never reached the essence, and maybe doesn't even see their blind spots. Since the lion's share of an analyst's job is precisely getting to the essence, you'll figure that at work they'll miss blind spots too. Which means their understanding will be full of holes: lean on it and you fall through — and you'll be the one answering for those falls. You'll have to keep double-checking them forever.

You're an experienced analyst yourself and you think in probabilities, so you know any one of these criteria can fail you. So you'll check all three (and more, actually: soft skills, culture, etc.). If even one criterion seriously spooks you, you'll most likely say no. Competition for junior openings is fierce, you have plenty to choose from, and hiring mistakes are very expensive.

Now let's climb out of the team lead's skin and see what all this means for the candidate.

Data analysts face pretty high demands right out of the gate when it comes to fundamentals: math, statistics, logic, scientific models of thinking. This is expected of juniors already. The bar for technical skills — Python, BI, the specific work software — is, on the contrary, forgiving.

Courses — judging by what people who took them tell me — teach practical skills but don't lay an educational foundation; there's just not enough time for that there. Graduates wield current tools but poorly understand what to apply them to, and just as poorly understand what's under the tools' hoods and why they are the way they are. So by the education criterion, by the experience criterion, and by the solved-problems criterion, course graduates are in a rather weak position. Exceptions happen, but I've seen few.

So if you have experience from your previous profession — show it at interviews. If you have a serious degree in an adjacent field, an academic title, papers — blow the dust off them and show them. If you opened an online store, set up a production line, launched a casual game in the app stores — and in general, if you've ever deeply figured out something complex from scratch — show it.

Convince the team lead that you will help them.

And if you don't have any of that and you've only just finished the courses — arm yourself with patience and keep trying to solve problems. And keep learning. Including after you get hired.

I already work as an analyst, I've mastered the basics, I seem to be managing. How do I grow into a senior?

This answer turned out long, so I've split it into parts.

I'm deliberately sharpening things to make the ideas stand out in relief. Reality is both better and worse than what I describe.

You're paid for meeting expectations, and promoted for exceeding them.

For your manager to promote you, you need to do something useful for them. Solve a problem of the product, the business, the company, the department. Most likely you'll have to find that problem first.

You'll tell me: everyone does something useful. Programmers program, admins admin, designers draw, managers manage. They get a salary for that.

True. If you're an analyst, you get a salary too. When you were hired, your employer had expectations — that's what they pay you for. As long as you merely meet the expectations, you're cruising along at your level; there's no reason to promote or demote you. To start a conversation about promotion, you have to exceed those original expectations.

Sometimes you first have to find out what the expectations even are.

Sure, your employment contract includes a job description, but it rarely says anything useful. The actual role can diverge wildly from the formal requirements: at state companies my title was "leading specialist" or "engineer," though I worked there as an analyst. And it's downright unheard of for a standard contract to spell out promotion conditions. In my experience, promotion has always been a matter of what you agree on with your boss.

I've never once seen anyone at a decent company grow past mid-level by doing only what they're told or what's expected of them. Time served doesn't count.

People expect who-knows-what from an analyst.

What does your employer expect from a data analyst? The only reliable way to find out is to ask. Because it varies enormously.

Companies with mature analytics have guides and requirements. Here's a current example from Avito, here's one from Yandex.Taxi from Zhenya Kozlov's time in charge. At less advanced places they expect some of this: answer managers' questions about the numbers, fetch the data from somewhere and stash it somewhere, compute things over it, build charts and tables, run A/B tests, develop models.

But you might also be required to:

• log events in the product and generally own the data infrastructure; maybe build data marts from "your" data for other analysts; maybe even manage the local analytical database;
• make pretty slide decks for top managers; maybe present to them regularly;
• do "open-source intelligence" (OSINT): collect open data from the web on request, write analytical briefs;
• build ML models — for a trial or straight for production;
• write code for the science-heavy part of the product (algorithms, models) and then maintain it in production;
• hand tasks to developers: you and the manager came up with a feature — off you go to the dev team lead to negotiate getting it into the backlog;
• build operational dashboards in a BI system for managers to use daily — and maybe administer that BI system;
• describe internal processes, draw diagrams for them;
• identify and map out customer journeys (CJMs);
• talk a lot with stakeholders, find out what hurts, collect a backlog of tasks, set priorities;
• babysit a product launch and jury-rig fixes wherever needed — because the launch is tomorrow and the programmers' queue takes three sprints;
• and so on, and so on.

Such variety creates at least two problems.

First, competencies sprawl. Neighboring professions have clear landmarks. Go ahead and ask a programmer to run a customer interview, design a screen, or shape the product vision. Or a product manager — to write code and ship it to prod.

It's harder to draw boundaries for an analyst because they sit on several chairs at once. They're close to the business, talk and negotiate a lot — but they're also close to the tech: can write code, know algorithms and math, can speak with engineers in one language. The only thing an analyst doesn't do is make the final product decisions.

Because of this, many analysts worry that experience at one company transfers poorly to others. A classic: "I sit in Excel all day; I'm not a real analyst — real ones write Python." Or: at Yandex everything is homegrown and custom-built, while everywhere else it's Hadoop/PySpark/PowerBI/whatever — or also custom-built, but different. Or the domains differ: in one place you need to know marketing, in another — transport, in a third — DevOps.

This worry comes from the idea that you can describe an analyst's job through what they do. Sit next to them for a day and diligently record which software they open, where they click, what they say in meetings — and you'll get a portrait. But it won't work, because an analyst's main work happens inside his head.

For the same reason it's hard to write competency maps. You can't just take Avito's or Yandex's grade grid and stretch it over your company. There are too many vague phrases in it, like "open-endedness of the problem" and "analytical product" (even inside Avito they haven't fully agreed on what those mean). To interpret them correctly you need experience solving those very problems and shipping those products — and that won't fit into a table. You need to fill the grid with concrete meaning that resonates with your managers' experience, top management included. And it will resonate if you state it in the language of achievements, of results.

Which brings us to the second problem.

An analyst produces knowledge, but nobody tasks him with it.

The second problem with expectations runs deeper.

If you look at a data analyst through the eyes of a "doer" (a developer, a designer, a manager — in general, someone whose work changes the world somehow), the analyst will look like a jack of all trades who gets shoved into the holes in the company's org chart.

No data engineers? Let the analyst build the warehouses. No ML people? The analyst will make the model. A manager didn't budget slack time for launch surprises? The analysts will pitch in — tack on an API parser here, dump a CSV of users there. Once I even saw engineers come to expect an analyst to understand production systems at an engineering level, write multithreaded Go code and deploy it across three data centers. And they were puzzled why the analyst "couldn't handle" it.

Well, because nobody can tell what an analyst actually produces! Designers produce mockups and creatives, programmers produce code and systems running in production; even managers produce decisions. Surely an analyst must produce something too.

The answer: an analyst is not a "doer" — his product is not changes in the world but knowledge about it.

As an analyst you produce knowledge that managers will later apply. You're a mapper from the packer/mapper dichotomy in the book The Programmer's Stone. The book is nominally for programmers, but for analysts mapping is a downright basic function.

It's for the sake of that knowledge — and of delivering it to the right heads — that you write code, hit APIs, build models, draw dashboards, run A/B tests. (Nastya Yakunina writes about the same thing.)

Literally: before your work, everyone around thought about the product/feature/costs/revenue/whatever in one way — and was wrong, or took needless risks. After your successful work, they think about it in a different way, closer to reality — they err less, take risks more consciously, see new opportunities.

So where's your product? How do you touch it? And how do you measure how much you've produced?

It turns out you must exceed your employer's expectations — but what they expect from you is not the thing you can be most useful with! If your manager doesn't understand the nature of analytical work, getting promoted will be extremely hard.

Doers, who produce tangible things, can't discern a product in knowledge. And they can barely task someone with creating new knowledge — because if they could state the task, that would mean the knowledge already exists! There's even a term for it — wicked problem: a problem you can't formulate until you've solved it. That's why the harder the problem, the worse its statement — down to the helpless "go figure out how it works."

Especially since, once new knowledge is absorbed, it's hard to "unsee" it and remember what the world looked like without it.

Somewhere in the depths of his many books, Anatoly Levenchuk writes about metanoia — a shift of consciousness after which the world changes forever. Do you remember what it was like when you couldn't read or do column addition — and then you learned?

I remember not understanding analog clocks. I just didn't get how you read time off the positions of the hands. And then — click — I got it. Ever since, I can hardly imagine what it's like not to be able to tell time by the hands.

In the same way, a good visualization, model, or metric flips your picture of reality so thoroughly that it's unclear how anyone lived without it before.

Well-done analytical work flips the client's picture of the feature, the product, the market, the business. But the client can't order that!

Knowledge turns into business value through knowledge-based decisions and tools.

Knowledge about the world brings no business value by itself. It still has to be applied. If you can't apply it — there's no case study, no recognition of value.

At the Moscow Masterplan Institute our team modeled such unpopular measures as charging for entry inside the MKAD (Moscow's ring road) or moving government offices out to the Moscow-City business district. Despite the impressive expected benefit to the city, these projects never went into execution — and probably never will. The knowledge exists, but there's no case!

Likewise, a product analyst who proves with data that a feature must not be launched, or must be rolled back, will meet heavy resistance — even though they may have done their job very well. What kind of case will come out of that? Maybe none.

So your ultimate goal should be not merely to obtain knowledge, but to benefit the company through it.

How?

First, there is demand for knowledge after all. It's higher the more important, risky, or money-laden the piece of business the knowledge concerns. Even when there's no explicit demand, there's always a latent one: the moment managers discover that a lot is being lost somewhere — or that a lot can be found there — they get very interested.

Experienced managers understand the value of knowledge better than analysts do. For Vladimir Tarasov the notion of the "picture of the world" is one of the central ones, and enormous effort goes into making it adequate. So the more important the questions in which you dispel the fog of war, the more valuable your work.

The most useful knowledge is the kind that overturns the established consensus. That's called an insight.

In the book Lean Analytics we find this thought. Founders believe in their idea so fiercely that they lift off from reality — this lets them convince everyone around that the plan is feasible and bend reality to their vision. But they risk lifting off so far that they lose touch with reality altogether. They need an anchor to hold on to — and that's analytics. The function of analytics is to ground founders, to give them solid ground under their feet.

Developing this thought, Lena Seryogina wrote (or so I remember — I can't find the link) that the most valuable analytical work is undermining the current business model: a well-founded claim that the model must change. Not every founder will love that!

So look for the zones where nothing is clear and lots of money is at stake. And dig!

Second, from your vantage point you sometimes see opportunities that are invisible from other angles. That's how analytical products are born — systems at whose heart lies a solved analytical problem, say, a forecasting model. Here you step onto the territory of product management and development, but you don't need to go deep. A prototype plus proof that it works is enough.

For instance, marketers distribute millions every month across ads, promos, partner posts and other acquisition channels. They'd love to know what works and what doesn't. More than that, they probably want to align it with the product backlog. And to account for the delayed effect of promos. And channel capacity. And cannibalization. And seasonality. In you come: you build a model of how the channels work — then hand marketers a self-service tool where they enter campaign parameters and see the effect. At first it will be hard on the marketers — they'll have to restructure their work. But then they'll get the hang of it, and the business will pocket solid savings and an edge over competitors.

Some startups build their entire business on such models.

Or: a company is fighting a competitor whose product is exactly the same as yours. You have to fight on price — bad, but can you at least do it efficiently? Analysts dig into the problem, devise an algorithm, test it — and an automatic discount dispenser ships to prod.

Or: you have a marketplace with lumpy demand — say, a ride-hailing service. How do you balance demand? Analysts build a demand model and an algorithm that nudges drivers to come out at peak hours in the right areas. You get surge pricing, and it goes into the foundation of the product. A huge breakthrough for the business.

I deliberately pick outstanding, breakthrough examples. Maybe you won't get a single one like them in your whole career. But I once asked a martial arts master how he manages to break boards with a strike of his hand. He explained that he strikes not at the boards but through them. He aims not to break the boards but to reach the space on the other side. I think there's something to ponder here.

I've been a data analyst for a long time but feel stuck. Not sure it's my thing. Is there another career path for an analyst?

Of course.

Look: you join a company as an analyst. And as you work, you see mountains of fossilized shit around you. You and your colleagues bump into it every time you do anything. It's been lying there since time immemorial and nobody touches it. Maybe it doesn't even smell much — or maybe everyone's gotten used to the smell — but you, you catch the whiff.

For example:

• every dashboard in the company is ugly and incomprehensible; managers complain about them and don't use them — or don't even know they exist;
• the product team is unfocused and doesn't know where to go or what to grab; ad-hoc requests fly in regularly and throw everyone off; priorities change mid-sprint; instead of scrum there's a cargo cult of scrum, and every launch goes through fire;
• data is strewn all over the place, its reliability is doubtful, and analysts burn tons of time every time just finding what they need;
• every team runs A/B tests however it pleases; metrics are computed differently everywhere; managers don't trust the test results.

All these are "side" problems — somewhere in the vicinity of the chairs the data analyst tries to sit on, but not squarely on them. That's why nobody takes them, and they go unsolved for years. But you can take them:

• If your dashboards are a head above the average analyst's in the company, and the execs hold yours up as an example and want them all like yours — you can take this on, and maybe grow into the BI team lead and stand at the origins of a whole new function in the company.
• If you can fish crisp formulations and tasks out of rambling discussions, state the desired outcome briefly and precisely, turn a cloud of vague meanings into a clear document and get everyone to agree with it — help your team clarify the product vision. You'll take on a slice of the product manager role (that role has many facets, and many of them touch data analytics), and before you know it — the whole role.
• If you get a kick out of having all the data at hand, all fields named cleanly and consistently, all corner cases covered, duplicates and gaps scrubbed — and you can answer half the ad-hocs with a single join-free query — try putting the data in order not just for yourself but around you. You'll become a data engineer; and if the company has no data management function, maybe you'll assemble a team and set the data up properly.
• If your eye twitches when people fire up a bootstrap where a t-test would do, and you're tired of adding to your collection of the ways retention or churn gets computed in different corners of the company — gather the scattered metrics into a single hierarchy, write standards and guides for A/B tests, roll out a single experimentation platform — you'll become the A/B expert, and maybe the lead of the team building that system.

Solving these problems may not make you famous as a badass analyst. But since you'll have brought the company a large and timely benefit, with a reasonable manager who understands the value of your work, you'll make a career leap and take a unique place in the company — one that fits you exactly, where you're at your most productive.

Or else you'll update your resume and find a role you love somewhere new — with no shortage of things to talk about at interviews.

Looking for unaddressed pains and addressing them is a great career strategy.

Are you suggesting we just take on any of the company's problems?

I'm suggesting the exact opposite.

"Find a pain and close it" doesn't mean "Grab more, throw farther, rest while it flies."

Throwing yourself into every story and plugging with your own body the holes that arise from systemic project problems (often unsolvable at your level at all) is the worst career strategy imaginable. There are always holes, and on fast-growing projects they multiply at a frightening rate. I've never seen a single person build a career on the "throw yourself at every problem" strategy (if you have — tell me!). I've only seen burned-out ones. And those who didn't want to follow that strategy but were forced by the work environment. They burned out too — sometimes to the ground: depression, leaving the profession.

Vladimir Tarasov, in A Book for Heroes, has this thought: when we have a problem but don't understand how to solve it, the state is so draining that we itch to start doing something, anything, just not to sit idle. That's how we build ourselves an alibi: when the problem rears up to its full height, we can tell ourselves and others — look, I tried, I did everything I could! But such bustling activity will most likely only do harm; worse, we'll believe the problem is handled and stop looking for the solution.

Peter Senge puts it even harsher: "All problems in the present are the result of someone's bad decisions in the past." So the job is not to plug holes, breeding future problems, but to find and fix the processes that generate the holes.

Figuring out where the holes come from is anything but trivial — especially when a process runs through several teams.

A joke on the topic. A car stalls on the road; the driver turns the key, pumps the pedals — won't start. He pops the hood, pokes around, wiggles some wires, tries again — nothing. A guy walks up with a hammer in his hand. "Want some help?" The driver nods. The guy whacks the engine somewhere, and the car starts right up. "That'll be a hundred bucks." "A hundred bucks?! For one hammer hit? Itemize that for me." The guy takes out a slip of paper and writes: "Striking with a hammer: 1 cent. Knowing where to strike: $99.99."

Don't hurl yourself at every problem like a soldier onto a machine-gun nest: unfortunately or fortunately, your sacrifice will be in vain.

Instead, study the situation thoughtfully, talk to colleagues, put forward hypotheses on how to do better, and test them — until you understand where to tap so the engine starts. When a situation is deeply understood, the solution sometimes amazes with its simplicity.

But how do you actually tell what hurts? Maybe you and everyone around you are used to how things work. How do you shake the inertia of thinking?

There are a couple of working tricks.

• Read other companies' blogs (for Russian content, lots of good stuff on Habr; in English there's Medium, and companies of at least Spotify's caliber usually run their own blogs). Blogs often paint a somewhat retouched picture, present the planned as implemented, and never reveal the true level of mess inside — but that plays right into your hands: you get to see how people want things to be. Compare that with how it is at your place.
• Take courses, study books. For instance, Trustworthy Online Controlled Experiments and Lean Analytics are full of great ideas. Something will hook you — then think how things would work at your company if you introduced, say, a metrics pyramid or some clever experiment setup.
• Talk to someone from another company. Find out how he or she works, what they do day to day, what tools they use, what processes they're part of. You can find colleagues on a mentorship platform, or straight on LinkedIn. Usually none of this is under NDA — companies write about their processes in blogs anyway. In a conversation you can ask questions until you grok how it all works.

You won't notice all the problems, and of those you notice, not all will irritate you. Irritation is the sign you'll have enough drive to solve the problem.

If the tricks yield no ideas, you'll have to think for yourself. It's not so easy: systemic problems sit on the boundaries of responsibility zones and expertise. If thinking about such things is still new to you, checklists will help. There are plenty: even Deming understood their value and included such a questionnaire in one of his books. Karl Wiegers's book on requirements elicitation also gives several. Osterwalder's Business Model Canvas, the Lean Canvas and the other canvases are essentially the same questionnaires, just in the fashionable format of boards with stickers.

Above I gave my own questionnaire for data-analytical problems, but it only sets the general frame of description, leaving the methods of finding problems up to the user. So in one of the next posts I'll offer another scheme, based on the systems approach and TRIZ (the theory of inventive problem solving).

…And if you're currently in the fire and thinking, "This is all very nice, but I have zero time — the deadlines are burning, my boss demands X/Y/Z from me, and the deadline was yesterday" — then it's you I most strongly advise to stop and do this exercise. For the arrow of your projects and career to fly forward, you first have to pull the bowstring back. Stop earning yourself an alibi by throwing that arrow forward with your bare hands. If that worked, you'd have managed long ago.

My title says "Data Analyst," but somewhere along the way I drifted from analytics into something adjacent, and I've stopped understanding who I am now and what to put on my resume later. Is that bad?

Not necessarily.

First, what if this new branch of your career is the very thing that's "yours"? You didn't stumble onto it for no reason. Some people are infuriated by ugly dashboards, some by the mess in the data, some by broken team processes. Your life steered to where you now find yourself through your many successive choices, most of which you didn't even notice. Your eye kept catching on certain problems, you solved them — for some reason it mattered to you to solve exactly those. So maybe this is your strength, the point of maximum return on your effort?

Second, nobody will forbid you to return to analytics if you don't like the new field. I've done it — it works. And the experience you gain will serve you well when you're getting to grips with a new complex domain. Work as a developer — and you'll be able to think like a developer, understand their pains and problems. Lead a team — and you'll know what a manager values in subordinates. Big projects are done by big teams; you'll have colleagues in other roles, and the fewer barriers between the workshops, the smoother things go.

On the wreckage of workshop walls, whole new professions arise — DevOps, say, or product management itself. The tectonic plates of the accepted norms of project-making are shifting. How about being there at the birth of the next such reassembly?

Here's a lovely old lecture by Kostya Gorsky on teamwork. Kostya made his name as a designer, but that didn't stop him from teaching programming at the applied math faculty for many years. (Sadly, I never studied under him and only dropped into his seminar a couple of times as a guest — but even those couple of times were very valuable. Kostya, if you're reading this — thank you!)

Look at what Roma Bunin or Artyom Gorbunov did before becoming gurus of their fields — it's very diverse. And Avito's current CEO grew from an analyst inside the company.

What I would recommend taking care of in your situation is time and resources for your new line of work.

If de facto you've long been doing data engineering, or BI, or something else important — but not what your manager expected of you when hiring you — better make sure you both see the situation the same way.

Think through what resources you need to do this new thing better and more fully, and discuss it with your manager.

Try to formalize your new status: find out whether your title can be renamed, whether your new goals for the month/quarter/year can be written down. As a fallback — at least send your boss a DM after the conversation along the lines of "Let's confirm we understood each other right. We agreed: …" and get a written "okay" from him.

Mismatched expectations are a very serious risk; don't leave it lurking behind your back.

We're used to thinking of data analytics as something defining and finished. Same with development, product and project management, DevOps, and so on. "This person is an analyst, and that one is a manager." We say "Joe is an analyst," though it's more accurate to say "Joe does analytics on project X." We sort of imply that Joe is an analyst in general — "an analyst for life" — and the role is glued to him. But on another project Y, Joe might be, say, the founder and the programmer, paying Pete to perform the analyst role; and at home he doesn't think about analytics at all, because he's writing a symphony. What's more, projects X and Y may demand substantially different things from the analyst role.

Anatoly Levenchuk noted back in 2015 that the profession as a defining life choice is obsolete: everything around changes too fast, and flexibility matters too much — you have to fit the role into the specific project. It's time to get off the horse called "one profession for life," even if it seems the horse is still breathing.

Hang as many labels on yourself as you like — just don't glue them on.

This all sounds nice, but when am I supposed to do it? They demand ad-hocs, experiments and dashboards from me — I barely have time to wipe the sweat.

Not everything analysts do at work is analytical work. Analysts shuffle data around, build data marts, draw dashboards, export tables from the database, sit in company-wide meetings, move tickets around in Jira, and so on and so forth. At advanced companies it's considered an achievement if an analyst spends 50% of the time on actual analytical problems.

But only solving analytical problems earns an analyst fame, recognition and grade bumps. And only on those does s/he grow in the profession.

Analysts aren't alone in this. Developers complain about shuffling JSONs, data scientists fiddle with features and scrub dirty data, managers write reports and drag tickets across boards (and you thought that was their core function, lol?). Every job in a company comes with some auxiliary routine.

Steve McConnell in Code Complete writes that programming has two kinds of complexity.

• The first kind belongs to the problem itself: if we're building an archiver, there must be a compression algorithm; if a distributed store — then ways to synchronize and maintain integrity, and so on. He calls this complexity essential. There's no escaping it. Fighting it moves you toward solving the problem.
• The second kind belongs to everything else: quirks of the language and libraries, the compiler, the dev environment, testing tools, builds and releases, team routines, and so on and so forth. He calls this complexity accidental. Fighting it doesn't move you toward the solution; it's something like a tax.

McConnell proposes getting rid of accidental complexity as far as possible. Automate, simplify, build tools. Organize the work so accidental complexity stays under control.

All that — to save your strength for essential complexity. Because in the end a programmer is valued for the ability to solve problems, not to fiddle with tools.

Analytics is full of accidental complexity. Reduce it for yourself — and you free up time for solving problems. Reduce it for everyone — and you're a hero.

Here's a maximally heroic example: think how much accidental complexity shrank for data analysts when SQL was invented! How much faster did hypothesis testing become, how much bigger were the problems that now fit in their heads?

A more modest example: in my experience, a good data mart cuts the time of a typical ad-hoc from several days to a few dozen minutes.

More options — not heroic, but hygienic in nature:

• Drowning in a sea of tabs? Sort them and make bookmarks, or set up a separate work browser.
• Need to monitor an experiment regularly? Get a neural net to write you a bot that sends the results every hour.
• Often asked to export/check/compute the same thing, or nearly the same? Write a parameterized script and put it on cron; then build a dashboard and teach the requesters to use it themselves. (Once a month counts as often.)
• Invited to meetings where the same questions get asked over and over? Write a FAQ and pin it everywhere visible: pinned messages in chats, dashboard headers, the new-ticket template in Jira. Answer template questions politely but implacably with a link to the FAQ.
• Took a task into the sprint, and mid-sprint someone bursts in with another one? Bring the burster together with the person whose task will fall out of the sprint thanks to their efforts, and silently watch them negotiate.
• Pestered a hundred times a day with urgent questions? Agree with the pesterer — or their boss — on which hours of the workday you're online; the rest of the time, switch off all notifications and work in peace.

Analytics is also full of essential complexity. It's the fight with it that moves the business, your career, and your problem-solving ability.

You're fighting essential complexity when you:

• devise an experiment design — not a standard one, but a new one nobody has done before;
• invent a metric for something that couldn't be measured before, or dig into the properties of an existing one, or improve it so it measures what you need more accurately, faster, more correctly;
• figure out how the business works: what happens where and in what quantities, what matters and what doesn't;
• dig into anomalies, look for explanations for facts that don't fit your picture of the world;
• take part in decision-making, correct the worldview of your managers and colleagues;
• build models: connect scattered facts with dependencies so that the consequences of decisions become predictable;
• simplify: where there was a lot of data and a lot of arguing in chats and meetings, now there are crisp theses backed by metrics.

All of this involves novelty and reflection; it can't be done on autopilot. It takes energy. So if you're in an ad-hoc crunch, first you need to reduce the accidental complexity — clear the field for real work.

Advanced companies won't let you sit on routine for long, either. At Avito, for example, there's a rarely mentioned rule: every analyst must grow to senior or leave (you can see it in the criteria in the playbook).

You can close your eyes to this and live in the "Matrix" of routine tasks — but you don't need to be a great analyst to predict where that leads in five, ten, twenty years. Besides, it's boring.

So which paper pill will you take: blue or red?

PS If you or a friend of yours are in this situation, write to me and I'll consult you/them for free. We'll have a one-hour call and think through concrete steps together. In return — a link to a repost of any of my texts on analytics in any social network.