A Tech Lead’s New Project Checklist

What’s the budget and the value proposition? should be #1. Projects without a clear purpose (happens way more than you might think) are sinking ships you've got to get away from.

My primary requirement is a demonstration that the site can be torn down and recovered any time – you never know when you will have a DNS problem or someone take over your domain

I would add "Make sure every stakeholder has the same idea what the project will be". I have seen a lot of projects where once you talk to all stakeholders it becomes pretty clear that there is no shared understanding of what we are trying to achieve. Especially be wary of senior managers injecting their pet ideas.

"Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead"

I'm only familiar with teams too small to have separate roles like this. How does good software planning scale down to smaller teams -- say 5 or 10 people in the whole organization? Ultimately someone has to be responsible for the same concerns, but I wonder how it maps.

In general I'd love to see a comparison of software teams at different sizes. What are the key, identified roles in a company of 5, 50, or 500? What are habits that smaller organizations ought to borrow from larger ones?

I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner.

We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly.

We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers.

It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on.

Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.