# How I develop engineers Source: https://manaienko.com/how-i-work/developing-engineers/ Author: Artem Manaienko 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 1. [01 Growth is scope and autonomy, not a title](#practice-developing-engineers-principle-1) 2. [02 Find the motivation](#practice-developing-engineers-principle-2) 3. [03 Same ladder, different rung](#practice-developing-engineers-principle-3) 4. [04 Say the rule out loud](#practice-developing-engineers-principle-4) 5. [05 Review your own diff first](#practice-developing-engineers-principle-5) 6. [06 Come with two candidate implementations](#practice-developing-engineers-principle-6) 7. [07 Skip the middleman](#practice-developing-engineers-principle-7) 8. [08 Rotation is a tool, primary ownership is not](#practice-developing-engineers-principle-8) ### 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. What I would do differently I have delivery, review quality, and how much of each person's work still needed me. I do not have a review system's record of any of it, because there was none, and I did not keep a written log of scope and autonomy milestones per engineer either. That log is what I would start on day one.