The book "How to manage intellectuals. I, nerdy and geeky "

Project managers (and those who dream of becoming a boss) are dedicated.

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 funny stories and serious lessons? Michael Lopp (also known in narrow circles as Rends) succeeded. You are waiting for fictional stories about fictional people with incredibly useful (albeit fictional) experience. This is how Rends shares his diverse, sometimes strange experience gained over the years in large IT corporations: Apple, Pinterest, Palantir, Netscape, Symantec, and others.

Are you a project manager? Or want to understand what your damn boss is doing all day? Rends will teach you to survive in the Toxic World of Inflated Turkeys and to flourish among the common insanity of dysfunctionally bright people. In this strange community of maniacal clever men, there are even stranger beings — managers who, through a mystical organizational ritual, gained power over the plans, thoughts, and bank accounts of many people.

This book is unlike any management or leadership manuscript. Michael Lopp does not hide anything, he just tells everything as it is (perhaps not all the stories would be worth making public: P). But this is the only way you will understand how to survive with such a boss, how to lead geeks and nerds and how to bring that fucking project to a happy end!

Excerpt Engineering mentality

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

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

Stay flexible!

To assume that you already know everything is a very bad idea. In a situation where the only constant fact is that there are constant changes in the world, flexibility becomes the only correct position.

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

Stop writing code!

Theoretically, if you want to be a leader, you must learn to trust those who work for you, and completely hand over the writing of code to them. This advice is usually hard to "digest", especially newly minted leaders. Probably one of the reasons why they become leaders is their development productivity, and when everything goes awry, their first reaction is to resort to skills that they are completely sure of, that is, their ability to write code.

When I see that the new manager “descends” before writing the code, I say to him: “We know that you can write code. The question is: do you know how to lead? You are no longer responsible for yourself, you are responsible for the whole team; and I want to be sure that you can make your team solve problems on its own, without having to write the code yourself. Your task is to figure out how to scale yourself. I want you not to be the only one, I want people like you to have many. ”

Good advice, right? Scale. Management. A responsibility. Such popular buzzwords. It is a pity that the advice is wrong.

Incorrect?

Yeah. Wrong advice! Not that it’s absolutely wrong, but it’s not true enough that I had to call some former colleagues and apologize: “Do you remember my favorite statement 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 on the Paradox team for Windows, and that was a huge team. Only one application developer was 13 people. If you add people from other teams who also constantly worked on key technologies for this project, such as the main database engine and main application services, you get 50 engineers directly involved in the development of this product.

No other team I've ever worked on has ever come close to a similar size. In fact, with each passing year, the number of people in the team in which I work gradually decreases. What is going on? Are we, the developers, collectively getting smarter and smarter? No, we just distribute the load.

What are the developers doing the last 20 years? During this time we wrote a fig cloud of code. Sea of ​​code! We wrote so much code that we decided: it would be nice to simplify everything and switch to open source.

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! Look for your name on Google or Github, and you will see a code that you have long forgotten about, but which anyone can find. Scary, yes? You did not know that the code lives forever? Yes, he lives forever.

The code lives forever. And 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 reduce the average size of an engineering team, because it allows us to focus not on writing new code, but on existing code and doing work with fewer people and in less time.

This chain of reasoning sounds depressing, but the idea is that all of us are just a bunch of integration machines that use adhesive tape to connect different parts of existing things together to create a slightly different version of the same. This is a classic line of thinking from a senior executive who adores outsourcing. “This can be done by anyone who knows how to use Google and who has duct tape! Then why do we pay a lot of money to our machines? ”

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

I don’t suggest you start worrying about your place just because some ingenious comrades allegedly hunt it. I suggest you start worrying about it, because the evolution of software development may be moving faster than you. You have been working for ten years now, five of them as a manager, and you think: “I know how software is developed”. Yes you know. Until…

Stop writing code, but ...

If you follow my initial advice and stop writing code, at the same time you voluntarily stop participating in the creation process. It is for this reason that I do not actively use outsourcing. Machines do not create, they produce. Well-designed processes allow you to 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 a little money, then the idea to stop writing code seems to me a bad career decision. Even in monster companies with their endless regulations, processes and policies, you have no right to forget how to independently develop software. And software development is constantly changing. It is changing right now. Under your feet! At this very second!

You have objections. Understand. Let's listen.

“Rands, 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 about this: since you sat in your chair “I will soon become a director!”, Have you noticed that the scope 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 transfer to another chair, because (I give a tooth!) The software development sphere changes at this very second. How are you going to grow if you slowly but surely forget how to develop software?

My advice is not to entrust yourself with the implementation of tons of functions for your next product. You need to constantly take steps to stay up to date with how your team creates software. You can do it as a director and as a vice president. Something else?

“Uh, Rends! But someone must be the arbiter! Someone should see the big picture. If I write code, I will lose sight of the perspective. ”

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

My tips on maintaining engineering mentality:

1. Use the development environment. This means that you should be familiar with the tools of your team, including the code building system, version control, and programming language. As a result, you will be proficient in the language your team uses when it speaks about product development. It will also allow you to continue using your favorite text editor, which functions perfectly.
2. You should be able to draw a detailed architectural scheme describing your product, on any surface and at any time. Now I do not mean a simplified version with three cells and two arrows. You need to know the detailed product layout. The most difficult. Not just some pretty scheme, but a scheme that is hard to explain. This should be a map suitable for a complete understanding of the product. It is constantly changing, and you should always know why certain changes have occurred.
3. Take over the implementation of one of the functions. I literally shudder when I write this, because this item is fraught with many hidden dangers, but I’m really not sure that you can fulfill point 1 and point 2 without taking on at least one function . Due to the independent implementation of one of the functions, you will not only be actively involved in the development process, it will also allow you to periodically switch from the role of “Manager in charge of everything” to the role of “Person responsible for the implementation of one of the functions”. This modest and unassuming attitude 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 are still the leader, which means that it should be some small function, okay? Yes, you still have a lot to do. If you just can not take on the implementation of the function, then I have some spare advice for you: work on eliminating some bugs. In this case, you will not feel the joy of creation, but you will have an understanding of how to create a product, which means you will never be out of work.
5. Write unit tests. I still do it in the later stages of the production cycle, when people start to go crazy. Treat this as a checklist of the health of your product. Do it often.

Again objection?

“Rands, if I write code, I will confuse my team. They will not know who I am - a manager or a developer. "

Good.

Yes, I said: “Good!” I am glad that you think that you can confuse your team only by swimming in the pond of developers. Everything is simple: the boundaries between the various roles in the development of software are currently very blurred. User interface guys do what you can generally call JavaScript and CSS programming. Developers are learning more and more about user interaction design. People communicate with each other and learn about mistakes, about theft of someone else's code, and also that there is no valid reason for the manager not to be able to participate in this massive, global, cross-pollinated information orgy.

In addition, you also want to be part of a team consisting of easily replaceable components? This will not just make your team more agile, it will give each member an opportunity to see the product and the company from various points of view. How can you even more respect Frank, the cool guy responsible for the layout, if not after seeing the simple elegance of his build scripts?

I don't want confusion and chaos in your team. On the contrary, I want to make communication in your team more efficient. I am sure that if you yourself are involved in creating a product and working on functions, you will be closer to your team. And more importantly, you will be closer to constant changes in the software development process within your organization.

Do not stop developing

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

“The coder is a brainless machine! A monkey! A coder doesn’t do anything 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 newly minted executives: “Stop writing code!” Not because by this I’m supposed to be coders, but rather because I proactively invite them to start ignoring one of the most important parts of their work are software development.

So, I finished 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 not yet left Silicon Valley. Over the past 20 years, Michael has worked in a variety of innovative companies, including Apple, Netscape, Symantec, Borland, Palantir, Pinterest, as well as participate in a startup that slowly sailed into oblivion.

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

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

»More information about the book can be found on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley a 20% discount on the coupon - Managing Humans

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

PS: 7% of the cost of the book will go to the translation of new computer books, a list of books submitted to the printing press here .