(Image generated using ChatGPT)

A playbook born from years of onshore - offshore engineering battles.

Recently I have been involved in taking interviews for a Delivery Leader role. In these interviews I ask the candidates - "What all you need to do to get a new team started on a new project?". Candidate's response - "I would ensure that we have detailed requirements, identify stakeholders, identify scope, plan the milestones, identify the risks, and have high level technical design."

Now, began the painful process of back and forth to get the candidate to talk about what about the tooling, what about the communications, what about the processes, what about the testing, what about the meetings, what about the reporting, and on and on.

In my 25+ years of experience in software industry, I have taken so many interviews of engineering leaders for the position of Delivery Manager, Engineering Manager, and Technical Leaders. In all these interviews I ask them about how to start a new project and there are variations of these questions like -

• How do you start a new project?
• How do you enable a new team to get started on a new project?
• How do you enable a new team to produce code?
• How do you enable a new team to become productive?

I have been surprised to see that in most cases Engineering Leaders can't get to the basics of how to start a new project. Most of them invariably end up just talking about project requirements making me wonder if they have really started a new project in their career or do they even take time to think about what all is needed to start a new project. They simply assume that most things just fall in place on its own and they only need to think about requirements.

So, I thought let me put down a list of things that I expect our Engineering Leaders to share when they are asked this question. Idea here is not to list down an exhaustive all encompassing list of things that are to be done to start a new project, rather a simple basic list that all Engineering Leaders should be aware of.

Identify client stakeholder

• Business / Product owner
• Technical Decision makers
• QA / Compliance owners
• DevOps / Infra approvers
• UI / UX owners
• Who approves requirements
• Who signs off releases

Requirements

• Problem Statement
• User personas
• High level requirements (Epics / Features)

Architecture

• Tech Stack Finalization
• High Level Architecture Diagram
• Integration landscape

Project management setup

• Setup Jira or Azure DevOps Boards
• Define - Epics, Features & Stories
• Establish Sprint Duration
• Establish Backlog Grooming
• Establish Definition of Readiness
• Establish Story Point Estimation Scale
• Establish Definition of Done
• Create shared Documentation Space - Confluence
• Miro Board or Lucid Charts - for Diagrams

Communication channels & agile ceremonies

• Slack or Teams
• Email groups or distribution lists
• Daily Stand-ups
• Sprint Planning
• Sprint Demos or Review
• Sprint Closure Meetings
• Sprint Retro
• Risk & Dependency Review

Engineering tools & environment setup

• IDE - Visual Studio Code or IntelliJ
• Version Control - GitHub or Bitbucket
• Local Dev environment setup instructions
• Establish branching strategy
• Setup continuous integration
• Integrate SonarQube for code quality checks
• qTest or something else for TestCase management
• Jira or something else for Defect management
• Establish environment for - Dev, QA, UAT, performance, and production

Access & Security

• Access to team on various tools
• Access to team on appropriate environments
• How will you manage secrets

Governance & Metrics

• Sprint closure reports
• Velocity tracking
• Commitment predictability tracking
• Defect density tracking
• Unit test coverage tracking
• Risk logs
• Weekly client sync
• Monthly status review
• Monthly architecture group forum

Conclusion: A team becomes productive when friction is removed

Starting a new software project or setting up a new team is all about setting the stage so that the team can perform.

Just like a great symphony doesn’t begin without tuning instruments, testing microphones, aligning chairs, and syncing the conductor’s cues—engineering excellence also begins with preparation.

When leaders get the setup right, teams flourish. When they get it wrong, teams struggle—no matter how talented the engineers are.

In software services, especially across offshore/onshore models, this preparation is the difference between a shaky start and a strong one.