Software Engineers Leading Projects: Part Two
Practical approaches for engineers to run projects from the kickoff to wrapping them up.
Q: What are practical approaches to run engineering projects within Big Tech or high-growth startups?
This is a question I first had back in 2016. When I joined Uber, we shipped almost all work via short, 2-12 week projects completed by small teams, led by engineers or engineering managers. In order to get better at project management, we hired an external training company to provide project management training.
This training was a disaster. It was completely disconnected from our high-paced work. The contents were so out of sync for what we needed that we canceled it midway.
This issue covers the ‘practical’ aspects of leading projects I wish that training could have delivered, back then. All of this is specific to software engineering teams in companies that have decent engineering cultures. It’s all directly applicable to Big Tech, and many of the suggestions apply to getting engineering work done within most tech companies.
Kickoffs and milestones: why they are important, and what good kickoffs look like.
Stakeholders how to work with them, especially the problematic ones.
The “law of software project physics”: how people, scope and timeline are connected.
Day-to-day project management: practices worth using.
Risks and dependencies: spotting and mitigating them.
Wrapping up projects properly.
Leading several projects: managing workload once you’re an accomplished project leader.
This issue is the second and final part of a mini-series about software engineers leading projects. In part one, I covered why and when engineers at all levels can and should lead projects, with advice on how to prepare for driving these.