Scaling As a Leader - Learning To Trust But Verify

As a leader, regardless of what industry you're in, mastering the skill of delegation is a must. You cannot scale as a leader unless you are able to delegate the ground work to others. Successful delegation requires a certain amount of trust. But blind trust is the enemy of successful delegation.

Successful delegation means being able to trust that the person you are delegating to is capable, competent, and willing to get the job done. The best way to ensure their success is to follow the trust but verify model. In this model, you follow up with the delegate periodically to determine if:

1. The task is on track
2. The delegate is looking around corners. i.e. identifying what's coming up that's not directly in their line of sight
3. The known unknowns are being addressed
4. The delegate is working to identify the unknown unknowns

One common problem with people trying to implement the trust but verify model is micromanagement. Here are some tips for practicing trust but verify and avoiding micromanagement.

it's okay for it not to be done your way

In most cases there are many ways to solve a problem. Yours may or may not be the best way. Giving your delegate room to figure this out is important. Your primary role in the trust but verify model is to make sure that they:

1. Have thought through the problem and aren't just going off the cuff
2. Aren't making irreversible or hard to reverse decisions
3. Aren't falling behind schedule
4. Are aware of the decisions they're making, specifically with regards to long term sacrifices for short term gains

focus on the outcome

When making sure that the person you've delegated to is thinking through the problem it's important to make sure your questions are focused on the outcome of the task and not on the approach. Remember, you're not solving the problem and therefore the approach may not be the same as if you were solving the problem.

Focusing on the outcome of the task makes sure that whatever the approach, the correct result is being achieved.

understand how to measure success

As you delegate tasks or projects to others you need to be clear about what the definition of done is. Additionally, you should talk with them about milestones that can be defined and achieved before the task or project is complete. Use these milestones to measure the success of the task or project. The best way I've found to do this type of measurement is to create SMART goals.

Leading Well

Understand you're part of a larger system, and are not the center of that system

Your team, your software, and your role are crucial for the success of your company or division. But it's important to remember that you're not THE ONLY thing that lets your company or division succeed. You're one part of a larger ecosystem. Knowing this will help you identify:

1. Your role and your teams role in the ecosystem and how best to contribute.
2. What inputs/outputs are needed from you and your team to make the larger system better.
3. Where you may be a bottleneck to the success of the system.

Do the right thing, not because you're rewarded, but because it's the right thing

Good leaders understand that you're not always going to get rewarded for doing the right thing, but you still need to do it (whatever it may be). Doing the right thing may actually mean you have to take on more work. It may mean admitting that you were/are wrong. It may result in not achieving expectations. Whatever the outcome, it's about doing the right thing because it's right in and of itself.

Make time to step away and remove yourself from the problem space

If you're constantly in the thick of things you're going to burn out, you're going to get sloppy, and you're going to miss key things. You need to make sure that you are giving yourself time to pull back and think through problems.

I'm not just talking about vacations (which are important). I'm more talking about making sure you have built in distance from the problem so you can think. For me, this often happens when I'm riding my bike to or from the office. I have 35 minutes where I don't have anyone asking for my help or input. I'm not being barraged with email or phone calls. It's just me, the road, and my bike. It allows me to take time to think through things critically.

Surrounded yourself with advisers

Good leaders understand they don't have all the answers. But they also know how to get to the right answers. They do this by surrounding themselves with advisers who are subject matter experts on problems that they will never have enough time to become an expert in. For example, the President of the United States has his cabinet and the joint chiefs. These are people whose job it is to know the answers to problems that the president is accountable for helping to solve.

Hold strong opinions very loosely

Good leaders have opinions and are willing to express them. This doesn't mean that good leaders are arrogant. Quite the contrary. Good leaders are able to recognize when their opinions are wrong and are able to adjust. But they're not afraid to go out on a limb and express what they believe is right.

Preparing for a software development interview

Software Engineering interviews can be stressful. They're typically 4 - 5 hours long meeting with 4 - 6 different people.  Being prepared can be the difference between getting that job you've always wanted or failing to truly demonstrate your capabilities and skill-set. Here are some tips for preparing for software development interviews.

Make Sure You Understand The Problem, Ask Clarifying Questions

One of the bigger problems I often see in interviews is the candidate just jumping in to solve the problem without making sure they understand what they're being asked to do. Even if you feel like you understand the problem 100%, you should ALWAYS repeat back what you think the problem is before jumping in.

Every problem comes with some level of ambiguity. As you repeat back the problem think about how to remove that ambiguity. Ask clarifying questions that help you understand what is in scope and out of scope for the problem.

Review Your Data Structures

One of the main things that you need to be able to demonstrate in any software engineering interview is how well you 1) know your data structures 2) know when to use certain data structures and 3) understand the systematic complexity for each one (e.x. how long do reads or writes take). Before every interview you should review the following data structures and understand how to apply them to solve real world problems.

1. Array
2. Linked List
3. Hash Table
4. Binary Tree
5. Queue

Give An Overview Of How You're Going To Solve The Problem 

To be successful as a professional software engineer you need to be able to communicate well. It's not enough to simply be able to code. Because you're going to work on a team and with people that aren't engineers (product development, program management, design, and etc) being able to communicate effectively is an essential part of the job.

Being able to talk through your solution helps you demonstrate that you're able to communicate effectively. Additionally, talking out loud about a solution often helps you identify gaps or potential bottlenecks before you get into your code. Essentially, it gives you a chance to validate your design and show the interviewer that you can approach a problem systematically.

Focus on Solving The Problem First Then Optimize

Another common mistake I see interviewees make is getting so focused on giving the most optimal solution that they never finish creating a valid solution. You're not likely to get an offer if you can't complete the exercise within the time allotted.

Your goal should be to create a working solution first. At that point, if you have time, you can optimize it. Along the way you can point out potential bottlenecks or un-optimized code.

Keep Things Simple

Simplicity in software is a gift. Complex software typically has problems with readability, understandability, and scale. You should focus on demonstrating that you understand how to keep things simple when solving your problem.

Some easy ways to do this are:

1. Limiting the number of classes/interfaces you create.
2. Use meaningful variable names.
3. Encapsulate the code into short simple methods, rather than one giant method.
4. Use built in language constructs rather than re-inventing the wheel.

Know How To Test Your Solutions

Professional software engineers test their own software. You need to be prepared to identify:

1. Test cases when the code should succeed
2. Test cases when the code should fail
3. Test cases that handle typical edge cases like NULL values, being passed 0, 1, or many objects, no connectivity, and etc.

Problematic Software Development Interviews

Interviewing in the tech industry is hard. Both for the interviewer and the interviewee. As an interviewer you've got 45 minutes to 1 hour to determine if someone has the right technical prowess and is a good fit for the company and for your team. As an interviewee you've got 45 minutes to an hour to show off what you know, how well you adapt to change, and how you respond when you don't know something.

In my 16+ year career I've been on my share of bad interview loops. The reason they were bad wasn't because of anything inherent about the person conducting the interview. They were bad because the person conducting the interview didn't know how to flush out what they needed to know about the candidate because they were asking the wrong questions or questions with the wrong focus. Here are four ways I've seen interview questions go down the wrong track. 

The Problem Requires More Than 20 Lines of Code

Writing code takes time. But even more so, solving the problem takes time. You need 3-5 minutes to go over the problem. The candidate then will likely 5 or so minutes to ask clarifying questions and make sure they understand the problem. Then there's another 5 or so minutes of them thinking through the problem and coming up with a solution that they can code.

Ideally, the candidate should be able to write the code for the solution in around 10 minutes. That's 30 seconds per line at 20 lines of code. If your problem requires more than 20 lines of code to solve, you're going to miss out on talking through their code with them. You'll also miss out on being able to scale your question to see how adaptable their code is to change.

The Problem Is Niche And Took You More Than An Hour To Solve

It's very rare that your problem space is so niche that you only want a candidate that has an EXACT set of knowledge in your problem domain. More likely, it's the case that you want to determine if the person knows her/his fundamentals well enough to be able to quickly adapt and learn a new problem space. Because of that, you should avoid niche questions or questions that require you to have super in depth knowledge about the problem space.

A better way to determine if the person is able to adapt and learn is to give them a problem to solve that requires them to critically think through an issue. Once they've satisfactorily solved that problem, change the parameters. You can do this by asking things like "how could you do this with less hosts" or "how could you solve the problem with half the memory usage" or something else that changes an external factor, an input, or an output.

Responding to change is what we do day in and day out as Software Engineers. It's more important to see how well they know their fundamentals and respond to change than it is to determine how deeply they already know your problem space.

The Problem Has Nothing To Do With The Problem Space The Job Is For

Unfortunately, too many times I've seen people ask questions that were not anywhere near the problem space that the job was in. I've seen front end web or mobile developers struggle trying to solve binary tree or problems involving Dijkstra's algorithm when the real problem domain is working with object life-cycle, state management, hardware constraints, and etc.

Make sure that your interview questions are able to tease out whether they will be able to be successful in your problem space. Not whether they know some arbitrary algorithm that isn't applicable or won't help them be successful in your problem space.

The Problem Determines How Clever They Are, Not What Their Skill-set Is

Trick questions, riddles, and brain teasers are not good interview questions. They help determine how clever a person is but not how likely that person is to succeed in your position. There was a time in the early 2000's when you couldn't attend a software development interview loop without being asked a question like "why is a man hole round" or some other riddle.

As an interviewer you want to determine if the person knows the fundamentals of software engineering, can think critically, can adapt to change, and fits in with the culture of your company or team. Your goal is NOT to determine of the person is clever.

Managing someone elses software development career

In my last post I talked about how to manage your own career as a software engineer. In this post I want to talk about managing someone else's career. As a manager you have a responsibility to your directs to make sure they're aware of what it takes to get to the next level, that they're on the right path, and that they've got the right opportunities to achieve their goals.

Here are some tips to managing someone else's career in software engineering.

Understand their career development goals

Don't make the assumption that what you think they're good at is something that they want to be doing. I've had engineers that would make tremendous project managers or software development managers that just didn't want to pursue those roles. While they were good at them, it was wasn't something that they were passionate about. One of your jobs as a manager is to find out and explore what they're passionate about.

Some of your engineers may not know what their goals are. In this case you should be able to walk them through what options they have available. Help them understand not just how they can advance in their current role, but what other roles are available to them.

Identify their strengths

As a manager you should be able to discern your direct reports strengths. This is does not mean identifying just what they are great at, but also what they would be great at if they just had some coaching. As a manager you need to understand that your directs have both realized and unrealized strengths. Your goal should be to help them realize the ones that they have not already.

Identify the gaps and set some goals

This is probably the most obvious job of a manager but it's also the most over indexed one and one that is often misunderstood. At the core of this problem is helping your directs be aware of the areas that they need to improve on. This will involve having a tough conversation with them about things they're not doing well. When you have this conversation you should be prepared to help them formulate a plan to overcome these deficiencies.

Not all gaps are worth closing. There are some weaknesses that your directs may have that aren't going to be worth the investment from them to fix. Either because it's not going to help them on their desired career path or because the level of investment wont produce enough return to make it worth it. It's as important that a manager helps their directs avoid taking on the work that doesn't play to their strengths as it is to help them take on work that does.

After you've identified the gaps you should set goals to help them gain the skills they need. The key to them achieving their goals is having the right opportunities. As a manager one of your responsibilities is to identify the right opportunities for them and give them a chance to take these opportunities.

Get them visibility

It's important to make sure that as your direct reports achieve their goals that you get them the right level of visibility into their achievements. Getting them visibility helps them gain the trust of other leaders in their space. This in turn will help them get bigger and better opportunities.

Solicit feedback

Part of helping your direct reports grow is getting them good feedback from their peers as well as other leaders in their space. In the course of their day to day they may not have the time or opportunities to debrief on the things they have completed. As a manager you should be periodically checking in and helping them to get this very valuable feedback.

Be able to articulate their achievements

The last key to managing someone else's career is being able to articulate their achievements. This is key because you're likely to have to be their proxy at some point and your ability to articulate their achievement is paramount to their success. At a minimum you should understand:

1. What the problem was
2. Why solving the problem was important
3. What trade-offs they had to make along the way
4. What the impact of solving the problem was

Managing your software development career

One of the things I wish I had done better as a Software Engineer was manage my career. I was in the role of software engineer for over a decade but it wasn't until the last 5 years of that portion of my career that I started to take control. For the first 6 or 7 years of my career I naively believed that if I just did a great job my career would advance. I trusted that my management team and senior leaders would recognize my achievements and I would make my way up the leadership ladder.

While there's nothing wrong with having that much trust in your leadership team, in my opinion, it isn't the right way to manage your career because you have very little ownership of your success or failure. You're career should be a reflection of your capabilities and your desire to succeed. Not everyone wants to move up and not everyone is capable of moving up, but most are.

Here are some tips to help you understand how to navigate your software development career.

 

Start the conversation with your manager

No matter how good your manager is, you have to assume that he or she is unaware of your desire to make it to the next level. Starting the conversation with your manager helps them understand that you want to grow as an engineer. 

One important thing to be aware of is that when you have that conversation you're going to need to be prepared to hear about both the good and the bad about where you're currently at. You need to approach that conversation objectively and with a desire to close the gaps. Getting to the next level in your career is mostly about closing the gaps between where you're at and where a person at the next level already is.

Understand the responsibilities

No one is ready to move on to the next level until they're already over performing at their current level and have begun to perform the duties and responsibilities of the next level. Because of that, understanding the responsibilities of your current level and that of the next level is key to growing and achieving your goals. In particular you should understand:

1. What the expected technical capabilities should be
2. What the volume of code that you should be producing is
3. What the expected level of autonomy is
4. What the scope of influence should be. I.e. what influence you should have on your team, across teams, and within your org
5. What your role should be with respect to your roadmap and the teams day to day activities

Create an achievements doc

If you're anything like me you're not going to remember the important details about your everyday achievements. What I like to do is to keep an achievements doc where I can keep track of the details of my achievements. I don't write in it everyday but I try to re-visit it once a week and make sure that I put my big achievement of the week into it. I like to keep track of what I deliver, who I influenced, and other big decisions I made or contributed to.

I try to keep track of the following information for each achievement:

• What the problem was
• What the proposed solution was
• What the alternatives were i.e. what were the trade-offs
• Why the solution chosen was the correct one
• What the impact the solution had on the business, the team, operations, and/or efficiency

That last point is important. You're going to need a way to measure each of your achievements. Having data to back up what you do is the best way to have an objective conversation with your management.

 

Expand your influence

One thing common to every role is that the more senior you get the more influence you should be having. As a junior engineer you're sphere of influence is largely limited to yourself and your work. As you grow and develop you're sphere of influence expands from just yourself to your team. The more senior engineer you become your influence expands outside of just your team to your org. Expanding your influence means identifying what the sphere of influence should be at your current level and what it should be at the next level.

Get a mentor

As a growing engineer you need an outside influence. You need an objective voice to help you see both your strengths and your weaknesses. A mentor is someone that can help you see the obstacles to your career growth. They can help you grow your existing skills and identify new skills that you need to gain.

Create goals

The last step in career advancement is to create a set of goals. These goals should represent a mix of things it takes to be successful in your current role as well as things it takes to show that you're already working at the next level. Your goals should be SMART (specific, measurable, achievable, relevant, and time bound) and should be something that you review directly with your manager periodically (at least once a quarter). Goals are your best way to make sure you're on track for career advancement. 

The importance of team identity

Does your team have an identity? Something that defines them? Something that they can rally around when things get tough? Something that allows them to put a stake in the ground and affect change? Having a team identity provides many benefits that will make your directs happier at their jobs, more productive, and more efficient in their interactions.

Resiliency to change

Identity at it's simplest form means there's a sense of oneness or sameness. For example, my body is constantly changing. The cells I have today, the blood flowing through my veins, and the hair on my head is not the same as it was 10 years ago. But I am still me. When a team has an identity, they are able to be more resilient to change. People can come and go on the team without affecting the team as a whole. Team charters can change without causing a panic. Team identity is the glue that holds things together.

Stability when the crap hits the fan

When a team has identity they have the ability to weather a storm. They have the ability to lean on each other and be honest about mistakes because there's a shared value system. Teams that have an identity tend to help each other out when someone is struggling. Sometimes that takes the tough form of helping someone recognize they don't fit in with the team identity. But more often, it gives people a way to rally around their peers and help them be better.

Allows for a sense of ownership

When a team has an identity the members on the team feel a sense of ownership in keeping the identity in tack. People want to be involved, want to be included and want to be associated with positive results. A team with identity is more likely to have folks who are willing to step up and own the hard problems because "that what this team does."

Gives you a frame of reference from which to engage

When your team has an identity and things happen that are out of character, you have an easy way to engage and address the problem. You won't be fighting an uphill battle just trying to convince people that a problem exists. People will recognize that "this isn't us" or "this isn't how we do things" or "we don't make these kinds of mistakes". You'll be able to focus on working towards a solution much easier.