lessons I am learning
- You can do one-on-ones really well
- Productivity looks totally different than when you coded more. You can't measure your success by your old metrics
- Just like code, there are blog posts and videos about how to do better that really help
- The reason I feel overwhelmed is because I am currently an engineering manager, a product manager, and the face of the tech team in business meetings, and I am still learning how to improve in all of those roles
- People need to be shown respect by a manager, and one way to do that is by respecting their time
- Managing is really about being a 💩 ☔ for the people you manage
- In other words, managers are there to protect everyone "below" them on the org chart from as much crap from above as possible,
"[Your] role is to protect it from pointless meetings,
unnecessary interruptions and random changes
so they can focus on doing their job."
- Honesty and transparency are pretty much always the way to go.
- Read the body language of the engineer. Often will tell a lot about his condition and if he is being transparent (honest)
- Be empirical about people things. For example, estimates
- Protect the engineers' flow state!
- Senior engineers reduce risk, but
Through trial and error, engineers can identify the sorts of problems they enjoy solving.
A senior engineer should find a company which both has those problems, and knows it.
Anything else will lead to frustration, and eventually apathy.
- Read this
- Language and phrasing is really important. This article is very relevant to product and marketing, but it is also worth keeping in mind when talking to those that you manage. As an engineer, I sometimes pretend that humans only converse to exchange information, and make decisions completely rationally. But, even engineers don't really act that way.
- Be empathetic! This post on Quora was in repsonse to the question "What should all non-technical managers know about managing software developers?", but all the advice applies equally to technical managers. It suggests saying things like “Users are loving this new feature” and “If you need more time we can make that happen.” By focusing on what you should say, and not what your internal state should be (and expecting that to cause you to say the right things), it really drives home how important it is to respect your engineers enough to see things from their point of view.
I guess it's directed at non-technical managers because it is assumed the technical managers will remember what it is like to be an engineer... and maybe other technical managers do. But I am too overwhelmed with the dozen things I need to get done, missing my family, and a bunch of other dumb shit to have what it takes to construct a high-fidelity simulation of the person in front of me's internal state. It's nice to be able to augment a quick simulation of them with some simple rules like "praise is good," "say something that indicates you value their time and effort." The fact that rules like that are helpful doesn't mean I am not being genuine with my praise, just that I don't always do the best job expressing gratitude to the people near me (my wife will attest to that).
- Break down barriers between teams. Build teams you can trust. Make everyone responsible for hitting business objectives. Automate as much as possible. Always shorten feedback loops. Continually remind yourself about Agile and DevOps culture.
- Being a great manager means being a great leader. Optimize for trust when faced with difficult decisions. Communicating clearly to your team is very important, andyou communicate clearly when your thinking is clear. Who you hire and fire matters, a lot. Also, have integrity and be committed.
- Fill key roles and teams with top talent. Inspired employees are substantially more productive. Other obvious-yet-easy-to-forget things: Why Employees At Apple And Google Are More Productive
- Teams are good; factions are bad. Fighting Factions: How Startups Can Scale Without Mutiny talks about obvious things like hiring and onboarding, but also something that to me was very interesting: technological factions. They talk about the big faction between the Java and Scala camps at Twitter. Sure, on one level it’s a classic engineering debate. But there’s a much deeper philosophical issue at play. “It raises the question: What's more important? Is it shipping code quickly, or shipping the right code? Those values-based questions have broad implications and letting technological divides deepen is a recipe for factions,” says Loftesness. “It took us years to come to a resolution. And in the meantime, teams grew and those divisions persisted and hardened throughout the company. It led to other conflicts between those groups — and even departures.” The article offers an interesting solution.
- Your employees will eventually apply for other jobs. They will be happier if their resumes accurately reflect their skills and accomplishments. Help with this by sometimes focusing reviews on "achievements", defined to mean "Concrete numbers that showcase your talent... can be measured with a number, monetary value, or percentage"