Artem Manaienko

How I develop engineers

Growth is scope absorbed. For about four years I had no titles to give at all, so I hand out ambiguity on purpose and make ownership the thing you earn.

My principles

08 operating rules

Growth is scope and autonomy, not a title

For about four years the engineers in my team were contractors, with no promotion path and no title to hand out at the end of a good year, so growth had to be observable or it did not exist. What I watch is how much ambiguity a person takes on and how much of their delivery still needs my review to be safe. Depth into one domain counts as much as breadth across several.

Find the motivation

Every engineer optimises for something. Money, harder problems, recognition, a day that ends on time. Usually more than one. Find it, and build their growth path around it.

Same ladder, different rung

Bounded ownership first, a real piece of work with a clear edge. Then more ambiguity and more options to choose between. Then direct contact with the teams that consume the work. Scope goes up when judgment has become visible, and not before.

Say the rule out loud

Each person heard what the next rung was and what would move them onto it. A rule is only fair if the person being measured by it knows what it is, and saying it out loud is what turns a growth path into something an engineer can act on.

Review your own diff first

Read your own change as if a stranger wrote it and you have to maintain it. An engineer who cannot criticise their own code will not absorb criticism of it either.

Come with two candidate implementations

"I'm stuck" hands the problem back to me. Two implementations plus the question that separates them is something I can actually answer, and answering that is what builds the judgment.

Skip the middleman

Need something from another team? Talk to them directly, no PM and no me in between. Every hop between you and the answer costs you time and them context.

Rotation is a tool, primary ownership is not

Rotating people through systems to keep the work interesting is how a team loses the context it was supposed to be accumulating. I rotate deliberately and sparingly. Primary ownership of a system stays with one person, and stays explicit.

The ladder scope moves along

  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.

Where a person starts on the ladder differs. The ladder does not, and a rung is earned by judgment becoming visible rather than by time served.

What that looked like

03 cases

  • Raised the ceiling one task at a time

    Case
    Joined at low-middle level. Weak on requirements, code style and review quality, but a real problem-solver who wanted it.
    My decision
    Raise the difficulty one step at a time. Self-review before my review. Platform questions go to a principal engineer, accountability for the answer stays here.
    Result
    About four years later, complex third-party SDK integrations end to end. Senior by observed capability, not by title.

  • Built the role around the one real strength

    Case
    An inconsistent generalist who wanted to get better. Broad seniority was not the way there.
    My decision
    Build the role around accessibility, where they were genuinely strong. Two conditions: candidate approaches before any request for help, and a reviewed AI-assisted workflow for component integration.
    Result
    Became the person accessibility work was routed to. Integration output improved measurably.

  • Moved someone from tasks to ambiguity

    Case
    Executed well when the task was spelled out. Uncomfortable owning it when it was not.
    My decision
    Stop handing out tasks. Treat the system as a product they would still be maintaining a year later, and hand over the product and technical trade-offs to decide.
    Result
    Took unclear problems from framing through delivery. Became the most AI-fluent engineer on the team.