This is one of the best playbooks I have read about Engineering Management.
Thank you Yishan Wong (ex-facebook director engineering). It covers all aspects of operational product engineering. i.e. Recruiting engineers, technical leaders.
He also gives uncommon wisdom on encouraging talent, process and tools implementation and a healthy technology company.
A lot of these principles are also applicable to outsourced product development (OPD) vendors.
Being a good product development team is all about good execution. Sure, you need the necessary vision, the technical prowess, design, creativity and managerial skills. Apart from the necessary technical skills, a good product team needs ability to remain calm and composed in the face of challenges. One of the least discussed traits of a successful product team is ‘Composure’. How one responds to key pressure points will decide how your product turns out to be. Well managed, good product teams respond to pressures with cool head, prioritize correctly.
The product team has to make sound decisions everyday, have to prioritize, identify the most important features for a release and deliver high quality product release as per plan. In this context, A good leader makes a BIG difference. He/she plays a key role in helping the team by maintaining ‘positive’ pressure – the pressure to get things done. Getting it done with excellent quality, with consistent focus. The leader insulates team from unwanted distractions, de-prioritizes least important features. He/she negotiates with product management by keeping a tab on the situation.
In the long run, better products are built by teams that execute well with composure which in turn makes it easy for all stakeholders to deliver ‘customer delight’.
Follow up to his earlier post about Greatest Enemy of a Programmer, Jeff talks about how programmers can avoid getting stuck. Observing how good programmers work, I agree with him about traits of a great programmer –
The master programmer performs an O(logn) algorithm at worst. At worst, each experiment invalidates half of the possible causes. Some experiments, thoughtfully chosen, eliminate a much larger swath. Therefore even if there are millions of possible causes for the bug—millions of lines of code—the tests must ultimately converge somewhere. And they will do so in a relatively small number of steps.
