# How I develop engineers Source: https://manaienko.com/how-i-work/developing-engineers/ Author: Artem Manaienko 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 1. [01 Look at scope and autonomy](#practice-developing-engineers-principle-1) 2. [02 Understand the motivation](#practice-developing-engineers-principle-2) 3. [03 Increase scope as judgment improves](#practice-developing-engineers-principle-3) 4. [04 Make the next step explicit](#practice-developing-engineers-principle-4) 5. [05 Review your own changes first](#practice-developing-engineers-principle-5) 6. [06 Bring options and a specific question](#practice-developing-engineers-principle-6) 7. [07 Talk directly to the other team](#practice-developing-engineers-principle-7) 8. [08 Keep primary ownership clear](#practice-developing-engineers-principle-8) ### 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. What I did not record well enough I could see the progress in delivery, reviews and how much help each person needed. But I did not keep a written record of those changes. These are my observations, not formal promotion results. Next time I would keep that record with each engineer.