- Management 101
- Mentoring
- Tech lead
- Managing people
- Managing a team
- Managing multiple teams
- Managing managers
- The big leagues
- Bootstraping culture
Engineering management is not just about people management. Hands-on expertise gives you credibility and helps leading your team effectively.
You should expect from your manager
1-1s allow human connection. You should let your manager know about your life a bit, it would be easier to ask for time off when times become stressful. Great managers notice your energy level.
Being an introvert is not an excuse to avoid treating people like human beings. Your manager should treat you like a human that has a life outside work, you should expect to talk a few minutes about that life when you meet.
It is an opportunity to speak privately. You should expect 1-1s to be scheduled with some predictability, so that you can plan for them.
Good 1-1s are not status meetings. You can use the email or chat for those.
It's a good idea to come with an agenda of things to discuss.
Good managers will let you know when you screw up. The sooner you know about your bad habits the easier they will be to correct.
Praise should be public and criticism should be private.
If you do things apart from code, your manager should help you out to improve in those things. Asking for advice is a great way to show respect to her. Your manager is your number one ally.
In difficult situations with your teammate or people from other teams, your manager should be there to help you navigate the situation.
Good managers will also help you understand the value of the work you are doing when is not fun or glamourous.
The more senior you become, the less feedback you will be likely to receive. You should become comfortable driving your 1-1s.
Your manager holds some responsibility helping you out with training and other resources for career growth.
Your manager should be essential in advocating for your promotion and getting approved. She should also know if you are qualified to be promoted. Managers cannot guarantee promotions, but good ones will know how to help you out to perform well in the system.
Knowing yourself is step one. Step two is going after what you want.
When you want to work on a project, ask. When you are persistently unhappy, speak out. You will not get everything you want, and asking is not fun, but it's the fastest way forward.
The job of your manager is to do the best thing for the company and the team, not to do whatever it takes to make you happy.
The only person you can change is yourself. Your manager expect you to bring solutions, not problems.
Consider not only the job, the company and the pay, but also the manager when evaluating job opportunities. Strong managers have strong networks, and they can get you jobs even after you stop working for them.
It is an opportunity in a safe way about the job of management, and the feeling of being responsible for another person. The mentee gets a supervisor that is solely focused on him.
You want him to love you as he will go to his friends and tell about you and the company he worked for.
You will have to have a project in mind, look for small features of your current project that would take a few days to complete and start from there.
Try to sit with him as much as possible the first days.
- Listen carefully. Listening is one of the basic skills for people management. Listening is the precursor of empathy, which is one of the core skills of a quality manager. When you mentee is speaking to you, pay attention to your behaviour. Listening goes beyond hearing words, people are not usually precise on what they mean. Let your mentee correct you.
- Communicate clearly. Communicate what needs to happen.
- Calibrate your response. During the first weeks of the internship, you'll learn the frequency you need to check in with your mentee to provide the right adjustments.
Your job consists of onboarding this person in the company effectively, helping out adjusting to the life in the company and building out her network of contacts. There will be many opportunities to clarify many bits of process, culture and jargon that will be completely foreign to a new joiner.
Effective teams have good onboarding documents to provide to new hires.
Part of the mentoring is introducing the new person around, bringing this person into some of your networks will help her to get up to speed faster. Adopt the mindset that network building is a worthwhile investment of your time and energy.
The best mentoring relationships evolve naturally and in the context of larger work.
- When you are a mentor. Don't do it unless you think it will be rewarding for you and the person you're mentoring. Don't say yes and then fail to actually do the mentoring work.
- When you are a mentee. Think about what you want to get out of this relationship, and come prepared to your sessions. If you don't have time to prepare or you don't think preparing is necessary, ask yourself if mentoring is really something you need at all. Maybe instead you need a friend, or a therapist, or a coach.
The alpha geek is driven to be the best engineer on the team, to always have the right answer, and to be the person who solves all the hard problems. He values intelligence and technical skill above all other traits. Can't deal with dissent. He has all the answers. The alpha geek tries to create a culture of excellence, but ends up creating a culture of fear.
The alpha geek believes that every developer should know exactly what she knows, and if you don't know something, she will point out your ignorance. She can be very rigid about how things should be done and closed off to new ideas that she didn't come up with.
If you have ever wondered why people don't seem to come to you for help despite your clearly strong technical skills, ask yourself whether you're showing some signs of being an alpha geek.
Mentoring can be a great opportunity to break out of that habit. Practicing the art of teaching can help us learn how to nurture and coach, how to phrase things so that others will listen, instead of just shouting them down.
Alpha geeks make absolutely terrible managers. Better off to give them a focus on technical strategies and system design.
What you measure, you improve. You help your team succeed by creating clear, focused, measurable goals. Figure out what you're hoping to achieve then find the person who can help meet those goals. If your company is setting up mentoring programs, make sure that there is some guidance and structure.
Recognise that the mentor productivity will slow down during the mentoring period. Look for someone that you believe can succeed who wants to distinguish herself beyond her coding ability.
Skills that address emotional needs of people and teams. Because the outcome can be difficult to quantify is often dismissed as less important. Mentors need to be recognised, should be treated as first-class citizens.
Best mentors are going to be people who are further along in their mastery of the job skills that the mentee is trying to develop.
Use this opportunity to reward and train future leaders of your team.
- Be curious and open-minded. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Working with new people who are learning things for the first time can shed light on hidden patterns and help you make connections you may not otherwise have made.
- Listen and speak their language. Mentoring forces you to hone your communication skills. You must be able to listen and communicate in a way that the person can understand. Teams have to communicate effectively to get anything done.
- Make connections. Your career ultimately succeeds or fails on the strength of your network. Mentoring is a great way to build this network. Your career is long and the tech world can be very small, so treat the other person well.
The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for.
The tech lead role is not a point in the latter, but a set of responsibilities that any engineer may take once they reach the senior level.
- Regular (weekly) 1-1 touchbases
- Regular feedback on career growth, progression towards goals, areas for improvement, and praise as warranted.
- Working with reports to identify areas for learning and helping them grow in these areas via project work, external learning, or additional mentoring.
The tech lead is learning how to be a strong technical project manager by delegating work effectively without micromanaging. They focus on the whole team's productivity and strive to increase the impact of the team's work product.
It is very hard to grow past senior engineer 2 without ever having acted as a tech lead._
You can't lead without engaging with other people, and people skills should be important, much more than technical expertise. Tech leads will work on one major new technical skill: project management, or the work of breaking down a project.
Being a tech lead is an exercise in influencing without authority. How do I empower my team? How do I remove the obstacles slowing them down?
The willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs.
You'll often need to balance doing things you know how to do and enjoy doing, such as writing code, with things you don't know how to do. You'll feel uncomfortable about it.
The worst scheduling mistake is allowing yourself to get pulled randomly into meetings.
It's important to get your team into a schedule that allows them to be focused on development for long stretches of time. Part of your leadership is helping the other stakeholders, such as your boss and the product manager, respect the team's focus.
- System architect and business analyst. Have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. Understand business requirements and translate them into software.
- Project planner. Breaking down work into rough deliverables. Part of the challenge here is getting as much productive work done in parallel as possible.
- Software developer and team leader. Software developers and leaders write code, communicate challenges and delegate. In your position as a tech lead, you should continue writing code, but not too much. Start looking for opportunities to delegate work.
You have to act as a software developer, a system architect, a business analyst, and a team leaders who knows when to do something single-handedly, and when to delegate work to others.
When faced with a project with many unknowns and relatively hard deadlines, you'll find agile processes tricky.
You need to understand how to break down work that has complexity beyond the scope of what you can do as an individual.
Hiring for project management is bad, but still project management has to happen. As a tech lead, you should be doing it when needed, especially for deeply technical projects.
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 self-discipline to think about the project in some depths before diving in and seeing what happens.
Take time to explain. Never hesitate to take the opportunity to explain basics and motivations to senior or junior members. It educates them without making them feel small.
- Break down the work. Start breaking down your big deliverables into tasks.
- Push through the details and the unknowns. Work through the unknowns until you really feel that there is no more value to be gained in spending time on them.
- Run the project and adjust the plan as you go. The value of planning is that it helps you know how far the project has come, and how far it is from completion.
- Use the insights gained in the planning process to manage requirement changes.
- Revisit the details as you get close to completion. Run a premortem, an exercise where you run through all the things that could fail on the launch of the projects. Make a launch plan; make a rollback plan. Celebrate.
The process czar believes that there is is one true process that will solve all the team's biggest problems. Agile, Kanban, scrum, Lean, or even waterfall.
Engineers sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues with planning, focus, time management, and prioritisation.
Processes must meet the needs of the team and the work.
Be careful on relying on processes to solve problems that are a result of communication or leadership gaps on your team. It's a waste of your time to play rule cops, and automation can often make the rules more obvious.
- Understand architecture. Take time to understand it. It's almost impossible to lead projects well when you don't understand the architecture you're changing.
- Be a team player. If you're doing all the interesting work yourself, stop. Working on the less exciting, boring or frustrating parts of the code base can teach you a lot about where the process is broken and how to fix it. Also, if you are doing the most boring work, stop that too. You want to encourage others on your team to learn the entire system.
- Lead technical decisions. Determine which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve. Make it clear what the matter under discussion is, and communicate the outcome.
- Communicate. Your productivity is now less important than the productivity of the team. You will pay the price of communication overhead, you represent the team. If one universal talent separates successful leaders it's communication skills. Successful leaders write well, they read carefully, and the get up in front of a group and speak. Don't forget to listen and give others a chance to speak. If you aren't a good note taker, you may need to become one.
Your team is only as healthy as its individuals.
The main tasks required to manage people:
- Taking on a new report
- Holding regular 1-1s
- Giving feedback on career growth, progression toward goals, areas for improvement and praise as warranted
- Working with reports to identify areas for learning and helping them grow in these areas via project work, external learning, or additional mentoring.
- Build trust and rapport. Get to know each other.
- Create a 30/60/90 day plan. This plan includes basic goals. The more senior the hire, the more he should participate in creating the plan.
- Encouraging participation by updating new hire documentation. Team onboarding documents get updated on every new hire to get up to speed.
- Communicate your style and expectations. How often will you meet him, how will you share information, and when and how often you'll want to review his work.
- Get feedback from your new hire. Get as much feedback as you can about the new hire's perspective on the team in that first 90 days.
- Have regular 1-1s.
- Scheduling 1-1s. The default should be weekly. Try to avoid as much as possible interrupting your reports in the middle of productive workflow hours.
- Adjusting 1-1s. Adapt the cadence of your 1-1s, junior people or people who need frequent feedback or help on difficult times will appreciate more dedicated time.
One or both parties comes with a list of goals to cover in order of importance. This style is very professional and efficient, but sometimes is a bit cold. It forces reports to think beforehand what do they want to discuss.
Listen to anything your reports want to discuss. Let them drive the meeting. It should be as much as a creative discussion as a planning meeting.
If you start focusing a lot of energy on hearing reports' complaints and commiserating, you're quite possible making the problem worse. There is very little value to repeatedly focusing on drama.
Quarterly is frequent enough to give the topic attention without feeling like all you talk about is career development. Progress towards goals, whether they are formal or personal.
If you have an employee with performance issues, feedback meetings should happen more frequently, if you are thinking of firing someone I advise you to document these feedback meetings.
When someone does something that needs immediate corrective feedback, don't wait for the 1-1 to provide that feedback. The longer you wait, the harder it will be for you to bring it up, and the less effective the feedback will be.
Leave room to get to know the person reporting to you as a human being. Show them that you care about them as individuals. Show that you are invested in helping them now and in the future.
Remember that when you're not taking notes you'll probably forget some important things. Do your 1-1 meetings in private so that you can feel free to discuss sensitive topics.
Tip: For each report, keep a shared document as a log of the things that you discuss in your 1-1s.
The hardest thing about micromanagement is that there are times when you need to do it.
Trust and control are the main issues around micromanagement.
Autonomy is an important element of motivation.
Delegation is not the same thing as abdication. When you're delegating responsibility, you're still expected to be involved as much as is necessary to help the project succeed.
Being a good leader means being good at delegating.
- Use team's goals to understand which details you should dig into. If the team is making progress on its goals, the systems are stable, and the product manager is happy, I rarely dig into the details beyond cursory overview. However, it requires goals with a plan for people to be making progress against, and a product manager who can give you another perspective. When you are managing a team that doesn't have a clear plan, use the details you'd want to monitor to help them create one.
- Gather information from the systems before going to the people. The worst micromanagers are those who constantly ask for information they could easily get themselves. Use a light touch. The team will not be productive or happy spending half of their time gathering information for you that you could easily find yourself.
- Adjust your focus depending on the stage of projects. You should know all of the details of the project status as part of your regular team process.
- Establish standards for code and systems.
- Treat the open sharing information, good or bad in a neutral to positive way. If you don't figure out how to let go of details, delegate, and trust your team.
Continuous feedback is a commitment to regularly share both positive and corrective feedback. Raise issues as they happen.
Steps you can take to be great at continuous feedback:
- Know your people. What are their goals, strengths and weaknesses and what do they need to do to get to the next level.
- Observe your people. Good managers have an intuition for identifying talents and helping people draw more out of their strengths. Lookout for things to praise. Every week there should be at least one thing you can recognise about someone in your team.
- Provide lightweight, regular feedback. Start with positive feedback.
- Bonus: provide feedback. When things are going well, praise them, but also make suggestions as to what could be even better in the future. Going beyond a simple "good job" to really help your people grow.
Continuous feedback is not a replacement for a more formal, 360-based performance review process.
The 360 model is a performance review that includes feedback from, in addition to a person's manager, his teammates, anyone who reports to him, and coworkers he regularly interacts with, as well as a self-review.
Your job as a manager is to gather all that feedback together and summarise it into a high-level view of what other people think about your direct reports.
- Give yourself enough time, and start early. Spend solid, uninterrupted time working on reviews.
- Try to account for the whole year, not just the past couple months. Keep a running summary of your 1-1s.
- Use concrete examples, and excerpts from peer reviews. Forcing yourself to be specific will steer you away from writing reviews based on underlying bias.
- Spend plenty of time on accomplishments and strengths. Celebrate achievements, talk about what's going well, and give plenty of praise for good work. Those strengths are what you'll use to determine when people should be promoted.
- When it comes to areas for improvement, keep it focused. If the feedback seems valuable for the person to hear, share it, but don't just blindly report all the grudges. If you have very little feedback for improvement maybe that means the person is ready for promotion or given more challenging work.
- Avoid big surprises. If someone is underperforming across the board, the review should not be his first time getting that feedback.
- Schedule enough time to discuss the review. Give them a copy of the review as they're leaving on the evening before the review is scheduled. This gives them a chance to read it at home and come prepared to talk about what it says next day.
If you're a manager, you are going to play a key role in getting people on your team promoted, you'll need to make a case for their promotion. Learn how the game is played at your company. You need to be transparent with your team.
Start identifying promotion-worthy projects and trying to give those projects to people who are close to promotion.
If there is no growth potential on your team there's no room for people to work at a more senior level, it may be a sign that you need to rethinking the way work is done in order to let individuals take on bigger responsibilities.
You might have to provide a performance improvement plan, a set of clearly defined objectives that a person must achieve within a fixed period of time.
One of the basic rules of management is the rule of no surprises, particularly negative ones.
You'll always need to have a record of negative feedback to fire someone in any environment where HR is active. Give people clear improvement feedback in writing, with a timeline for improvement, and have them acknowledge it in writing as well (an email is ok).
A final warning: don't put anyone on a plan whom you wouldn't be happy to lose.
Coaching someone out of the company If you think your team is not the right place for somebody to grow his career. You aren't firing him, but you are telling that he needs to move on if he wants to progress. Give the employee a chance to find a job in another part of the organisation or at another company. When he does, let him go happily.
The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team.
The person who fills this role is expected to have a large impact on the success of the organisation as a whole.
In addition to strong management skills, the engineering lead acts as a leader for their technical roadmap for their product group pillar.
Being a good manager isn't about having the most technical knowledge. The work of supporting people is far more important to management success.
Engineering management is a technical discipline, not just a set of people skills. Technical instincts honed over years of doing the job are very important for guiding that process.
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. You have to learn how to balance.
If you don't stay in the code, you risk making yourself technically obsolete too early in your career.
You need to stay enough in the code to see where the bottlenecks and process problems are.
Strong engineering managers can identify the shortest path through the systems to implement new features.
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.
- Not shipping. The trick is to learn how to balance pushing your team and holding back. Start to push for the removal of bottlenecks. When people are contending for a scarce resource, conflicts and unhappiness among team members are almost inevitable.
- People drama. Make it clear that a bad behaviour has to change, bring clear examples, and provide corrective feedback quickly after things happen. The best defence is a good offence, quick actions are essential.
- Unhappiness due to overwork. If overwork is due to (in)stability of the production system, it's your job as the manager to slow down the product roadmap in order to focus on stability for a while. Measures of alerts, downtime, incidents, and strive to reduce them. Dedicate 20% of your time in every planning sessions to system sustainability (technical debt). For time-critical releases you should be playing cheerleader helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Offer breaks after the push and make it as fun as you can. You should avoid it next time.
- Collaboration problems. Regular touch-bases with the appropriate peers to work through issues. Gather actionable feedback from your team, and have productive conversations about possible improvements. Try to stay positive and supportive of their efforts in public. If your team isn't working well together, look into creating some opportunities for them to hang out.
If you are now managing someone who was truly your peer, acknowledge the weirdness of the transition. Be honest and transparent with this person and communicate that you're going to do your best job you can, but you'll need his help to do it. You're going to have to be a little bit vulnerable with him.
You may now have the ability to override his decisions, but use this power very cautiously. Resist the temptation to micromanage people. They are going to be sensitive.
You're going to have to let go of some of your previous work.
Your goal is to show the team that you're committed to helping them succeed.
It's valuable for everyone to realise that they can and should focus on the things they can impact and change, and ignore the things they can't
Helping them understand the key important goals and focusing them on those goals is important. However, it's unrealistic to expect that you can or should shield your team from everything. Sometimes it's appropriate to let some of the stress through the team. Help them get context into what they're dealing with.
You are not their parent. Your team is made up of adults who need to be treated with appropriate respect.
While the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details, you are usually accountable for the team's progress.
- Create a data-driven team culture. Get used to give to the product or business head person data about team productivity (time that takes to complete features) or data about quality measures (number of outages, bugs found, etc).
- Flex your own product muscles. Taking the time to develop customer empathy is important because you'll need to give your engineers context for their work.
- Looking into the future. Think two steps ahead, from a product and technology perspective. Getting a sense of where the product roadmap is going helps you guide the technical roadmap. Start asking the product team questions about the future might look like, and spend some time keeping up with technological developments that might change the way you think about the software you're writing or the way you're operating it.
- Review the outcome of your decisions and projects. Review assumptions after the project is done.
- Run retrospectives for the processes and day-to-day. Discuss what happened during the sprint and pick a few events, good, bad or neutral, to discuss in detail.
Creating a safe environment for disagreement to work itself out is far better than pretending that all disagreement does not exist.
- Don't rely exclusively on consensus or voting. Don't set people up for votes that you know will fail instead of taking the responsibility as a manager of delivering bad news yourself.
- Do set up clear processes to depersonalise decisions. Start with a shared understanding of the goals, risks and the questions to answer before making a decision.
- Don't turn a blind eye to simmering issues. Conflict avoidance manifests as an inability to address problems until they've gone on for way too long. It's probably an indication that you are not paying attention.
- Do address issues without courting drama. The goal is to identify problems that are causing the team to work less effectively together and resolve them, no to become the team's therapist.
- Don't take it out on other teams.
- Do remember to be kind. Your goal as a manager, should not to be nice, it should be to be kind. Nice is saying "please" and "thank you". It's kind to tell someone who isn't ready for promotion that she isn't ready.
- Don't be afraid.
- Do get curious. Be thoughtful about your behaviour.
Most gelled teams have a sense of camaraderie that makes them joke together, get coffee, share lunch, and feel friendly toward one another. They don't view their team as something they're eager to escape every day.
The goal is to reach psychological safety, take risks and make mistakes in front of one another. Get to know people as human beings. It fosters relatedness, sense of people as individuals and just anonymous cogs.
Teams that are friendly are happier, gel faster, and tend to produce better results.
This is why those who undermine team cohesion are so problematic.
Produces individually outsized results, but is so ego-driven that she creates a mixture of fear and dislike in almost everyone around her.
It's incredibly hard of a manager to justify getting rid of someone who produces great work.
Simply not hire one. Getting rid of brilliant jerks takes a level of management confidence that I think is uncommon. These folks will often get rid of themselves, it's unlikely that you'll be stupid enough to promote them.
Simply and openly refuse to tolerate bad behaviours. One of the few instances where "praise in public, criticise in private" is upended. You don't want your culture to mimic, you need to say something in the moment to make the standard clear. If you seem emotional, it may undermine you. Your first goal is to protect your team as a whole, the second is to protect each individual on the team, and your last priority is protecting yourself.
The person who hides information from you, from his teammates, from his product manager.
You have to nip this information-hiding habit in the bud as soon as possible. He doesn't feel safe sharing his work in progress, and his fear often sets an example for the rest of the team.
Address the root cause of the hiding.
A person who simply doesn't respect you as a manager, or who doesn't respect her teammates. If your team member doesn't respect you or her peers, why is she working there?
Some rules of thumb to keep in mind.
- None of this is a replacement for agile project management. You are responsible for the larger picture, the accomplishments that are measured in months instead of weeks, and this is where you have to start exerting some higher-level planning.
- You have 10 productive engineering weeks per engineer per quarter. Don't expect to get more than 10 weeks worth of focused effort.
- Budget 20% of time for generic sustaining engineering work. Testing, debugging, cleaning up legacy code, migrating language or platform versions, and doing other work that has to happen.
- As you approach deadlines, it's your job to say no. The only way to achieve this goals is to cut scope at the end of the project. Figure out what "must-haves" are not actually must-haves.
- Use the doubling rule for quick estimates, but push for planning to estimate longer tasks. Whenever asked for an estimate, take your guess and double it.
Get someone to walk you through the systems and architecture, as well as the process for testing and releasing the software. Follow the developer onboarding process.
Work on at least a couple of features in your first 60 days. Pair with one of the engineers on a feature he's working on, have him pair with you as you start working on a feature of your own. Get your code reviewed. Perform a release and do rotation of supporting systems.
Understanding details across a couple of teams probably means one important thing: you're not writing (much, any, production).
The engineering director leads engineers across multiple product areas, or multiple technology functions. Tech leads and individuals report into them.
The engineering director is not generally expected to write code on a day-to-day basis, however she will be responsible for their organisation's overall technical competence, guiding and growing it as necessary via training and hiring. They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends. They should help debug and triage critical systems, and should understand the systems they oversee well enough to perform code reviews. They should contribute to architecture and design efforts primarily by serving as the technical savvy voice.
They focus on ensuring that we continually evaluate and refine our development/infrastructure standards. Being responsible for creating high-performance, high-velocity organisations, measuring and iterating on process. They are leaders for recruiting, headcount management and planning, career growth and training for the organisation.
They are responsible for creating and growing the next generation of leadership and management talents, and they are obsessed with creating high-functioning, engaged, and motivated organisations.
They both create a strategic and tactical tech roadmap that tackles business needs, efficiencies and revenue, and fundamental technology innovation. They are strong communicators being able to explain technical concepts to nontechnical partners.
It is very difficult for a person responsible for hands-on management of multiple teams to write code. Debugging and production support are also valuable. You might be more helpful doing pair programming, or fixing minor bugs or features.
You should spend the time to gain mastery of programming before moving into management.
One of the critical parts of the job at this level: debugging team issues and keeping your teams producing quality software smoothly.
Even if you don't program on a daily basis, it is strongly advised to code half a day per week on some creative pursuit.
I miss code terribly. Is this a sign that I shouldn't be a manager?
There is a transition period where people question frequently whether they've made a mistake. Management is a job, it is a necessary and important job, and in particular, it's your job now.
Writing code is full of quick wins. Management has fewer obvious quick wins. It's natural to feel some longing for simpler times. You can't do everything all at once. Becoming a great manager requires you to focus on the skills of management, and that requires giving up some of your technical focus. It's a tradeoff, and one you'll have to decide if you're up to making.
It's time to figure out how to manage your time. Setting goals for the team, helping your product team put details on the product roadmaps.
Time management is a personal thing. Managing your time comes down to one important thing: understanding the difference between importance and urgency.
| Not urgent | Urgent | |
|---|---|---|
| Important | Strategic, make time | Obvious work |
| Unimportant | Obvious avoid | Tempting distractions |
Urgency is often more clearly felt than importance. Emails feel urgent, but they aren't urgent. We also tend to substitute obvious for urgent in determining something's value.
It's likely that you're spending a lot of your time on things that are urgent but only slightly important, and sacrificing things that are important but not urgent. Important but not urgent is actually preparing for meetings so that you can guide them.
As a manager of multiple teams, you can win back a lot of time by pushing an efficient meeting culture down to your teams.
When you stop going to all of their internal meetings, you run the risk of missing out on the clues that will help you catch problems early. Your attendance at these meetings is partially to pay attention to the dynamics and morale of your team.
Ask yourself: How important is the thing I'm doing?
If your team needs a manager more than they need an engineer, you have to accept that being a manager means that you by definition can't be that engineer. If you are going to suck at one, which one that will be. I feel bad when I suck at being an engineer, but sucking at being a manager would be a choice inflicted on other people. That's not fair.
The first several months of managing multiple teams can feel like a death march, even when your hours are not excessive.
The only way out of this situation is to go through it. If you don't feel a little bit overwhelmed, you're likely missing something.
Feeling of management from here on out is plate spinning. Your plates are the people and projects you're overseeing, and your job is to figure out how much attention each one needs at what time.
You'll get better at this over time. Your instincts will improve.
| Frequent | Infrequent | |
|---|---|---|
| Simple | Delegate | Do it yourself |
| Complex | Delegate (carefully) | Delegate for training purposes |
Strong managers spend a lot of their time developing members of their teams in these areas. Your goal is to make your teams capable of operating at a high level without much input for you.
Project management. Onboarding new team members. Working with the product team to break down product roadmap goals into technical deliveries. Production support.
Delegation is a process that starts slow but turns into the essential element of career growth.
- "Yes, and". "Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap".
- Create policies. Making a policy helps your team know in advance the cost of getting to "yes".
- "Help me say yes". Means you ask questions and dig on the elements that seem so questionable to you. This line of questioning helps people come to the realisation themselves that their plan isn't a good idea.
- Appeal to budget. Lay out the current workload in plain terms, and show how there is little room to maneuver. "Not right now".
- Don't prevaricate. When you know that you need to say no, it's better to say it quickly that to delay and drag out the process. You'll be wrong sometimes, so when you discover that you were too quick to say no, apologise for making that mistake.
Assuming that the job at this level becomes essentially nontechnical is a mistake. You now need to develop an eye for technical health signals for the overall team,
As the popular management book First, break all the rules.
Interrogate every process to determine the value it should provide, and always ask yourself if it can be automated further.
- Frequent releases. Frequency of code change is one of the leading indicators of a healthy engineering team. Part of moving fast requires breaking work down into small chunks. As a technical leader, while you may not be writing code much, you're still responsible for the technical side of getting work done. You're also responsible for keeping your team happy and productive, and often the solution to this is not cheerleading or paying them better or praising them more. You have to be the advocate and push for technical process improvements that can lead to increased engineer productivity, even if you're not implementing them all yourself.
- Frequency of code check-ins. The importance of breaking stuff into chunks. Engineers who don't write tests often have a harder time breaking down their work, and learning how to test-driven development can help them better at this skill.
- Frequency of incidents. Determining the level of software quality you need for the product you're building and adjusting that measure over time is a technical challenge for you, the manager, to help address. Developers support code or systems they write. Incident management, when it becomes merely reacting to incidents rather than working to reduce them, can turn into a task that diminishes your team's ability to do what they do best.
It can be hard for new managers to create a shared team identity. They unite the team by empathising how this identity is special as compared to other teams. Taking this too far, this identity is used to make the team feel superior to the rest of the company, and the team is more interested in its superiority than the company's goals. This attitude make the team vulnerable of many dysfunctions.
- Fragile to the loss of the leader. When you hire a manager who builds a clique, that clique is likely to dissolve and leave the company if the manager leaves the company.
- Resistant to outside ideas. Miss opportunities to learn and grow.
- Empire building. Leaders who favour and us-versus-them style tend to be empire builders, seeking opportunities to grow their teams and their mandates without concern for what is best for the overall organisation.
- Inflexibility. Struggle against changes that comes from outside the group.
Before you try to change everything to fit your vision, take the time to understand the company's strengths and culture. The trick is not to focus on what's broken, but to identify existing strengths and cultivate them.
By creating a strong and enduring alignment between the team, its individuals, and the overall company, purpose-based binding makes teams.
- Resilient loss of individuals.
- Driven to find better ways to achieve their purpose.
- First-team focused. Consider the needs of the company as a whole before focusing on the needs of their team.
- Open to changes that serve their purpose.
Getting clarity about the purpose of your team and your company can take time. In startups especially.
Impatience paired with laziness is wonderful when you direct it at processes and decisions: figuring out what's important, and going home.
Be impatient to figure out the nut of what's important. Laziness as "faster", about "the same value to the company in less total time". Go home! Forcing yourself to disengage is essential for your mental health.
Now you are responsible for several teams, for overseeing the health of those teams, and for helping them set goals. There are more projects and people than you could possible handle by yourself. Instead of managing a couple of closely related teams, you may manage a larger scope of efforts.
Managing managers adds a whole new level of complexity.
It's easy to miss out on the details because you no longer engage regularly with all of the individual developers on each team. You'll need to practice honing your instincts.
Let's take the case of managing a team that is doing work outside of your skill set.
Sometimes a person might be playing project manager instead of training their managers to do that job themselves.
This position is the first level in a much bigger game.
I've told my team I have an open-door policy, they can come to me whenever they want to discuss problems.
One thing managers have to keep in mind is that a part of their job is to ferret out problems proactively.
The open-door policy is nice in theory, but it takes an extremely brave engineer to willingly take the risk of going to her boss to tell him about problems.
When you manage managers, you ultimately evaluate them on the performance of their teams.
Part of the job is simply to make sure that your 1-1s have room for real conversations.
No one wants to add yet more meetings to their calendar. A skip-level meeting it's a meeting with people who report to people who report to you. Their purpose is to help you get perspectives on the health and focus of your teams.
It's a short 1-1 meeting, held perhaps once a quarter, between the head of an organisation and each person in that organisation. It's a personal relationship between you and everyone in your organisation. It also gives individuals time to ask you questions. Each person should come prepared to focus on what he or she is interested in talking to you about.
Possible prompts for a skip-level 1-1:
- What do you like best/worst about the project you are working on?
- Who on your team has been doing really well recently?
- Do you have any feedback about your manager, what's going well, what isn't?
- What changes do you think we could make to the product?
- Are there any opportunities you think we might be missing?
- How do you think the organisation is doing overall? Anything we could be doing better/more/less?
- Are there any areas of the business strategy you don't understand?
- What's keeping you from doing your best work right now?
- How (un)happy are you working at the company?
- What could we do to make working at the company more fun?
If you have a larger organisation, there are other ways to get skip-level time. Like holding lunches with whole teams a couple of times a quarter for each team.
However, people act differently in group scenarios. It is a good opportunity to get a sense for where the team believed their focus needed to be. Some questions that can be used to draw out information:
- What can I, your manager's manager, provide for you or your team? Anything I should be helping with?
- Is this team working poorly with any other teams, from your perspective?
- Are there any questions I can answer?
Skip-level lunches provide familiarity, which in turn generates more willingness for people to come to you.
At this level, you're constantly making tradeoffs between investing in expensive engagements, such as 1-1s, or casual engagements that are more efficient but provide less detailed information.
There is one universal goal for these relationship: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team.
Sometimes managers make your life easier by hiding problems and telling you what you want to hear, until months later you see things failing apart and wonder where you went wrong. You have to hold managers accountable.
The manager ultimately needs to take responsibility for pulling the team out of problematic situations (unstable product roadmap, errand tech lead, full-time firefighting mode). The manager is accountable for the health and productivity of the team.
When the product organisation is constantly changing goals, the manager should identify that the changes are causing problems on the team, and work with product to explain the problem and refocus on what's important.
If the team can't do anything but fight fires, the manager should put together a plan for tackling causes of the fires, and if necessary bring requests for hiring more people or adding more people to the team so that they can get the situation under control.
You'll need to help your managers, sometimes they won't have the energy to push back against product and they'll need your support.
Managers need coaching and guidance in the same way that individual contributors need coaching and guidance.
The people pleaser has deep aversion to ever directly making people he cares about unhappy. If you're in the group that he cares, he'll always say yes. People pleasers often burn themselves out.
- Her team loves her as a person but is increasingly frustrated with her as a manager.
- He's more interested in a team that runs smoothly and avoids mistakes than really become excellent.
- When she is feeling bad, she wears it on her face, and the whole team lose confidence.
- He never pushes back work.
- She overpromises and underdelivers.
- He says yes to everyone and sends contradictory messages.
- She seems to know about all of the problems, but hasn't directly addressed any of them.
The therapist people pleaser can inspire huge loyalty, but unfortunately this can mean he amplifies drama and negativity, and disappoints his team by making promises that he cannot possibly keep.
There is the external pleaser, the one that wants to make her boss and her external team partners happy, and is terrified of revealing problems on her team.
The people pleaser struggles to say no.
These managers make it hard for the team to fail in a healthy way, because of the manager's own fears of failure and possible rejection. An externally focused people pleaser shuts down honest conversation by evasion. A team pleaser fails by promising things that aren't realistic, making the team bitter toward either the manager or the company for failure to live up to these inflated expectations.
If it happens you end up managing somebody in this situation, you can work on help the person feel safer saying no and externalising more decisions so he doesn't take failure personally. Providing strong partners who can take on the task of determining the work roadmap. Creating better processes for getting work scheduled, having a structure that specifies the requirements for getting promotions or accessing other opportunities, the people pleaser can rightly point to the process as something outside of her control.
One of the best things you can do is show the person that he's exhibiting the behaviour, and highlight the downsides.
First-time managers need a lot of coaching, it will be an up-front cost that pays long-term dividends for your organisation.
No book or training can replace you spending some time asking your new manager how her 1-1s are going.
When people start quitting because their manager hasn't give them a career path or isn't inspiring them, it's the ultimately your responsibility. Use skip-level meeting to help out detect areas where you need to support your new manager fully.
A new manager who is working all the time is probably failing to hand off her old responsibilities to other people on her team. Make it clear that you expect the new manager to hand off some of her old work, and help her identify opportunities to do so.
Managers who neglect the job are bad, but managers that take to the job with gusto because they believe it's the key to realising authority are worse. A skip-level meeting will reveal their frustration that they have no ability to make decisions themselves. If your new manager is skipping your 1-1s or evading questions about what the team is working on, you may have a control freak on your hands.
The manager you're training should be ultimately making your job easier. Clearly set the expectations up front that you'll hold her accountable for the team, and help her build the skills to achieve this.
If they truly don't have the willingness to learn and the aptitude to become solid managers, they're a big problem. Making the wrong person a manager is a mistake, but keeping her in that position once you've realise she's wrong for it is a critical error.
Management tends to be a very culture-specific task in a company, if you either work as a manager or hire a manager for a company that's not a good culture fit, you'll have problems.
First challenge is making sure this person fits in with the culture of your team. Often we overvaluate expertise in product areas and allow it to blind us to cultural and process fit with our companies and teams.
You need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge.
Collaborate on areas of difference, allow him to teach you things, and take an active role in the process.
Make sure that the person has the skills you need, then make sure that she's a culture match for your organisation.
You can verify the latter by asking the people who would report to the new manager to interview her by asking her to help with problems they have right now, or have had in the recent past. You can role-play difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.
A manager must be able to debug teams. Ask the manager to describe a time when she ran a project that was behind schedule, and what she did in that scenario. Ask her to role-play with an employee who is thinking about quitting. Describe how she's coached employees who were struggling.
Ask about her management philosophy. If she doesn't have one at all, that might be a red flag. What's the role for a manager? How does she stay hands-on, how does she delegate?
Speaking skills are useful for certain types of leadership but not all.
Give her an abbreviated version of your standard technical interview.
To check for cultural fit, you need first to understand the values of the company around you. If you value servant-leadership and you hire a manager who wants to dictate exact marching orders to the team, there will be a bad fit. Similarly, if you value collaboration and hire a manager who thinks that the loudest voice in any conversation should win, you will also have problems.
Managers shape their teams to their culture. If you hire a manager who doesn't fit culturally with the team she's managing, the manager will fail and you'll have to fire her, or most of the team will quit and then you may still have to fire her.
Most new hires act in self-interest until they get to know their colleagues, and then they move into group interest.
Critical elements to hiring a new managers: the reference check. Ask the references to describe the ways the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again.
Be very curious, ask lots of questions, but in an open way. Make it clear to that your goal is to understand what people do so that you'll be capable of appreciating it better.
Grit your teeth and make the time to get comfortable with each area; take time to get to know the manager and employees in the team, and practice asking for details about the area, so that you can start to learn and develop a sense for what the people in that team are actually doing.
The best engineering managers are often great debuggers. They are relentless in their pursuit of the "why".
Managing teams is a series of complex black boxes interacting with other black boxes. When the outputs aren't as expected, figuring out why requires trying to open them up and see what's going on inside.
- Have a hypothesis. You need a reasonable hypothesis that explains how the system got into the failed state.
- Check the data. Look at the team chats and emails, look at the tickets, look at the repository code reviews and check-ins. What do you see? Look at their calendars.
- Observe the team. Now is the time to start doing some potentially destructive investigations. Sit in their meetings. Boring meeting are a sign. They may be a sign of inefficient planning on the part of the organisers. Good meetings have heavy discussion element, where opinions and ideas are drawn out of the team. Be aware, the act of observing changes the outcome, or rather, causes an outcome to happen. Your presence might provoke hiding the problem you're trying to find.
- Ask questions. Ask the team what their goals are. If they don't understand the goals of their work, their leaders aren't doing a good job engaging the team in the purpose of the work.
- Check the team dynamics. Very professional groups tend to have a degree of personal connection between the members. A bunch of people who never talk to each other and are always working on independent projects are not really working as a team.
- Jump into help. It's OK to jump in and help debug team issues as you see them, particularly when the manager in question is struggling. It can be an opportunity to teach the manager and help him grow.
- Be curious. We get better at debugging by doing it often. We become better leaders by pushing ourselves and our management teams to really get into the bottom of the organisational issues.
Why something is taking so long? Answering it is significantly harder when you aren't embedded deeply in the details.
Hopefully you're being asked this question because something is running over plan by a significant margin.
Sadly, we are often asked this questions in times when things are not taking any longer than the estimate.
You must always be aggressive about sharing estimates and updates to estimates, even when people don't ask. You must be aggressive about getting estimates.
Estimates are often useful even if they aren't perfectly accurate because they help escalate complexity to the rest of the team. Not every project necessarily has requirements that change frequently, and it's possible to do up-front work to drastically reduce the unknowns that make software estimation difficult. Business want to plan and get ideas of cost for effort. Teaching your teams how to hone their instincts about complexity and opportunity is worthy goal.
Don't be afraid to cut scope toward the end of the project in order to make important deadlines.
Challenge of changing product and business roadmaps. There are a few strategies about building a roadmap:
- Be realistic about the likelihood of changing plans given the size and stage of the company you work for.
- Think about how to break down big projects into a series of smaller deliverables so that you can achieve e some of the results, even if you don't necessarily complete the grand vision. Everything must be repeatedly re-examined with an eye toward what's the most valuable right now.
- Don't overpromise a future of technical projects. This kind of thinking will get hopes up and then disappoint.
- Dedicate 20% of your team's schedule to "sustaining engineering". Refactoring, bugs, improving engineering processes, doing minor cleanups, and providing support.
- Understand how important engineering projects really are.
Treat big technical projects the same way as product initiatives. Gather data to support yourself, and talk about what will be possible when the work is done. Pick your battles.
Teams may even be disbanded or moved around in ways you don't understand or agree with. Push for engineering involvement in the early planning for the new work so that people can get excited about the projects they are moving on to. The calmer you can be, and the better you can show (or fake) enthusiasm for the new direction, the easier the transition will be for your whole team.
- Oversee technical investment. You're accountable for making sure the team is placing its technical best in the right places. You can see where the ares of greatest need or opportunity lie.
- Ask informed questions. Having accountability doesn't mean that you personally do the research to find potential investments. You guide these investments by asking questions. You need to know enough about the work to sniff our misguided efforts and evaluate proposed investments.
- Analise and explain engineering and business tradeoffs. Understanding the business and customer goals, you offer guidance as to which technical projects can achieve those goals within reasonable time frames.
- Make specific requests. You still need to have enough understanding of the technology in your organisation to make specific requests without distracting the senior engineers with questions. Managers who don't stay technical enough relay these questions on the team, and then relay the team's response back up to management. This is not value-add role.
- Use your experience as a gut check. Rely on your instincts to guide where you spend your time and attention. So, how should you invest your time to stay technically relevant?
- Read code. Looking over code reviews and pull requests can give you insight into changes that are happening.
- Pick an unknown area, and ask an engineer to explain it to you. Have him pair with you on a small change.
- Attend postmortems. In times of failure you can most clearly see where problems have built up.
- Keep up with industry trends in software development process. Make time to learn about how other teams deliver software.
- Foster a network of technical people outside your company.
- Never stop learning.
Your first job is to be a leader. The company looks to you for guidance on what to do, where to go, how to act, how to think, and what to value. You help set the tone for interactions.
You're capable of making hard decisions without perfect information and willing to face the consequences of those decisions.
You know how to plan for the months and years ahead.
You understand organisational structure and how it impacts the work of teams.
You can play politics in a productive way, in order to move the organisation and the business forward. You work well with your peers outside of engineering.
You understand how to disagree with a decision and commit to deliver on it.
You know how to hold individuals and organisations accountable for their output.
The book High Output Management, breaks down management tasks into four categories:
- Information gathering or information sharing: synthesising large quantities of information quickly, sharing information with 3rd parties in a way they would understand.
- Nudging: Reminding people of their commitments by asking questions instead of giving orders.
- Decision making: Taking conflicting perspectives and incomplete information and setting direction.
- Role modelling: Showing people what the values of the company are. Showing up for your own commitments. Setting the best example for the team even when you don't feel like it.
My job wasn't to be the smartest person in the room. It wasn't to be "right", my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way.
VP role has one obvious difference from the CTO role. The VP is usually at the top of the management career for engineers.
This role means that the person has a solid handle on processes and details. This person is capable of dropping into the details and making things happen at a low level. The VP is usually the one pushing the execution of ideas, while the CTO focuses on larger strategy and the position of technology within the company.
She aligns the development roadmap to the hiring plan, planning out how teams need to evolve.
The job for an VP of Engineering is both a big one and a detail-oriented one. This position must be able to gain people's trust and show wisdom in management and leadership. Most engineers are reluctant to trust people without technical credibility.
The VP of Engineering have some stake in organisational strategy, she sets goals to achieve business deliverables, closely aligned with the product team. She should have a strong business and product instinct and a track record of getting teams to deliver big projects, including the ability to negotiate deliverables.
They want their teams to be happy, but it's important to tie that happiness to a sense of accomplishment. They cultivate a healthy and collaborative culture.
A CTO is not an engineering role. CTO is not at the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers. It's not a role most people who love coding, architecture, and deep technical design would enjoy doing. It follows that the tCTO is not necessarily the best engineer in the company.
The CTO should be a strategic technical executive the company needs in its current stage of evolution.
A CTO must care about and understand the business and she should be able to shape business strategy through the lens of technology. She is an executive first, a technologist second. The CTO may identify areas where technology can be used to create new or bigger lines of business.
Strong CTOs also have significant management responsibility and influence. The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.
CTOs that don't have management oversight over teams, technology becomes an execution arm and they cannot have much strategic influence. You can't give up the responsibility of management without giving up the power that comes with it.
If you give up management, you're giving up the most important power you ever had over the business strategy, and you effectively have nothing but your organisational goodwill and your own two hands.
Being a CTO it's a business strategy job first and foremost. It's also a management job. If you don't care about the business your company is running, then the CTO is not the job for you.
Priority changes from senior management can sometimes happen without warning. When leaders see an opportunity or feel that the priorities of the organisation need to change, they often expect the change to happen immediately. This rarely happens..
You must first go though the list of things in flight and kill or postpone work in order to make room for new priorities. You need to do that, if it's truly urgent.
Not focusing on the right priority it's a sign that you and the CEO have a misaligned understanding of reality, and you need to get on the same page.
The more senior the management and leadership position you take in the company, the more the job becomes making sure the organisation moves in the direction it needs to move in, and that includes changing direction when needed. You do this by clearly communicating the direction to your teams and making sure they understand it and are taking the necessary steps to change course.
Most people need to hear something at least three times before it really sinks in.
The larger the organisation, the harder it'll be to change priorities quickly. Keep the CEO informed about what's happening and why. Do your best to show that you understand his priorities and tell him about the concrete steps you're taking to meet those priorities.
Strategy as a critical element, setting strategy looks like
- Do a lot of research.* The technology we had currently built, the pain points. Where the expected growth will come from the future. What are the scaling challenges right now, and where they might be in the future. What are the current productivity bottlenecks.
- Combine your research and your ideas. Draw out the systems in place at your company, slice and dice the systems and teams across various common attributes. Get insights on the way data flows and changes, and possible axes for evolution.
- Draft a strategy. Actionable ideas to improve operational efficiency, expand features and grow the business. Consider the structure of the business, the needs of the customer and possible future evolutions. Develop a technology strategy that supports these factors into the future.
- Consider your board's communication style.
- In an underdeveloped strategic plan, the system and architectural details offer very few forward-thinking ideas beyond the next 6 to 12 months. It's not uncommon for company boards to read through the slide deck before a meeting, so that the meetings can be focused more on the details on presentations.
- A good technology strategy means good technology architecture, team structure, underpinnings of the business and the directions in which it was header. Potential futures of the business. Anticipates and enables future growth.
You'll need to excel at communicating sensitive information to large groups
- Don't blast an impersonal message to a large group. The worst way to communicate bad news is via impersonal mediums like email and chat. Your team deserves to hear the message coming from your mouth directly. The second-worst way to deliver a message is with all them in a room at once.
- Do talk to individuals as much as possible. Try your best to talk to people individually about the news.
- Don't force yourself to deliver a message you can't stand behind. You might need to have someone else help you deliver it.
- Do be honest about the likely outcomes. Being forthright with people will help them trust you and tolerate unhappy news well.
- Do think about how you would like to be told.
Reporting to a nontechnical manager can be a total culture clash.
- Don't hide information behind jargon, and be careful with details
- Expect that you will need to run your 1-1s with your new boss, so come prepared with a list of topics.
- Try to bring solutions, not problems to be solved. Don't shy away from delivering bad news.
- Ask for advice. Nothing shows respect like asking for someone's advice.
- Don't be afraid to repeat yourself.
- Be supportive. Show that you are there to support.
- Actively look for coaching and skill development in other places. Get a coach, ask for training, and create a peer group outside of the company.
Senior leaders must actively practice first-team focus. They should dedicate first and foremost to the business and its success, and secondly to the success of their departments. Having few to no peers on your first team who are fellow engineers can feel very isolating.
You let them own their ideas, and they let you own yours. If you disagree, try to stay out of it, always choose to discuss with kindness. The place for disagreement is either one-on-ones or in your leadership team meetings. Expect to defend your own technical decisions and roadmap in this settings.
You have to put aside the idea that they're acting in irrational and self-interested ways when they disagree with you or do things you don't like.
Establishing this fundamental trust is really difficult. A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines and budgets. You have to figure out how to understand and trust everyone's styles across the spectrum.
Your peers who are not analytically driven are not stupid. Throwing out jargon to people make us look stupid to them.
Disagreements that happen in the context of leadership team don't exist to the wider team. Once a decision is made, we commit to that decision.
You'll be watched more closely than you've ever been watched in your life. Your first team is compromised of your peers at the leadership/executive level, and your reporting structure has now become your second team. Socialising heavily with your team outside working hours is a thing of the past.
If you don't detach, you're likely to be accused of playing favourites. In fact, you probably will play favourites if you maintain very strong social ties with people who report up to you on the team.
You need to detach because you need to learn how to lead effectively, with a throwaway comment, you can cause people to change their whole focus. Your reports are going to have a hard time distinguishing between their buddy and their boss.
Your mere presence will change the tone and structure of meetings you attend.
As you choose which behaviours to model in front of the team, they will learn those behaviours and copy them.
You're going to be part of hard decisions. It won't be appropriate to discuss these decisions with other people at the company. It is tempting to rant to those you consider friends and your reporting team, but this is a bad idea. As their leader, you can easily undermine their confidence by sharing worries that they can't do anything to mitigate.
Care more about people as individuals. Take time to get to know as many people as you can as humans. It cab be easy to start to dehumanise people and treat them like cogs. People can tell when their leader stop caring about the individuals. Nurture that kind of connection reinforce that you do care.
- Practice relatedness. Getting to know your team as people or let them know you as a person. If you want a team that feels comfortable taking risks and making mistakes, one of the core requirements is a sense of belonging and safety. This means you need to take little time to small talk.
- Apologise. When you screw up, apologise. You're showing the team that apologising doesn't make you weaker, it makes the whole team stronger.
- Get curious. When you disagree with something, stop to ask why. Attacking something we disagree with makes that harder. Learn how to turn that disagreement into honest questioning.
- Learn how to hold people accountable without making them bad. How do you measure success? Does the team have the capabilities needed to succeed? Are you providing feedback along the way?
The role played by a senior leader of a functional area (CTO, CFO, etc.), sets the baseline of what excellence looks like in this function ("True North").
A way of exploring the True North in technology is by looking through the lenses of risk analysis. Things like:
- Having a single point of failure.
- Having known bugs and issues.
- Being unable to tolerate high load.
- Losing data.
- Putting out code that is undertested.
- Having slow performance.
True North helps us understand that all these issues must be carefully considered. Just because these rules have exceptions doesn't mean we forget that they exist. True North is the guiding instinct that we as leaders have developed over time
You must spend enough time in your career to hone these instincts in order to be comfortable making fast judgment calls.
At this level your coaching and mentoring are likely to come from people outside of your company. Do you know other senior managers at companies in your area? Do you admire any technology senior managers? What is it about them that you admire? Are you behaving like a role model for your team?
As part of your role of senior engineering leader, part of your job is to set the culture of your function. Neglecting the team culture is a sure-fire way to make your job harder.
In startup culture, the ideas of "structure" and "process" are seen as pointless at best and harmful at worst. Startups believe that structure is the reason large companies move slowly.
Instead of talking about structure, is better to talk about learning. Instead of talking about process, it's better to talk about transparency. We don't setup systems because structure and process have inherent value. We do it because we ant to learn from our successes and our mistakes, and to share those successes and encode the lessons so we learn from failures in a transparent way.
Consider not only what you care about, but also how you can scale that knowledge and effort effectively.
The important thing for leaders to be willing to do in those early days is to pic a strategy and run with it. You don't need to find the perfect solution; you need to find something that will get your through to the next milestone.
Sometimes companies decide to limit the decisions themselves, as in organisation that forgoes titles. Deciding not to decide right now is a popular option for new companies, because it really doesn't matter at the scale of a few people.
Pretending to lack structure tends to create hidden power structures. In The Tyranny of Structurelessness Jo Freeman describes a set of circumstances in which the unstructured group can work:
- It is task oriented. It is the task that basically structures the group.
- It is relatively small and homogeneous. Homogeneity is necessary to insure that participants have a "common language" for interaction.
- There is high degree of communication. Information must be passed on to everyone.
- There is a low degree of skill specialisation. Everything must be able to be done by more than one person. People become interchangeable parts.
When work is done to satisfy an immediate task, in a unified code base worked on by a team of interchangeables, the result is not usually a larger thoughtful structure, but a tweak here, a hack there. We usually end up refactoring the code to make it scalable, this involves identifying and explicitly drawing out structure in order to make code base easier to read and work in.
That is the value of structure. Structure is how we scale, diversify, and take on more complex long-term tasks. In the same way that strong technical system designers are capable of identifying and shaping underlying system structures, strong leaders are capable of identifying and shaping underlying team structures and dynamics, and doing so in a way that supports the long-term goals.
The earliest startup is like a driving car. As you grow, you graduate to a commercial flight. So you need to consider your movements more carefully. Finally you graduate to a spaceship, where you can't make quick moves and the course is set long in advance, but you are capable of going very far and taking tons of people along the ride.
- People. Leaders who want a high degree of control over their organisation tend to need more structure in place to make sure their wishes are enacted.
- Age. The longer a company is around, the more habits become entrenched. The longer the company has been around, the more likely it is to continue to survive.
- Size of existing infrastructure. If you have few established business rules and little code or physical infrastructure, there is less need for structure. The more existing business rules and infrastructure you have, the more you'll need clarity on how to handle them.
- Risk tolerance. Your structures and process should reflect this.
When failures occur, examine all aspects of reality that are contributing to those failures. The patterns you see are opportunities to evolve your structure, either by creating more or different structure or removing it. Using failure to guide evolution lets you apply structure at the right level. Success is often a poor teacher. If you want to learn from success, make sure you can identify the actually improvement you're seeking.
When every new hire slows down the team down for months because there is no onboarding process, that is a failure due to lack of structure. When people regularly leave the company because they have no path to advancement or career growth, that is a failure due to lack of structure. The third time you have a production outage because someone logged directly into the database and accidentally dropped a critical table, that is a failure due to lack of structure. Better to talk about learning and transparency rather than using the word structure.
Culture is how the things get done, without people having to think about it.
Consciously guiding the culture of your team is part of a leader's job.
Culture is the generally unspoken shared rules of a community. Culture doesn't mean that every single person holds exactly the same values, but it tends to guide a general overlap.
In complex environments where the needs of the group must override the needs of the individual, cultural values are the glue that enables us to work as a team.
Define your culture. If you have a set of company values, map those values onto your team.
Reinforce culture by rewarding people for exhibiting its values in positive ways. The stories that we tell as a community bond us together.
One of the most important uses of performance reviews is to evaluate the alignment between team members' values and the company's values.
Learn to spot people who have value conflicts with the company or team. Using the core values to coach people in areas where they are misaligned can help you articulate what otherwise may feel like just ambiguous friction.
Finally, use this as part of your interview process. Look out explicitly for places where the interviewee seems to match or collide with these values. Cultural fit is not about hiring friends. Cultural fit as determined by friendship tests is almost certain to be discriminatory in some way.
Write the values down if they aren't already written, and try to be explicit. Use this explicit list to evaluate candidates, praise team members, and inform your performance review process.
Getting started on these documents from scratch is hard. Fortunately there are fewer and fewer documents that you need to start from scratch to create, as more people are sharing publicly their policies and processes. Be mindful however, what works for one company, will not always translate well to another company, even if the companies have a lot of things in common.
- Solicit participation from your team. Enlist the support for senior managers and engineers on the team to provide feedback and details.
- Look for examples. Examples of ladders from friends at other companies to help provide some ideas for the details.
- Be detailed. You want something that is inspirational and descriptive but that matches your company.
- Use both long-form descriptions and summaries.
- Consider how the ladder relates to salary.
- Provide many early opportunities for advancement. You may want to be able to promote someone every year for the first two to three years of her career. Create several levels that encompass the role of software engineer.
- Use narrow salary bands for early-career stages. Lots of levels and narrow salary bands mean that you can promote people quickly.
- Use wide salary bands when and where you have fewer levels. You want those salary bands to overlap. Software engineer band may go $50-100K, and a senior software engineer band might go $80-150K. This is meant to retain talent who are performing well at their current levels. This also also allows you to hire people who are on the fence into the lower level with the expectation that they will be promoted quickly.
- Consider your breakpoint levels. Lack of advancement means that the person has not achieved the maturity of independence needed to remain at the company. For many companies, it's somewhere around senior engineer. Someone who's made it this far is a solid team member. You may even want to use it as a the point at which your ladder levels get harder to achieve.
- Recognise achievement. Celebrate and share keystone promotions.
- Split management and technical tracks. You do not want people to feel that the only path to advancement is by managing people, because not everyone is suited to that role.
- Consider making people management skills a mid-career requirement. Consider making leadership experience (tech lead) a requirement for promotion to senior individual contribution levels.
- Years of experience. Distinguish the keystone levels by an expectation of maturity increase, and these tend to correspond with years of experience.
- Don't be afraid to evolve over time. A ladder is a living document that will need to evolve as your company grows.
(Rent the Runaway Ladder](https://dresscode.renttherunway.com/blog/ladder).
Who do you work with? Who do you report to? Who do you collaborate with?
Cross-functional product development is putting everyone who is needed to make a project successful together in one group.
We are acknowledging that the most important communication is that which leads to effective product development and iteration. It will probably produce systems that have some inefficiencies compared to companies that have a more engineering-centered team structure. You'll have to decide where you're willing to take some system design hits in order to most effectively create products.
Engineers are managed by engineering managers that report to the CTO. Product managers report to the head of product. The determination of who was working on what is done largely by the team itself.
Someone in engineering needs to oversee critical core systems, and you probably need a few specialists. These functions can be kept in a small infrastructure organisation that is not generally assigned to product development. Engineers assigned to product teams still need some time to account for engineering-specific tasks like on-call, interviewing, and technical debt (advise to reserve 20% of the time for these tasks).
The infrastructure team supports both fundamental systems as well as large frameworks and technologies that will be used by many teams across the company.
In technology-focused structures, the focus is on being the best engineer. In product-focused structures, the engineers who have the best product sense will start to emerge as the leaders of the team.
In the areas where the technology must be rock-solid or exceptionally innovative and cutting-edge, you probably want teams that have more of an engineering focus and that are led by people who can design complex systems.
Without any process, your teams will struggle to scale. With the wrong process, they will be slowed down.
Think of process as risk management.
This has two important implications. The first is that you should not put a complicated process on any activity where you want people to move quickly or that the risks themselves are obvious to the whole team.
The second implication is that you need to be on the lookout for places where there is hidden risk, and draw those hidden risks out into the open. Processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socialising change or risk to the team as a whole.
You want the process to be straightforward and efficient:
- Be clear about code review expectations. Code review is largely a socialisation exercise, so that multiple team members have seen and are aware of the changed code.
- Use a linter for style issues.
- Keep an eye on the review backlog. Limit how many outstanding review requests a person can have assigned to him.
- Resist the urge to point fingers and blame.
- Look at the circumstances around the incident and understand the context of the events. Understand and identify the factors that contributed to this incident.
- Be realistic about which takeaways are important and which are worth dropping. Pick the one or two that are truly high-risk and highly likely to cause future problems, and acknowledge the ones that you are going to let go for now.
The goal of architecture review is to help socialise big changes to the appropriate group, and to make the risks for those changes clear.
- How many people on the team are comfortable using this new system/writing this new language?
- Do you have production standards in place for this new thing?
- What is the process for rolling this out and training people to use it?
- Are there new operational considerations for using this?
Some guidelines:
- Be specific about the kinds of changes that need architecture review. Usually these include new languages, new frameworks, new storage systems, and new developer tooling.
- The value of architecture review is in preparing for the review. It forces people to think about why they want to make these changes. It make people aware of the risks that they may not have considered.
- Choose the review board wisely. The scope of the deciding group is best kept to the people who will be closely impacted by the decision.