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. 

What's the measure of success for your project?

When I first started in the software industry I believed that the measure of success for any project was whether or not it shipped anywhere. One of the biggest surprises to me transitioning into the industry was how much software never actually ships. It baffled my mind (and still does) that people could work for weeks, months, or even years on software that would never ship.

What I've learned though in my career is that shipped software is not the right measure of success. USED software is the correct measure of success. No, not re-sold software. I mean software that is being used in the real world by real people/processes to solve real world problems.

Simply shipping software is not enough. Why? Because shipping software that is not used is the same as not shipping the software in the first place. Anecdotally, the top three reasons for software not shipping in my experience have been:

1. The team never reaching feature complete.

2. The project running out of money.

3. The requirements changing so fundamentally that it made sense to just build something else.

#1 and #2 are closely correlated in that #1 eventually leads to #2. All 3 of those situations are symptoms of having a broken process. So how do you fix your process?

Get a product owner

All good (i.e. used) software has a product owner. Someone who is responsible for making sure that the software being built is solving an actual problem and has people who need the problem solved. A good product owner doesn't search for a customer for the software. Instead a good product owner builds software that has people who already need it and figures out how to get it in front of them.

Focus on building individual features rather than a breadth of features 

All too often in the software industry features get built because of some gut feeling of some higher up in the organization. Don't build software this way, it's the easiest way not to have real users. Instead focus on a small feature set (one feature if at all possible) and build it, ship it, and iterate on it.  

Once you've got people using a feature you'll know the correct next feature to build because your customers will ask you for it. The key is, your existing customers. The ones that rely on your software to accomplish some task, will ask you to build something that they need/want. 

Release early, and often

I've talked about this many times but it bears repeating. The only way to build the correct thing is to get feedback on what's being built as soon as possible. The only way to do that is get something in your customers hands as soon as possible, gather feedback, and pivot in response to customers needs. The only real way to do that is to release early and often.

Getting To The Next Level

Over the several years I've spent a lot of time mentoring, managing, and leading teams. For most of my career I was unclear what it meant to get to the next level. I thought that as long as I did a good job I would be recognized for my accomplishments in the form of career advancement.

While my career has advanced well, I missed several opportunities to move up simply because I was unaware of what it took to get to the next level. So here are some helpful tips that you can use to advance your career.

Make it known you want to be there

This sounds obvious, but you'd be surprised at how many people never let their bosses know they're looking to move up the career ladder. In the fast paced world we live in, you're not going to get something unless you ask for it. Taking this step is pretty simple. It just requires the courage to say you want it.

Identify Your Gaps

This is more difficult. Not because it's hard to figure out where we need to grow, but because it's hard to hear that we do need to grow. Even the most self-aware people I know can tend to gloss over the areas they need to grow in. When you sit down with your manager to let them know you want to get to the next level ask them these two questions:

What am I doing now that I need to stop doing?
What am I not doing now that I need to start doing?

Take the Opportunities presented to you

Getting to the next level is not just about skill. It's also about taking advantage of the opportunities presented to you and applying your skill, or learning new skills. The latter is more important because most likely, you need to learn a lot in order to start functioning at the next level. Every opportunity you take gives you a chance to both learn new skills and hone the skills you already have.

Look for opportunities that will stretch you in an area you're not comfortable with.

Be a Mentor

The best way to learn something is to try to teach it. You'll learn where the gaps are in your knowledge or skill set very quickly. A great way to do this is to start mentoring others. You'll be asked lots of questions you have no idea how to answer. But you then have an opportunity to get to the right answer and learn a new skill or some new knowledge along the way.

Get a Mentor

Having a mentor who is at or above the level you're trying to achieve is important. Having already achieved the thing you're trying to achieve makes them a good resource for you. Ask them that their hurdles were to getting to that level. Ask them what areas you should focus on and how to practice working at that level. Talk through situations and opportunities you currently have and see how they would respond or lead.

Most importantly listen. Being mentored isn't about showing the mentor how much you already know. It's about being humble enough to be teachable.