I think it can be summed up as &quot;code less&quot;.<p>I want to stress that this is much more easily said than done.<p>- A lot of programmers gain immense satisfaction from writing nice code, and getting into &quot;flow&quot;. There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product&#x2F;module&#x2F;apis rather than how elegant your code or apis are, then you are heading in the right direction.<p>An earlier comment on this page sums up the goal:<p>&gt; Your satisfaction changes from being happy that you&#x27;ve polished some nice bit of code to being happy that you&#x27;ve shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it&#x27;s own reward.<p>- You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline.<p>- Coding less allows more time for you to ask your team what they need, think about what they need but don&#x27;t realize, and get that for them.<p>- Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension.<p>- Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have.<p>- Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. &quot;What did everyone learn this week&#x2F;sprint? What could you do better?&quot;. As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.