Technical Management Consulting Insights: Team Value, Innovation, and R&D Efficiency

Recently I was invited to provide technical management consulting and R&D efficiency improvement for a media‑technology company, and after learning the technical leader's environment I was reminded of my own situation three years ago.

The team consists of about 80 people, led by a technically strong leader from a top‑tier company, yet the team holds low status despite high salaries, feels over‑worked, and the boss is dissatisfied, believing R&D slows business growth.

The team wrestles with three core dilemmas: can iteration speed be faster, what value do engineering or refactoring projects bring, and how can the tech department help the company reduce costs and increase efficiency.

The boss wonders what the team does daily, while the business sees the team as incomprehensible; the product team blames tech for poor outcomes, yet the product team is the most friendly because they bear the blame for product failures.

A key insight is the differing mindsets: business adds features to capture opportunities, then subtracts during implementation focusing on time and cost, whereas engineers first consider feasibility and technical elegance, often missing the business perspective.

To judge the tech team's value, the article argues that the team should be evaluated on how much money it can save or generate for the company, distinguishing labor‑intensive code‑writing work (low‑budget, high‑efficiency) from higher‑value activities.

It proposes a simple cost‑calculation method: inventory all systems and modules, estimate the ideal personnel and experience needed for each, apply a 20% premium, and sum to obtain a target budget, adjusting for management overhead as the team grows.

For innovation, the article suggests allocating about 20% of resources to R&D, then following four steps: collect long‑term innovation clues, brainstorm topics, open a bidding process for solutions, and validate the chosen solution, iterating if expectations are not met.

The recommended innovation team structure includes a clue‑collection group, a topic‑selection team led by a manager, and a solution‑implementation team of mid‑level staff.

Additional practical “methods” for technical leaders are listed, such as “overtime tactics” when iteration speed is demanded, “requirement‑cutting” to focus on MVP, “concentrating resources” to prioritize high‑value work, and cautionary notes on sacrificing quality.

The article concludes with a brief promotion of a DevOps engineer certification course covering organization, product design, development, testing, and operations, encouraging readers to enroll in the upcoming class.