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.