Dedicated to project managers (and those who dream of becoming a boss).
Writing tons of code is hard, but managing people is even harder! 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 Rands) succeeded. You are waiting for fictional stories about fictional people with incredibly useful (albeit fictional) experiences. This is how Rands shares his diverse, sometimes bizarre, experience gained over the years working in large IT corporations: Apple, Pinterest, Palantir, Netscape, Symantec, and others.
Are you a project manager? Or do you want to understand what your damn boss does all day? Rands will teach you how to survive in the Toxic World of Pouted Turkeys and thrive in the general madness of dysfunctional bright people. In this strange community of maniacal nerds, there are even stranger beings - managers who, through a mystical organizational ritual, have gained power over the plans, thoughts and bank accounts of many people.
This book is unlike any management or leadership manual. Michael Lopp doesn't hide anything, he just tells it like it is (maybe not all stories should be made public :P). But only in this way will you understand how to survive with such a boss, how to manage geeks and nerds, and how to bring “that fucking project” to a happy ending!
Excerpt. Engineering mentality
Reflections on the topic: should you continue to write code
Rands' book on Rules for Leaders has a very short list of modern managerial must-dos. 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 management method for one employee will be a real disaster for another. This idea is the first item on the manager's "must-do" list:
Stay flexible!
Thinking you already know everything is a very bad idea. In a situation where the only constant fact is that the world is constantly changing, flexibility becomes the only correct position.
Paradoxically, the second item on the list is surprisingly inflexible. However, this item is my personal favorite, because I believe that it is it that helps to create the foundation for managerial growth. This paragraph reads:
Stop writing code!
In theory, if you want to be a leader, you should learn to trust those who work for you and completely hand over the code to them. This advice is usually difficult to digest, especially for new leaders. Probably one of the reasons why they became leaders is because of their productivity in development, and when things go wrong, their first reaction is to resort to skills that they are completely confident in, that is, their ability to write code.
When I see a new leader descend to code, I tell him, “We know you can code. The question is: 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 make sure you can get your team to solve problems themselves, without you 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 there to be many like you.
Good advice, right? Scale. Management. Responsibility. Such common buzzwords. Too bad the advice is wrong.
Incorrect?
Yeah. Wrong advice! Not 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 incorrect! Yes… Start programming again. Get started with Python and Ruby. Yes, I'm serious! Your career depends on it!”
When I started my software engineering career at Borland, I was on the Paradox for Windows team, which was a huge team. Only one application developers were 13 people. If you add people from other teams who were also constantly working on key technologies for this project, such as the core database engine and core application services, you had 50 engineers directly involved in the development of this product.
No other team I've ever worked on even comes close to that size. In fact, with each passing year, the number of people in the team I work on is gradually decreasing. What is going on? Are we developers collectively getting smarter and smarter? No, we're just spreading the load.
What have developers been doing for the last 20 years? During this time, we wrote a shitload of code. Sea of code! We wrote so much code that we decided it would be nice to simplify everything and move 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! Search your name on Google or on Github and you'll see code that you've long forgotten about, but anyone can find. Scary, right? Did you know that code lives forever? Yes, he lives forever.
The code lives forever. And good code not only lives forever, it grows because those who appreciate it constantly make sure that it does not lose its freshness. This pile of high-quality, well-maintained code helps reduce the average size of an engineering team because it allows us to focus on existing code rather than writing new code, and get the job done with fewer people and in a shorter amount of time.
This line of reasoning sounds depressing, but the idea is that we are all just a bunch of integration automata using duct tape to connect different pieces of existing things together to create a slightly different version of the same thing. This is a classic outsourcing-loving top management mindset. “Anyone who knows how to use Google and who has duct tape can do this! Then why are we paying a lot of money to our machines?”
We pay these management guys really big money, and they think such nonsense. Once again, my key message is that there are many brilliant and very diligent developers on our planet; they are really brilliant and diligent, although they have not spent a single minute sitting in accredited universities. Oh yes, there are more and more of them now!
I am not suggesting that you start worrying about your place just because some brilliant 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, five of them as a manager, and you think: “I already know how software is developed.” Yes, you know. Bye…
Stop writing code, but...
If you follow my original 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 do not actively use outsourcing. Machines don't create, they produce. Well-designed processes can save a lot of money, but they won't bring anything new to our world.
If you have a small team and they do a lot for little money, then the idea of stopping coding seems like a bad career decision to me. 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 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 keep writing code, no one will believe that I can grow.”
I want to ask you this: Ever since you sat down in your "I'll be CEO soon!" chair, have you noticed that the software development landscape is changing even within your company? If your answer is yes, then I will ask you another question: how exactly is it changing 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 field of software development is changing at this very second. How are you even going to grow if you are slowly but surely forgetting how to develop software?
My advice is not to commit yourself to implementing tons of features for your next product. You need to constantly take action to stay on top of how your team is building software. You can do this both as a director and as a vice president. Something else?
"Ugh, Rands! But someone has to be the referee! Someone needs to see the big picture. If I write code, I will lose sight of the perspective.”
You still have to be the arbitrator, 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 "We are all doomed" for 30 minutes. ! But on top of all that, you need to keep an engineering mindset in you, and you don't have to be a full-time programmer to do that.
My tips for keeping the engineering mentality:
- Use the development environment. This means that you should be familiar with your team's tools, including the code build system, version control, and programming language. As a result, you will be fluent in the language your team uses when talking about product development. It will also allow you to continue using your favorite text editor which works great.
- You must be able to draw a detailed architectural diagram describing your product on any surface at any time. Now I don't mean the simplified version with three cells and two arrows. You must know the detailed diagram of the product. The most difficult. Not just any nice scheme, but a scheme that is difficult to explain. It 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.
- Take over the implementation of one of the functions. I'm literally shuddering as I write this because there are a lot of hidden dangers at this point, but I'm really not sure that you can complete point #1 and #2 without taking on at least one feature. . By implementing one of the features yourself, you will not only be actively involved in the development process, it will also allow you to periodically switch from the role of "Head in charge of everything" to the role of "Person in charge of implementing one of the features." This humble and unassuming attitude will remind you of the importance of small decisions.
- I'm still shaking all over. It seems that someone is already yelling at me: “The manager who took over the implementation of the function?! (And I agree with him!) Yes, you are still the leader, which means it should be some small function, okay? Yes, you still have a lot to do. If you can't possibly take over the implementation of a feature, then I have a fallback tip for you: focus on fixing some bugs. In this case, you will not feel the joy of creation, but you will have an understanding of how the product is created, which means that you will never be left out of work.
- Write unit tests. I still do it late in the production cycle when people start to go crazy. Consider this as a checklist for the health of your product. Do it often.
Another objection?
“Rands, if I write code, I will confuse my team. They won't know if I'm a manager or a developer."
All right.
Yes, I said "OK!" I'm glad you think you can confuse your team just by swimming in the dev pool. Everything is simple here: the boundaries between different roles in the field of software development are currently very blurred. The UI guys are doing what can generally be called JavaScript and CSS programming. Developers are learning more and more about user experience design. People communicate with each other and learn about bugs, code theft, and that there is no good reason why a leader should not participate in this massive, global, cross-pollinated information bacchanalia.
Besides, you want to be part of a team of easily interchangeable building blocks, don't you? This will not only make your team more nimble, it will give each team member the opportunity to see the product and the company from a variety of perspectives. How can you have any more respect for Frank, that calm guy in charge of linking, if not after seeing the simple elegance of his build scripts?
I don't want your team to be confused and chaotic. On the contrary, I want your team to communicate more effectively. I am sure that if you yourself participate in the creation of a product and work on features, you will be closer to your team. And more importantly, you will be closer to the constant changes in the software development process within your organization.
Don't stop developing
A colleague of mine at Borland once verbally attacked me for calling her a "coder".
“Rands, the coder is a mindless machine! Monkey! The coder doesn't do anything important except write boring lines of useless code. I'm not a coder, I'm a software developer!
She was right, she would have hated my initial advice to new CEOs: “Stop writing code!” Not because I'm kind of suggesting they're coders, but more because I'm proactively suggesting they start ignoring one of the most important parts of their job, software development.
So I've updated 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 don't stop developing software.
About the Developer
Michael Lopp is a veteran software engineer who still hasn't left Silicon Valley. Over the past 20 years, Michael has worked in a variety of innovative companies, including Apple, Netscape, Symantec, Borland, Palantir, Pinterest, and also participated in a startup that slowly drifted into oblivion.
In addition to his work, Michael runs a popular technology and management blog under the pseudonym Rands, where he discusses ideas in the field of management with readers, expresses concern about the constant need to keep abreast and explains that, despite the generous rewards for creating a product, your success is only possible thanks to your team. The blog can be found here .
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 being busy.
» For more information about the book, please visit
»
»
For Habitants, a 20% discount on a coupon - Managing People
Upon payment for 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 handed over to the printing house .
Source: habr.com