Artem Manaienko

How I develop engineers

At Teladoc I had no promotions to offer my contractor team. I measured growth through the scope people could own, the ambiguity they could handle and how independently they could deliver.

My principles

08 operating rules

Look at scope and autonomy

For about four years, my engineers at Teladoc had no formal promotion path. I looked at the ambiguity they could handle and how much review their work still needed. Going deeper in one domain counted as much as working across several.

Understand the motivation

Money, harder problems, recognition, a working day that ends on time. Often more than one. I shape the growth path around what matters to the person.

Increase scope as judgment improves

Start with bounded work, then add ambiguity, end-to-end responsibility and direct stakeholder contact. I expand responsibility when the person shows they can handle the decisions it brings.

Make the next step explicit

Each engineer needs to know what they can take on next and what they need to demonstrate first. I explain those expectations so they have something concrete to work towards.

Review your own changes first

I ask engineers to read their own code as if someone else wrote it. Find the problems and explain the choices before asking another person to review it.

Bring options and a specific question

When someone is stuck, I ask for two possible implementations and the question that separates them. We work through the choice together while they keep ownership of the problem.

Talk directly to the other team

Engineers can work through questions directly with the teams that need their work, without a PM or me carrying the conversation. Principal and senior engineers can advise on technical choices without taking over ownership.

Keep primary ownership clear

I rotate work deliberately and sparingly. Moving people around just to keep things interesting loses system context. Each system keeps an explicit primary owner.

How responsibility grows

  1. 01

    Bounded task

    A real piece of work with a clear edge, and the difficulty raised one step at a time. Self-review before my review.

  2. 02

    Ambiguity

    The problem stops arriving as a task. The engineer frames it before anyone hands them one.

  3. 03

    End-to-end delivery

    The whole change from framing through release, rather than the slice of it that fits in a ticket.

  4. 04

    Direct stakeholder contact

    Talk to the team that consumes the work directly. No PM and no me standing between the question and the answer.

  5. 05

    Framing the technical options

    Two candidate implementations and the question that separates them, instead of an open request for help.

  6. 06

    Product and platform trade-offs

    Treat the system as a product they will still be maintaining a year later, and own the trade-offs that come with it.

People start at different points. I increase scope when their decisions show they are ready.

Three people, different kinds of progress

03 cases

  • Taking on harder Android work

    Case
    An Android engineer joined with limited independence. Requirements, teamwork, code style and review quality needed work, but he wanted to improve and was good at solving problems.
    My decision
    I started with smaller tasks and increased the difficulty gradually. We worked on self-review, explaining uncertainty and discussing options with the principal engineer. Responsibility for the answer stayed with him.
    Result
    After about four years, he could handle complex third-party SDK integrations end to end. I could trust him to clarify the problem and deliver the work. That was senior-level capability, even though his title had not changed.

  • Finding a strength in accessibility

    Case
    An iOS engineer wanted to improve but struggled to deliver consistently across different kinds of work. Accessibility was a clear strength.
    My decision
    I helped him build on that strength. He reviewed his own code, brought possible solutions before asking for help and consulted senior engineers. For component integration, we used a structured AI workspace with human review.
    Result
    He became someone the team could turn to for accessibility problems and improved his component delivery. His progress was more focused than the others, and still valuable to the team.

  • Working without a ready-made task

    Case
    Another engineer delivered well with clear instructions, but wanted the task spelled out before starting.
    My decision
    I gave him more responsibility for deciding what to build and how. We talked about the system as a product he would keep maintaining, including product trade-offs and the maintenance debt his choices could create.
    Result
    He grew into taking unclear work from the first questions through delivery. He also became strong at using AI in that work. I no longer had to turn every problem into a detailed task for him.