Don’t Take Anything for Granted.

One of the good things that I learned early in management of engineering functions is this: never force a ready-made template that worked elsewhere onto a new team or function.

Yes, we should start from principles, but not from fixed practices.

Each company, product, priority, and team—along with the team’s skills and purpose—differs.

If all these vary, how can the same rule suit every company?

No single process fits every engineering team—whether Kanban, Scrum, waterfall, one-week sprints, two-week sprints, or project milestones.

We learned to walk by falling many times. Bottom-Up, Never Top-Down.

The soundest principle I found to work every time is to start small. Plan for the short term first, a 1 week amount of work, then proceed.

This rule is constant: start small, start local.

From there, change in cycles: spot a problem, propose a solution, implement, review, and begin a new cycle (call it a sprint, week, or epic—it must end so you can reassess).

This is bottom-up action. In each cycle the team discovers what works. Not the EM, the director, or the CTO, but the team itself. It adapts locally and iterates.

Thus everyone helps decide what each next cycle should be, which practices to adopt, and which to discard.

With enough cycles, teams discover the few processes that matter. Control only the essential variables; ignore the rest.

Keep policies to a minimum. Too many feel robotic and dictatorial. Preserve an open-market style of work.

Start small. And keep an open mind with min # of policies.

Hire mediocre people and you need to force a way. The principles above won’t hold.

Hire great people and let them find their way. The principles above hold.