Managing a tech team can be one of the hardest things in the world. If you are a manager, you need to work with experts in many areas, coordinate product requirements with your superiors, work with peers who coordinate product deliverables, and work with peers who translate product features into technical requirements, and lead direct reporting to your team and more. In some bad times, you have to deal with coworkers who will drive away your autistic newspaper delivery kid .
I've worked as a development manager, development director, and as a developer, and over the past few decades, I've experienced many very different "management styles" on both sides of managing technical teams. From the technical team's point of view, it is necessary to be a good technical manager, and I will give some suggestions.
First of all, the working environment of technicians is always changing rapidly, and I think how to be a good technical manager is a very important topic. Over the past two decades, we have seen a dramatic shift in the paradigm of software development. In most organizations, software development cycles have become shorter, and management has put more pressure on product development because of quarterly profitability goals. For many start-ups, new software products need to be released in the first place. These situations have led to the use of various methods of change management in software development. (Refer to PMP Traditional Project Management or Change Management in Agile Approach)
I understood the first truth when I was a developer. My boss asked me at the time, do you know how your work contributes to the company?
Me: "Uh... me, I'm just writing code. 』
Boss: "Okay, you're writing code. Let me ask you another way, how much profit do you think each line of code you write will make your company profitable? 』
Me: "(Brain exploding...) Oh, isn't it? I feel like, I can't...I never... uh...what are you talking about? 』
My boss explained to me afterwards that the idea of the company was that every developer should know their contribution to the company. Of course this is not about how much each line of code can contribute, the main point is that you know that your work will have an impact on the company's bottom line. Your work affects the product you develop that will help the company make money or save money over its life cycle. If you can get these profit or saving figures, divide the company's investment (the salary income of the developers on the project), and you can know the approximate profit of your project. After listening to these words, I suddenly froze.
The significance of this is that, in the real business world, I'm here to quote Michael Douglas with a black back on the benefits of greed: For companies, it's all about making money. (See the film Wall Street starring Michael Douglas) . However, as developers, we focus on developing this artistry. We create code that solves problems and gets things done faster, better, and more gracefully than ever before. We work like painters on canvas to perfection, create from scratch, and develop exciting, blockbuster software that has anything to do with profit?
Technical managers are like the gatekeepers of the "zoo" (think programmers...). They should be able to use our language, understand our labor, understand our problems, and share the joy of victory with us. At the same time, when they are not doing these things, they give us feedback, give us the needs of the product, develop project budgets on our behalf with their superiors and colleagues at the same level, and confirm the cost of development and the size of the team. When a glossy sales sister promises a customer a product feature that isn't in the current development plan because she wants to meet her monthly sales target, they help us explain why this situation is causing the product release date to be delayed. a week later.
Managers are the lubricant of the company's machinery, the sergeant-major in the company's army. They know how to get things done, when to be tight and when to be loose. Simply put, as a developer, your probability of success at work is basically proportional to your boss's professional skills and job effectiveness. Throughout my career in the workplace, I have come to cherish and appreciate great managers, and I know that truly great managers are as rare as winning the lottery. After reading the article below, you can find out if you have won the "Good Manager" lottery.
1. Great managers connect teams and individuals | Managers Connect
- A great manager listens to the thoughts and concerns of his team. He will measure the feedback from the team within the broad framework of the company's requirements, trying to achieve a balance between product requirements, delivery dates and realities.
- A great manager will believe that his team is telling the truth all the time, and only the truth, and he will distinguish between right and wrong without emotion.
- A great manager balances the needs of the team with the needs of the company, and he can follow through on a project plan that meets multiple requirements at the same time. Because he believed it was the right thing to do, and in most cases, it was the only way to success.
- A great manager will be in close communication with the entire team and all members of it from time to time. He will know what the team's challenges are and what the team or the individuals in it should do to be successful.
- A great manager will share successful experiences with the team and the company, and at the same time he will make sure the team gets the credit it deserves. You're always getting constant, timely feedback from your boss about your job performance, your progress on your goals, and advice on how to improve yourself, so you always know where you're going in your career How's it going.
2. Good Managers Manage the Task | Managers Manage the Task
- A great manager should first be a person with a technical background. As a developer, when you tell your boss that you need to refactor a particular method because you find that some non-re-entrant function will break the system while running Should be able to know what you're talking about, or at least acknowledge your ability to solve the problem.
- A great manager has a technical foundation. Although he may no longer be an expert in a certain area, he still has considerable technical ability to participate in technical discussions of the team or give methodological advice in difficult situations. and help.
- A great manager knows that the technologist he's hiring is you, not himself, so it's your responsibility to provide solutions when problems arise. Good managers manage tasks, not technology.
- A great manager doesn't impose specific skills on you in a project plan because of his experience in a specific technical field, digging holes for you. He recognized that there are usually many ways to solve a problem, and the experience and methods of many years ago may not be applicable today. He does not force technical design decisions without considering all possible options, nor does he impose certain technical solutions on the team because he has frequently used them in the past.
- A great manager knows that technology is constantly changing and evolving, and that the person who finds the solution to a particular task and implements the best solution is the developer.
3. A good manager is good at managing | Managers Manage
A great manager is one who manages time, tasks, needs, norms, resources, and people well. He will have the ability to see the whole forest, but also he believes that you as a developer can take care of the trees in the whole forest. He'll keep an eye on your workload and see how you're progressing in every possible way. After all, great managers should use all the necessary management methods and tools to track the work and progress of their teams. This means that your team should have tools to track and report on day-to-day development tasks. Such tools can be simple defect tracking systems (like Mantis or Bugzilla ), or complete systems designed based on agile development processes (like Greehopper ). Either way, these tools will allow your boss to manage projects in a non-active way. At the same time, these kinds of tools can also remind you when your boss should be actively involved in the project.
一个卓越的经理不会以“微管理”的方式来管理你的工作（除非你在工作上表现实在很差），而且不会经常每天通过各种可能的方式来骚扰你，来获得你最新的工作进展情况。 他知道在你解决困难问题的时候，你的大脑需要一个不被打扰的环境，任何打扰只会拖延解决问题的时间。他会知道你什么时候需要这样的环境来完成工作。
如果一个卓越的经理不知道为什么你对一项工作的估测时间增大之时，他会需要你提供时间估测的具体分析，并和你一起探讨。 如果需要对你的时间估测进行改动的话， 他会征得你的同意，而不是强行地进行更改。 另外，当计划外的工作被添加到你的计划中的时候，他会重新安排计划，以确保你能有足够的时间来完成这些工作。（《为什么程序员总是不能准确估测项目时间》）
一个卓越的经理会为你提供你所需要的所有资源，以确保你能够在规定的时间内完成工作。 但是，如果你需要的新硬件、软件、或是对工作环境的改变超出了目前项目允许的范围，只要你证明这些变化的确能够提高你的工作效率，他会同意的。 作为一个技术团队的一员， 你的职责是理解投资回报（Return of Investment, ROI）的基本概念。这样的话， 你就能像你的老板描述问什么项目计划外的支出能够帮助公司获得更多的回报。
4. 优秀的经理要尊重他人 | Managers Respect
一个卓越的经理会尊重他的团队的专业技能、 时间安排以及各种诉求。 他会给团队成员提供各种需要的工具来帮助他们在规定的时间内完成事先承诺的工作。 他会尊重你的个人生活和职业发展。当员工需要处理办公室里或日常生活中碰到的各种问题时，他会灵活安排员工的工作。对一个卓越的经理来说，只要团队的工作在规定的时间内完成，他不会要求所有人严格按照进度去工作， 他也不会过度关注每一项工作何时完成。 卓越的经理人知道在特殊状况下团队需要额外的时间来完成一项工作，但他们知道，当团队夜以继日的在每天晚上、周末、假日加班的时候， 这是例外，并不是常态。一个卓越的经理理解当团队一周工作60个小时以上的时候， 这是因为团队想这么干，并不是被逼的。 如果员工是被迫如此加班的话，他会意识到这是他自己在开发任务的时间管理上有问题，而不是因为团队的能力问题造成的。
5. 优秀的经理要代表团队 | Manager’s Represent
- 一个卓越的经理会在各个方面代表他的团队，他会成为他所代领的卓越的团队的一个真实写照。 他会是一个卓越的领导者，被他的团队视为是一个贡献者而不是一个拖油瓶。
- 一个卓越的经理会起到标杆的作用，同时他会向所有的团队成员证明他自己也会付出个人的努力来帮助团队获得成功。如果一个经理期望自己的团队一天工作整8个小时，那么他自己也要工作同样长的时间。卓越的经理是那种“按我做的去做”而不是“按我说的去做”的那种老板。
- 一个卓越的经理会以极大的热情在团队、部门、公司范围内表彰员工的杰出表现。他会经常对有对贡献的员工在公众场合进行表扬，同时确保他们得到物质上的奖励。相反，如果团队失败了， 他会认为这也是自己的失败。
- 一个卓越的经理会和他的团队一起分析一个特定任务或事件失败的原因，这样他们就可以采取一些措施来防止再犯同样的错误。他会为团队的成功负责， 他也会为团队的失败担负一样的责任。
我完全了解一个经理的职责远远超出了他所带领的团队。我试图从一个团队成员，而不是一个一线经理，或是一个总监的角度来写这篇文章。对程序员来说，在基层工作的一个好处是当你不知道你的上级在做什么的时候，你可以随便批评他们。相信我，一个一线的技术经理每天的工作包含了很多和管理团队无关的事情。如果你觉得你老板的工作很容易，或者你会比他们做得更好，为什么不去试一下做你老板在做的事情？我觉得你是不会想要他们的工作或是相应而来的压力的。
如果一个团队有幸能够得到一位卓越的技术经理，这支团队应当积极地保护甚至培养和他们老板之间的关系。通常，开发团队可以使用他们老板不知道的方法，通过额外的付出和努力来帮助他们的老板成功。一个卓越的经理会关心他的团队，同样的，一支卓越的团队也会如此地关心他们的老板。长此以往，团队和经理成为了有机的一体， 像剑圣一般坚不可摧，战无不胜，成为组织中其他团队的标杆。
在卓越团队中的每一个人，都应该反映出这支团队的经理的技能、态度和道德水准。