Splitting engineering teams into defense and offense

I’m Daksh - one of the co-founders of Greptile. We build AI that understands large codebases, which you can query via an API. Large software teams use it for things like AI-powered code reviews and diagnosing root causes for outages.

We are a team of 4 engineers. Our customers are often surprised to learn this, since they assume we must be much larger given the breadth of our product. While this is flattering, the truth is that our product is covered in warts, and our “lean” team is more a product of our inability to identify and hire great engineers, rather than an insistence on superhuman efficiency.

The result is that our product breaks more often than we’d like. The core functionality may remain largely intact but the periphery is often buggy, something we expect will improve only as our engineering headcount catches up to our product scope. Nevertheless, the reason we get anything done at all in these circumstances has to do with a specific way in which we structure our engineering team.

15 years ago, Paul Graham wrote about the “maker vs. the manager schedule”, the idea that makers, such as software developers, were different from managers in that they needed long, uninterrupted hours to build great things. This essay resonated with engineers around the world who had been trying to squeeze their work in between endless mandatory meetings, and probably led to some sweeping changes at least at software-driven companies in favor of creating a “maker-schedule” for engineers.

Leave a Comment