One of the early lessons in leadership, whether it is via direct management you a vide or indirect influence, is that people are not good at saying precisely what the dire mean in a way that others can exactly understand. We have yet to achieve Borg Cal hive mind or Vulcan mind meld, so we’re constantly pushing complex ide through the eye of the needle of language. And language is not something that most engineers have mastered in nuance and interpretation. So listening goes beyond hearing the words your mentee is saying. When you’’re face to face with another person, you also have to interpret his body language and the way he’s saying those words. Is he looking you in the eye? Is he smiling? Frowning? Sighing? These small signals give you a clue as to whether he feels understood or not.
Be prepared to say anything complex a few times, in different ways. If you feel that you don’t understand something your mentee has asked you, repeat the question in a different way. Let him correct you. Use those whiteboards scattered around your office, if necessary, to draw diagrams. Spend the time that you need to spend to feel understood, and like you understand the mentee. And remember that you’re in a position of huge power in your mentee’s eyes. He’s probably nervous about screwing this opportunity up, trying his best to please you, and trying hard not to look stupid. He may not ask questions even when he doesn’t understand things. Make your life easier and get those questions out of him. The odds of you spending all of your time answering questions are slim compared to the odds that your intern will go off in the absolute wrong direction because he didn’t ask enough questions.
When you are a mentor Tell your mentee what you expect from him. If you want him to come prepared for your meetings with questions he has sent you in advance, ask for that. Be explicit about your time commitment. And then be honest with him when he asks questions. There’s no point in being a mentor to a relative stranger if you can’t at least use that professional distance to offer him the kind of candid advice that he may not get from his manager or coworkers.
If you’re ever in the position to promote people to management, be very, very on the team. Highly technical hands-on managers can be good for small teams of careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role. The alpha geek culture can be very harmful to collaboration and can deeply undermine those who feel unable to fight back. Alpha geeks who believe that their value comes from knowing more than others can also hide information in order to maintain their edge, which makes everyone on the team less effective.
What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals. So often, we fail to apply this basic wisdom to the process of assigning mentors, but it applies here as much as anywhere else. When you need to assign a mentor for your new hire or intern, figure out what you’re hoping to achieve by creating the relationship. Then, find the person who can help meet those goals.
Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying. To work successfully with a newcomer or a more junior teammate, you must be able to listen and communicate in a way that person can understand, even if you have to try several times to get it right. Software development is a team sport in most companies, and teams have to communicate effectively to get anything done.
The tech lead is learning how to be a strong techniC project manBger, and as such, they are scaling themselves by delegpting work effec tively without micromanaging They focus on the whole team’s productivity and strive to increase the impact of the team’s work produuct They are empowered to make independent decisions for the team and are learning how to handle difficult management and leadership situations They are also learning how to partner effectively with product, analytics, and other areas of the business.,
Asa new tech lead, be carefual of relying on process to solve problems tha are a result of communication or leadership gaps on your team.
Another approach that many experienced managers use is to help their new reports create a 30/60/90-day plan.
When you feel like you want to micromanage, ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis.
Why bother writing any code if all you’re doing is small stuff? The answer is that you need to stay enough in the code to see where the bottlenecks and process problems are. You might be able to see this by observing metrics, but it’s far easier to feel these problems when you’re actively engaged in writing code yourself.
If the build is really slow or deploying code takes too long or on-call is a nightmare, you’ll feel it in the difficulties you, an experienced engineer,
Sometimes, teams aren’t shipping because the tools and processes they’ve been using make it hard to get work done quickly. A common example is that your team only tries to release changes to production once a week or less. 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 kmow how to break their work down. Now that you’re managing the team, start to push for the eam, removal of hese bottlenecks.
Be careful that vocally negative people don’t stay in that mindset on your team for long. The kind of toxic drama that is created by these energy vampires is hard for even the best manager to combat. The best defense is a good offense in this case, and quick action is essential,
It might be cultivating the list of things that are important but you haven’t thought about in a while, so you know what to focus on. If you don’t set aside some time to focus on these issues, they’ll sneak up on
The purpose of this skip-level process, beyond maintaining trust and engoge Ment, is to help you detect places ìn which you’re being “managed up” well o the detriment of the team under that manager.
One of the best ways to do this is 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. Similar to a senior engineer being asked how he might approach debugging an issue that you just resolved, a good manager-even without a full understanding of the people or projects involvedshould have good instincts for questions to ask and suggested next steps that might improve matters. You can take it a step further and actually role-play other types of difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.
Importantly, a manager must also 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. Or ask her to role-play with an employee who is thinking about quitting. Ask the manager to describe how she’s coached employees who were struggling, and helped great employees grow to new levels.
Design and architecture questions based on the types of systems she’s built or managed are a good approach. Make sure she can discuss the tradeoffs that were made and why. You might also have her mediate a technical debate between engineers who disagree on the solution to a problem.
Managing teams is a series of complex black boxes interacting with other complex black boxes. These black boxes have inputs and outputs that can be observed,
Dedicate 20% of your team’s schedule to “sustaining engineering,” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support. Take this into account in every planning session. Unfortunately, 20% is not enough to do big projects, so additional planning will be needed to get major technical rewrites or other big technical improvements. But without that 20% time, there will be negative consequences with missed delivery goals and unplanned and unpleasant cleanup work.
As you can see from this tale, good technology strategy here meant several things. It meant technology architecture, yes. It also meant team structure. It meant understanding the underpinnings of the business and the directions in which it was headed. I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business.” It’s not just a reactive document that tries to account for current problems, but it anticipates and enables future growth. If you’re in a product-focused business, this is the heart of your technology strategy. It’s not about actually deciding the product’s direction, but about enabling the larger roadmap to play our successfully.
One of the best analogies I’ve heard for startup leadership comes from a friend, On Freud, who’s been in engineering management at several different startups. On describes the earliest startup as like driving a race car. You’re close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you’re also at risk of crashing at any moment, but you only take yourself down if you do. As you grow, you graduate to a commercial flight. You’re farther from the ground, and more people’s lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly.
Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.
Buy yourself a copy of the book.
Thanks for reading 🤗
