A while back I posted about ways to structure teams that will get the most appropriate input into your product development inside the smallest possible communication loop. My argument was essentially for organizing by product or service - deconstructing your domain to the smallest units of functionality that can be owned end-to-end by a multidisciplinary team of 5-10 engineers. I haven't yet come across a webscale system that this can't be done with.
Of course there are benefits to organizing by skill (java team, DBA team, QA team etc) such as ensuring consistency in how tasks are performed and creating a sense of community among engineers in similar roles. Grouping people by the role they perform tends to make you really good at executing those particular skillsets. Grouping by the product or service you take to market tends to make you really good at the subset of those skillsets that make the most difference to your product - what particular part of system administration is most critical to keeping a trading exchange online? What particular part of testing finds the most critical issues in a deposit and withdrawal service?
Like most things one isn't the 'right' answer; it's really two different sets of benefits and you need to ask yourself which are more valuable to your company.
If you use off-the-shelf commodity systems to support traditional business processes then you're probably better off organizing by trade - chances are you'll get the most competitive advantage by keeping JD Edwards online, making sure your file servers don't run out of disk space and your CRM system is always up. If you're are a technology-led company then you really should consider organizing by product or service. You'll still always have the business of running the business (you'll need some corporate systems) but chances are you will create the most competitive advantage by being the best at those particular engineering tasks that are specific to your product.
No comments:
Post a Comment