Performance management is one of those topics that everyone loves to hate on, but I’ve found that if done right it can produce real value for your team (and everyone will still hate on it.) The key to the most successful performance management process I’ve seen involves the use of flywheels (positive feedback loops, virtuous cycles, etc.) The crux of any performance management system is the evaluation of both the “what” and the “how.”

The Impact Flywheel

The “what” summarizes the work that was completed in the review cycle. It should include a measure of the impact that work had on the company, team, or product. First, this starts as a simple summary of the work completed, but the focus should be on finding the most important items. You can allow the smaller items to fall away. Second, enumerating how beneficial the work was is a difficult, but very important part. There’s no need to list every single accomplishment in the performance review. Finally, grouping the accomplishments into key areas that align with your career rubrics is a crucial element. For instance, leadership, collaboration, or technical mastery. This creates the first flywheel of performance management, a focus on impact.

By focusing on how the work completed made the company better and rewarding individuals you reinforce a culture of company improvement. Improvements can be making the company faster, more valuable, more profitable, larger, whatever is valuable to your team. Every time you reward someone for making the company better you encourage the team to look for more ways to do it again. As an example: say an engineer on the team created a new feature now used by 90% of new customers. We should congratulate them for that work by noting it in their performance review and reward them appropriately.

The Growth Flywheel

Similarly, the “how” of performance management is also a critical component. “How” looks at the behaviors demonstrated by the individual in accomplishing the work. However, you still only need to hit the highlights. Don’t document every single behavior that was demonstrated in the performance review period. Highlighting those behaviors demonstrating next-level performance will keep the focus on the most impactful work. Note: measuring these is considerably more tricky as the impact from this work is often subjective. Capturing the clearest demonstrations of behaviors your company values will create the second flywheel.

This flywheel of performance management creates a positive feedback loop of individual growth. Individual growth that is rewarded (say with a compensation increase, a promotion, or why not both) encourages even more next-level growth. For example, you notice a more junior team member is starting to show leadership across the team. You should encourage this by recognizing and rewarding that behavior. This encourages them to take on more leadership in the future.

The Partnership Flywheel

The final flywheel is less about the process of documenting the performance. It’s about how the individual and their manager partner in making sure the performance review is representative of their work. I’ve found that doing performance reviews in a collaborative (the manager and the individual working together) and progressive (writing down the accomplishments and behaviors throughout the review period) manner makes the work required at the end of each cycle considerably less onerous. It also drives good conversations about performance and growth opportunities throughout the review cycle. By creating a partnership between managers and individuals in this way you can create an organization that values performance growth.

This is the third flywheel of performance management. Individuals see growth and are rewarded for it. Managers help individuals grow and are rewarded for it. The company, product, or team improves and morale improves. And the cycle repeats as the company and individuals grow together.

I have 17 posts in draft form for this blog right now. This post would be number 18, however, the purpose of this post is to clear out the cobwebs. I could just post a simple, “whoops, I’m sorry,” post and say I’ll do better. That would not be starting again. That would just be apologizing for the long pause between posts. That post would not provide any positive feedback on starting again. It also would not be of any value to the people reading this.

I needed to start writing again. A post on the theme for this blog. “Getting started” is a perfect post for that!

The energy involved to start is always more than the energy involved to maintain momentum. This is one of those fun places where you can use physics to explain human behavior. In the physical world, we have to provide all of the energy to accelerate an object to a particular speed. Once we’ve attained speed we only need to provide enough energy to overcome the drag (friction, air resistance, etc.). I often default to inaction due to procrastination, feeling too busy, or a number of other excuses. Here are four reasons to get started.

Starting builds momentum.

There’s documentation in Cognitive Behavioral Therapy that dedicating five minutes to start will help with procrastination. Starting helps determine if this is a thing worth doing and gives a gentle nudge to push through to completion.

I don’t often stop at the five-minute mark. Telling myself that I can stop after five minutes gives me the freedom to start. Even when I feel I may not be able to dedicate the full time needed to complete.

Starting determines what to do.

By tackling the first phase of a task, the remaining steps are more clear and the remaining work is estimable. It will also help you size the work and determine the return on investment.

The first step I take on a major project is often to map out the phases I can see. Planning the work can often expose information I need, people I need to consult, meetings I need to schedule with busy people, or something else I can do quickly to continue to build the momentum on this project.

Starting is getting done.

Recently coming back from the Thanksgiving break I looked at my to-do list and I realized that a number of the items were simple emails, meetings, or other simple tasks. These items should never have sat on my to-do list as long as they had (embarrassingly long.) I used the “get things done” (GTD) method and completed a half-dozen items before lunch.

Starting starts getting better.

We use the phrase “get started and then get better” regularly on our engineering teams. It is useful to get something that provides value to a customer first and then we will take the time to refine the application to be of even more value to customers. If you never start, you never have anything to improve. There’s a lot of power in being able to look at something and decide that there’s a simple way to improve it.

That’s it.

Not a monumental post, but I’m back to posting again and that has value. Maybe not for you, but it has value for me. It’s good to be back.

Speaking at SXSW is always an honor and a privilege. This year, I got the opportunity to speak at a co-branded event between SXSW & General Assembly, on “Overcoming Impostor Syndrome.” Impostor Syndrome is often encountered purely internal feelings of inadequacy in high performers. There are a number of great resources out there on Impostor Syndrome, that I won’t even try to duplicate, but this post is an anchor providing my slides and resources for those researching Impostor Syndrome.

Impostor Syndrome Takeaways

1. You’ve got to name and claim the Impostor Syndrome feelings you’re having. By knowing what you’re dealing with, you can begin to explore the way out.
2. Document your successes and return to them when you feel vulnerable. This list of success will help you remember the value you provide.
3. Bodies in motion tend to stay in motion. Create a virtuous cycle of successes, instead of a downward spiral of fear and feelings of inadequacy.
4. Use the GROW model to get moving and documenting your progress. Mapping out your goal, realities, options and the way forward will help you figure out the next first step to getting unstuck.
5. Reference your personal board of directors to gather great advice. Collecting some mentors who’ll listen to your fears and speak truth in love to you.

My Impostor Story

Because it’s not covered well in the slides, I’m taking a moment and being vulnerable that I’ve experienced Impostor Syndrome many times.

• Driving home in 2007 with a newborn, feeling like I couldn’t possibly be qualified to remove him from the safety of the hospital.
• Moving into engineering management in 2010 and suddenly being thrust into managing people who were my peers the day before. I was immediately terrified that I wasn’t the right person to lead them forward.
• Moving my family to NYC in 2011 to start the Bazaarvoice NYC office from scratch with no connections. Feeling like I couldn’t be the right person to start this team.
• Even speaking at SXSW on Impostor Syndrome itself I felt wholly unqualified.

Resources

http://startupbros.com/21-ways-overcome-impostor-syndrome/

http://nymag.com/scienceofus/2015/10/new-research-on-the-impostor-cycle.htmlhttps://www.mindtools.com/pages/article/newLDR_89.htm

http://elyseholladay.github.io/tigers/

Learning baseball is certainly about the fundamentals but it’s also about knowing the rules. You can certainly have fun in the backyard playing catch and practicing your curveball. However, when it comes time to head down to the sandlot you need to understand how the game is played. The same is true for business sectors and technology.

Baseball rules infographic

You have to know, or learn, the rules for the space you’re in to avoid making big mistakes. If you’re platform as a service company, you need to know how’ll you be measured. If you’re an enterprise software company, understanding what your customers expect will be crucial in designing the right team and technology to grow. A lot of my career has been in the Software as a Service (SaaS) space, discovering the rules we have to live by.

Read More

Remote teams work from home, why shouldn’t Jedi?

Having built a remote team of software engineers in New York City a few years ago, there were several lessons learned about how to build a team that sits apart from the rest of the team and how to make them successful. A lot of companies have trepidation about starting a remote team outside of your headquarters, as they should. There are some serious pitfalls, but there are some nice benefits as well, one of which being it gives you a second base to interview and hire candidates into. There are several great articles on the pros and cons, this post focuses on how to do it well.

Here are four tips to make a remote team successful:

1. Give them a clear project to own, soup to nuts. The less they need the other office the better in this regard. Best would be to build on top of an existing, refined and documented API. This minimizes communication delays and back and forth between headquarters and the remote team. It also helps the team at HQ get used to a remote team. (Side note: Keeping them in timezones helps communication as well.)
2. Inject leadership from HQ. Sending a cultural & technical leader with depth of knowledge of the stack, team, and processes will help to keep them anchored to the team back home. This ties the culture and helps to make sure you hire to the same bar and that remote team members will get along with team members back at home.
3. Get your leaders early. Give a lot of leash to hire a great group of early engineers, and sprinkle in a handful of great consultants if you need to get the project flowing quickly. Having some key wins in the first few quarters is a key to the remote team feeling like they’re a part of a bigger picture. It also gives you enough people on the remote team that you can begin to formalize your team’s culture a bit more.
4. Hire local leadership. Backfill the cultural leader and start building a second team. Just as a team of one is not a team, an office with only one team is not an office (or at least not much of one.) People need the ability to switch teams, move between projects, and spitball on projects with people not on their immediate team. This also gives you a succession plan, flexibility for your leaders as the remote team continues to grow, and growth opportunities for leaders at your remote office.

With any successful business, you’re going to have to eventually have to learn how to have product, design, operations, development or other functions distributed into other teams. It’s only a matter of time before you’ll have to have two locations for development, so before you get to the point of needing a second center, get it spun up and firing on all cylinders.

As I’ve been a part of several fast growing Engineering teams I’ve seen a number of approaches to building out a Quality Assurance organization. Sometimes this has gone well, and others it has been less than effective, which will be the focus of this post. I talked about these in an Ignite style presentation today at DevOps Days Austin, but thought these would be good to share here as well.

The first anti-pattern is hiring a “pile of testers.” While manual testers have their place, and can be a useful at times, only having testers will not dramatically help you produce better quality software. The thought process goes that this is outsourcing work that otherwise your developers would be doing, which is in itself a good thing. However, simply having testers produces typically produces two things: test plans & manual tests. The bad news here is that this means that each release you want to ship the manual regression suite will grow, as will the cost of testing/number of testers required will increase. Also, my experience was that the detail oriented nature of testers produces a lot of miniscule bugs, minor UI issues, and not the more systemic release issues.

To lower these costs you can fall into the second trap, of outsourcing it to another team and/or another country. While your team overseas can be cheaper on the hourly rate, all of our validation showed that the total cost of ownership on this work amounted to an equivalent Senior Engineer based in the United States. Additionally, if you choose to outsource, they often don’t have the same level of commitment to your project. If you are just expecting a bolt-on team to add quality to your product, you’ll likely find that it doesn’t work.

The final anti-pattern is similar, throwing the process, tools, and responsibility for creating quality over to another team, whether your quality team or your DevOps team. The truth is that you need your entire company, and certainly your entire engineering team committed to quality. Engineers building software and throwing it over the wall to another team is an opportunity for confusion, frustration and lower quality.

I’ll cover some best practices in building out quality at scale in a future post, but this airbnb post provides some thoughts to get started with. I’m not so simple as to believe that you can boil quality down to only one thing, and of course your mileage may vary with these tactics above, but if I had to focus on one and only one thing it would be that every engineer owns every line of code they write.

Building a strong software as a service (SaaS) business you’re focusing on scaling your software, but simultaneously you’re inevitably needing more supporting personnel. You’re hiring account managers, support technicians, quality assurance, sales directors, and more folks to keep the business humming and growing. Each new client often means that more people will be needed to service that account. Of course as you grow you’ll need more of these people, and many other roles as well, but the question becomes does each new account linearly add some number of additional hires to your roadmap? Can you bend that curve and change the ratio of new accounts to new hires?

The great news is that if you’re team is building software then you’ve got everything you need to change that game. Using innovation and software to eliminate, be more efficient, or to fully automate some work will drastically change the calculations on how many new employees you’ll need. But first, you’ve got to get the baseline metrics on where your team’s time is going.

Metrics will rule the world

Knowing where the time is going will give you a true data driven approach to determine how much you can change the equation. If you find that all of your team’s time is in elements that have to be done manually or by a human, then you have to look for another area for improvement. If on the other hand you find large areas of opportunity to automate you’ve got your direction. Having at least one team dedicated to internal tools and process improvements will pay huge dividends over time in at least three areas.

1. Efficiency. Shaving off 10% of the work from a 10 person team is equivalent to giving them an extra hire. It’s not easy, but it’s a huge win that will pay off over the long term. Using the metrics on which type of issues have dominated the most of your team’s time will give you the prime targets to attack.
2. Automation. Creating software that makes some functions of the team’s work completely push button is a huge win. This is more than just a simple efficiency gain, it’s removing a whole slice of work they previously had to do.
3. Elimination. Once you’ve automated a piece of work it becomes much easier to move some of that work to your customers. Shadow work is a phrase commonly used to describe the work pushed to the consumer of a service which previously had been provided as a service. This is clearly the end goal for a lot of efficiency gains, giving your customer the ability to “self-service” their needs.

These things scale. Hiring more people to do these things for your customer don’t. Bend the curve by making the investment in innovation. It’ll pay off.