Shulou(Shulou.com)06/01 Report--

Eliot Horowitz is the founder and technical director of MongoDB.

In a technology company, software technical managers should spend no less than 30% of their time programming. Whether managing a team, a division, or an entire company, the technical manager's ability to perform his duties deteriorates significantly when he spends less than 30 percent of his time programming.

This assertion of mine may be the exact opposite of what I see software programmers wanting to be team leaders expect. Programmers expect to spend significantly less time coding with each promotion, and when they climb from "leader" to "manager," they should completely disengage from coding activities. Also, they expect to maintain familiarity with the codebase in a "mouth/eye, no hands" manner. The next higher level of leadership has nothing to do with coding (if any).

About a year ago, when my time was increasingly taken up by other things, such as hiring, management, meetings, etc., I found that as a technical leader, when the time spent on programming fell below a certain percentage, management effectiveness and productivity would be problematic. I wrote a short blog post about this experience and point of view before, but did not elaborate on it. I will discuss this point in more detail here.

Why do you insist on programming activities

Many people believe that managers should step back from the front lines and focus on big strategy and management. Of course, managers should spend most of their time on such things. But in an industry like ours, because we allow or require managers to program almost no more, reality is costing us dearly. Once a person stops coding, the vital connection between him and the things programmers care about deteriorates. When this happens, decisions, plans, and cadre relationships go awry, undermining the well-intentioned foundation that promoted technicians to managerial positions.

Project Development Assessment Capacity

One of the most important tricks in a programmer's treasure chest is estimating duration. Without the ability to predict accurately, the overall plan cannot be correctly formulated. As you know, programmers as a group are notorious for estimating durations. It couldn't be worse. In fact, when you get an estimated number from a programmer, the accepted method is to multiply it by two. Programmers tend to have a very optimistic attitude toward development, but if we use the "estimate traction" theory, we find that programming activities exhibit a particularly volatile character. Because we can implement a function in many ways, our estimates are unreliable until we get into the details.

technical debt

Another thing is that the technical manager must have firsthand knowledge of the impact of technical debt on the project. The term technical debt is very popular these days and is often used as a term to argue over whether to prioritize new features over old code. Those familiar with the meaning of the word "technical debt" are usually the easiest to argue with. As a technical manager, you don't just have to be familiar with these concepts; they play a direct role in your decision about when to pay off technical debt. Managers who write code often have more valuable information to judge when/how to make such decisions.

continuity of knowledge

I didn't choose 30% at random. Based on my own experience, if you spend enough time involved in development activities, you can easily keep track of any changes to the codebase. If you have too little time, your grasp of development dynamics is intermittent and cannot be connected. Once the thread was broken, I needed to re-thread it, and the penalty was wasted extra time.

shared responsibility

As the person in charge, you cannot have all decisions made or approved by you. But you need to understand the context and context of all decisions to support them. Ultimately, you are responsible for the consequences of these decisions, and your control over the project needs to match that responsibility.

Actively participate in programming to win team respect

Understand this: To be a successful manager, you need to serve your team members, facilitate development, and make sure they get things done. I wrote a blog post about how to diagnose and repair managers 'problematic relationships. But for administrative programmers, you need to love programming. Because your team is programming, if you set an example in programming, they will respect you.

Obstacles to 30%

Despite my best efforts, I still encountered a lot of obstacles in maintaining 30% of my coding time. These include the following:

A lot of work: in a startup, you always have a lot of work to do, and even after the company has grown and grown, how to prioritize the many things that matter is a test. The technical manager has a lot of responsibilities, and he will definitely occupy 70% of his time. Here are some:

Leading and caring for the team: This is the number one priority of a technology manager. You are no longer solely responsible for your own work; you are responsible for keeping your team at its best. It takes time to direct team tasks, resolve disputes, and think about how to optimize working conditions for productivity and comfort.

Decision Making: As responsibilities increase, technical managers need to spend more time on various strategic planning and coordination tasks. At first, it may just be technical decisions, but then product development and competitive strategy will take up a large part.

● Recruitment: Managers, directors, VPs, CTOs all need to form their own teams, sometimes quickly. A good recruiter can go a long way, and the technical manager's role in such matters is irreplaceable. Good technical managers actively communicate with their superiors and constantly recommend outstanding people in their teams.

Customers: As technical managers gain authority, they are often exposed. They would be taken to "sales meetings," expecting him to deliver some deep words. Or called in to put out a fire when an important customer is upset.

PR: Senior technical managers dedicate part of their time to public speaking, blogging, or publishing articles in newspapers. No matter how much effort you put into these activities, writing, editing, rehearsing, traveling, attending events, etc., all take time.

Reclaim time: The activities I mentioned above are all things a technical manager should invest time in. Here are some of the pitfalls I have found in my experience that have prevented me from trying to keep the 20% minimum coding time and still stand in front of me today, preventing me from getting back to my 30% goal.

Don't say no: High achievement means hard work; however, be sure to do things right, and the most important responsibility of a technical manager is to say no when your team is overburdened or close to it. If you don't say no at this point, others will start telling you what to do with your plans and deadlines.

Meetings: There's a huge cottage industry that's coming up with ideas for how to meet effectively, and for its own reasons. I've wasted more time in meetings than I have in my career. This is especially true for constant interviews or attending meetings where team leaders must attend.

losing strategy

When it comes to figuring out how to get my coding time back, there are a lot of ways that don't work.

● Sleep less: Although this method has great temptation for me, in fact, sacrificing sleep time has no effect. Your brain needs rest, and lack of sleep affects mood and productivity.

Looking only at headers: I thought this would work, but in practice, looking only at the headers of the submitted C++ code will do little to help you manage your work.

Focus: As a team leader, it may be okay for you to focus on one project in the codebase, but for a director or higher, you should be familiar with everything you are responsible for.

● Delegation: Sometimes in order to do more work, some things will be handed over to others at will, but in fact, some things like writing reports must be carefully instructed.

successful strategy

Despite all the dead ends, I found some ways to succeed:

Time Staging: There is very little time on my calendar that is not pre-allocated. It's obvious when you think about it. So I set aside some time specifically for programming. In practice, these periods are often reshuffled, although only eight hours per week are squeezed out, with completely different effects.

Delegate: Delegate skillfully, especially if you have strong ideas about how to execute and are capable of doing it. There are many reasons why a manager should object to delegating tasks, but virtually every reason should be treated as an existing problem that needs to be solved, not an insurmountable obstacle. Nothing frees you up more coding time than letting someone you trust run a meeting for you.

● Working hours: divide the time and try to avoid interruptions during working hours. In between these periods, I do things that are not important or require constant attention.

The last few moves

Here are some lessons for technical managers who find themselves trying to reach 30% but can't get close:

Learn how to read code. This is a completely different skill than writing code.

● Specify the meeting flow and maintain control over the meeting process. Don't attend any meetings that aren't scheduled.

·Use a good computer. Do you like MacBook Air? No, don't use it.

·Know how to access a development environment so that changes can be tested quickly.

·Remember that you are the one who divides the hour into five periods. If something takes an hour, mark it on your calendar.

20-30% is my own discovery. Yours may be different from mine. Evaluate your own (How long does it take you to fix an emergency bug? Do you know what the most troublesome piece of code in the codebase is? Find a random program and see if you know what it does. If not, you need more time.)

·Classify what to do when and what should be done. (Those of you who know about Getting Things Done (GTD) will recognize this as a basic productivity tip.)

·Finally, I've become more and more interested in putting things on paper lately. Contrary to what it feels like, printed instructions, a list of prioritized tasks on paper, or a piece of code, often serve as a counterbalance to spending a lot of time staring at the screen.

I hope these methods work for you. If you have any better tips, please let me know in the comments. Thank you very much.

Engineering Managers Should Code 30% of Their Time

From: Foreign Journal IT Review Network

Link: http://t.cn/8shflDi]

You may also be interested in these articles!

Say goodbye to programmers and become real programmers.

Programmers, please lay your professional foundation with algorithms and mathematics

One of the ways out for programmers is to have a skill, build their own boutique, and more

Programmer: Do what you love.

Where is the $500,000-a-year engineer?

An ordinary product manager: myself in my eyes

What should you know about jumping ship? A very thorough article about job hopping

IT career planning, testers, your value is not your salary

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.