How to drive away your best engineers

As someone who has been in industry for over 20 years, I have been spending a lot of time thinking about and living thru this. For me, my manager and my relationship with him/her is probably the most important aspect of a job. A few things that I have learned:

* Manager maturity. Young managers tend to be very hands on, they will naturally micro manage. More times than not they were previously an engineer, possibly in the role your currently in, so they continue that role, but with manager power and authority. Young managers work best with younger employees. Young engineers need hands on managers to explain things and mentor them, and that plays well into a young managers need to manage things. Older, experienced, and more mature managers tend to learn what their value is and where they are important. Usually that means listening, coaching, and communicating. Technology has literally changed under their feet, so they tend to be hands off. They also rely on their team more to make decisions and drive towards success. They depend on you. These managers tend to work well with senior engineers (a senior engineer is someone with decade(s) of experience).

* Conflict. A few years ago I did a handful of manager interviews with some top tier tech companies. I was a bit dismayed that these companies were not looking for nice guy managers who values things like compassion and supporting their employees, and possibly even be friends with them. Rather, they want managers who are hard, can wield power, and comfortable with conflict. Conflict here means that management and employees are in constant dispute over literally everything. This means that managers are constantly squeezing work out of you and will have no problem introducing politics and other authority techniques into their day to day managing.

* Communication. Open communication is extremely important. What I find is that when you have many layers of management, decisions are made using information which needs to be withheld from lower levels (or decisions are made based on no information!). When it reaches the lower level, it seemingly makes no sense and can be confusing. Good management communicates everything and does so transparently. This way everyone understands the what and the why. If you don't agree, given you know the why, then you are at least better prepared to pitch an alternative or make the needed changes. If the why is something contentious like you or the team is underperforming, then again, its best that is communicated so everyone has the power to make corrective action, if they choose.

I think a lot of this comes down to culture. A good culture values engineers and adapts to making them happy, as that is how you get the most productive engineers.

Yep, janky needs to look janky and be slow and break. Otherwise they'll think it already works :D

That's also why you always keep the UI on par with the backend as far as completion goes. If the UI looks complete -> people think the backend is complete too.

Only Coder GUIs until the backend is done :)

I argue it's democracy. (That can save Nations and presumably companies)

Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work.

I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate.

I mean if a boss is sexually harassing all the female staff and then asks for their vote at the next manager election, you won't need HR intervention to get rid of him.

I have no idea truly how this might work, but I do think that if the employees of a company voted how to run it you might find some unusual outcomes.

As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.

Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...