Leadership Program | 1-on-1 Meetups

As you may know, I work at TBC x Payme as a Frontend Engineer. Recently, my responsibilities have expanded to include making team decisions, such as participating in project planning stages, hiring new developers for my team, and managing small teams within my business vertical. To support leaders in these roles, the company's Learning & Development (L&D) department offers a Leadership Program. I was fortunate to be invited to join this program, where we have monthly sessions on various topics aimed at enhancing leadership skills.

This blog post focuses on the key takeaways from our second session, which was dedicated to organizing effective 1-on-1 meetings.

What Are 1-on-1 Sessions?
A 1-on-1 session is a dedicated meeting between a manager and a team member to discuss professional goals, challenges, feedback, and growth opportunities. These meetings are critical for building trust, fostering open communication, and aligning expectations within a team.

Key Takeaways from the Session
- Allow employees to schedule meetings themselves.
Initially, I thought only managers could initiate 1-on-1s. However, we discussed how empowering team members to schedule these meetings creates a more collaborative dynamic and builds trust.

- Hold initial 1-on-1s in informal settings.
Meeting in a casual environment helps people feel at ease, especially junior colleagues. This could be over coffee, during a walk, or touching grass together

- Announce meetings with context and inform the team.
One of my earlier mistakes was not providing enough notice about 1-on-1s. Letting everyone know about upcoming meetings and sharing topics for discussion helps prepare the participants and fosters transparency.

- Document agreements and follow up.
For 1-on-1s to be productive, they should result in actionable agreements. After the meeting, document what was discussed and agreed upon so you can track progress in subsequent sessions.

Suggested 1-on-1 Structure
Our team collaboratively designed a structure for conducting effective 1-on-1s:

1. Small talk (sincerity) or introduction
2. "What do you want to talk about?"
3. Previous agreements
4. Achievements should include timelines
5. Issues and criticism
6. Solution plan
7. Areas for growth
8. Agreements

The key point is that you shouldn't strictly adhere to this exact structure, as every situation is different. Instead, focus on practicing to become comfortable with transitioning between steps naturally and learning to actively listen.

Also, ask, "Is there anything else you'd like to add?" This gives them the chance to bring up any remaining concerns or ideas.

Questions for Delegating Responsibility
When assigning responsibility or encouraging team members to take ownership, consider asking:

- "How would you assess this situation yourself?"
- "How do you plan to address this?"
- "What steps are you planning to take?"

Do you have one-on-one sessions at your company, how do you feel about them?

TBC x payme Office Tour

Our office tour is live! Check out TBC x Payme Office Tour to see where your everyday-use products come to life

digging into Leetcode lately — thought I'd share this resource in case you need it

https://leetcodetherapy.com/

Trying despite disbelief

I am very good at finding reasons why something will NOT work out, and pessimistically hyper-focusing on them. In my past they were enough to immediately give up on an idea. One thing that my wife taught me is what I call trying despite disbelief.

I think the first time it happened was ~9y ago. The company I worked for made me a H1B work visa and offered $56k/year salary. I took the deal without negotiations and moved to the US. When my wife, girlfriend at the time, heard that my salary is just $56k, she was like "WTF, they low-balled you, go and ask for 20% more". I laughed because nobody gets 20% raises, but she convinced me to TRY. I went to my boss and asked for 20% raise with zero belief that I will get it. The funny thing is, when I try I appear like I know what I am doing, smiling and such, and what do you know, to my surprise I got ~15% increase.

Another time I left my backpack with a laptop in a coffee shop. I called them up and they said they don't see one. Past me would give up, because I got a pretty strong signal that it isn't there. By that time I already had a few experiences where trying helped, so I simply drove there and there it was, on the floor. I don't know how they couldn't notice it.

There were many other examples. Some still required encouragements by my wife and others, like trying for L7, and asking for more money. Another example is me accepting the L7 high-risk high-reward offer -- I'll do my best and hopefully survive. Even publishing this post is an example -- the reason not to post it is that this is possibly bullshit.

---

I am not saying that it will help everyone, but it might certainly help those competent but not confident. Quoting Wikipedia "The Dunning–Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability" (I encourage to read the rest of article). If you believe you belong to the second group, or sometimes you find yourself thinking "if even he/she did it, then I should be able too!", then it might help. Or if you are a woman, because the ever-present patriarchy makes you feel small.

A part of this is accepting a possibility of failure. In fact, I usually go with low expectations and just do my best. If you fail, that's OK. It isn't the end of the world.

Another thing is, you might luck out. An interviewer might not ask you topics that you are weak at (I am weak at parsers). In my Google interview I wasn't prepared for system design. I failed one; the other was quite algorithmic (=easier) and the interviewer was from Android (not working distributed systems themselves), so I got lucky. You cannot get lucky if don't even try 😉.

Like I said, I tend to hyper-focus on reasons why something will NOT work out, in a pessimistic way. While it is discouraging, it also guides me to work on the weakest parts. If you think about chances of success as a confidence interval, then working on the weakest parts maximizes the lower bound. You can see an example of this in my obsessive preparation for the behavioral interview which I never did before and which isn't very technical. This attitude also poses the question "What am I missing?" and you can see an example of this in researching my Microsoft interviewers and discovering new topics to learn. Thinking how a system might fail (failure modes, unhappy cases) is one difference between L4 and L5.

Overall I can say that this simple technique made a big difference in my life. The first step is the hardest.

I recently wrote an article on a topic that often seems simple but can become a real performance challenge: working with lists in web development.

It covers key concepts like virtual scrolling, infinite scroll, and how proper keying can make a difference — with practical examples for both React and Angular.

Would love to hear your thoughts or experiences around this too

https://medium.com/@mansurisakov.dev/working-with-lists-in-web-development-performance-patterns-and-examples-0ccdaaea34d5

Working with WebView looks easy — until you're deep in edge cases, routing issues, and native-web sync problems.

At payme, I dealt with all of that while building avia & tickets. I recently wrote a post breaking it down:
– When WebView makes sense (and when it doesn’t)
– Problems we faced in production
– Communication between native and web
– UX nuances, routing, and lifecycle quirks

Wrote it in two versions:
📎 Habr (RU): https://habr.com/ru/articles/919856/
📎 Medium (EN): https://medium.com/@mansurisakov.dev/from-browser-to-app-the-inner-workings-of-webview-10aea73dcf86

Might save someone a few hours of debugging — or help decide if WebView is even the right call.
Happy to hear your take too.

I intently follow and read posts by Diyorbek. Recently, he released a podcast on Frontend System Design, covering all the important aspects and providing clear, concise insights on each topic.

https://www.youtube.com/live/Pcxs07g-xVU

Interviewing at Bloomberg (Prep Doc)

https://drive.google.com/file/d/1UoL6q5egwXLpinWqivmSPG_YstfGLBur/view?pli=1

recently, I started taking Matt Pocock’s course “Claude Code for Real Engineers”. the idea I liked is that when working with coding agents, engineering fundamentals become even more important. It’s less about writing every line of code yourself, and more about clearly defining the task, guiding the process, and checking the result. I want to start a small series of posts about engineering concepts that I use in my work and life.

the first one is Red-Green-Refactor.

Red-Green-Refactor comes from TDD — Test-Driven Development. It is a simple cycle: first, you write a failing test (Red), then you write the minimum code to make it pass (Green), and after that you improve the code without changing its behavior (Refactor).

what I like about this idea is that it makes you think about the expected behavior before implementation. You first define what the code should do, what cases it should cover, and how you will know that it works. Only after that you start writing the solution.

i found this useful in many cases: at work, in pet projects, and also during interviews. For example, when you have a live coding session, it’s often better to start with test cases. It shows the interviewer that you care about quality and edge cases, and the session goes smoother because you already have a clear picture of the problem in your head. You are not randomly trying to solve something, you are moving step by step: define the behavior, make it work, then improve it.

i think this approach becomes even more important when working with AI coding agents.

the second concept i liked is Tracer Bullets that comes from Progmatic Programmer.

most LLMs tend to code horizontally. they build layer by layer: first models, then services, then UI, and only at the end you see if everything actually works. it can feel productive, but the problem is that feedback comes too late.

tracer bullets push you to do the opposite: build a small vertical slice that goes through the whole flow. not the final version. not the perfect architecture. just one thin path that works end to end.

for example: one screen, one API call, one database operation, one result back on the screen.

what i like about this idea is that planning becomes more grounded. you are not trying to guess everything in advance. you quickly see the real problems: missing requirements, unclear data, wrong assumptions, integration issues.

after that, it is much easier to plan the next steps.

i think this is especially useful when working with AI coding agents. instead of asking an agent to build a big feature at once, i prefer to start with a tracer bullet first.

small working flow → feedback → improve.

it keeps the agent on track, and keeps me in control of the direction.

here is do-work skill example by Matt:
https://github.com/ai-hero-dev/cohort-003-project/blob/live-run-through/.claude/skills/do-work/SKILL.md