Engineering Focused on Delivering Business Value

In my previous post, I questioned whether companies would continue to support open-source software in a climate of economic uncertainty and layoffs. I’m going to be a bit more controversial and suggest that smart companies will start taking a closer look at what kind of work they’re funding for internal-only use, too.

Once a software engineering organzation reaches a certain critical mass of developers, it might be beneficial to start creating a “developer experience” team and/or various “platform teams”. The idea is that these teams deliver tools and processes that empower other engineers who work on “business-critical” or “user-facing” functionality to do their jobs faster and with higher quality. And indeed when well-executed in an appropriately-sized (read: really large) company, these teams can serve that role. They can also turn into massive sources of waste if not properly directed.

To take a strawman example, how many platform engineers think they can build a better logging library, see it adopted by the entire company, and achieve glory (and “impact” for promotion)? Based on the number of times I’ve seen people take a crack at it over the years, I’d empirically say that number is high.

There are many less obvious examples of engineering work that probably doesn’t need to be reimplemented in-house. How about workflow automation? Deployment systems? User interface libraries? (That’s a big one!) Just download these things and move on!

Rebuilding fundamental libraries from scratch where viable third-party alternatives exist might have been acceptable in the old economic climate. But today, those are more often than not vanity projects and doing them on company time is not a productive use of engineering resources.

Want to discuss development projects that might or might not meet the business value bar? Reach out!