The tasks you are accountable for change over time. Some tasks are automated and disappear. Others are added as a result of process changes or changed skills. Designing an organization is therefore not a one-time activity, but a continuous process. When you use the tasks executed within your organization as a starting point, and combine them with the required competencies for the task, you can keep your organization up-to-date and your employees happy.
This may seem more complicated than it actually is. The governance plane of the MyREFerence architecture model (see image below), in combination with the eight steps below, provide a solid base to limit the amount of work and reduce the impact of change to a minimum.
1. Define the tasks
Tasks are all manual process steps executed within your organization. The processes in use within your organization therefore determine which tasks exist. The tasks may be derived from process frameworks such as ITIL, ASL or BiSL, but can also be based upon your own experience or way of working. In order to be able to validate and test the completeness of the task list, they are plotted on the MyREFerence governance plane. Plotting implies determining whether the task is operational, tactical or strategic in nature and in which focus layer (business, process, functionality (application related) or capacity (infrastructure related) the task is executed. Review the task list regularly to identify changes.
2. Link tasks to competencies
The next step is to determine which competencies are required to execute a task successfully. To do this you can use the existing competency framework that is used within your organization in HR and recruiting. This creates an objective set of required competencies, unbiased towards the existing capabilities of your current staff. This step needs to be executed only for new or changed tasks.
3. Determine the roles within your organization
The existing organization and framework in use provide clear pointers towards the roles required. Create a clear definition for these roles. After step 5 (when the tasks are linked to the roles) it becomes clear whether the definition is complete and correct. If not, either the classification of the tasks or the definition can be adjusted as needed. When tasks change, only the roles touched need re-addressing. It is important to note that roles are not the same as functions. A role is functional for your processes, functions are used by HR to unify the reward structure in use within your company. Your employees are linked to functions and the employee can fulfill one or more roles at the same time, either temporarily or permanently. This makes the organization scalable: in small organizations a single employee will fulfill multiple roles, in large organizations you may have multiple people for a single role.
4. Group roles to departments
The organizational boundary of a department is determined by the tasks executed within the department. In this lotting, the tasks should logically belong together. The same is valid for the roles. Linking roles to departments makes it possible to validate organizational lotting as soon as the tasks are linked to roles. This should not deviate too much from your current situation.
5. Link tasks to roles
The key step is the linkage of roles and tasks. To do this, use the well-known RACI (Responsible, Accountable, Consulted, Informed) model.
6. Visualize the result
The connection between tasks, roles and competencies makes it possible to determine the competencies required for a role and a function. In addition it is possible to determine which department is active in which part of the MyREFerence governance plane. The amount of data involved however often prohibits this verification. Visualization is a powerful assistant here. Plotting the location of roles and departments in the governance plane makes instant verification possible. Depending on the results, revisiting the task classification, the RACI or both may be required to alter the outcome of the visualization to the desired picture.
7. Implement the result
Now that everything is clear and validated, an objective balance can be struck between the interests of the company (optimal setup of the organization) and the interests of the employees (match in knowledge and experience). This balanced approach weighs the interests of all stakeholders, leading to a well-functioning organization.
8. Repeat regularly
Organization development is a process, not a project. Do not expect to be finished in one go.
Other relevant DevOps content
- BLOG: Red Hat – OpenShift Day-2 Ops from the trenches
- REPORT: 2018 State of DevOps Report – DevOps Research Assessment
- OFFER: DORA – DevOps Research and Assessment
- BLOG: Observability in OpenShift with Prometheus
- WHITE PAPER: The Digital‐Native Enterprise – The Red Hat and Devoteam Success Formula
- BLOG: Shared continuous delivery toolchain, the silver bullet?
- NEWS: Atlassian Gold Solution Partnership for Devoteam
- INFO: Our CALMS approach towards DevOps
- CASE STUDY: Improving the CIO delivery cycle at Liberty Global
- BLOG: Monitoring to reduce Mean Time To Recovery (MTTR)
- EBOOK: API Strategy and Architecture
- EBOOK: DevOps Perspectives
- OFFER: DevOps and Culture
- OFFER: Continuous Delivery
- CASE STUDY: Same meat, different gravy
- BLOG: Become a high performing organization with DevOps as business enabler