"Culture" is a pretty ambiguous word. Sure, reams of social science research explore exactly what exactly "culture" is, but to the average Joe and Josephine the word really means something different than it does to academics. In most scenarios, "culture" seems to map more closely to something like "the set of social norms and expectations in a group of people." By extension, then, an "IT culture" is simply "the set of social norms and expectations pertinent to a group of people working in an IT organization."
I suspect most people see themselves as somewhat passive contributors to this thing called "culture." Sure, we know we can all contribute to cultural change, but I don't think most people actually feel particularly empowered to make this kind of meaningful change. On top of that, we can also observe significant changes in cultural norms that depend on variables like time and geography. An IT company in China, for example, might have a very different culture from a company in the San Francisco area. A startup in Birmingham, England will have a different culture to a similar startup in Berlin, Germany. And so on.
Culture is critical. It's the lifeblood of an organization, but it's complicated to understand and shape. The "IT culture" of the 1980s and 1990s differs from "IT culture" today—and it will be different again 10 years from now. Apart from generational changes, cultural norms for IT practitioners have changed, too. Today, digital technology is more social, more accessible to people with fewer technical skills, and more embedded in our consumer-oriented world than ever. We've learned to cherish simplicity, elegance, and design, and this has reflected the kinds of organizations that are forming.
So in one sense, IT culture is a box of frogs: a variable, changing, and at times unpredictable entity. In another sense, IT culture is a relatively straightforward issue: It's the connective tissue between people and output. Organizations need to produce output—products, services, support, events, and more. People drive that work, and they need to be productive, efficient, contextually aware, evolving, and happy. None of these attributions are optional: When one is missing, frustration starts setting in.
More important than defining IT culture today, though, is exploring what an optimal IT culture of tomorrow will look like. I want to focus on five key areas that I consider to be critical facets of a high-quality IT culture.
Let's do this.
1. Pipelines should be connected
In a typical organization, you have a number of different "pipelines," as people external to the organization get connected to different teams. Examples include:
- Sales: prospects → leads → opportunities → customers
- Community: users/consumers → advocates → contributors
- Recruiting: prospects → candidates → employees
- Marketing: broader audience → qualified → connected
You'll also find pipelines that relate to workflow. Examples here include:
- Engineering: product features/bugs → specs → code → reviews → product
- Product: requirements → ideas → backlog → scoped items
- Marketing: key messages/features → ideas → scoped items
- Support: requests → triaged requests → engagement
Organizations suffer when people descend into silos, and disconnected pipelines can be a contributing factor to this, especially for IT organizations. As such, explore how you can glue different pipelines together in a sensible and natural (not "forced") way. How can your IT team connect to the community pipeline, for example? How can community members support the sales pipeline? How can engineering and marketing workflow connect together?
Done well, this reduces silos, integrates team-cultures, and reduces complexity and road bumps along the way.
2. Workflow should be asynchronous
I spend a lot of time working with companies, helping them to build internal communities and organizational workflow. While many factors influence the start of this work, I always zone in on one key area first: asynchronous workflow.
Put simply, asynchronous workflow is the ability for employees to be able to work on anything, from anywhere, at any time. Conventional organizations mix together in-person meetings, whiteboard sessions, online discussions, and other methods of collaboration. But multiple ways of working mean that information often gets lost. For instance, in-person meetings without clear notes mean that those outside the room have a deficit of context.
Asynchronous workflow helps to solve this issue. When we focus on discussing ideas and projects in an electronic setting, content and discussions are archived and available to everyone. This makes organizations (including IT organizations) more open and transparent. This doesn't mean you can't have in-person meetings, but you have to reinforce a policy of taking notes and decisions in a way that ultimately end up online for the wider team.
Asynchronous workflow is critical for organizations to scale and it is better to get it integrated as early as possible. It requires discipline and training but, done well, it breaks down silos, opens up opportunities across the organization, and creates accountability and a powerful imprint of best practice (and failures) that can be invaluable.
3. Operate a connected meritocracy
I come from the open source world, where the notion of meritocracy has been steeped in our culture. In this context, a meritocratic culture is one in which everyone is judged on their merit, and it doesn't matter what their gender is, what their skin color is, what car they drive, what their haircut is, and so forth. They're judged on their contributions.
Remember that meritocracy is not a framework or model. It's really a philosophy. Meritocracy can be difficult to put into practice for all kinds of reasons, but I do think it is an important shining light to guide our work.
When thinking about your IT culture, think about how you can provide a pathway in which anyone can showcase their capabilities and contributions. This is where being connected is important. The best organizations I have seen have the ability for people from across the organization to contribute. And this is where asynchronous workflow can be hugely helpful. Tracking your project management, engineering, and marketing in an open, online internal system provides an opportunity for people in different teams to feed in and contribute.
When I have seen this in place, I've observed surprisingly valuable contributions: legal feeding into engineering (e.g. such as reviewing licensing/copyright/firmware issues), sales reps feeding into community (e.g. fueling shared knowledge bases and potential customers), product people feeding into support (e.g. coordinating around customer requests), and beyond.
4. Data-driven experimentation is essential
No two organizations are the same. Seemingly similar beasts such as Microsoft and Intel, or Mattermost and Slack, or Canonical and Red Hat embody totally different cultures. As such, we can learn different lessons from different organizations, but the real insight into what makes your organization tick has to be formed with your people, processes, and workflow in mind.
As such, to really optimize an IT culture, we need to experiment.
The construction and execution of small and large scale experiments will help us to discover new insights that we can use as clues to help us make future decisions. With one of my clients, for example, I put in place an experiment to reward contributors with different types of validation (both intrinsic and extrinsic) of their work at different levels of participation. This helped us to determine what kinds of validation people appreciated, and as a boon this mapped well to staff too (who were also wanting validation for their contributions). This was a small experiment, but we analyzed the results to look for clues that could inform future experiments. We applied what we learned to future work and saw some great results.
The key here is to be data-driven and, frankly, honest with yourself while you're experimenting. We need data to suitably determine the success or failure of an experiment, and we need to be honest in peeling away our internal goals and biases to see the experiment's results in an objective light.
We can perform these experiments all over an IT organization, and we should encourage employees to brainstorm ideas for segments. These can be small exercises that involve very limited costs and can deliver incredible insight. They can act as a means of diversifying ideas and limiting risk. I highly recommend you put in place a regular cadence at which you run different experiments across multiple teams. Doing this can deliver great results and offer a wonderfully creative environment for your employees.
5. Accepting failure is not an academic exercise
Many people understand the value of embracing failure as a means to learn from it. Thousands of people read books and articles about this, and with the best will in the world seek to bring this into their organizations.
Sadly, in many cases we can see an academic understanding of this but not much of a practical application. Leadership in the majority of organizations rolls downhill. If you have a bitter, nasty leader, you get a bitter, nasty culture. If you have an engaging, respectful, friendly leader, you get a more positive culture. As such, embracing failure needs to cascade through the ranks in a meaningful way.
The best IT leaders I've seen embrace failure have been remarkably upfront about failures, both organizationally and personally. They've said "I screwed this up and this is how I learned and became better from it". These conversations can't be soundbites. They have to be authentic and have to be real, and this can be tough for leaders of an organization to instill in their day to day.
Another element here is to re-enforcing in others the value of embracing failure. You can't preach the value of failure and then hammer people when they fail. Of course, be disciplined in requiring excellence from people in the organization, but base your criticism on a body of constructive next steps. Anger, frustration, and annoyance are normal and to be expected, but they have to be augmented with sage, constructive, guidance. Our ultimate goal here is to have people look back on their failures and feel like they grew and became better from them.
Of course, I am merely scratching the surface of what great IT culture is, but I think if you can take these five areas and start building them in your organization, you will see some great results.
This article is part of The Open Organization Guide to IT culture change.
2 Comments