Status: LIVE

EL: Engineering Lead

"My project has the perfect technical setup given the problem we are solving, that correctly balances product requirements, development effort, maintainability, security, elegance, interestingness and learning opportunities. Also, I keep the PM in reality-land."

• If the AL is responsible for setting "what" we build and "when". Then it's up to you to define "how" we build things. You are not a dictator and you need to seek consensus with the Engineers, but you are the one who is ultimately responsible for driving the discussion and pushing for decisions. And ensuring that they are adhered to.

• Ensure that the appropriate technical architecture has been chosen for the requirements.

• Be available as a quick sanity check for the AL's rough plans.

• Take part in customer facing meetings. Maybe not always, but usually.

• Ensure that tasks are distributed among the Squad appropriately. Match task difficulty with Engineer seniority. Strike a balance between efficiency and learning opportunities.

• Ensure that each project follows a single code style.

• Balance product requirements with creating learning opportunities for the Squad.

• Ensure that the 9Y Software Engineering Manifesto is followed on the project, such as code reviews, time for testing, mentoring, etc.

• Inform the Squad about underlying implicit requirements. Are we writing automated tests? Do we need to be PCI or HIPAA compliant? Do we need to worry about preventing reverse engineering? Any strict security requirements? And so on.

• Push back on the AL if their pace setting is too tight to allow the Squad to do quality work. Ensure that the AL bakes in enough time into the plan to allow for proper engineering practices.

• Look for opportunities to extract generic code into libraries that can be used in future projects.

• Ensure that we are effectively leveraging public and internal libraries.

• Try to standardise on things where it makes sense. Talk strategies for this with the CTO in your 1::1s.

• Ensure that project dependencies are kept up to date.

• Resist the urge to add too many dependencies.

• Resist NIH (not invented here syndrome).

• Resist YAGNI (you ain't gonna need it).

• Resist the lure of over engineering. Don't make academic solutions. Sometimes you really need a websocket, other times polling is just fine. Make sure that the Squad knows the difference.

• Ensure that performance of the project is satisfactory.

• Ensure that security implications of the project are considered.

• Ensure that we are maintaining an appropriate level of documentation. And this documentation is up to date. If you don't think that we can keep documentation up to date, then don't have any – out of date docs are worse than no docs.