We organize chaos or how to implement a process approach in an organization
Once I changed my job and got from a large, well-structured organization to a booming startup. I really liked everything at once: the energy with which people worked, and the professionalism, and the soulfulness of internal communications. But at the moment when they began to pass on to me PM-affairs, a surprise was waiting for me:
- In the sense of no descriptions? That is, you have not written anywhere, by what rules do your teams work? Quite quite?! Even a SLA? And how will you give me? In terms of memory, what if some kind of arrangement is forgotten and not transmitted? How do I understand this along the way? Oh, mummies ...
Have you ever had the feeling that your head is round, and the thought you are trying to think is square? That’s how I felt about myself, trying to understand how I would work. The startup was no longer small - more than 200 people, offices in several countries, clients around the world. And, as far as I understood, the agreements on how the development teams work, how often they release releases, how they fix tickets, how they report, where the documents are and how they are updated - everything was decided somehow on a hunch. And this is wonderful - when you are few and you are all in one place. But when your new team sits in a new location, everyone else in other cities and even countries, and new people every day more and more ... I was not at ease.
As a result, I remembered one simple thought, since I have a technical education:
For programmers and not only those who believe that describing management processes is a waste of time: just like the code should be covered with technical and user documentation, the work of the company should be described by instructions and processes. For the same reasons: the more rules and the more confusing they are, the more difficult it is to mention.
Especially they need to be described if the number of newcomers is constantly growing and the processes tend to constantly change. What is it useful for later:
I never thought that I would write it, it seems it is clear and true. But no, it turns out that technical startups usually miss the complexity of managerial processes and prefer to think that everything should turn out on its own.
In short and simpler, then instructions and agreements with all parties on how the work is organized with incidents, problems, releases, knowledge, capabilities, security, etc. in our organization.
If more, open the ITSM Talmud and read :)
This article is not entirely about what to describe, but rather how to describe and implement so that the processes live.
The task of describing so that people use it is not very trivial, especially in conditions when changes do not come from above, from the leadership. It becomes even more complex with sheer resistance.
I found a source of resistance, long instructions about 10-30 pages, written about 5 years ago, about which everyone forgot about a year later. That is, attempts at structuring were, did not work, and there was confidence that it would not work.
By reading these documents (quite, by the way, sensible, but long, too sophisticated) I made myself nicks
Lesson 1: Describe the arrangements short and lively.
What you cannot explain in simple terms a complex process is your problem, not the one reading it. Perhaps you are trying to stick several processes into one.
Lesson 2 If you can not use the chart - do not use. Never use a complex diagram.
From the outside it seems that the opposite is that reading a pier is more difficult than looking at a chart. I thought so too. However, I am now holding two documents describing how we will release features, text and diagram. The diagram is not updated (either difficult or once), the text is constantly (this has been done not only by me for a long time).
Lesson 3: Two short documents are better than one long document.
Nobody reads long texts anymore, you just have to put up with this.
Lesson 4: If you yourself can not write, do not write.
It's easier for people to use what they come up with and structure themselves. To convince someone of the importance of creating an agreement is more correct than writing yourself. Although, of course, not easier.
Lesson 5: If you still write yourself, then ask to check
Very often, a document arises after the question “how do we do it?”. Well, if you sent a document for verification to someone who received the information, with the words "please check, is everything right?"
Lesson 6: In addition to the inputs, outputs, and performers and those responsible, each document should have a target audience.
As in marketing: for an article to be read, it must be of interest to you personally. If you shove information for everyone into one document, it will be long, and we remember that long texts scare modern people. For example, there is a general rule for everyone how we work in accordance with the GDPR. In practice, these are three documents:
If something goes wrong, I open the documents, poke a finger in them and say, we agreed to do so. What needs to be fixed? If someone from the manual, say, is not satisfied with the deadlines for working on the ticket, I open the process where it says
and I ask a question, will we now change the process, ticket priorities or something else?
This pretty much mitigates dissatisfaction, facilitates communication and, most importantly, increases your predictability and transparency of your work. And where there is transparency, there is trust. And on trust, you can build a lot more.
Plus, it gives you the ability to defend your team if the fault is not in public, but in confusion in management (80% of cases in fact).
Part of the release management process was born out of three conversations with release managers ... Based on it, I explained to the management why the release was taking so long, and the release manager called for this discussion. Now in this place there are several documents about how, why and what should be released here. Written, of course, not by me, but by release managers. Accustom people to the fact that it is convenient, which frees you from unnecessary explanations and makes it possible to be transparent at once and for everyone. By example.
I do not forget from time to time to give a small lecture that the written agreements on the format of work are much better than those not written. I am interested in talking about this, so everyone has to listen many times. Not the first time, gradually, most of the agreements we have crawled into confluence. Water sharpens a stone.
At a minimum, the chaos in the head and in the workplace will become less.
As a maximum, you are lucky and you will be noticed in this organization as an intelligent manager who knows how to work with processes. :)
Thoughts about, quite controversial, just speculate.
I have a fairly serious belief that someone cannot write and implement processes from the outside. He can describe the current state, but no one will support the process. And if you need quick changes, they will happen, and the process will wait until its creator makes the changes.
Management processes are the business of those people who use them.
And yet, it should happen that the process approach is not an externally imposed rule, but my agreement with the outside world on the rules for working with me. Then the process approach will not be a brake on the development of the organization (I have already seen this before), but a growth catalyst.
- In the sense of no descriptions? That is, you have not written anywhere, by what rules do your teams work? Quite quite?! Even a SLA? And how will you give me? In terms of memory, what if some kind of arrangement is forgotten and not transmitted? How do I understand this along the way? Oh, mummies ...
Have you ever had the feeling that your head is round, and the thought you are trying to think is square? That’s how I felt about myself, trying to understand how I would work. The startup was no longer small - more than 200 people, offices in several countries, clients around the world. And, as far as I understood, the agreements on how the development teams work, how often they release releases, how they fix tickets, how they report, where the documents are and how they are updated - everything was decided somehow on a hunch. And this is wonderful - when you are few and you are all in one place. But when your new team sits in a new location, everyone else in other cities and even countries, and new people every day more and more ... I was not at ease.
As a result, I remembered one simple thought, since I have a technical education:
The system changes from anywhere in the system.And she decided that I would probably be that point that would bring the system from a state of chaos to a state of clear structure.
For programmers and not only those who believe that describing management processes is a waste of time: just like the code should be covered with technical and user documentation, the work of the company should be described by instructions and processes. For the same reasons: the more rules and the more confusing they are, the more difficult it is to mention.
Especially they need to be described if the number of newcomers is constantly growing and the processes tend to constantly change. What is it useful for later:
- Remind people of how the process works (for example, when not executed)
- Put a new one in the process
- Make changes to the process without missing anything
- Think about what we are doing wrong and optimize the process.
I never thought that I would write it, it seems it is clear and true. But no, it turns out that technical startups usually miss the complexity of managerial processes and prefer to think that everything should turn out on its own.
What to write
In short and simpler, then instructions and agreements with all parties on how the work is organized with incidents, problems, releases, knowledge, capabilities, security, etc. in our organization.
If more, open the ITSM Talmud and read :)
This article is not entirely about what to describe, but rather how to describe and implement so that the processes live.
How to write
The task of describing so that people use it is not very trivial, especially in conditions when changes do not come from above, from the leadership. It becomes even more complex with sheer resistance.
I found a source of resistance, long instructions about 10-30 pages, written about 5 years ago, about which everyone forgot about a year later. That is, attempts at structuring were, did not work, and there was confidence that it would not work.
By reading these documents (quite, by the way, sensible, but long, too sophisticated) I made myself nicks
Lesson 1: Describe the arrangements short and lively.
What you cannot explain in simple terms a complex process is your problem, not the one reading it. Perhaps you are trying to stick several processes into one.
Lesson 2 If you can not use the chart - do not use. Never use a complex diagram.
From the outside it seems that the opposite is that reading a pier is more difficult than looking at a chart. I thought so too. However, I am now holding two documents describing how we will release features, text and diagram. The diagram is not updated (either difficult or once), the text is constantly (this has been done not only by me for a long time).
Lesson 3: Two short documents are better than one long document.
Nobody reads long texts anymore, you just have to put up with this.
Lesson 4: If you yourself can not write, do not write.
It's easier for people to use what they come up with and structure themselves. To convince someone of the importance of creating an agreement is more correct than writing yourself. Although, of course, not easier.
Lesson 5: If you still write yourself, then ask to check
Very often, a document arises after the question “how do we do it?”. Well, if you sent a document for verification to someone who received the information, with the words "please check, is everything right?"
Lesson 6: In addition to the inputs, outputs, and performers and those responsible, each document should have a target audience.
As in marketing: for an article to be read, it must be of interest to you personally. If you shove information for everyone into one document, it will be long, and we remember that long texts scare modern people. For example, there is a general rule for everyone how we work in accordance with the GDPR. In practice, these are three documents:
- for all employees - a description of the rule itself, what can be done and what cannot be done with information.
- Where and how to contact in an exceptional situation - for developers and support services
- How and where the technical described is executed - for developers
What to do so that it is not only described, but also works?
Declare that you and your team are managed as written.
If something goes wrong, I open the documents, poke a finger in them and say, we agreed to do so. What needs to be fixed? If someone from the manual, say, is not satisfied with the deadlines for working on the ticket, I open the process where it says
- how do we take tickets to work,
- what stages can they go through
- what is the reason for stopping work on the ticket and
- what is the average time in each of the stages.
and I ask a question, will we now change the process, ticket priorities or something else?
This pretty much mitigates dissatisfaction, facilitates communication and, most importantly, increases your predictability and transparency of your work. And where there is transparency, there is trust. And on trust, you can build a lot more.
Plus, it gives you the ability to defend your team if the fault is not in public, but in confusion in management (80% of cases in fact).
Show people how it works
Part of the release management process was born out of three conversations with release managers ... Based on it, I explained to the management why the release was taking so long, and the release manager called for this discussion. Now in this place there are several documents about how, why and what should be released here. Written, of course, not by me, but by release managers. Accustom people to the fact that it is convenient, which frees you from unnecessary explanations and makes it possible to be transparent at once and for everyone. By example.
Become a source of knowledge
I do not forget from time to time to give a small lecture that the written agreements on the format of work are much better than those not written. I am interested in talking about this, so everyone has to listen many times. Not the first time, gradually, most of the agreements we have crawled into confluence. Water sharpens a stone.
Why do you need it
At a minimum, the chaos in the head and in the workplace will become less.
As a maximum, you are lucky and you will be noticed in this organization as an intelligent manager who knows how to work with processes. :)
Thoughts about, quite controversial, just speculate.
I have a fairly serious belief that someone cannot write and implement processes from the outside. He can describe the current state, but no one will support the process. And if you need quick changes, they will happen, and the process will wait until its creator makes the changes.
Management processes are the business of those people who use them.
And yet, it should happen that the process approach is not an externally imposed rule, but my agreement with the outside world on the rules for working with me. Then the process approach will not be a brake on the development of the organization (I have already seen this before), but a growth catalyst.
All Articles