In Search of Organizational Consciousness
What does it mean to be conscious? Flying across the country earlier this month, I read a recent issue of the Atlantic and in particular an article on anesthesia: “Awakening“. While general anesthesia is designed to make a surgery patient unconscious, we actually know very little about what consciousness actually is. One of the models of consciousness put forward by Giulio Tononi is that a conscious mind is an integrated mind.
When your nose detects a new smell, your motor cortex might quickly respond by inhaling more deeply. The scent is referenced against what you have smelled before. In an instant, you recognize a perfume your grandmother wore, visualize her, and emotionally respond to the memory. A conscious brain pulls all this together and integrates the experience. An unconcious brain receives the signal from the nose but does little with it. Dr. Tononi is working to measure this by stimulating one area of the brain and measuring the ripples across others. The image below, shows brain activity increasing in different areas in a patient recovering from a coma.
This model of consciousness can have a profound impact on how we want to operate as a company or team. Suppose a few software developers are hanging out, playing pool with support guys after work. When asked, “Any cool support questions today?” a support guy responds, “Naw, just the usual people confused by the login screen.” Our friends in development might be surprised to discover a common usability problem, just as most of you readers were surprised by developers hanging out with the support team. Marketing and sales teams that are getting vague feedback about the software not being user friendly would also be able to contribute to this conversation.
At this moment, in a bar around a pool table, a ‘scent’ picked up by one part of the organization is starting to ripple to another area that can respond in the interest of the company. When the login screen is addressed, the company has acted consciously.
A conscious and alert company is one where new information can quickly ripple across departments, gain additional context, and drive changes in action. In a sleepy company, this communication is limited. A company where little inter-departmental communication is limited and document driven can be considered comatose.
How do organizations become more alert? They find ways for people from different areas of the organization to come together. This may be as simple as locating the technical support teams for a product on the same floor or building as the developers to increase the odds that they talk over a ticket rather than email. It may be social business tools or new processes.
Social Business tools are put in place to make our work more visible. These tools are inspired by how Facebook or Twitter allow us to stay informed of changes in our friends lives, and get informal advice. Can we leverage our work network in a similar, informal way? If I subscribe to the Yammer notifications from colleagues across a wide swath of the business, I can connect with them a little bit better and offer insight on their projects on the rare occasion when it’s appropriate.
On the process side, Agile and DevOps are movements designed to wake up IT organizations. Agile brought the reality of what was being built to the business more quickly. Done right, it fosters better exchange of ideas between development and the business. At the extreme, XP desires to bring a representative of the customer into the same room as the development team to maximize feedback. Pair-programming exposes each keystroke to knowledge of another individual.
DevOps seeks to bring development and operations teams into closer contact or even eliminate the distinction between them. The DevOps movement is in response to brain-dead organizational behavior where productions problems would take a long time to diagnose without developer input and developers build new applications that don’t scale or that the operations teams do not know how to support.
This view of DevOps provides very clear guidance to emerging “DevOps Teams”. Your job is to be “connective tissue” that facilitates better Dev / Ops collaboration. One day you might be putting a tool in place that gives them a common way of standing up infrastructure or doing deployments, the next you might be lobbying to change the floor plan to get these teams closer together. You should be working with release management to be an honest mediator when those groups have disputes. The more you dictate to other teams the less useful you are.
Fighting off sleep
Over the past couple years, we have grown like crazy at Urbancode. While the leadership types don’t talk in terms of “organizational consciousness”, they do spend a lot of time worrying about how to have more distinct teams, while still having healthy information flow. Here’s what we’re doing:
- We drag people into the same room – We regularly have company wide lunches together to socialize big updates from various teams, and get everyone in a room talking. Similarly, we bring our field sales people in to headquarters periodically to keep them integrated.
- We burned the org-chat – That’s not quite true. We refuse to publish an org chart. We worry that a UI/UX designer who sees their name under a product lead would de-value the work they do with their cross-product UX peer group.
- We work hard to stay co-located – We want hallway conversations, chats at the water cooler, and to learn by overhearing. So few roles at Urbancode are available to people not willing to work at headquarters. We also are not fans of working from home.
- We hang out – We setup meet-ups open to anyone in the company. Last week I saw reminders for a trip to the art museum, GO night, a dinner event, and a MTG tourney. Going to bars usually takes care of itself without a lot of organization.
- We broadcast - Our bias is towards including more people on emails than probably need to be.
- We have an open floor plan – For the most part, cube walls don’t exist and we have few private offices. We’re shifting towards team sized rooms.
We’re still figuring it out. Some of this can hurt developers who are trying to focus or cost us an opportunity to hire a talented person. But staying awake and alert is critical to us as we try to exploit slower moving competition. We are willing to bear those costs out to stay in touch with each other. Plus, knowing and liking your co-workers is so much better than hating the jerks on that other team.