Project management is a path that interests many software engineers and technical operations people. In some ways, it seems like a natural move – engineers have the technical knowledge to understand estimates and risks, to plan contingency, and to know the real story on the progress that’s being made. But there are some downsides, and anyone thinking about making the change should be prepared to handle them (or understand when they’re uncomfortable enough that the move is just not a good fit). Probably the biggest change is that instead of focusing on safeguarding the technical integrity, as a software engineer does, a project manager must balance technical nirvana with the business needs. It’s a big and difficult leap. As engineers, we all want the best possible technical solution. That’s an admirable goal – but sometimes the best possible solution will take too long, cost too much, affect other users, be unmaintainable operationally, be outside the company strategy – the list goes on. It’s the project manager’s job to understand the business imperatives as well as understanding the technical trade-offs, ensure the business needs are met, and choose which (if any) battles for technical purity are worth fighting in the context of the business needs. After all, if the business needs aren’t met the engineers are out of a job, so truly it’s in everyone’s best interest. Another difficult change is that as software engineers we typically want to make everyone happy. Project managers, by definition, are unlikely to make everyone happy. Project managers have to make tough decisions and be firm about them. They only way to do this successfully is to base decisions on what is best for the business – and do that absolutely consistently. Everyone on the project, as well as management, needs to have faith that the project manager is absolutely unbiased, interested only in getting out the best possible product that meets the business needs. Finally, a project manager’s view of the water glass has to be that it might spill – how do we prevent that and if it happens how do we clean it up with the least damage? That’s rarely the viewpoint of software engineers – as software engineers, we are endlessly optimistic. When the project manager puts together schedules, contingency plans, and risk analyses she has to be on the pessimistic side of realistic – without insulting the software engineers or seeming untrusting. It’s a difficult balance to strike, particularly for new project managers working with the software engineers they already know and have worked with as a technical implementer. So there you have it – tougher, balanced, and realistic. New project managers coming from the engineering side of the house should be prepared to deal with all of these changes or give it up and choose a path that fits more comfortably.