A narrative to create a digital culture… for the customer (part 2 Building Blocks)
So now we should make the digital culture from this
Obsess over customers, not technology
A fundamental learning from the past several decades that has influenced modern methodologies and organizational layouts is running IT organizations in a silo misaligns IT with business results. When IT becomes enamored with internal workings by way of process and technology selection, it loses sight of the customer. This is why the foundational block of a digital culture should be to obsess over the customers, not technology. IT should have the same purpose as the business to exist for the customer. Each technology team should directly connect to the same input and research from the customers that Sales and Marketing use. This is an intentional decision to make the technology team partners in the overall fabric of the business. Hearing input directly from the customers shortens the feedback loop, decreases solution cycle time, and elevates the relevancy of each solution IT provides.
This means requirements for technology teams should be aligned to customer success metrics first, before specifying functional requirements. All too often in IT, we build software for functionality rather than first considering the metrics most important to the customer. Metrics are the basis for decision making. To make decisions faster, set requirements for real-time metrics reporting that does not rely on batch processes or lag time. This reduces bureaucracy because it delivers relevant and actionable data instead of feelings and assumptions. Operations and the Project Management Office should change the focus from passively monitoring operations to actively facilitating it by using customer metrics as the basis for decision making.
Journey into DevOps
The next layer of the digital culture is to journey into DevOps. The term DevOps doesn’t represent a specific methodology or set of standards. Rather it represents a way of thinking which can be used as a basis to develop culture, automation, measurement, and sharing. There are several key concepts in DevOps to build into the framework of a digital culture. The first is to break down traditional silos within IT by bringing development and engineering activities together in a cohesive team rather than having them separated by management and process. Teams should be small enough to operate with speed but large enough to have representation from key areas including software development, QA, infrastructure, UX, and project management.
The second concept is to maintain always releasable code through versioning, branching strategies, automated builds, and feature flags. Continuous deployment requires a development process to have a code branch always in a releasable state that can deploy to the customer at a moment’s notice. Building feature flags into the design of the code is part of this concept. This means features can be turned on/off to in an application with data rather than requiring code rebuilds and deployments. It enables the removal of features that may be causing problems with production and enables advanced testing (i.e. A/B testing) of features to see how they impact key metrics. Additionally, database artifacts should follow the same version control processes and repository as application code. In practice, this means we should represent changes to the database as a database migration script to include things like schema changes, database code changes, and reference data updates.
The third DevOps concept is to embrace automation. One area of automation is within the development and deployment pipelines (Continuous Integration/Continuous Deployment). But an automation mindset also includes solutions for the back office, stores, and warehouse areas. The smaller working teams and product managers within IT will align requirements to the customers and internal business flows. Automation isn’t done for the sake of using technology but rather to solve the right problems and improve the right metrics.
Finally, the DevOps journey should define and mature standards for areas like Incident management, on-call, Wiki knowledge bases, publishing APIs, programming guidelines, code reviews, and the technology stack. The emphasis shouldn’t be on words in a codified procedure which historically made the IT culture rigid and unempathetic. Rather the emphasis should be on setting standards that are periodically reviewed and published to the team. The standards are subject to change based on learnings or environmental business factors (aka Continuous Improvement).
Innovate locally
The third layer of the digital culture is to innovate locally. Bring the IT service delivery model in-house to build ownership and institutional knowledge. It means the technology team prefers to build solutions rather than buying them and prefers to use open-source platforms rather than licensed ones. Open Source tools will not always satisfy the need and in this case, it is necessary to use solutions from third parties. Work teams should have the autonomy to create solutions that are within the boundaries of customer-driven requirements and metrics.
The play card looks like this:
| Hire extraordinary problem solvers | To increase capacity for innovation |
| Give team members big puzzles | To create an environment for innovation |
| Use open-source tools | To allow unrestricted innovation |
| Align solutions to customer-driven metrics | To sustain the desire to innovate |
This is a recipe to build a culture of workers who genuinely care about the customers of the business.
Be FOR us
The concept of FOR is from the FOR Company and the book Know What You’re FOR by Jeff Henderson. It is used to answer the question, What do you want to be known FOR? To be FOR someone or something requires intentional actions to show them you are genuinely concerned about their success. Within a digital culture, we want to be FOR customers, team members, and ourselves. Let’s represent this collective group as us. To create and sustain a working digital culture we must be FOR us.
To be FOR the customer, Managers should intentionally and often repeat the purpose of the organization. Use meetings, emails, chats, and one-on-ones to capture the spirit of our purpose. If we are aligning our requirements and metrics with the customers, this becomes part of conversations already happening. Additionally, celebrate when established metrics are exceeded.
To be FOR our team members, Managers should be encouraged to frequently express appreciation for team members both corporately and privately. Managers should be encouraged to use a mix of electronic, verbal, and even handwritten notes.
To be FOR ourselves, allow each team member time to recharge and learn. This can be accomplished by having department-wide quiet periods, competition events such as hackathons, or sponsored learning events on relevant topics.
I love this concept because it forces focus on people and relationships. Yes, the company can’t survive without making money. But the company will sustain itself and make money by taking care of “us”.
What do we want to be known FOR? What are we known FOR?
Next Week – Part 3 – Envisioned Future
Onward and Upward!