Service Culture

Everyone is a Client

It is commonplace to refer to your end users as clients, though we rarely refer to those we work with as clients – though we should. In our Service Culture, everyone who uses the work you produce, especially those directly adjacent to you in the value stream, are your clients.

Systems Thinking

This new paradigm would require each group to ensure that the work they do is designed to facilitate the work of those who interact with their services. It aligns well with the Systems Thinking approach recommended in modern day literature elaborating on modern digital organizational structures.

Power of Choice

It also supports the natural reallocation of resources and facilities the identification of unnecessary Context Switches that take place within the department, and reduce organizational efficacy.

Example

If there exists a group that does not add to the Value Stream, then all other groups need the option to opt out of using the services provided by this group. Conversely, if a group does add value, then groups will gravitate towards their services. A reduction of services indicates either that the services of a given group are no longer required due to technological innovations, process, or organizational changes, or that the work provided by the group does not add value for other members of the value stream.

Role of Automation

Toil

Ideally, each context switch in the value stream should be as automated as possible. Each group should interact with one another through a list of services. This aim is to ensure that when value is added, it is added in a scalable manner. This requires that Toil be reduced when looking to solve organizational problems.

Shift Quality Left

When automation is leveraged and new processes are created there need be a focus on reducing Context Switches and shifting quality left. Often when one talks abut shifting quality left (dzone.com/articles/how-shift-left-testing-works) one speaks of testing. Thus, below we have opted to include a reference that discusses infosec shifting left.

In Accelerate, written by Nicole Forsgren, Jez Humble, and Gene Kim, on page 70 it reads

“information security should be integrated into the entire software delivery lifecycle from development through operations. This means infosec experts should contribute to the process of designing applications, attend and provide feedback on demonstrations of the software, and ensure that security features are tested as part of the automated test suite. “

…

“This can be achieved by ensuring that there are easy-to-consume, preapproved libraries, packages, toolchains, and processes available for developers and IT operations.” “In many organizations, security and compliance is a significant bottleneck for taking systems from ‘dev complete’ to live. Involving infosec professionals throughout the development process also has the effect of improving communication and information flow – a win-win and a core goal of DevOps.”

Automation will change the way we work. He must adjust structures and processes to best leverage the opportunities that lay before us regarding automation. Teams must offer an opt-in set of services which should best meet their clients needs. If this is not the case, clients should look elsewhere to better meet their teams needs.

It should be the case that internal teams are better able to address the needs of their internal clients, given that they are able to focus exclusively on their unique problems. If another solution better addresses the needs of internal clients then this service-based approach should provide feedback to the internal team providing the service, indicating to them that their services are not enabling efficient use of time and resources, thus permitting them to refocus their efforts where they are most needed by their clients within the organization. This method aligns well with the Systems Thinking approach, one of the three core tenants of DevOps.

Scaling the Client Model

1. Focus on automating the processes by which groups interact with one another (reduction or complete elimination of group mailboxes)
2. Allow teams to opt out of using services provided by groups, which are better provided by another. For example, a group who requests an e-mail be sent to a group mailbox, rather than to a portal that begins an automated workflow. If the same result can be generated by the more efficient automated process, the non-automated processes should be repurposed to add value elsewhere.
3. Once IITB has generated the internal knowledge permitting an efficient internal service culture, begin interacting with its clients in a similar fashion. All of IITB’s services to our clients should be automated. Clients should be able to interact with our services in an automated fashion, opting into the services due to their value added.
4. Continue scaling this approach to evolve the manner in which Canadians and private enterprise interacts with ESDC and other governmental bodies. Initiatives in this direction are already taking place, such as the recent addition of ESDC services to the Government of Canada’s Api Store (api.canada.ca/en/homepage).

For further details as to the organizational, cultural, and procedural, changes that must be made in order to achieve the evolution to an efficient Service Culture, please refer to our Strategic Roadmap.