If you are interested in improving on purely the people management side of leadership, books like First, Break All the Rules1 are excellent references.
I encourage you to share the responsibility of having good 1-1s with your manager. Come with an agenda of things you would like to discuss. Prepare for the time yourself.
A great manager will notice some of the little things you’re doing well in your day-to-day, and recognize you for them. Keep track of this feedback, good and bad, and use it when you write your self-review for the year.
Your manager should be the person who shows you the larger picture of how your work fits into the team’s goals, and helps you feel a sense of purpose in the day-to-day work.
It’s even more important as you become more senior that you feel comfortable driving your 1-1s and bringing topics for discussion or feedback to your manager, because she is otherwise unlikely to spend a lot of time on this outside of performance reviews.
One thing that early career engineers often don’t appreciate is how their current peers will turn into their future jobs. This peer group includes everyone from your schoolmates to your teammates to the people you meet at conferences and meetups. It’s OK to be a little bit shy, but most CTOs have to learn how to socialize with all sorts of people and create strong networks across companies.
One final thing to realize is that most CTOs are the CTOs of small companies. They are often the technical cofounders of startups.
There is simply less demand for interns, and thus you should have a lot of options. You can choose to take this opportunity in many ways, but encourage you to push for hiring candidates from underrepresented groups. Diversity in your internship program will translate to diversity in your new grad hiring, which in turn will translate to diversity in your organization.
Becoming a tech lead required me to change my focus. Work is now less about me and working on the most technically challenging idea or the most fun project; instead, my focus is more on my team. How do I empower them? How do I remove the obstacles slowing them down?
Ultimately, the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens.
Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it. Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan.
If one universal talent separates successful leaders from the pack, it’s communication skills. Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constantly testing the limits of their knowledge and the knowledge of the team. Now is a great time to practice your writing and speaking skills. Write design documents and get feedback on them from better writers. Write blog posts for your tech blog or your personal blog. Speak in team meetings, speak at meetups, and get practice standing up in front of an audience. Don’t forget to listen during all of this communication. Give others a chance to speak, and hear what they say. Practice repeating things back to people to ensure you understand them. Learn how to hear what someone says and rephrase it in your own words. If you aren’t a good note taker, you may need to become one. It doesn’t matter whether you choose to dive deep into technology, or become a manager —if you can’t communicate and listen to what other people are saying, your career growth from this point on will suffer.
Positive feedback also makes your reports more likely to listen to you when you need to give them critical feedback. When they believe that their manager sees the good things they do, they’ll be more open to hearing about the areas where they might improve.
Upon hearing that someone is underperforming, many companies will have you write the person a document called a performance improvement plan. This is a set of clearly defined objectives that the person must achieve within a fixed period of time. If she manages to achieve them, then she is taken off the plan and all is well; otherwise, she’s fired. Depending on the company, such a plan might actually be an effort to turn an employee around, but often the plan is written in such a way that the person can’t possibly hope to achieve the goals in the allotted time, and it’s just a generous way of giving someone time to look for another job before being fired.
One of the basic rules of management is the rule of no surprises, particularly negative ones. You need to understand what a person is supposed to be giving you, and if that isn’t happening, make it clear to her early and often that she is not meeting expectations.
A final warning: don’t put anyone on a plan whom you wouldn’t be happy to lose. Most smart employees will take this formal warning as a sign that the organization is not a good fit for them, and leave as quickly as possible.
if you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t underestimate the value of your technical skills as you work to become a successful engineering manager.
It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.
Infrequent releases can hide pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers who don’t know how to break their work down.
The goal is not to stress them out, but to help them get context into what they’re dealing with. The extreme shielders think they can best focus and motivate their teams by giving clear goals. But humans usually need some sort of context into why these goals have been set, and thereby into what problems they’re working to solve. If you’re going to have operational issues in November if a particular system isn’t up and running, your team deserves to understand that consequence. Appropriate context is what helps teams make good decisions about how and where to focus their energy.
Most gelled teams have a sense of camaraderie that makes them joke together, get coffee, share lunch, and feel friendly toward one another. They may have obligations they respect, and passions outside of work, but they don’t view their team as something they’re eager to escape every day. The real goal here is psychological safety that is, a team whose members are willing to take risks and make mistakes in front of one another. This is the underpinning of a successful team. The work of gelling a team begins by creating the friendliness that leads to psychological safety. You can encourage this by taking the time to get to know people as human beings and asking them about their extracurricular lives and interests. Let them share what they feel comfortable sharing. Ask how their child’s birthday party went, how their ski trip was, how their marathon training is going. This is more than empty small talk; it fosters relatedness, the sense of people as individuals and not just anonymous cogs.
There are 52 weeks in a year, or about 13 per quarter. However, realistically your team will lose a lot of that time. Vacations, meetings, review season, production outages, onboarding new employees all of these things take away from focus. Don’t expect to get more than 10 weeks’ worth of focused effort on the main projects per team member per quarter. It’s likely that Q1 (immediately after the winter holidays) will be the most productive and Q4 (the quarter that includes winter and the end-of-year holidays) will be the least productive.
The popular doubling rule of software estimation is, “Whenever asked for an estimate, take your guess and double it.” This rule is appropriate and good to use when you’re asked for an off-the-cuff guess. However, when you’re talking about projects that you think will take longer than a couple of weeks, go ahead and double the estimate, but make it clear that you’ll need some planning time before you’re sure about the timescale.