Last Tech Tuesday, I wrote about growing your engineering organization and the week before that about evolving your technology. Today here are three more best practices for successful engineering growth:
APIs - I will have a lot more to say about how APIs relate to strategy in a separate post, but they are also a key internal tool as you grow even if not exposed to third parties. Having clearly defined APIs is what lets different parts of the engineering organization work with different technologies and at different rates of progress. To make that work even when used only internally the same key rules apply to the evolution of an API: make sure your API is well documented (eg using Apiary) and don’t break existing calls as you make changes.
Loose Coupling - sometimes people think just because they have defined services internally and use APIs they have achieved loose coupling, but the two are not the same. I have written a whole blog post before where I called loose coupling a board level issue. The key idea here is that parts of your system should be able to slow down or even fail without causing failure of everything. If all your API calls are synchronous then you don’t have loose coupling. As you grow, loose coupling becomes more and more important because you may encounter bottlenecks that you have not anticipated.
Engineering Metrics - having some measure of the throughput of your engineering organization is critical. One system that seems to work well is to assign some point measure to each ticket and make sure to break work items down small enough so that you only have say one, two and three point items (anything that would be more points will have to be broken down into subtasks). You then measure how many points are being achieved each development cycle. Cycle time should be short, ideally one week but no more than two. This will give you rapid feedback on how many points you are covering per cycle. You can keep track of it by team for additional granularity and in particular see how it changes as you grow the number of engineers.
If you have your own best practices that you believe are essential to growing engineering please let me know. I am thinking of compiling a list potentially at a separate web site.
