How we organized the execution of an engineering team goal

Goals are important. Not just for the individual, but also for the team, the department and the entire organization. On my team, we’ve been setting ourselves quarterly goals. As a part of that process, we’ve been setting core goals as well as stretch goals to ensure that the team’s effort is focused and remains on track. At the end of a quarter, we hold retrospectives to assess our performance as a team and check-in to what extent we’ve met the goals we set for ourselves.

More often than not, our goals are business oriented – we aim to take on projects and undertakings that are central to the product and also aim to bring in a large benefit to a broad set of our users. While some of the goals correspond to large feature releases and the creation of new workflows, other goals revolve around improvements to the core infrastructure of our product as well as goals that enable us as a team to get better.

One such goal that we set recently was to improve the overall performance of the product. Instead of limiting the goal to some specific improvements in the code, we took a broader view and looked to include performance as a first-class metric in all aspects of development and release. In the end, we also wanted the goal to directly influence end-users and as such considered the goal’s purview as being anything that got the user from where they were to where they wanted to be much faster.

Since this was a pretty broad goal, it wasn’t immediately obvious how we would proceed in executing on this goal. To tackle this problem, I took a two-pronged approach that divided this goal into two large sub-goals:

  1. Improve product performance
  2. Improve our ability to measure product performance
The two sub-goals for the overall goal.
The two sub-goals for the overall goal.
The sub-goal on improving our performance was pretty straight-forward (it’s kind of the overall goal itself!). As a part of this I wanted to identify the highest priority – lowest hanging fruits so that we got the greatest bang for our buck. I considered the second sub-goal of improving our ability to measure performance equally important. Our product had decent but not great logging. Improving and enabling better logging would not only help us identify problematic areas but also would help us quantify our investment into improvements in end-user performance. This data gathering would empower us to make better decisions in the future.

 

Improving product performance

 
We want to improve performance, but at the same time we want to be very impactful with our investment and resources and target areas of greatest return. To tackle this sub-goal, I leveraged the following execution principles:

Screen Shot 2015-08-31 at 7.12.57 AM
Improving product performance

 

 Execution principle #1 :  User Interviews and surveys
As a first step, we want to target parts of the product where our users feel is the greatest need for us to improve. We want to conduct user interviews as well as surveys to identify common points of frustration and make sure that these get tackled first. Any feedback here will go into the high-priority list of things to tackle.

 

Execution principle #2: Technical debt and refactoring
User interviews or surveys do not capture all the opportunities on the opportunity spectrum. Particularly within an analytic platform, the end user does not necessarily have all the context to know whether a specific action is as fast as it can be. In such cases we rely on our engineering knowledge and knowledge of technical debt to identify and execute on the opportunities that we know ( but the end user might not) would still make users get to where they want to be faster.

 

Execution principle #3: Feature development / UX enhancements
Not all of the work to improve performance will be related to making queries return faster or making existing features work faster. We want to build features or enhancements that will enable users to reach their end goal faster. Some quick examples here include : making a common 2-step process into a 1-step process, better preserving user decisions to avoid repeat work and automatically doing the work that the user has to do each time.

 

Execution principle #4: Prioritized resource allocation in each sprint
Once the target areas are enlisted based on each execution principle, we create a prioritized backlog of tasks that we then plan to work through our sprints by having a specific well defined story point allocation for this goal within each sprint. Having continuous resource allocation ensures that we always pick off the top unfinished items under this performance epic and this results in continuous progress.

 

Improving our ability to measure product performance

 
As a part of this sub-goal we want to not only increase the coverage of performance logging within the product, but also increase usage logging throughout features. For the logging that we already had in the product, we want to organize them better. To tackle this sub-goal, I leveraged the following execution principles:

Screen Shot 2015-08-31 at 7.10.12 AM
Improving our ability to measure performance

 

Execution principle #1: One-place to access all logging information
As mentioned above, we did have logging in some key parts of the product, but information on the logging statements was scattered in multiple places and on different dashboards. This made querying for any usage statistics and combining such statistics a real pain. As a first step, we create a central place to document all of our logs and compile a list of the parts of the product in which we do want to have logging.

 

Execution principle #2: Stay ahead of the curve
Once the list above mentioned is created, we prioritize addition of logs and the organization of logs to those features/ areas in which we anticipate upcoming performance work as a part of sub-goal #1. That way, we stay ahead of the curve and following implementation of performance improvements, we would be able to benchmark performance and also quantify how our investment had paid off.

 

Execution principle #3: Prioritized resource allocation in each sprint
Similar to the execution principle in the previous sub-goal, we maintain a prioritized resource allocation within each sprint to accomplish this sub-goal. Within each sprint, we plan to have a ‘Performance logging story’ that captures the prioritized set of logging we want to enable.

 

Execution principle #4: 80-20
At times in which it takes too much effort to get the exact time (up to to the 3rd or the 4th decimal point), we plan to take an 80-20 approach and make sure that the core bottlenecks in terms of time are being captured within the performance logging. This is specifically important for us as we would have to set up complicated ways to get to the exact time which may not be worth the effort involved.

 


Having the team goal structured into specific sub-goals and having specific principles for executing each of the sub-goals gives us a clear path ahead in attaining this goal and giving the best value to our users by making the best use of our time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s