IT Conferences for Analysts: A Practical Guide

You can watch a recorded talk later. The distinctive value of an in-person conference is the chance to discuss a problem with people who see it from another project, company, or role.

That does not mean meeting everyone in the room. A useful professional connection begins with a substantive question, not a stack of contacts.

My context, updated in 2026

I have spoken at Saint HighLoad++ 2024, Analyst Days in 2022–2023, Infostart, the Summer Analyst Festival, and internal T1 Group events.

At the 2022 Summer Analyst Festival, I spoke about working as an analyst in a time of change and the value of data. At INFOSTART’s “Analysis & Management in IT Projects” conference, I led a workshop titled “Eliminating Data Illiteracy.” The organizer hosts a recording page and an article based on the session. The date shown on those pages, 7 June 2024, is the publication date of the materials; I do not give an exact date for the workshop here.

The old Russian abbreviation needs clarification: ЛАФ in the conference list means “Летний Аналитический Фестиваль” — the Summer Analyst Festival, an annual event for systems and business analysts. It is unrelated to my personal R&D product, also called LAF.

In 2022–2023, I also developed the external speaking programme within a corporate analyst community, helping colleagues choose subjects and prepare their material.

I have seen conferences from three positions: attendee, speaker, and someone helping colleagues prepare their own talks. Each position should produce a different outcome.

An attendee should bring back a better question or a useful approach. A speaker tests their experience against an external audience. Someone running a speaking programme needs to create a clear route from an employee’s idea to a credible public contribution.

My subjects changed with my work: data quality and risk, the analyst’s development path, engineering communities, team formation, and moving a banking product to real-time. That archive shows more than public activity. It also records how my professional responsibility changed.

Why attend when recordings will exist?

Test your context. Questions after a talk quickly reveal whether a solution is broadly useful or only works with a particular load, team structure, or corporate constraint.

See current problems. Slides present a prepared story. Hallway conversations are more likely to cover work that has not yet become a polished success case.

Find experience before starting the work. A conversation with someone who has handled a similar integration or organisational change does not replace research. It can, however, give you better questions and reveal easy-to-miss risks.

Test whether your own experience is useful. Repeated questions from different participants are a good signal for an article, an internal review, or another talk.

Choosing an event

I care less about event size than its fit with the problem.

Format	When it helps
Engineering conference	Architecture, performance, operations, technical peers
Analyst conference	Requirements, data, product practice, professional development
Management track	Teams, delivery, organisational change
Meetup	A first talk, a narrow subject, fast feedback
Internal conference	Reusing solutions and connecting teams within one group

The programme matters more than the event brand. If it does not address a problem close to your work, a famous name adds little value.

Before the conference

I choose a few priority talks and write down why each one matters. Not “learn about Kafka,” but, for example, compare event contract practices or understand how a team tested degradation under load.

If I want to speak with a presenter, I prepare one specific question. A short context produces a better answer and respects their time.

For my own talks, I separate the material into context, decision, constraints, and conclusion. Internal metrics and protected-environment details are not required to make the argument credible.

Before buying a ticket, I define the outcome I want. At one event it may be feedback on a specific architecture problem. At another, testing an idea for a future talk. At a third, speaking with several people from an adjacent field. A stated purpose is more useful than counting the number of sessions attended.

When an event requires meaningful time or budget, decide how the result will return to the team: a short internal review, a written note, or a small experiment. A conference becomes a working tool when the new context does not remain with one attendee.

During the event

I do not try to attend every session. After several talks, attention drops and notes become a copy of the programme.

Instead, I record three things:

• what I could test in my own project;
• who might be worth speaking with again;
• which claim I disagree with, and why.

The last point is particularly useful. Different approaches do not require a public confrontation. Clarifying the context is usually enough to see where each one applies.

I treat audience questions as a test of the model, not an examination of the speaker. If I do not know the answer, it is better to state the boundary of my experience and follow up later than fill the silence with a confident guess. A precise “I don’t know” usually builds more trust than improvised certainty.

Repeated questions deserve attention as well. If several people independently ask about the same constraint, either the talk does not explain it clearly or the issue genuinely matters across the industry. The first calls for an edit; the second may justify a new subject.

After the event

A contact loses value quickly without follow-up. I send a short message that recalls the subject, shares the promised material, or asks the next question.

Ideas need the same discipline. Choose one small experiment rather than bringing the team a list of twenty new practices. One tested change is more useful than an inspiring collection of links.

If you want to speak

An internal talk or a meetup is a good place to start. It lets you test the structure and see which questions the audience actually asks.

A strong proposal is specific about the problem, context, decision, constraints, and what the audience can apply. “We introduced a technology and things improved” rarely gives a programme committee enough substance.

I build a proposal around a decision rather than a technology. “Apache Flink in a bank” names a field. “Which constraints appeared when a batch scenario moved to event processing, and how the team changed the architecture” promises a useful examination.

Selection is the start of the demanding work. The material needs to lose anything that does not support the central idea. Terminology needs checking, transitions need rehearsal, and uncomfortable questions deserve advance discussion. Internal review works best across roles: an engineer checks technical accuracy, an analyst checks the continuity of the context, and a manager tests the leadership conclusion.

A joint talk also needs explicit ownership. The audience should not have to infer why one speaker covers the business problem and another suddenly shows code. Agree which part of the story each person holds and where the handovers happen.

Developing speakers inside a community

In a community of thousands, posting “who wants to speak at a conference?” is not enough. Many people have relevant experience but no finished subject or confidence that an external audience will care.

A useful process resembles an editorial workflow:

1. collect ideas and identify which ones have a case that can be examined;
2. help the author state the value for the audience;
3. review the proposal internally;
4. run several rehearsals with specific feedback;
5. preserve the material for colleagues after the event.

The programme lead should not write the talk on someone’s behalf. The role is to provide a structure, a safe first audience, and access to colleagues who can verify the facts.

Public boundaries need their own step. A talk must not disclose sensitive measurements, customer data, or the design of protected infrastructure. Removing a company or product name may be insufficient if the remaining detail identifies the environment. Content therefore needs technical and, where required, corporate review.

After the event, the recording, slides, and answers can become internal learning material. The preparation then works twice: for the speaker’s professional reputation and for knowledge sharing inside the company.

A conference does not build a career automatically. It creates an environment where experience becomes visible and can be tested in conversation. The rest depends on the quality of the work and the effort to maintain professional relationships afterwards.

My current topics and talks are listed on the Speaking page.

---

Original Russian article: “IT Conferences for Analysts” on Habr. The LAF description is based on the official Summer Analyst Festival website.

Yours, DPUPP