Opinion on: Truth and Consequences of the Technical TrackNov 14, 2015 · 4 minute read · Comments
Howdy, I read an article and felt I wanted to add something.
First I’m going to summarize this blog post. from a CTO named Camille. It’s a response to a post from Dan McKinnely. I’ll give a short summary of the main points. Then I will give hopefully useful addition on these two great articles which I enjoyed. I’ll use both Camille’s and Dan’s names in the post.
Camille is trying to make tech employees appreciate management more. That’s both noble, and important. Managers should be appreciated, their job can be important and difficult. She values management in tech and wants to show that they too makes sacrifices for their job. A big assumption the author makes, companies need tree like management structures to run. The higher positions make broader decisions, thus you need levels of management. She feels as a great engineer, she has only the impact of one. When you’re a great manager you not limited by this. She felt that becoming a manager was necessary “in order to have the broader ability to focus people on projects where I felt their impact would make more difference on the company.”
She mentions people who don’t want to do management shouldn’t get promoted. Both articles agree on this. At some point she thinks we are giving undeserved raises to tech employees. These employees don’t give enough value to the company. Both managers and tech workers should have to prove that they are increasing their area of value. Not by a constant, but by a multiplier (my words). Camille makes an interesting point. All companies should be promoting those who create business value.
Dan believes promoting somone to management should take a lot of thought. Make sure the promotee thinks hard too. He doesn’t believe the current level of management overhead is good or benefitial. Dan makes a crucial point. Given one a senior manager and one a senior dev who make roughly the same, developers get no super powers. Managers can hire, fire, make meetings, cancel meetings, choose what gets worked on, etc. Developers often only get to choose what and how they themselves work. Developers having a small silo of influence can cause developers to become nihilistic1.
My Admittedly Naive Opinion
I believe that companies do not need a top down decision making approach. It’s possible to give a lot of decision making power to the people who know best. These are often not people high up on the management ladder, instead they are at the bottom. There is a way to give engineers more impact and reduce the number of managers. You can trust the employees to make good decisions and let them be a big part of the decision making process.
“What if the employees make a bad decision?” Two options:
- Accept the risk, after all managers must make a lot of bad decisions too.
- Mitigate the risk, train your employees better. Get them more involved with the business, that doesn’t mean they have to change roles. Here’s an anecdote
As a tech worker autonomy might equal your ability to achieve managements business goals. Generally you are only given autonomy while you are producing company value. I agree with this to a certain extend. Company value trumps most else. Camille doesn’t say why this changes with becoming management. I think it’s exactly the same - you’re always accontable to someone.
A manager in a traditional company should ‘run interference’ for their employees. This enables employees to do work they see as valuable to the business. Further, if a manager see it’s good for the engineer that’s also good for the company. I believe a company is their employees.
Managers of technical teams should first be developers, ops people, or fill in the blank. In other words I think managers should all understand how difficult good programming is. Neither of the authors would dispute this but it’s important. I think it’s important for managers to contribute occasional code. The Anti-fragile author, Talib Nassim believes that to make economic predictions you have to be invested in them. His term is “having skin in the game”. This holds for software architects (especially), managers, maybe even CTO’s (I can’t say).
We don’t trust our employees to give good business input in their area of expertise. That might be because they don’t understand the business, or aren’t prepared to. If thats currently the industry, this management discussion is NOT our biggest problem. Our biggest problem is that we aren’t investing, trusting, and empowering our employees.
- Nihilism is a philosophical doctrine that suggests the lack of belief in one or more reputedly meaningful aspects of life. [return]