When I resigned from my developer job at a company once, some middle managers suggested a 2-on-1 meeting with me to see if they could convince me to stay. They asked me for my mid term career plans, and I replied: “I want to be a world class software developer, working five times faster than average, and I expect to earn an appropriate salary that matches my productivity.”
They realized they could not offer me a career path like that; because being a service company, their business model is to rent out lots of low-paid developers to customer projects and produce as many billable hours as possible, not letting a highly skilled and expensive team build an awesome product in a few weeks. I already anticipated that earlier and had applied to a couple of product companies, so there was no way I was going to stay.
Sure as hell I did not plan to quit coding and start drawing pictures of systems as a so called architect, or even worse, become a project manager. During my career, I got used to see my supervisors as the people who stopped being engineers because they were not good at it, or were not smart enough to become engineers in the first place. While my job was to solve interesting problems and build real working stuff, those lower managers had to attend meetings, fill out excel sheets and attend more meetings.
I was totally aware that some of them were good at their job and others were not. The bad
project managers would interfere with engineerings decisions they were not qualified to make, try to push away responsibility for everything that goes wrong and always report to their superiors that the project is progressing as planned (ha, ha!).
The good managers set clear priorities for the upcoming work, shield the team against most of the communication noise from other parts of the organization, and keep motivation high by recognizing good work and maintaining a nice atmosphere. Although I appreciated that someone did the job, it seemed absolutely not desirable for me.
Last week I listened to an episode of software engineering radio featuring Jonathan Nightingale on engineering management, which changed my perspective a bit.
You should definitely go and listen to the whole interview, but I’m going to give you the most impacting statements right here.
He raises the question from a start up companie’s perspective: Why should I put someone as manager on a team of engineers, and pay an additional salary although he is not producing anything? But the point is: If you have a team of eight engineers without effective management, you pay eight salaries but probably get three or four engineers worth of productivity out of it, for various reasons.
He mentiones products that are half built and than abandoned, or products that are fully built but useless because they are not aligned with the means of the company.
(I buy his explanation immediately: I have in fact seen the productivity of a six person engineering team approaching zero, because we were told to work on components supposed to contribute to a huge system, but nobody was making sure that the pieces actually worked together (I mean in code, not on the drawings) or even the specification made sense. A year after the planned delivery date, there was still no release in sight, management removed nearly everybody from the teams and sent other people in to rescue the project…)
A good engineering manager may cost an additional salary, but if he can get seven or eight developers worth of work out of the team, that extra money has easily paid off. Jonathan states, that manager’s job is to make the team as productive as possible. Providing mentorship to the team members (so the manager should be a former developer himself), aligning the team’s work with the business needs, and establish good practices in the team.
You know what? That’s what I love to do anyways!
As I said, I just enjoy feeling productive and contribute as much as possible to great products. I also like it to teach younger developers whatever they can learn from me, and discuss possible approaches with more experienced developers to find out what works best for the current situation.
One time Jonathan mentions starting as a senior engineer and evolving into that role of a team lead. This path sounds very appealing to me.
An other interesting point from the interview is, that managing requires skills that should be learned, not simply “being good with people”. This might be another reason why it didn’t seem desirable to me to become a manager: The feeling that there is nothing else to it than doing the busy work of communicating all the time.
But if there are skills to be mastered and value to be created – challenge accepted!