[4/8] Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (How to Manage Intellectuals: I'm Nerds & Geeks) (Category Management)
The second part of The Process is the Product, where the author describes how good processes help prevent problems and disasters. Good processes give structure to work, and bad processes lead to bureaucracy, meaningless meetings, conflict situations. Author in 10 The chapters give you advice on how to make your processes good. (Previous posts 1, 2, 3)
22) 1.0 In this chapter, Rands talks about launching a product version. 1.0 always-built (In fact, it is the creation of a startup.). He gives a metaphor for an inverted pyramid with 4 levels where you, as a balancer, balance it on the edge of the project The project contains the essence of what you want to do and gives the effect of urgency People need a team to start a project (There are no irreplaceable people in it.) The process determines the communication of people
- Product - unless you have a company Most startups don’t take out balance and the whole pyramid falls apart. 23) Myths about the process Processes are the inventions of managers that drive engineers mad. As long as the company was small, the processes were simple and informal. But as the company grows, the processes become more complex. This does not like the old guard inside the company, which, even without new improvements in the processes, is guided by what is happening. And new trials are usually created by the new guard. It's what causes conflict. Generalizing good processes can be helpful, but it’s important to understand the purpose and essence of each process – otherwise it’s some kind of cargo cult. 24) How do I start? Rands talks about how to break down a big goal into individual steps and execute them. These steps may not always be linear and that's OK. The main thing is to relieve the pressure of a big goal, but check that completing a significant number of steps brings you closer to the goal. I use this approach myself to write a book. 25) Take time to think. The author says that managers often fall into the operating system and simply react to events. But we need to think separately about the time that can be allocated to think. He invites us to meet. Brainstorming on big issues where discussions take place Prototype where a prototype solution is discussed It is important to separately monitor whether you make decisions and implement them. (or just say) 26) Value of impregnation A good idea is that to solve a complex problem, you need to give it time to infuse into your head. First, during the active phase, you need to put facts, ideas, and context into your head. And then during the passive phase, take a pause and make the brain think about these problems in the background. Next you will get insight... but that’s not certain. I use this approach for presentations and articles. 27) Fixing context The author proposes to fix brilliant ideas. To do this, he uses the VCS metaphor. (git). And that got me thinking about ADR. (architecture decision records) decision-log 28) Drop theory This idea is similar to the saying "water stone sharpens" 29) When the world collapses The author describes the approach of working in an incident, where a command center is formed, the situation is analyzed, the first plan is proposed, it is analyzed and finalized, and then applied. During the application, all interested parties are informed about the decision of the incident. 30) On the importance of hacking It's about the duality of companies. While the startup company is moving fast and cutting corners for the sake of speed. Then she grows up and begins to appreciate stability. But even so, there must be an unstable part of it, otherwise disruptive innovations from the market can be missed. 31) Entropy destroyers As a company grows, good project managers may be needed. The bad ones are brought only by bureaucracy and processes for the sake of processes, while the good ones help build quality processes.)
Continuation in next post.
#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership