I’ve been at a few software organizations navigating the transition from small company to established businesses with big customers. At that point, duplication starts to become a cost, and consistency and stability in the product becomes more important than earlier in the business cycle. This is when everything starts getting “platformized” and standardized: application platforms, app development frameworks, managed job queues, data pipelines. These all have the chance to be transformative for your company from a dev experience and cost control perspective. They also routinely get mired in endless migration timelines, and never being “ready enough” for big systems to transition to the platforms.

A phrase I’ve been using as a mantra when approaching platform projects and questions is “think big, build small”. Thinking big means finding leverage outside of your team Keeping that “build small” focus encourages incremental delivery, adding capabilities one-at-a-time, in order of usefulness.

Thinking big

  • If you’re building for your team, ask the question “could we build for the department”? If you’re building for the department, ask “could we build for the company?” Play out those scenarios to identify opportunities, even if you choose not to tackle them.
  • You don’t need a “platform team” to think big like this. If you find an opportunity you may end up with one, but finding these opportunities is a mark of solid and ambitious engineers, and a skill you should cultivate.
  • Treat any platform as an internal product. Mandated adoption - at least early on - is not likely to succeed. If people don’t want it, you’re not helping the company. Finding out why they don’t want it and address that. Or abandon the platform! Honorable retreat is a reasonable response to failure.

Build small:

  • Start with two customers, preferably within your target customer profile but fairly different from one another. One customer is too specific, and you won’t build generally enough. Three or four customers are going to have sufficiently different needs that you’re going to spend too much time building before you’re getting real usage. Teams building new systems are great candidates early on, because you can nail some features before you invest in migration tooling.
  • Continue to prioritize active customers over theoretic ones. Don’t build for someone you hope will use the tool in 2 years.
  • Assess often. A two-year roadmap may or may not be reasonable, but if you’re unable to make progress in 6-month intervals you’re biting off chunks that are too large. If active users and early customers are waiting two quarters after the start of work, it’s time to take a hard look at the project.
  • Accept that “the big complex team” may never adopt a given platform. As long as the costs of that are internalized to the team rather than externalized to the company, that’s actually fine. It’s an Engineering trade-off, and custom deployments are often necessary somewhere.