NOTE: I'm proud to announce that since this ReadMe was written in 2018 Altru has been acquired by iCIMS! Everything written still applies, I just wanted to be up front about the context in which this was originally written.

This document is a guide for anyone that works on a team that I manage. It was originally written for my role as CTO at Altru, but should apply to any role, at any company. The intention is to present this document as a sort of contract to set expectations clearly and allow you to hold me accountable. None of this information is secret or hard to discern in person; I just think it's convenient and transparent to have it documented somewhere public. (More info)

• I am speaking only for myself, not for any other managers or employees.
• Company policies take priority over this ReadMe, though I will do my best to make sure they don't conflict.
• This is a living document, it is subject to change as I evolve and improve.
• I very much appreciate feedback, so please let me know what you do/don’t like.
• This is on GitHub so you can track changes, feel free to look at the history.
• My GitHub photo is supposed to be ironic, as is the "About" section of my LinkedIn profile.

I graduated from Carnegie Mellon University with a double major in computer science and psychology. I've worked as a software engineer, a media engineer, technical director, and a cofounding CTO. My first company, PublicStuff, provided 311 services for local government. I ran it for 7 years until it was acquired in 2015. After that I spent some time re-tooling and getting ready for my next company.

On a more personal note, I'm a native New Yorker, I currently live in Williamsburg but have lived all around Brooklyn and Manhattan over the years. I have an awesome dog named Chip; you'll probably be forced to look at pictures of him from time to time. Things I love, in no particular order: social psychology, the Knicks, science fiction, gifs, sushi, snowboarding, bike riding, and Muay Thai. I try to take a laid-back approach to life as often as possible. Sometimes I don't succeed. That's fine, we're all just people.

Chief Technology Officers have two primary roles, as technical leaders and as individual contributors. The appropriate balance of these roles changes as the company grows. This is normal, but it’s important to understand the responsibilities of both roles because they vary so significantly.

As of this writing I am split about 50/50 between the two roles. As the engineering team grows I will end up spending more and more of my time as a technical leader. (More Info)

I spend a lot of time thinking, talking, and reading about effective management. There are a lot of conflicting opinions and a lot of data to parse, so here's a brief rundown of things that inform my management style:

• Team coherency is absolutely crucial to a business’s success. Anything that brings a group of engineers closer together and aligns their objectives is tremendously valuable, and anything that makes it harder for them to collaborate openly and honestly is unacceptable. A team that is comfortable together will work harder and faster than one that isn't, and more importantly, they'll express dissenting opinions more positively. This leads to more learning, less stress, and higher levels of job satisfaction for engineers of all levels of experience.
• With that being said, I also place a lot value on individual autonomy. After a reasonable onboarding period, an engineer should be able to navigate the codebase effectively on their own, even if it involves components or technologies they are unfamiliar with. In the ever-changing world of software development, it's much more important to learn quickly than it is to have a tremendous amount of domain knowledge or experience in a single technology.
• I generally value progress over process. This means that if the team is spending too much time worrying about how to structure an initiative (i.e. sprint planning, product management, or bug reports) I'll generally just push forward with a simple approach and iterate on it later. This can be frustrating for some engineers, but I think that a smart team will learn more by doing, and as long as they're willing to adjust their approach over time, they'll end up in a better place faster than if they spent extra time planning at the outset.
• Intellectual bullying is something that I won't tolerate. This can take many forms, for example making a joke about someone not being familiar with a technology, or getting impatient when walking someone through a technical task, or publicly pointing fingers when something goes wrong. All of these directly result in people communicating and trusting each other less. If someone is afraid to speak openly, their ability to contribute to the team is severely limited, which harms everyone involved.
• Presenting problems without proposing solutions can be tremendously frustrating. Everyone should be free to voice concerns, but doing so without any viable alternatives tends to come off as complaining rather than problem solving. We all want to improve the system, but sometimes our hands are tied by logistics or practical concerns. If you have a better idea, let’s hear it, and if the goal is just to make people aware of a potential issue, make the point and let’s move on to something more productive.

• I value transparency and will share any and all information with you that I am able to. If you're not sure, just ask, I'll never get upset about a question, I'll never lie to you, and I'll expect the same from you.
• I'm big on scalability, and that includes work/life balance. I firmly believe that sometimes life gets in the way of work and sometimes work gets in the way of life, and that's fine, but finding a sustainable balance is absolutely crucial to building a successful team and business.
• "Hero coding" is almost always bad for the company. There are a few exceptions, but if a situation arises where it is necessary for an engineer to single handedly tackle a monstrous feature or project, it means that management has done something wrong. Hard work is par for the course but the peaks and valleys should always feel reasonable. (More info)
• Time is our most valuable resource, one of my most important jobs is respecting yours and making sure you are able to do your best work free of blockers and distractions. The same goes for the rest of your team.
• I like the DRI model and will often put one person in charge of a complex task. This isn't intended to stress anyone out, it's to avoid the a diffusion of responsibility that can occur on larger teams. (More info)
• My primary responsibility is to the team I manage. This means that when you need something, you are my top priority regardless of my schedule. Let me know when something comes up and I will make time available.
• I have had to let people go in the past; it is an unpleasent but necessary component of my job. I promise that when I have to do it in the future it will be after many clear attempts to correct course, and it will never come as a surprise to the employee in question.

We'll schedule one on one meetings every week. These will generally be 30 minutes long, sometimes longer, never shorter. The format will be fairly loose, but the intention of the meeting is specifically not to give a status update (that's what standups are for). We'll talk about product ideas, personal growth, team dynamics, what I or the team can do to be more effective, etc. This is the perfect time to bring up anything that is bothering you or stressing you out.

After you've been at the company for a few months we'll sit down and set some goals for you. These can be personal, professional, or business related, but they're so that you can hold yourself accountable and ensure consistent growth in our organization. We'll refer back to this list regularly in our 1:1s, but they won't change until the following year, so choose carefully.

Feedback should be fairly constant in our 1:1s or between them. I'm always trying to improve and I appreciate any help you can provide on that front, so long as it's respectful and constructive. That being said, our annual performance reviews will include a management feedback component where we can discuss specific areas of improvement and things that are going well.

It is tremendously important to me that everyone on my team always feel like they're growing. To ensure that this is the case, we offer a number of perks and benefits to encourage learning, including a small budget for courses/conferences, a centralized list of books and articles on trends in tech, and knowledge-sharing opportunities like regular lunch-and-learn sessions. None of this is helpful though, if you, the engineer don't take advantage of the benefits. If you want to learn a new tech or tool, tell me! We'll try to find a way to fold it into the coming sprints, and if we can't, we'll set time aside to focus just on learning something new.

Hope this was helpful, please let me know what you thought of it!