krvkir's weblog

Data Analytics Career FAQ

2026-08-01T00:00:00+04:00

Table of contents:

Who are you, and why should I listen to you?
How to choose between data analytics and data science? What's the difference?
I got rejected at three places — am I done for?
I finished courses at Yandex Practicum, Skillbox and the like, but can't find a job. What should I do?
I already work as an analyst, I've mastered the basics, I seem to be managing. How do I grow into a senior?
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?
Are you suggesting we just take on any of the company's problems?
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?
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.

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.

Data Analytics Project Canvas

2026-08-01T00:00:00+04:00

Table of contents:

What this canvas is
Where to get the template
Examples
How to fill it out
Feedback and development
Bonus
Legal notes

What this canvas is

This is a template for describing an analytics project (a research): a list of connected questions, arranged in a chain, that you should ask yourself in order to understand the task. It helps data analysts solve tasks better and explain their findings to others more easily.

The template has three goals:

not to miss important things in the task;
to build a habit of thinking about these things when solving a task;
and to explain to others how you think about the task and what you know about it.

The goal is NOT to fill out a big checklist for every task every time. Fill it out 2–3 times — you'll get used to it, and in simple cases you'll run through the checklist in your head, writing it out in text only for complex and large ones.

Where to get the template

Copy this page to your Notion:

Data Analytics Project Canvas — Template

Over time, templates for Google Docs, Logseq, etc. will appear here.

Examples

Data Analytics Project Canvas — Examples

How to fill it out

The template assumes that you will come back to it and extend it — thereby rethinking the task.

So spend no more than an hour on the first pass. Write facts and figures from memory — you'll add links later. If it's going slowly, fill in as much as you can within an hour and come back in a day.

The template can be filled out in any order; you can go back or skip ahead. Stuck on stakeholders? Try filling in the pains or the "What we know" and "What we don't know" sections, then return to stakeholders.

If filling out the checklist is hard — that's good! It most likely means you understand the task poorly. The earlier you discover your lack of understanding, the easier it is to fix, and the lower the chance it will shoot you in the foot later. Forewarned is forearmed.

If filling it out is easy — congratulations, you understand the task well and have simply confirmed that nothing important was lost. It will also be easier for you to explain your understanding to fellow analysts and customers: in data analytics, it's not enough to do the research — you also have to convey its results to colleagues and achieve business impact.

Blocks and formulations

The template includes two spare blocks: "Processes" and "Metrics". Early on you may have neither metrics nor processes, so skip them at the start. As you work on the task, you will discover/create processes and understand which metrics are needed — then fill them in.

The formulations in the template may seem clunky, but on the first pass still try to squeeze your thought into them. What matters is not the beauty of the text but the clarity of thought. Later you'll return to the template and rewrite and shorten where needed.

Pay special attention to the situation description (the first block) and to the formulation of hypotheses.

Describing the situation

The "Situation" block should be written from a third-party position.

Suppose you joined a product to build up the user base and generally grow it in every way. There's a strong temptation to describe the situation like this:

"We need to find growth points and increase MAU to X people."

By writing it this way, you immediately box yourself into this requirement. Worse, you shift from a researcher's perspective to that of a detailer, an engineer. After that, the whole template stops working for you, and you lose the ability to impartially figure out what's going on. So take a step back and write as if you were an outside observer with no stake in the situation or in what happens to the company.

"Company X does such-and-such, has this many users and is growing this way. It operates in a market with players A and B; they have these problems, and the company solves some of them. The company has these goals, and they must be achieved because of this and that (investor requirements, cash runway, competitors, etc.)."

You'll have time to formulate the solution. That's a familiar train of thought, a familiar role — we all know how to write "what to do" statements. For now, hold yourself in the researcher's role.

Hypotheses

The easiest way to explain hypotheses is through examples:

"Why don't users buy?" — not a hypothesis but a question; its place is in the "What we don't know" block.
"Users don't buy because it's too expensive for them" — not a hypothesis but a statement, and one phrased as truth. If it really is true — move it to the "What we know" block and link to the fact confirming it (a customer development interview, a chart, a table, a dashboard, etc.). If you're not sure — formulate it as a hypothesis and test it.
"I believe users don't buy because it's too expensive for them" — better, but still not a hypothesis; it's a belief. It's unclear whether it's true.
"I believe users don't buy because it's too expensive for them. To check this, I'll run a pricing A/B test." — getting good, but still not a hypothesis. First, explain how the test will be designed (put this on a separate Notion page and link to it from the hypothesis block). Second, suppose we ran the test and the statistical criterion gave a p-value of 0.06. Does that mean the hypothesis is rejected?
"I believe users don't buy because it's too expensive for them. To check this, I'll run a pricing A/B test. If purchase conversion in the discount group is X% higher at a significance level of 0.05, we accept the hypothesis; otherwise we reject it." — this is a good formulation.

A hypothesis has three parts: 1) the statement we believe in; 2) the ways to test it; 3) the acceptance and rejection criteria.

It's good when there are several testing methods using different approaches: A/B tests, surveys and customer development interviews, descriptive data analysis, collecting external statistics. In data analytics we usually work with complex systems where it's rarely possible to isolate all influencing factors, so any confirmation is probabilistic. If a hypothesis is confirmed by several independent methods, the probability of error is lower.

Note: our hypotheses are not hypotheses about changing the product ("We believe that by doing X we'll see Y"), but hypotheses about how reality around the product works ("We believe users behave in such-and-such a way"). We're not changing anything yet — only investigating. The line here is thin, but with time you'll feel it.

Working cycle

The last four blocks form something like a cycle:

Based on what we don't know, we formulate hypotheses;
Hypotheses dictate the next steps to test them;
Once these steps are done, the hypothesis stops being a hypothesis and becomes a fact — we remove it from the "Hypotheses" block and write the discovered fact into the "What we know" block. If along the way we learned something valuable that we hadn't planned to check, we add it to the "What we know" section (and possibly to "Processes", "Metrics", "Stakeholders", "Pains").
At the new level of understanding, new questions appear (we realize there's something else we don't know) — we put them into the "Don't know" section. The circle is complete.

There's a temptation to build a kanban process with cards around this cycle. Although that can be useful at some stage, I don't recommend doing it from the very beginning. Keep your focus on the task itself, not on dragging cards around. But if you've done it and it works for you — great.

Map size

Keep the map short: it should fit on one screen, two at most. If some item has grown too large — for example, the "What we know" block has many facts and charts — summarize them in a short statement and link from it to a page where that statement is expanded and substantiated.

A short map fits in your head, it's easier to think about, and it's easier to explain to others.

Additional blocks

The map can be extended at least at the "What we know" point. The "Metrics" and "Processes" blocks grow out of it: you know about certain processes and metrics, but they're such important entities that it makes sense to set them apart. Similarly, your task might develop, say, "Data" and "Models" blocks. Add them next to "What we know" if a) you've accumulated quite a lot of facts about data or models, and b) you've tried hiding them in a subpage of the "What we know" block but want them in front of your eyes at all times.

Another place where extending the map seems logical is the project description. At some point you'll understand the situation well enough to set a task "to do something" and "to arrive at some result" — then add a "Vision" block (briefly describing what problem your system solves) and a "Milestones" block (listing the stages of work and the definition of done for each).

Remember: by adding blocks you make the map heavier. Make sure it still fits in your head.

Feedback and development

This template is not set in stone — I keep improving it. Fill it out and tell me how it went: what was especially hard, which formulations were confusing, which sections were redundant, and which were missing. Together we'll make the perfect template :)

Bonus

I'll give you a free consultation on your task if you come to me with a filled-out template for it 🙂 To get one, message me on Telegram and attach a link to your task description written using the template (ideally in Notion). We'll pick a time for a call and discuss what you've come up with.

Legal notes

The author of the template is Kirill Krasnoshchekov. I publish the template and its documentation under the CC-BY-SA 4.0 license. Please feel free to use it in any projects. If you adapt it, publish your version under the same license and credit the author.

Artificial Intelligence

2026-03-08T00:00:00+04:00

Table of contents:

Do LLMs solve new problems, or only those they've seen in datasets?
When to use LLMs' help and when to avoid it

The topic is hot nowadays, and I have some ideas about it. It's easier to think about them when they're written somewhere, so here they are.

I also added some LLM-generated infographics to each section. Because, you see, they both illustrate and meta-illustrate my ramblings.

Do LLMs solve new problems, or only those they've seen in datasets?

I think of problems and their novelty using the following model. Say you have a set of solved intellectual problems-proving a theorem, writing a high-load backend, drawing a webtoon, or conducting empirical research. Each of the problems was solved using some methods. A set of known methods forms the second level of our pyramid. Then, methods have some ideas behind them, and some methods share their underpinning ideas. That's how we get the third level. Proceeding upward through the pyramid in this manner, we arrive at more and more abstract concepts.

No doubt, on the lower level, there are many problems not solved: many backends not written yet, many pictures not drawn. Doing this work is solving new problems, in a sense. After all, before LLMs it wasn't possible to do so automatically with considerable amount of generalization. In software engineering we had project templates, or research protocols for empirical studies, but a human was necessary. Now it's not so. But compared to what humans could do, there's only improvement in speed, accuracy and scalability.

One may ask: are those novelties real? We already have blueprints for them on the second level of our pyramid. For example, a course on software engineering that teaches you how to design systems, or techniques used to draw various kinds of paintings, artistic styles and schools.

To me, there are no signs of discoveries on the second level made by LLMs yet. I see only level-one problem solving, boosted and scaled, no doubt, but should we call it a novelty? Of course, there are signs of new approaches to the old work, like focusing more on requirements and specifications in software development, but those improvements happen with heavy involvement of humans, not autonomously.

How does a new method emerge? My understanding is this. When a human uses a method from the second level to produce something on the first level, they possibly (not always) learn something about the method itself. Its boundaries, upsides and downsides, this stuff. If someone used a second-level method ten times, from the accumulated experience, they possibly extract some useful aspect of it which wasn't there before. If they do the hard work of reflecting on that and sharing with others, then the level-two method grows a bit, enriching level two as a whole. When a genius (whatever that means) stumbles upon a problem, maybe s/he even reaches level 3 or above.

How exactly does this addition happen? My first guess is that humans have a very long context. An LLM runs, solves its task, and then disappears into the void. All the context is lost. A human solves the task and stores the experience somewhere. Humans live many decades, so this experience, distilled, repeated, distilled again, sometimes (not always, but there are 9 billion of us) molds into something new.

If it's the only difference between us and LLMs, then we'll see second-level discoveries from LLMs soon (but possibly won't understand them).

One important question is whether this experience can be accumulated purely in form of words or not. Humans definitely accumulate their experience beyond the speech level (or maybe we should say "below"). Feelings, emotions, body sensations, some guttural ideas that are hard to express. I'd even say (and some psychologists like Wilhelm Reich would confirm) that it's our main level. In contrast, modern AI agents store their context either as text or other "final stage" artifacts. They don't edit their network weights right away after each interaction with the world, but (so long as we stick to artificial neural network metaphor for human brain) humans do exactly that.

Maybe there are other differences, more qualitative than quantitative ones, like human brains utilizing quantum physics effects or something.

When to use LLMs' help and when to avoid it

Talking about helpers and tools, as with any other tool, there are cases when they're helpful, cases when they're not particularily helpful, and cases when they're outright detrimental.

My take on LLMs for any complex intellectual work, such as programming, is this. You may delegate work to LLMs, but you may also delegate understanding. Delegating work while retaining understanding is generally not risky. Delegating understanding, on the contrary, is very risky.

There are cases when you already understand something. If you're a skilled backend developer, and you use an LLM to write code for you but still review its results, you delegate only work. You get pure benefits with virtually no costs or risks.

Then, there are cases when you don't understand something and don't want to understand it. Maybe the thing is so ubiquitous and so well-documented, and the outcomes of the work are so standardized, that you don't care and decide to trust the LLM and the state of the art it absorbed from training. As an example, you're again a backend developer, but this time you need a front-end for your hobby project. You don't care much about the front-end architecture or the performance, and you definitely don't plan to become a front-end guy. You also assume that millions of front-end apps have already been written by now, and thousands of books and guides on the subject are available. Then you delegate both work and understanding, accepting the risks of being unable to scale the results or modify them as you want—or having an accidental JS crypto miner working on your users' machines.

Finally, there are cases when understanding is an indispensable part of your goal. As a maximal example, imagine that you're a student striving to finish a computer science course. You need to make your way through programming assignments. Should you delegate this work to LLMs? Your only goal is understanding, and the lab work is how you gain this understanding. By delegating it, you undermine the whole endeavor.

There are nuances between those three corner cases. For instance, when starting a weekend project, what interests you more: getting a grip on new tech, or building a usable contraption doing some job for you? Maybe the first time you go with a contraption that just does the job, and postpone the understanding until you decide to improve the tool you've got.

There's one more dimension to this, namely, the long-term effects of each choice. A back-end dev from the second example will never learn a bit of JavaScript, though successfully accomplishing their short-term goals. This means that the market loses a full-stack dev where it could get one "in the good old days". Forget about the market, but for the dev it means less technical breadth, less ability to communicate with their peers, less agility if the technology trends change, and less experience to draw on something "on the level two" (see the previous section). On the other hand, they saved a lot of time and money for themselves and their employer. What outweighs what in each case — that is the question to answer.

Another rule I formulated for myself: is the result disposable? If I want to get some work from an LLM, delegating to it both the work and the understanding — how valuable is this work and for how long will it remain valuable? If it'll be used several times before being thrown in the trash, then of course I'll use an LLM. If I want a thing to last and be reused, then understanding is important to me and I shouldn't delegate that understanding.

In the software realm, applications mostly fall into the disposables category, but frameworks and libraries belong to the latter, lasting one.

In the art domain, marketing art falls into the disposables, along with word illustrations for language learning cards — but visual style experiments or, say, paintings that go beyond visual art and express something of universal value, are designed to last (although only time will tell whether they truly will).

In writing, all the reports, requirements, and documentation fall into disposables (to the extent that, in the case of software, one can generate bespoke documentation for oneself from the source code, which calls into question the need for documentation at all), but poems, novels, and scientific monographs should last (or at least compete with other poems, novels, and monographs for the right to last).

Why is disposability a criterion? Because if I plan to keep a thing for long, I would inevitably want to improve it. I'll add features to a framework, write new chapters to a book. I wouldn't be able to do that without understanding.

Bittensor

2026-01-09T00:00:00+04:00

Table of contents:

Applications
Architecture
- Consensus
Governance
- Dynamic TAO
Development
Conclusions
References

According to the whitepaper (Rao 2022), Bittensor is “a market where intelligence is priced by other intelligence systems peer-to-peer across the internet”.

Statistics and the current state:

TAO explorer: price, market cap (1b at 2026-01-10), subnets (around 200) and more, very discoverable dashboard, even has its chatbot.

Applications

The DAO consists of numerous subnets each being a separate startup generating value for its clients. There are about 200 of them now (2026-01-10), grouped into several dozen types like Agents, 3D, Programming etc. Subnets vary in their quality and maturity. Few examples of top subnets:

404, a company providing quick 3d assets AI-assisted generation (also see its CEO interviewed). There is a ton of info: twitter, discord, blender and unity plugins, demos, even a game made in a month as a demo project. Bittensor-related code is kept in a github repo.
Chutes, an AI models infrastructure which incentivises its "miners" to keep models "hot" (loaded into memory) and thus provide low latencies.

And the "bottom" ones:

Talisman, supposedly some sentiment analysis network, but appears to be a part of some indistinguishable crypto wallet startup, one of thousands alike. No info about the subnet and its features is given.

Bittensor acts as a marketplace for their subnets: attracts miners and validators, provides rewards. Consider this quote from 404 CEO interview:

By operating within Bittensor’s decentralized AI network, we ensure that our platform scales organically, improving as more contributors join. This system incentivizes innovation—miners are rewarded for improving the models, meaning that our AI is constantly evolving based on real-world demand. It also removes reliance on a single entity, ensuring that creators have open, unrestricted access to cutting-edge 3D tools, rather than being locked into proprietary ecosystems.

Architecture

The whitepaper (Rao 2022) builds a formal model and proves its properties. The network consists of peers, each providing its own [ML] model trained on a dataset with a loss function. Peers evaluate models of each other, assigning weights to them. Additionally, peers have stakes. When a model gets a stake-weighted review from 50% of a network, it is said to get consensus. There are incentives to avoid collusions and spur consensus level growth. All this mechanics supposedly maximizes the amount of intelligence provided.

Unfortunately the paper is very terse telling how things would work together in a real world: what problems would peers solve, who will use their work, how peers would evaluate others models quality.

Possibly related field: mixture-of-experts models.

The network has two types of nodes (neurons): miners (servers, axons) and validators (clients, dendrites). Servers do the computations and validators validate their work, assigning weights to them according their performance. Validators have stakes at play but servers don't.

Consensus

The consensus mechanism (so-called Yuma consensus, by the name of an original whitepaper author) is described in details, with a simulation.

The system is initiated with a set of hyperparameters:

$\kappa$ , the ratio of stake that decides consensus. Its typical value is 0.5. The lower it is, the lower consensus is required;
$\beta$ , the bonds penalty;
$\xi$ , the emission ratio.

Glossary:

Validator stake $S_i$ : amount of network tokens validator $i$ has.
Server consensus $W_j$ : a weight value that maximizes the total stake-adjusted weight which surpasses $\kappa$ .
Consensus score $C_j$ : ??
Consensus-clipped weight $\bar W_{ij}$ : a maximum of a weight given by validator $i$ to server $j$ , and a consensus for this server.
Server rank $R_j$ : stake-adjusted sum of consensus-clipped weights. (Not actually a statistical rank but just another weight.)
Server incentive $I_j$ : percent of the rank of a server to the total ranks given in the turn.
Validator bond $B_i$ : ??
Validator reward $R_i$ : equals incentive-weighted bonds given to servers by a validator.
Emission $E_i$ : new stake issued after each turn and given to validator $i$ .

Each turn validators assign weights to servers, adjusted weights are calculated, and incentives and bonds are emitted (new tokens are minted) and doled out to servers and validators. The reward is distributed in the following proportions: 18% to subnet owners, 41% to the miners, and 41% to the validators.

The adjustment algorithm keeps the stake of honest majority of the net to this majority subject to wide ranges of malicious behaviour of network minority, i.e. emissions to the honest part keeps being greater than the stakes of this majority: $E_H \ge S_H$ . For instance, simulations show that a honest network with 60% stake can retain its stake if if generates 70% or more utility.

The reason these guarantees are weaker than e.g. Bitcoin 51% limit is that the network doesn't have a provable objective utility, like Bitcoin's PoW, and thus it must rely on bids of the peers which are at least partly subjective. (There is a pack of plots showing the simulation results under various levels of subjectivity.)

Governance

A section in the docs describes the governance process. The control over the network was initially held by one person. Then it transitioned to a system of a Triumvirate (three members able to create proposals for changes) and a Senate (up to 12 members who vote to approve or discard a proposal). The next stage is promised to be more decentralized/democratic.

Each member of the Senate has a stake of network tokens in game. Additionally, other members may delegate their stakes to a senator of choice. To be elected, one must aggregate at least 2% of the total network value in own funds and delegated stakes.

Dynamic TAO

The proposed next stage of the governance is Dynamic TAO (Rao 2025). It changes incentives allocation across subnets to make weights distribution among subnets more optimal. The idea is to introduce subnet tokens and make them to be openly traded in a constant-product automatic market makers (cpAMMs), thus eliciting subnets value via the market.

AAMs usually need liquidity providers (LPs) who stake their TAO tokens into AMMs, and also attracts speculators arbitraging the prices among AMMs. However, Bittensor AMMs will gain liquidity only through emission, so no LPs and no swap fees present here.

Glossary:

APY: annual percentage yield
Root validators / root network: ??

Development

There is an org on Github: opentensor. The blockchain layer, subtensor, is written in Rust.

There is an SDK for users.

Conclusions

There are the following groups of stakeholders in the DAO:

servers (miners) who produce the common good (the computations) and gain 41% from the network emission, and also benefit (or suffer) from the network token price movement;
validators who make the network operate in zero-trust environment also get 41% of the reward and also have interest in maintaining DAO tokens prices high;
subnet owners, of which I don't know much yet;
users who order computations from the servers and pay for them with the network tokens, thus keeping the tokens price high.

Their incentives are clear.

Then, there are governing structures: the Triumvirate and the Senate, which accumulate network token stakes. Supposedly, these people are from the companies/organizations running servers and/or validators and thus having stakes.

Also, there are developers, analysts and others who improve the network. They possibly also have stakes, run servers, own stakeholding entities or work for such.

References

Rao, Yuma. 2022. “Bittensor: A Peer-to-Peer Intelligence Market.” Google Docs, April 18. https://drive.google.com/file/u/0/d/1VnsobL6lIAAqcA1_Tbm8AYIQscfJV4KU/view?usp=sharing&pli=1&usp=embed_facebook.

Rao, Yuma. 2025. “Dynamic TAO.” February 4. https://docs.learnbittensor.org/dynamic-tao.

Ethereum

2026-01-08T00:00:00+04:00

Table of contents:

Definitions
Architecture
Governance
Development
References

The first crypto network with smart contracts, i.e. a distributed engine for Turing-complete programs. Original vision may be found in the 2014 whitepaper (Buterin, n.d.). The paper gives a brief intro in the Bitcoin mechanics, then describes the advent applications (Namecoin, complex contracts) for which Bitcoin doesn't provide a foundation. Bitcoin has a simple scripting language used to check the authorization for spendings, but it's not Turing complete.

Smart contracts are written in Solidity, a JavaScript-based language.

Where to learn about it:

a lot of good articles can be found on the Learn section of the main site;
there's a dedicated forum for Ethereum research.

Current state:

MigaLabs observability dashboards;
see growth scenarios and storage costs analytics

Definitions

Account: an address with a balance and a data storage; states of all the accounts constitute the network state.
- External account: an account controlled outside the blockchain by a key.
- Contract account: an account activated by recieving a message.
Message: something one account may send to another (analogue to transactions in Bitcoin, but extended to contract accounts, and also repliable).
Transaction: a message from an external account.
Ether: Ethereum internal currency used to pay for transactions.
Gas: a measure for transaction size and for amount of computation happening when a contract is executed. Each byte in a transaction takes a fixed amount of gas.
- Gas price: value in Ether for a unit of gas. Is set separately for each transaction, allowing for validator nodes to pick up the most lucrative contracts and thus for senders to buy transaction speed with higher gas price bids.
EVM: Ethereum virtual machine, an environment where contracts are executed. It is a "low-level, stack-based bytecode language".
- Serpent: one of the high-level languages which compile to the EVM low level programs.

Architecture

Supposedly, the Mastering Ethereum book is a good technical introduction for a developer.

The most major event of the recent years was switching from Proof-of-Work consensus mechanism to Proof-of-Stake one.

?? What is a relay and a builder? How the network is deployed?

Governance

Like Bitcoin, Ethereum grows by EIPs (Etherium Improvement Proposals, see the list). The process is described in EIP-1. There is a forum called Ethereum Magicians where EIPs are discussed.

EIPs are divided into types: Standard track EIPs aim to change the protocol or add features, Meta EIPs change the process around Ethereum, and Informational EIPs don't change things. Supposedly, Meta EIPs are the most interesting governance-wise.

Among Standard Track EIPs are ERCs which are application-level standards not involving core protocol featuers, e.g. ERC-721 defines NFTs.

??refine?? The prominent case in the Ethereum history happened after The DAO hack, when the network was forked to roll back the fraudulent transaction. Part of the network rejected the rollback.

Development

There's a Ethereum organization on Github: the client code, the website, EIPs are all stored there. There is about 300 repos in it.

The main client seems to be written in Go, has 50k stars, 200 active issues and 170 pull requests where code review and discussions happen.

Since network upgrades require network hard forks, which is an event of no small size, new features are included by batches, which are themselves documented as EIPs (example).

References

Buterin, Vitalik. n.d. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.

Bitcoin

2026-01-07T00:00:00+04:00

Table of contents:

Glossary
Governance
Development
Conclusions
References

The first working crypto currency, the oldest one, the largest by now by capitalization. Basic technical details are described in its 2009 whitepaper (Nakamoto, n.d.), but a lot was added since.

The current state:

capitalization etc can be found on the stats wiki page, also see dashboards on Dune;
transaction cost is ?? 1 sat/transaction ?? — see a realtime Clark Moody dashboard

Where to learn about it:

Bitcoin Wiki

Glossary

ASIC: Application-specific integrated circuit — a specialized hardware for calculating hashes for a blockchain. Usually it can efficiently compute only specific hashes of a certain blockchain, rendering them unusable for any other purposes.

Governance

Governance is done via BIPs (Bitcoin Improvement Proposals). The list of BIPs is on Bitcoin Github repo (at 2025-01 the max number is somewhat 450 but there are gaps, so maybe 200 total of BIPs really exist).

The BIP process seems to be more or less standard for open-source projects management, e.g. PEPs in Python. The first three BIPs describe it, plus there are several more BIP-related BIPS. In few strokes, BIPs go through this pipe:

a BIP draft is sent to the Bitcoin mailing list;
the discussion happens;
the draft is either accepted (and at some point implemented) or rejected;
if a change is implemented, it must be accepted and adopted by the majority of users (network nodes aka miners), if they don't upgrade their software, the change will not be deployed (don't have info of cases when something was rejected this way).

BIPs are labeled with their scope (consensus, api, applications etc).

Development

The development occurs in a repo on Github. The main language is C++, the license is MIT.

There is a client software called Bitcoin Core. "Client software" here means the software needed to validate the transactions, i.e. to participate in the network as a node.
The development is done on Github via PRs, the PRs are discussed also on Github.

Some BIPs contain links to PRs in the Bitcoin Core repo.

Discussions are also held on IRC (//irc.libera.chat/bitcoin), on the forum and on Reddit (the last one is mostly for memes though).

Conclusions

What is the goal of this organization? What objectives do people participating in Bitcoin ecosystem have?

The users (senders and recievers) of Bitcoin are essentially free riders (see Mancur Olson): they pay fees but fees are a minor source of miners income (see TimechainStats dashboard), and they're not directly included in Bitcoin governance.
There's a lot of money produced in this DAO, so miners (and all others down the supply chain, including hardware manufacturers) supposedly want these money to flow in, otherwise their investments devaluate. But miners also are not directly included in the governance, although they may participate in the development and discussions around it.
The ones who are directly participating in governance are the Bitcoin developers. Their incentives may vary. It's interesting what's the structure of efforts, how much effort comes from corporate bodies with monetary interests, and how much comes from independent persons.

References

Nakamoto, Satoshi. n.d. Bitcoin: A Peer-to-Peer Electronic Cash System.

Angela Tran Kingyens et al. (2018) A Guide to Marketplaces

2024-05-05T00:00:00+04:00

This book was recommended by Vladimir Pravdivy, who spent many years as the CEO of Avito (Avito is Russia's largest classifieds platform, roughly the local Craigslist) and grew the company into the giant we know today. As so often happens, the book sat waiting for its moment for two years — but the wait was worth it :) It's a slim little thing (70 pages), more of a handbook than a book, really, but it explains with remarkable concision how to think about marketplaces.

The book is freely available online — you can download it as a PDF or EPUB. Below is a brief summary, along with my thoughts.

What is a marketplace? Picture a market where deals (transactions) are struck between two parties. For example, therapists are looking for clients, and clients are looking for therapists. Or passengers are hunting for cabs, and cabs are hunting for passengers. This market already has some transaction volume happening without you. Now you show up with your platform and say to the parties in the deal: let me help you out. They start using you, and from then on some share of the deals goes through with your involvement.

And there you are, sitting astride the pipe through which the money from all these closed deals flows. And you want to know two things: 1) how much money is flowing through the pipe, and 2) what share of that flow goes to your platform.

The first is called Gross Merchandise Value (GMV), the second — take rate. The book argues that these two metrics are the key ones for any marketplace.

The whole spectrum of existing marketplaces lays out beautifully along these two measures — and marketplaces can be wildly different from one another.

Take ride-hailing services: Yandex.Taxi, Uber, Lyft. The market has two sides — passengers and drivers. The service takes care of everything: finding a car for the passenger and a passenger for the driver, processing the payment, plotting the route, making sure there are enough cars in the city, checking the condition of the cars and the competence of the drivers. The services embed themselves so deeply in the transaction that it's fair to ask: aren't the drivers effectively employees by now? Thanks to this degree of control, the services can command a take rate of 20–30% and earn enormous revenue on a comparatively modest GMV.

Now for an example from the opposite end of the spectrum: classifieds boards, such as Avito, Craigslist, Thumbtack. There is often no clear line between buyer and seller at all: today you show up as a buyer, tomorrow you decide to clean out the garage and become a seller. The platform barely controls the transaction; it merely brings buyer and seller together, and how they get in touch, where they meet, and whether the deal actually happens is their own business. But the platform is enormous: you can find everything from diapers to Swiss watches, from cashier job listings to entire businesses for sale. The result is a huge GMV (a couple of years ago Avito boasted a GMV equal to 3% of Russia's GDP) but a rather modest take rate, earned not on transactions but on listings.

Exercise: think about where italki, Booking, BlaBlaCar — and any other intermediary services you can think of — would land on these two axes.

What does all this mean for data analytics? Unit economics is no longer so easy to compute, because there is no sale: we aren't the ones doing the selling, we aren't the ones providing the product or service — we merely connect the two sides (though, as we've seen, the depth of that "merely" varies). Accordingly, our commission, or the price of our additional services, depends on the state of the marketplace: how many sellers there are (supply), how many buyers (demand), and whether both sides have enough liquidity.

So we can still measure the funnel, acquisition cost, and retention metrics for each side of the marketplace, but to estimate LTV we need to know the state of the other side of the market over the user's entire lifetime in the service. That complicates things considerably.

That's why marketplaces try to devise some quantity that captures each user's contribution to the market on the platform while being decoupled from the other side. For taxis, this could be the number of hours a driver is available online (regardless of whether there was a ride during that hour); for a classifieds board — users weighted by their activity on the board. And then unit economics gets calculated against that quantity.