Leadership and Mentoring

Over the last ten years I've paid a lot of attention to the successful people in the companies I work at. While my definition of success has changed quite a bit, the common thread that hasn't is that a successful person is someone who enjoys their job, is respected and sought out by their peers, is not afraid to fail, and is given opportunities to take on new challenges.

As I've tried to dissect what makes someone successful I've noticed a trend. Most of the successful people I know have a mentor and have someone that they're mentoring. Upon further review I believe there are several reasons why being a mentor and having a mentor contribute to individual success.

Successful leaders are mentored by others

At it's core being a mentee means you have someone who you can get an outside perspective from. Why is that so important? 

• You have someone who can provide objective insight into the success or failure of something they're not intimately involved in. 
• You have someone that can ask you though questions to help identify your blind spots or personal biases that are getting in your way.
• You can learn from different life experiences.
• You have someone that is able to look at your situation through a different set of biases.
• You can learn from their successes and what has lead to their failures.
• You can talk through ideas, plans, and problems and gain an outside perspective.

Successful leaders mentor others

Being a mentor is not just about having the ability to impart knowledge to another person. It's about being able to ask the right questions, being an outside voice, and being able to break apart problems into smaller more solvable pieces.

I believe there to be a causal relationship between being a mentor and being a successful leader. There are several reasons I think the causality works this way.

• Mentors are able to proactively identify and correct potential problems in their lives by helping someone work through their problems.
• Good mentors can break problems down into smaller more solvable pieces.
• Good mentors ask a lot of questions. They try to reduce ambiguity.
• Being a mentor means being introspective and able to talk about your own failures and successes.

Difference between a programmer, developer, and engineer

Coder, programmer, developer, software engineer and others were among the many different titles I had in my career while writing code. Some were sought after and some were not depending on where I was at in my maturity writing code.

When I first started out I wanted to be called a coder. I worked in IT divisions of small companies where some people in the group were in charge of configuring and maintaining the servers and some were in charge of writing the software that ran on the servers. In those early days  I wanted to distinguish myself from the former group and I put a heavy emphasis on distinguishing my self as a coder or programmer (usually the later). I wanted people to know that I was responsible for the logic of the programs that were running on the system, not responsible for using those programs to manipulate the system.

As I grew in maturity as a programmer I learned that good programming involved refinement and iteration. I started to learn that good programs, ones that were run for years on machines weren't simply written, they developed over time. Developing a system over time required recognizing tried and true patterns and best practices. It required abstractions in order to iterate over the system. Programs weren't simply the logic used to solve a problem. Programs were a set of requirements that grew and changed as the program became more complete.

As I started to master my trade I learned that the best developers were really engineers. People responsible for the design, implementation, and deployment of software. In my mind I started to realize that a great developer was really an engineer. Someone that was able to look at the requirements and design a system that met the need but was also resilient to change. I learned that the one constant in software development was change. Being adaptive to change required a solution to be engineered. You start with an idea, built a system around that idea, and put that system into practice.

As I honed my craft, I started to recognize the different between software programmers, software developers, and software engineers. Some key differences are:

Design

• Programmers think in terms of languages, SDKs, and APIs. They build systems based on the tools they know and are comfortable with. Programmers value creativity and cleverness.
• Developers think in terms of requirements, components, and interactions. They design systems using patterns and best practices that meet the requirements. They're able to evaluate, investigate, and determine if particular platforms, languages, and/or frameworks meet the need of the requirements.  Developers value completeness.
• Engineers are problem solvers. They solve problems regardless of platform, language, or tool. They think about architecture. That is dependencies, single points of failure, scalability, and resiliency change. Engineers value simplicity, flexibility, and adaptability. They recognize that a system is never fully complete.

Development

• Programmers value the most creative or clever code.
• Developers value the most abstract, generalized, and re-usable code.
• Engineers value the simplest code that can be maintained and changed.

Deployment

• Programmers don't typically think about deployment. They throw their code over the fence to operations folks who own and maintain the production systems for them.
• Developers think in terms standardized tools and processes. Developers value the ability to rollback.
• Engineers think in terms of automation, repeatability, and reliability. They think about the surface area of the change, and how to measure success.

Executing Well

Regardless of the industry you're in or the role you have executing well is crucial for you to be successful. It's also, very difficult and takes rigor to do well. He's some tips on how to execute well.

Understand what you're being asked for

This sounds obvious, but it's amazing how often during the course of a day I see a group people walk away from the same conversation with different understandings of the expectations on them and their team. It's important to ask clarifying questions and even more important to repeat back what you're being asked for so that the other person can validate or correct your assumptions. One tip to do this well is to simply restate the action items at the end of a meeting or conversation.

If, when you're asked for something, the person doesn't specify a time don't assume that you can do it whenever you want. Ask what the expectation is for you to deliver and if it's unreasonable, negotiate.

Take Notes

Your memory is not as good as you think it is. The context that seems obvious in the moment isn't going to be obvious 4 hours or 4 days later. The details about your initial approach may not be clear later.

Don't make assumptions

If you're not 100% sure about something clarify it. Making assumptions is always a losing bet. Best case scenario you're assumption was correct and you lost a non-tangible amount of time clarifying your assumption. Worst case scenario your assumption was incorrect and you were going to do the wrong thing or do something that is sub optimal.

Follow Up 

It's important to remember that your stakeholders job isn't to be in your problem space 100% of the time. That's your job. The farther up the management chain you go the more your space is competing for the attention of your stakeholder. You should assume your space is not the highest priority right now for the other person. You should also assume that your space is crucial for their and your teams success.

Even if you haven't started a particular ask or aren't complete, give periodic updates. Don't wait to be asked. This helps those that are relying on you to have confidence that you're thinking about the problem and are going to deliver on the ask. It also empowers others to help you by removing roadblocks, taking other lower priority tasks off your plate, identifying dependencies that you're unaware of, or helping to manage expectations with others.

When you see a problem, do something about it

You should assume that the problem also affects someone else and that the others affected aren't empowered to do something about it. You should also assume that no one else is going to do something about it. Don't leave broken windows unfixed.

Know your stakeholders

Understanding the level of abstraction your stakeholders work at is key to executing well. The people responsible for solving the problem will want to talk about the details and the methods used to deliver. As you communicate up the management chain you should transition what you talk about from the more intricate details to timelines, dependencies, and risks involved in executing.

Building a successful software platform

Building a successful software platform is done by building software with a purpose by solving a problem that people already have. The problem may not be obvious, and it may not even be a problem that people are aware of, but the problem exists. Using Instagram as a case study, I think there are four keys a platforms success.

Intrinsic Value 

Most people aren't professional photographers. They don't have access to the tools professional photographers use nor the time or money to buy the tools and learn them. But they do want professional looking photos. Instagram built a platform that had intrinsic value on it's own by providing people the ability to easily create professional looking photographs.

Simplification

One of the keys that made Instagram successful was that they took something people were already doing and made it easier and better. They removed the need to download photos from a mobile device and then upload them from a desktop or laptop. They simplified the process and allowed users to share exiting photos right from their phones or take a new photo to share.

They also simplified an otherwise complex photo editing process by providing a set of templates that people could apply without having to understand image editing. This enabled a regular person to have professional looking photos without any work.

Interoperability

One thing that Instagram did very well is that it built it's software to work with exiting services like Facebook and Twitter. Services that already had a huge community of users. They didn't try to re-create Twitter or Facebook. Instead, they allowed Twitter and Facebook to get better by making their service interoperable.

Choice

Instagram didn't force people to ONLY use their service. Instead, it allowed people to continue to use their existing social media services and augment a specific workflow to be better if they wanted to. Users don't want to be asked to chose between this OR that. They want to be able to use this AND that. Will your software provide additional choices or limit choices?

Improving the efficiency of your team: cleaning up after yourself

If you're anything like me you're constantly trying to figure out a way to help your team become more efficient. One area that's often overlooked is how much time your team spends repeating the same mistakes or cleaning up after the same mistakes over and over again. I'm not talking about show stopping, bring your site down mistakes. If you're having those often you've got major problems in your underlying infrastructure and you should stop all feature development and get it fixed right away.

No I'm talking about small mistakes that over time compound the amount of time your team is taking to work around a problem or clean up after it. In order to help your team spend more time working on features and less time working on cleaning up after mistakes you should be doing two things.

Retrospectives

I've written before on Sprint Retrospectives before but it's worth mentioning them again as they are the easiest source of improving the efficiency of your team. Sprint retrospectives are a good way to understand what's randomizing your team. They're also a good way to find out why your teams estimates were off (i.e. what wasn't accounted for or what was over accounted for).

The key to the sprint retrospective not to just talk about the problems, but to create action items that will resolve the problems moving forward. After each sprint retrospective you should have an action item list. Each item in the list should have an owner and a due date. This will help ensure that nothing falls through the cracks.

Postmortems 

Postmortems help your team identify and correct problems with your process or places where there is no process where there should be. I wrote a good deep dive into postmortems a while ago, but the key to a postmortem is that you use the facts about an incident to see where your process breaks down and identify clear actionable steps to prevent the breakdown in the future.

Postmortems don't have to be used when something catastrophic happens. You can use them to help identify simple things that prevent your team from being more efficient. For example; you can do a postmortem on your sprint planning if your team wasn't able to accomplish all the work they scoped for the sprint. You can do a postmortem on why a feature wasn't built as expected or why a build broke. You can do a postmortem if your team misses a date. There are many reasons you can do a postmortem that don't have to do with a catastrophic event.

The goal is not to do a postmortem for the sake of doing one. But instead to add value where possible by identifying areas of inefficiency and digging in to find out where the problems are and creating actions to remedy them.

Two questions you need to ask yourself everyday to be successful

There are two questions that I've learned to ask myself (and others) everyday. Two very simple questions that will help you to uncover a lot of bad habits and help you fill any gaps preventing you from accomplishing your goals.

1. What am I doing today, that if I stopped doing, would be beneficial to me or my team?
2. What am I NOT doing today, that if I started doing, would benefit me or my team?

What you need to stop doing

The goal of this first question is to help you look more objectively at yourself, your habits, and your process and find roadblocks that you're putting up yourself. There are many many many things that every one of us does everyday that get in the way of us being more productive. The key is identifying them and either replacing them with something helpful or just stopping the behavior all together.

For example, are you randomizing your team without knowing it? A good example of this is asking a question of your team that causes some of them to stop working on what they're working on to get you the answer. Are you sure getting that answer now is a higher priority than what they were working on? If not, that's something to stop doing.

There are so many examples of things we do every day from the emails we send to the meetings we call that are not helping us or our teams be productive. Rooting out these problem behaviors/activities will help you and your team be more productive.

What you need to start doing

The goal of this second question is to help you identify your blind spots. I can promise you there are several things you're unaware of that happen everyday that, had you been aware of, would have changed something about your work. Your goal should be to help identify these things and incorporate their knowledge into your everyday process.

For example, maybe your team suffers from randomization, always being pulled in a different direction. You need to start saying no to work and work on creating an intake process to help prioritize your current and future work.

Like the former question, asking this question will help you understand your problem space better. The better you understand your problem space, the easier it is to navigate and be successful in it.

Stumped where to start?

The great thing about these questions are that everyone around you has an opinion on them.  Start by asking your boss and your direct reports these questions. I would bet that you'll be surprised at some of the answers you receive.  Beware of those who constantly answer "nothing". They're likely not invested in your growth or the growth of your team.

Are you using your own products?

I'm always surprised when I work on a software team that doesn't use the product they're building. It's a sign that your team isn't invested in the product. More importantly, it's a sign that your team isn't as invested in the customers.

Teams who dogfood their own software make better products. That sounds anecdotal, which it may be, but that's what I've seen in practice. Why is software better when those that make it use it?

Your team is always in the ecosystem

If you aren't immersed in the ecosystem that your app lives in, you won't ever truly understand how your app should work. You won't understand what metaphors are the right ones and which ones will feel foreign or fake. You can be sure your customers will notice if you use an iOS metaphor on an Android phone or a Windows metaphor on a Mac. Until you are immersed in the environment your customers are in you won't really understand your customers as well as you could.

Your team is your customer base

Relying on your own software in your day to day life builds empathy for your customers because you are part of the customer base. You'll find the workflows that need simplifying. You'll understand which features are missing. You'll cringe and curse every crash.... just like your customers do.

Your team feels any added friction

When your team is using your app you discover added friction before your customers do. For instance, if you make a change that's not backwards compatible, your team will find it first because they're already using the app and that feature. Add additional, and unnecessary steps to some workflow, your team more likely to find it than a paying customer.

Long and short, you find the mess in your app before anyone else does. When the app gets to your customers, they're delighted with how intuitive your app feels.