Recently, quite by chance, thanks to a good person, an idea was born — to attach a brief summary to each article. Not an annotation, not a teaser, but an actual summary. Something that allows one to skip reading the article altogether.
I tried it, and I really liked it. But that doesn't matter — the main thing is that readers enjoyed it. Those who had long stopped reading, branding me as a hack, started coming back. And another good person suggested writing a summary for each old article. I agreed and now, in the meantime, I am writing these short pieces. I called them shorts.
I present to you several such shorts, based on a few publications. Perhaps you will find something useful for yourself.
The cat has died, the tail is worn out.
Meetings very often end up being unproductive. They gather, chat, and disperse.
The results, or products of a meeting — are decisions. And usually, they are absent. And if they exist, they are not always of good quality.
If a meeting is time-limited and a decision must be made, then the decision may be of low quality.
If a meeting is not time-limited and lasts until a decision is made, any decision will be accepted, just to end the meeting.
If a decision is conceived in the meeting, it will be made — simply because the brain values what it created.
The understanding of the low quality of the decision will come later, but by then it will be too late.
To make an effective decision, it is better not to participate in the discussion, but to observe silently.
Firstly, the brain won't be occupied with coming up with answers.
Secondly, there is no pressure to make a decision.
After the meeting concludes, one can calmly think it over and make a decision. It will be of higher quality.
The key: to be silent and listen during the meeting. To reassure others, say that this is a conscious position.
→
Latent parasites
There are fundamentally two approaches to task setting and performance control: parasitic and symbiotic.
The symbiotic approach — is to ensure that the task is accomplished.
The parasitic approach — is to ensure that the task is NOT accomplished.
The symbiotic approach is straightforward and uncomplicated, but difficult to implement. Hence it is rarely encountered.
The task is set in such a way that everything is clear — both the goals, resources, and constraints.
The control is carried out in such a way that the task is solved precisely.
A symbiotic approach involves leaving a portion of the responsibility (specifically, a larger portion) for solving the problem to the initiator.
The parasitic approach is convoluted and crafty, but simple to implement. Therefore, it is often encountered.
The task is set up so that nothing is clear. The less clear, the better.
Ideally, control should not be exercised at all.
There is no responsibility on the task initiator; all the 'monkey' is transferred to the performer.
The goal of the parasitic approach is manipulation, ego gratification, and self-assertion. Hence, it is often seen in the work of mentors with novice employees.
Of course, the symbiotic approach is better.
→
Measurements vs Illusions
If you evaluate the process and results of your activities without measurements, you will consistently make mistakes.
Evaluation without numbers depends on mood. A bad mood will make you feel like you're working poorly. A good mood will make the opposite seem true.
You can spend a week working poorly, and then on Friday deliver a 'result,' making it seem like the whole week went well.
There are fundamentally two types of metrics: quantitative and alternative (more commonly known to programmers as Boolean).
'The task was completed on time' is Boolean. It's the same as 'The part is usable' (an alternative quality indicator when numeric measurement is not possible).
'We are doing well,' 'We are meeting the plan,' 'I'm doing great' are also Boolean.
It's difficult to build a management process based on Boolean-type evaluations. It is recommended to transition to quantitative metrics as soon as possible.
Boolean leads to bureaucracy and formalism. For example, completing tasks on time can be achieved by extending deadlines, creating tasks for oneself, and performing busywork.
Managing based on Boolean indicators requires a lot of time— for meetings, analysis, etc. Because the information is too scarce.
It is recommended to measure both the process and the result. This will provide the most comprehensive picture.
For programmers, the 'Planning Poker' method from Scrum is recommended.
→
This is Sparta
Suppose you are a programmer, and you have been given a serious task. However, you believe that the task should not be solved—it's foolish and harmful.
Typical behavior in such a situation: bring the task into the public arena. Send it for approval from the manager, launch the internal project, document it in the system, etc.
This is where everything breaks down. The person who brought the task does not want to be seen as foolish. And since it went public, they will defend themselves.
It’s important for a person not to lose face, in a political sense. The main rule in politics is to never admit one’s mistakes. You can do nothing, but the key is not to have recognized errors.
The person will do everything possible to prove that the programmer is the villain, an idiot, an opponent of change. And the programmer still has to solve the task.
In some cases, a person will arrange everything so that the programmer does not solve the task at all. Then the person will be ‘white,’ and the programmer will be completely ‘black’ (having resisted and ultimately not succeeded).
There are several solutions.
The first is to become a business programmer, understand related fields, and determine for oneself what needs to be automated and how.
The second is to become the Chief of Changes. For example, the Director of Development.
The third is to not stand out and simply do what is told.
The fourth is the Spartan Way, a quick rejection of solutions. More commonly known as fail fast, fail cheap.
The main thing is not to make it public. Tell the person — let’s not waste too much time, let’s make a prototype, and see if the solution is viable or not.
The prototype will take little time. In case of success, both will benefit — a decent solution and political points.
In case of failure, no one will suffer. Moreover, the person will have a better attitude towards the programmer.
→
Surrogates
Business does not favor 1C and its products, web developers, quality management systems, accounting, economists, development projects, Scrum, TOC, controlling, KPIs, and motivation systems.
Businesses seek profitability gains through automation, increasing revenue from online promotion, improving product quality, a simple and clear picture of business metrics, forecasts of company performance, real efficiency improvements, accelerating project completion by 2-4 times, drastically increasing profits and reducing inventories, precise management systems, and a clear assessment system for the business situation, along with labor evaluation systems that enable the dismissal of half the managers.
Businesses love achieving their goals. Businesses dislike surrogates.
A surrogate occurs when the aim of achieving a business goal is replaced by an automation project, a website, a stack of paperwork, a baffling team of employees, or unreadable report formats.
A surrogate is when the goal is replaced by a means of achieving it. Meanwhile, everyone forgets the goal together.
The production of surrogates relies on three pillars: formalism, gradualism, and collusion.
Formalism involves transferring goals to paper through decomposition. Essentially, it shifts focus from significant goals to minor details. No one remembers the goal anymore; everyone's discussing the details.
Gradualism refers to the slow transition from goals to means. Initially, the goal may still be discussed occasionally. However, gradually, step by step, it gets mentioned less and less, until the client forgets about it entirely, drowned in the details.
Collusion manifests in the fact that all contractors behave similarly. There isn't a single automation specialist who genuinely increases profits. Thus, the client has limited recourse.
What to do?
Avoid surrogates and the first step towards their creation: formalism. At least in internal projects. Set a clear goal and continuously discuss it with the executor. Also address scale, resources, plans, etc. — but most importantly, focus on the goal.
Otherwise, the focus will inevitably shift, and you'll end up with yet another surrogate.
→
Wladimir Klitschko
There's a boxer named Wladimir Klitschko. He has a unique characteristic — the constant use of the jab. More consistent than other boxers.
The jab consistently keeps the opponent on edge, wearing them out.
Key features of Klitschko's jab: relative simplicity of execution and consistency.
Many authors talk about how simple, yet effective actions that are performed regularly can bring significant benefits.
I also decided to give it a try. I created a simple tracking system for the tasks I accomplished today.
It happened at the factory. I worked on tasks during lunch (I don’t take lunch breaks), that is, 1 hour a day. I did what others don’t (they say this leads to success).
I configured checks for the self-learning system, brainstormed development ideas, implemented others' ideas for improvement, set up automated tasks, refactored, and optimized code.
Every day — any task from this list. Complete one task — great job. You can do several.
I observed for 3 months. During this time, I conducted 30 checks, came up with 200 ideas, implemented 80 ideas from others, built automated processes for two departments, and made three significant optimizations.
Cool, right? This is all done 'in the meantime'. I highly recommend it to everyone.
→
Flexible surrogate
The term 'Scrum' refers to at least two entities: a philosophy and a framework.
The philosophy, or approach to work, is described in Jeff Sutherland's book.
The framework, that is, the algorithm of actions, is outlined in a document called the Scrum Guide.
The philosophy transformed into a framework because the authors wanted to profit from it (according to their own words).
The framework is significantly simplified compared to the philosophy. The main thing — the goal is simplified or rather eliminated.
The goal of the philosophy: acceleration of achieving results. In fact, by several times. The book includes examples of acceleration by 8 times.
The goal of the framework: for you to have Scrum. It states: follow the instructions — you have Scrum, violate the instructions — you don’t have Scrum.
The framework does not imply acceleration of achieving results at all.
People who teach or implement Scrum work with the framework. They explain and implement an algorithm that leads to no results other than 'now we have Scrum.'
The essence is clear. Selling the philosophy is very difficult. The framework is easier.
The framework is a product. It has, as expected, gone through 'packaging.' It is simple, understandable, has support, and many specialists. Sounds familiar?
Everything is fine, except for the results — there aren’t any.
If the client is not familiar with the philosophy of Scrum, then implementing the framework will suit them just fine.
If the client is familiar with the philosophy of Scrum, they will be disappointed by the implementation of the framework — there will be no acceleration in achieving results.
It will be cool, trendy, and modern, but no business objectives will be achieved (other than spending the budget on something 'new').
What should you do? Study the philosophy of Scrum. It is based on the Japanese philosophy of quality management, which emphasizes measurement and continuous improvement.
Unfortunately, it requires a lot of thinking, experimenting, observing, and, sadly, working. If this does not suit you — just take the framework.
→
Source: habr.com
