The book “How to manage intellectuals. I, nerds and geeks "

Dedicated to project managers (and those who dream of becoming a boss).

Writing tons of code is difficult, and managing people is even more difficult! So you just need this book to learn how to do both.

Is it possible to combine cool stories and serious lessons? Michael Lopp (also known in narrow circles as Randes) succeeded. Fictional stories about fictional people with incredibly useful (albeit fictional) experiences await you. This is how Randy shares his diverse, sometimes strange experience gained over the years of work in large IT corporations: Apple, Pinterest, Palantir, Netscape, Symantec, etc.

Are you a project manager? Or want to understand what your damn boss does all day? Rand will teach you how to survive in the Toxic World of Inflated Turkeys and thrive in the general madness of dysfunctionally vibrant people. In this strange community of manic wiseacres there are even stranger creatures - managers who, through a mystical organizational ritual, have gained power over the plans, thoughts and bank accounts of many people.

This book is not like any manuscript on management or leadership. Michael Lopp does not hide anything, he just tells everything as it is (maybe not all stories should be made public: R). But only in this way you will understand how you can survive with such a boss, how to manage geeks and nerds, and how to bring “that fucking project” to the happy end!

Excerpt. Engineering mentality

Thoughts on the topic: do you need to continue to write code

There is a very short list of modern must-do managers in Rands’s book on leadership rules. The brevity of this list stems from the fact that the concept of “must” is a kind of absolute, and when it comes to people, then there are very few absolute concepts. A successful method of managing one employee will be a real disaster for another. This idea is the first item on the must-do managerial list:

Stay flexible!

To consider that you already know everything is a very bad idea. In a situation where the only unchanging fact is the fact that constant changes are taking place in the world, flexibility becomes the only true position.

Paradoxically, the second item on the list is surprisingly inflexible. However, this item is my personal favorite, because I believe that it helps to create the foundation for managerial growth. This paragraph reads:

Stop writing code!

Theoretically, if you want to be a leader, you should learn to trust those who work for you, and completely pass code writing to them. This advice is usually difficult to “digest”, especially by new leaders. Probably one of the reasons why they became leaders is their productivity in development, and when things go awry, their first reaction is to resort to skills in which they are completely confident, that is, to their ability to write code.

When I see that a newly-minted leader "falls" before writing code, I tell him: "We know that you can write code. The question is different: do you know how to lead? You are no longer responsible for yourself alone; you are responsible for the entire team; and I want to be sure that you can get your team to solve problems on their own, without having to write code yourself. Your task is to figure out how to scale yourself. I want you not to be the one and only, I want so many people like you. ”

Good advice, right? Scale. Management. Responsibility. Such common buzzwords. It is a pity that the advice is incorrect.

Incorrect?

Yeah. The advice is wrong! Not that it’s completely wrong, but wrong enough that I had to call some former colleagues and apologize: “Remember that favorite statement of mine that you should stop writing code? It is wrong! Yes ... start programming again. Start with Python and Ruby. Yes, I'm serious! Your career depends on it! ”

When I started my career as a software developer at Borland, I worked in the Paradox team for Windows, and it was a huge team. Only one application developer was 13 people. If we add people from other teams who also constantly worked on key technologies for this project, such as the main database engine and the main application services, we get 50 engineers directly involved in the development of this product.

No other team that I have ever worked for has even come close to similar sizes. In fact, with each passing year, the number of people in the team in which I work is gradually decreasing. What is going on? Are we developers collectively becoming smarter and smarter? No, we just distribute the load.

What have developers been doing for the past 20 years? During this time, we wrote a bunch of crap code. Sea of ​​code! We wrote so much code that we decided: it would be nice to simplify everything and switch to open source code.

Fortunately, thanks to the Internet, this process has now become as simple as possible. If you are a software developer, you can check it out right now! Search your name on Google or on Github, and you will see a code that you have long forgotten about, but which anyone who wishes can find. Scary, huh? You did not know that the code lives forever? Yes, he lives forever.

The code lives forever. A good code not only lives forever, it grows, because those who value it constantly take care that it does not lose its freshness. This bunch of high-quality and well-maintained code helps to reduce the average size of an engineering team, because it allows us to focus not on writing new code, but on existing code and to work with fewer people involved and in a shorter time.

This line of reasoning sounds depressing, but the idea is that all of us are just a bunch of integration machines that use duct tape to connect different pieces of existing things together to create a slightly different version of the same thing. This is a classic line of thought for top management who loves outsourcing. “This can be done by anyone who knows how to use Google and who has adhesive tape! Then why are we paying a ton of money to our vending machines? ”

We pay these types of executives really big money, and they think such nonsense. Once again: my key idea is that there are many brilliant and very diligent developers on our planet; they are truly brilliant and zealous, although they have not spent a single minute sitting in accredited universities. Oh yes, now there are more and more of them!

I do not suggest that you begin to worry about your place just because some brilliant comrades supposedly prey on him. I suggest you start worrying about him, because the evolution of software development may be moving faster than you. You have been working for ten years, of which five years as a leader, and you think: “I already know how software is developed.” Yes you know. Till…

Stop writing code, but ...

If you follow my initial advice and stop writing code, then at the same time you will voluntarily stop participating in the creation process. It is for this reason that I am not particularly active in outsourcing. Machines do not create, they produce. Well-designed processes can save a lot of money, but they will not bring anything new to our world.

If you have a small team and it does a lot for little money, then the idea of ​​stopping writing code seems like a bad career decision. Even in monster companies with their endless regulations, processes and policies, you have no right to forget how to develop software yourself. And software development is constantly changing. She's changing right now. Under your feet! This very second!

You have an objection. Understand. Let's listen.

“Randy, I'm on my way to the director's chair!” If I continue to write code, no one will believe that I am able to grow. ”

I want to ask you this: since you took your seat “I will soon become a director!”, Have you noticed that the field of software development is changing even within your company? If your answer is yes, then I will ask you another question: how exactly does it change and what are you going to do in connection with these changes? If you answered “no” to my first question, then you need to move to another chair, because (I give a tooth!) The scope of software development changes this very second. How are you going to grow at all if you slowly but surely forget how to develop software?

My advice is not to entrust yourself with tons of features for your next product. You need to constantly take measures to stay updated on how your team creates software. You can do this both as a director and as a vice president. Something else?

“Uh, Randy! But someone must be an arbiter! Someone should see the big picture. If I write code, I will lose sight of the prospect. "

You still have to remain the arbiter, you still have to broadcast the decisions, and you still have to go around the building four times every Monday morning with one of your engineers to listen to his weekly tirade for 30 minutes: “We are all doomed ! " But besides all this, you have to keep the engineering way of thinking in yourself, and for this you do not have to be a full-time programmer.

My advice on maintaining an engineering mentality:

1. Use the development environment. This means that you should be familiar with the tools of your team, including a code building system, version control, and a programming language. As a result of this, you will be fluent in the language your team uses when it talks about product development. It will also allow you to continue to use your favorite text editor that works great.
2. You must be able to draw a detailed architectural diagram that describes your product on any surface and at any time. Now I do not mean a simplified version with three cells and two arrows. You must know the detailed product diagram. The most difficult. Not just any pretty scheme, but a scheme that is difficult to explain. This should be a card suitable for a complete understanding of the product. It is constantly changing, and you should always know why these or other changes have occurred.
3. Take on the implementation of one of the functions. I literally tremble when I write this, because this paragraph is fraught with many hidden dangers, but I am really not sure that you can fulfill paragraph 1 and paragraph 2 without taking on at least one function . Thanks to the independent implementation of one of the functions, you will not only actively participate in the development process, it will also allow you to periodically switch from the role of “Manager responsible for everything” to the role of “Person responsible for the implementation of one of the functions”. This modest and unpretentious position will remind you of the importance of small decisions.
4. I'm still trembling. It seems that someone is already yelling at me: “The leader who took over the implementation of the function ?! (And I agree with him!) Yes, you still remain a leader, which means it should be some small function, okay? Yes, you still have a lot to do. If you can’t take on the implementation of the function in any way, then I have a spare tip for you: deal with some bugs. In this case, you will not feel the joys of creation, but you will have an understanding of how the product is created, which means you will never be left out of work.
5. Write unit tests. I still do this in the later stages of the production cycle, when people start to go crazy. Think of it as a health checklist for your product. Do it often.

An objection again?

“Rand, if I write the code, then I will confuse my team. They will not know who I am, the leader or the developer. ”

Good.

Yes, I said, “Good!” I am glad that you believe that you can confuse your team only by swimming in a pond of developers. Everything is simple here: the boundaries between various roles in the field of software development are currently very blurred. The UI guys are doing what can be generally called JavaScript and CSS programming. Developers are learning more and more about designing user interactions. People communicate with each other and learn about mistakes, theft of someone else's code, and also that there is no good reason for the leader to not be able to participate in this massive, global, cross-pollinating information bacchanalia.

Also, do you want to be part of a team made up of easily replaceable components? This will not only make your team more agile, it will give each of its members the opportunity to see the product and company from a variety of points of view. How can you still respect Frank, that cool guy responsible for the layout, if not after you see the simple elegance of his assembly scripts?

I do not want confusion and chaos reigning in your team. On the contrary, I want the communication in your team to become more effective. I am sure that if you yourself are involved in creating a product and working on features, you will be closer to your team. And more importantly, you'll be closer to the constant changes in the software development process within your organization.

Don't stop developing

A Borland colleague of mine once verbally attacked me for calling her a “coder”.

“Rand, the encoder is a brainless machine! A monkey! An encoder does nothing but write boring lines of useless code. I’m not a coder, I’m a software developer! ”

She was right, she would hate my initial advice to the new leaders: “Stop writing code!” Not because by this I supposedly assume that they are coders, but more because I proactively suggest that they start to ignore one of the most important parts of their work - software development.

So, I finalized my advice. If you want to be a good leader, then you can stop writing code, but ...

Be flexible. Remember what it means to be an engineer, and do not stop developing software.

about the author

Michael Lopp is a software development veteran who has still not left Silicon Valley. Over the past 20 years, Michael managed to work in a variety of innovative companies, including Apple, Netscape, Symantec, Borland, Palantir, Pinterest, and also participate in a startup that slowly sailed away into oblivion.

In addition to his work, Michael maintains a popular technology and management blog under the pseudonym Rand, where he discusses management ideas with readers, expresses concern about the constant need to keep abreast and explains that, despite the generous rewards for the product being created, your success is possible only thanks to your team. The blog can be found at www.randsinrepose.com .

Michael lives with his family in Redwood, California. He always finds time to ride a mountain bike, play hockey and drink red wine, since being healthy is more important than busy.

»More information about the book can be found on the publisher’s website
» Contents
» Excerpt

For Khabrozhiteley 20% discount on coupon - Managing Humans

Upon payment of the paper version of the book, an electronic version of the book is sent by e-mail.

PS: 7% of the cost of the book will go to the translation of new computer books, the list of books handed over to the printing house is here .