Learning to be a Manager

The lessons in both Aaron's post and Reed's deck are deep, and they are closely related to things I've learned since the end of March when I came to this company, AnyClip was born, and I went from managing no one to being directly responsible for over 10 people.

Here are some lessons I've learned so far:

1. Make People Critical

   At AnyClip, we are lucky to have many star developers. We're also lucky to have a product and platform with many important and interesting components. So, instead of throwing tasks and responsibilities into "the pool" of developers, I've found we as a team get the most value and satisfaction when we find the right pairing between a developer and a component of the product or platform. When we find this pairing -- let's say Developer A owns the API services, Developer B the authentication system, Developer C the search algorithm, etc -- it makes each person critical to the company's success rather than incrementally helpful. Wouldn't you prefer to be critical rather than merely helpful? Wouldn't you rather have a team of critical people than a team of helpful people?

   What's been especially satisfying, as a colleague of my team, is that when we've found these pairings, each person steps up to the task beautifully. It's a thrill to watch people thrive.

2. Don't Decide. Lead.

   At AnyClip, I'm in the interesting position of being the most senior person on the org chart leading the technical operations. If you know me, you know this is interesting because I am not an engineer. How do I effectively CTO, then? By leaving most day-to-day technical decisions to folks who know, I never rarely as infrequently as possible sound like a total idiot and have the people who have to live with those decisions making them.

   This, however, is not a managementless decision-making process. Instead of spending my time reseaching problems to make decisions myself, I spend my time researching problems so the team can make better decisions themselves. I use my network to get advice the team could not otherwise get. I use my knowledge of the industry to bring vendors and best practices to the table -- and most importantly -- I bring both of these factors together to frame the values with which we should be making technical decision.

   I know I'm not the one to make the decision on a lot of matters, but I'm always the one to make sure people making decisions understand every possibility and how each possibility affects the long-term success of our company.

3. Confront Problems

   I think humans are designed to ignore their problems. Toothache? It will go away. Overweight? I'll get in shape one day. Debt? I'll pay it back when I have more money.

   But that's almost okay for personal problems. The only person who gets hurt is you.

   Problems in team dynamics, however, can never be ignored: they'll get toxic. For this reason, I've tried to be hyper-sensitive to potential problems in team dynamics, structure, and relationships. If I smell resentment between teams or managers on the horizon, I try and bring it up before it starts. If I sense mental exhaustion coming out of our pre-agile, ad hoc development methodology, I try and talk about it.

   Team is the most important dynamic in our company -- otherwise we'd all be contractors working with new people every few weeks or months -- so any threat to team dynamics is considered a threat to the entire firm's existence.

For now, that's what come to the top of my head. I have a lot to learn going forward, which is one of the major factors which keeps me totally enthused about my company and my job. Also, I must remind people that everything I'm learning I'm learning from Aaron and the rest of the team, especially those I work closest with on the technical side of the company. I'm truly blessed to be here working with these people.