How to fumble your promotion from developer to manager

People are sub-components, some with severe tech debt

When engineers become managers, they are simply moving up the stack. The system they now work on is a group of people running a process, and instead of learning how people work, they should instead treat them as software components and use all their existing system design skills.

People are like objects: they interact with each other by sending messages, protect their private data, use each other as examples of prototypical behavior, and have limited lifetimes. Based on this idea, you can design the SDLC (Software Development Lifecycle), get it running, and then go read Hacker News in peace.

You should only talk to your people if there are system hiccups:

• When roles aren’t clearly defined, and people float between jobs and help each other out, that violates the Single Responsibility Principle. Fix it by showing someone the door or enforcing stricter roles: developers can’t test, testers can’t improve requirements, and product managers can’t debug. Rember: if you show someone the door, let’s call her Liskov, she can be substituted by another of the same type easily.

• When employees give you feedback, remember that you are open for extension but closed for modification. You can make tiny tweaks to your core beliefs, but the internal details of your mental models of how people work are fixed.

• Don’t Repeat Yourself: if new employees don’t listen to you, then it is their fault that they don’t know your vision.

• When employees come to talk to you, be aloof and speak in generalities - abstract away who you are and allow them to interact and depend on the idea of a manager, not some concrete person.

• KISS (Keep it Simple Stupid): remember to say this to people when they bring you their complex people problems.