Why do most coders hate managers?

I spent half of my career as a managed developer, and the other half as managing (and working together with) developers.

As an employee, I’ve had great managers, and terrible hires who were incapable of working with a technical team.

Management 101 — not

That said, management is a craft that is designed to work with a team of individuals while complying with company goals and targets. Often there’s a misalignment between what a developer sees as a personal problem in a manager and what the company really needs.

Example being funded startups. If investors push for an early launch (MVP) of a product that hasn’t been properly tested and validated, this comes as a “burden” to the technical team regardless of the manager’s capabilities. Sure, there are nice ways to explain that and coordinate the process, and old-school army approaches from baby boomers who are used to a certain communication style not applicable with younger generations.

From my experience technical managers are often more inclined to work closely with software engineers due to the fact that they are familiar with the job and aware of the importance of taking care of technical debt, dealing with security and performance concerns, regular refactoring, continuous improvements, automated testing, continuous integration control, deployment processes and everything else that’s required for an ongoing product. Often non-technical managers (or ones that don’t come with a good track record of working with technical teams) can’t grasp those concepts right away and what is the value for the company.

Additionally, the management gig is a combination of soft-skills and understanding high-level business targets, which entails a long set of responsibilities — something that may be very stressful in a fast-paced environment and not apparent to developers who only see the dark side of the job.

Another common issue is the lack of procedures that nail down the management and communication process. We’ve gone through that nightmare when hiring 8 developers with different background a few years ago and expected all of them to work in the same manner.

Horrible mistake that took us half a year to sort out internally, through a lot of coaching, personal conversations, and writing several lengthy documents describing:

  • our tools (HipChat, Asana, GitHub etc)
  • communication protocol (reporting to other developers, QAs, management, customers)
  • templates for our project management system
  • required deliverables (what to provide, when to deploy, screenshots, use cases)
  • everything that happens between onboarding a project and delivering a version before moving to an ongoing retainer (together with the maintenance/support services to follow)

From our experience having these documents provided during the hiring process streamlines the workflow and transparently explains what would be expected by a developer. Then everyone within the company has to comply with those regulations — both developers, and managers. Any deviations could be reported so that the tone is back to normal.

From a management standpoint, there are dozens of different types of developers — and having hundreds of work styles may cause conflicts between some. For example, if you’re used to work with Pomodoro Technique — Wikipedia which requires uninterrupted time while the company workflow expects constant pings on Slack or Skype, there may be a conflict. A startup developer may be used to focusing on tons of code while an enterprise company comes with several layers of management, change order approvals, a ton of commenting and documentation etc.

Assembling the right culture is a notable challenge for the vast majority of the companies, and it’s something that should be discussed openly before starting a business relationship. Developers should ask more questions about the work style, working hours, what are the milestones of the project, what team members work in every team, what’s the company hierarchy, and everything around that. Managers should also spend time with both the team, and each developer separately, talking about the company goals and how to work closely in order to deliver results and grow together.

We are not enemies on the battlefield — working together and talking openly is the only way to succeed, or identify critical issues early enough before it’s too late.


Originally published at www.quora.com.