How should we estimate the number of engineers our org needs?

1. Analyze the current workload: Take a look at the current workload, the number of projects and tasks, and the complexity and duration of each project or task. This will give you an idea of the resources needed to complete the projects.
2. Evaluate the capacity and capability of current engineers: Evaluate the technical skills, experience, and capacity of the current engineers. This will help you determine if you need to hire additional engineers to meet the workload.
3. Identify the skills and experience needed for the projects: Analyze the specific skills and experience needed for the projects. This will help you determine the exact number of engineers and their skills and experience that you need to hire.
4. Consider future projects and workloads: Consider any new projects and workloads that are expected in the near future. This will help you plan ahead and make sure you have the right number of engineers to meet future demands.
5. Track and measure progress: Track and measure the progress of each engineer and the overall progress of the projects to ensure that you are meeting your goals. This will help you adjust the number of engineers needed if needed.

The organization process of strategic planning has elements that plan the revenue and establishes the business goals. We allocate an appropriate budget for delivering on the roadmaps. Based on the roadmap of the features, the engineering headcount meets the designed organization. External benchmarking helps to ensure the right-sizing and down-to-earth estimates.

I'm using "engineer" below to refer to software developers and DevOps folks:

First:  Decompose complex current and scheduled projects for the year into smaller pieces (use a Work Breakdown Structure or your own method) so that you can be much more precise in estimation -- at the small "chunk" level

Second: Determine the mix for the team, what specialists are needed, etc.

Third:  Use software engineering techniques as well as your own baselines from previous projects to help estimation of current and scheduled projects for the year - LoC (Lines of Code), complexity based on project/programming language/mix of different code/etc, errors per LoC, etc).  Add in engineering time for design/plan/rework/testing done by engineers/etc.

I haven't seen any data on the number of engineers needed should change based on the software development methodology(ies) used (Waterfall vs Agile vs DevOps, etc) or tech stack but I suspect there is also data available on this.

0 - If there is no work and no customers
10's to 10k if there is a strong roadmap, good customer base to ensure they are supported.

In simple words, engineers are needed to solve a problem, the number of engineers are dependent of the scale and size of the problem

It is subjective with respect to what business you operate in and what are your organizational goals.  Different org will have different IT needs, I would approach it by creating an org structure which accounts for areas like enterprise architecture, network administration, tech support, dev ops, cyber security and innovations & product. Create a smaller structure in each area which includes specialist, managers and developers and a team lead, outline specific roles and responsibilities and keep some space for new development and back-up and finalize the requirement. This can solve the problem with 70-75% accuracy.