As part of their ten year birthday celebration They’ve earmarked $10,000,000 to fund up to five projects with the potential to have a positive impact on the world in areas such as alternative energy, public health, or housing.  The cool thing is that anyone can submit an idea through the project web site. The massive pool of submissions will first be weeded out by what I’m sure is a ridiculously smart panel of Googlers, and the top twenty will be put to vote by the public sometime early next year. 

What a brilliantly simple example of crowdsourcing for the greater good. Seriously heavy stuff.

And if anyone can make it happen, Google can. They’ve got money comin’ out the search box. What is $10,000,000 dollars to them? A day’s worth of ad revenue? A week’s budget for Naked Juice?  An open bar at a holiday party? Which is not to say I don’t think this is awesome. I admire their optimism and mandate, and if other companies had this strong a sense of social responsibility, I think that we’d all have a lot less problems that need solving in the first place.

Submit your world-changing idea by October 20th!

I’ve been thinking a lot lately about the the effects that the organizational structure of a company can have on the work done  there. I don’t have a background in either business or management; my background is technical, and this is thus the primary lens through which I tend to filter things and around which I form mental models of the world. It’s not always accurate or appropriate, because the world works in a very different ways than a computer does. But good design is good design, and as evidenced by such influential work as Don Norman’s book “The Design of Everyday Things,”  Christoper Alexander’s notion of a design pattern, or Janine M. Benyus exploration of a phenomenon known as biomimicry, sometimes, borrowing ideas from a different domain can be an surprisingly fruitful exercise.  

In answer to the question posed above, there are several principles which I think can be applied to the design both software architecture as well as the structure of a company: 

A well organized company, like well architected software, is divided up into a modular set of functional components,

Modularization is perhaps the most important characteristic a corporation or piece of software can have. Each node, be it a software module or team of employees, has a mandate to perform a very specific task in the context of a greater whole; when all nodes are working in concert with one another, the entity as a whole works. Nodes should work seamlessly with other nodes to achieve a certain task, but shouldn’t be held responsible for performing the task assigned to another. After all, that’s not what it was built to do. There should not be an n-by-n relationship of accountability among the functioning parts: each one shouldn’t have to know what all the others are doing. Instead, it is the role of some kind of controller module upstream to make sure that everything is running smoothly. Software design patterns such as MVC (Model-View-Controller) are premised on this paradigm. Keeping to a model like this helps avoid spaghetti code and spaghetti management. 

all of which are allocated discrete, well-documented roles defined before they are built,

In software development, the programmer writes pre- and postconditions in order to establish the role of a particular software component. With these boundaries well defined at design-time, the programmer is less likely to try to sneak additional functionality into code that was never meant to accommodate it. The same holds true in an organization. If the mandate of a team is well defined and appropriately suited to the skillset of the members of that team, then the team will likely perform well.  If the team’s mandate changes, then some examination is in order to make sure that it can still perform its duties appropriately under the new definition. Some flexibility in re-using, reassigning and re-appropriating code or people is of course desirable, but eventually you reach a point of diminishing returns and end up so far from where you started that it just makes sense to scrap the whole thing and rewrite it from scratch.

all of which can communicate with one another using a universal and mutually agreed-upon protocol,

Message passing is a huge part of efficiently written software. With all the modular pieces buzzing along, doing their own thing, it becomes important that they have some mechanism to communicate with one another. Many programming languages have some level of built-in support for passing information back and forth between chunks of code, and it is often best to leverage these facilities. By mapping out the communication paradigm before a single line of code is written and keeping consistent throughout the whole application, the programmer saves him- or herself the trouble of inventing a new set of messages each time an additional module is added. 

The notion of communication here applies both between modules, or teams, which may constantly interact with each other and require well-defined APIs for interaction, and  for more asynchronous, interrupt-driven messages, which may better be handled by an event-based notification system. In a corporation, top-down information, such as announcements or strategic direction, should be able to easily be transmitted down the corporate hierarchy (this is often handled in meetings and email lists); equally important (though much harder to implement appropriately) is for messages coming from the lower levels to be heard at the very top without having been distorted or in any way compromised along the way. 

… and finally, all of which are constantly being monitored, maintained, upgraded, and, if necessary, refactored or phased out.

A company, or a piece of software, is subject to the same rules of survival as any living entity: adapt or become extinct. In a market which is in constant flux, the only way to stay on top is to avoid stagnation and embrace change.

While there is something to be said for not fixing something which isn’t broken, if your software is chugging along just fine using decades old technology, while the competition is constantly migrating to the latest and greatest  (and seeing the associated financial returns), then the functional state of the software is irrelevant; something at a much higher level is indeed broken. If your algorithm was top notch for years, but the competition figured out how to do the same thing faster/cheaper/better, then it’s time to refactor your algorithm.

The same holds true on a macro level for the businesses that create the software -  legacy systems, legacy organizational structure, outdated processes, and other baggage will inevitably keep accumulating over time, weighing down the enterprise and all but canceling out any innovation that is achieved. Without constant vigilant monitoring, and mechanisms to execute on whatever metrics those monitoring systems return (good or bad), then the organization inevitably has resigned itself to being retroactively labeled as a Version 1.0 relic in whatever industry it once commanded a presence.