In my previous article, I discussed Feature Factories and why the most highly productive software teams may not, after all, help your bottom line. This piece is dedicated to unpacking the way to alleviate the problems in Feature factories. The subject is Objective Targets. I recommend them for all teams as part of their toolkit for better outcomes.
Feature Factories and Hobby Projects
In a nutshell, Feature Factories are software teams that value new features over measurable improvements. In other words, output is more important for them than outcomes. This preference is quite normal for humans but often it’s driven by management that gives the team requirements in the form of tasks to complete and features to build. What is lacking, is opening up the big picture and providing overall goals.
However, arguably even worse is an overall lack of outside guidance. After all, Feature Factories at least know what they should be doing. In such absence of direction you can face a phenomenon called Hobby Projects. In practice, Hobby Projects are technical improvements or features that simply don’t have a positive return on investment. They are merely important for some team members personally. Valuable features can also turn into Hobby Projects when they are polished excessively over over-engineered.
What would an adequate target look like
Objective Target means a measurable goal that can be defined more or less universally and is – surprise, surprise – objective in nature. Universality in this case means that the targets can be understood by all the team members and hopefully by other stakeholders as well. Objectivity follows from universality: anyone can use the same tools to find out whether the target has been met or not. Furthermore, objective means that measuring the target can be done, in theory, by anybody and that the value is the same for every snapshot as long as the underlying phenomenon is in the same state. In other words, Objective Targets are the opposite of personal opinions.
One good test for Objective Targets is the following question: could the team diverge from earlier agreements about features and their details if it still was able to provide positive results in light of the targets. In other words, are the targets almost always more important than some specific features. This is also a test to realize if the targets are just a disguise for a feature driven team.
However, don’t get too hung up on the definitions above. Starting with something is better than nothing. This recommendation stems from my personal observations and discussions with individuals from various kinds of teams: most teams don’t have objective targets whatsoever. Thus, having some targets is already an improvement. Furthermore, teams and individuals tend to get better at setting goals over time as long as they have deliberate practice.
If you have had any engagement with the discussion about business management during the past decades, you most likely are already getting goosebumps: numerically measuring performance is often misused and, even with good intentions, is extremely problematic!
The issues stem from the simple fact that “you get what you measure.” To tackle this issue, the Objective Targets I’m referring to should not be followed too religiously. Even knowing the targets is often enough to drive the team in the right direction, and trying to enforce them too strictly might do more harm than good. If the targets turn out to be unproductive, they should be changed instead of pursuing them mindlessly. Furthermore, if the targets have loopholes, that is completely acceptable; as long as no external encouragement is driving the team to take the shortcut.
Good targets are neither trivial nor perfect
Let’s consider targets on a scale from trivial to too difficult. Trivial targets would mean goals that are too easy to reach and don’t give the team sufficient direction. Trivial targets can also be mere tasks or projects. What is their indication is even more revealing: trivial targets mean that the team is content with just producing output and doesn’t have any ambitions about the outcomes. Furthermore, the team might not believe in its ability to improve in any way. It just is and does whatever. In conclusion, if the team is given the task to come up with goals by itself and the goals seem trivial, most likely there is an underlying issue and further discussions should take place about the purpose of the team and about the team’s ability to deliver.
Some self-restriction should be practiced in the target-setting, though. Otherwise, the targets will be too ambitious and too challenging to achieve. Mathematically speaking, this is self-evident: most phenomena have an area below optimal and above optimal. However, my point here is to guide a team just beginning their journey in target setting: don’t feel that you need to target your organization's absolute bottom line value with your goal. It’s enough if the objective target gives you guidance and direction. Otherwise, the targets may be significantly too laborious to measure due to excessive noise or lack of data.
To give a concrete example, improving overall customer satisfaction is a goal that’s often too ambitious. The issue is that there are always a wide array of factors affecting customer satisfaction adding noise in measurements. Thus, even with well implemented A/B tests the result is most likely non-conclusive since any positive development is smaller than the normal variation. A better target could be improving customer evaluations in a micro-feedback after a specific interaction. Another example would be for all teams to target improvements in company revenue. For instance, facilitating customer feedback submission or improving delivery time estimates most likely have value in the long term but don’t improve company revenue in a way that could be clearly demonstrated. For them the target should be simpler: amount of customers that have given feedback and amount of times delivery was 20% slower than estimated, for example.
Setting targets is part skill part imagination
First step in setting Objective Targets is trying to figure out the overall role of the team: is it an end-to-end product team, a component team, or a support team. This should guide the scope of your target. For product teams the team can target the overall performance of the product, but support teams need to restrict their targets to the area where they actually have an impact. For example, a team responsible for a whole ecommerce site should definitely target the total revenue of the site. The team responsible for only customer support can’t have such bold targets but should strive for, e.g., shorter resolution times for customer problems.
One way to set targets is to consider the service under construction as a pipeline. The pipeline has steps that occur one by one (e.g., product search, add-to-cart, start checkout, add credit card, submit order, company revenue, company profit). The team should consider what steps in the pipeline it’s responsible for and consider taking the success rates in those steps as targets. An alternative approach is to consider the common failure modes in the key steps and target reducing their frequency. For example, a team working with product search could be measuring add-to-carts per session to indicate product findability and also targeting lower rates of unsuccessful searches where nothing was added to cart.
Setting targets is not trivial in the sense that there would be obvious targets for every team. Sometimes you need to use your imagination to come up with your own options. An ideation workshop is not out of the question: gather all possible information together from company strategy to customer feedback and use it as inspiration for throwing around suggestions on what you could target. One good approach is to summarize the past work and plans for the future and try to deduce the common denominator. Often there is some underlying target behind the work even if the team currently was a Feature Factory. When the target is found that can be the north star in the future instead of the features themselves.
Ask yourself what does your team celebrate
If you are still considering if your team does have Objective Targets, or if the targets are having a positive impact, you can consider the following. In your team, when kudos and appreciation are given to individuals, is the main subject output or outcome. A good rule of thumb is that Feature Factories tend to celebrate output and effort, and teams with Objective Targets celebrate outcomes more. My experience is that the more data collection and target metrics are discussed in the team, the more outcomes tend to be mentioned when past work is discussed. The other way around, the prouder and happier the team is about getting a new feature finally done and dealt with, the less likely it is that there is discussion about if the original targets were met.
Celebration can also be a gateway out of the Feature Factory mentality and into Objective Targets. Just try to find some outcome that you can be proud of and mention it in a positive light for the team. Getting more of this outcome could be one of your Objective Targets. Furthermore, directing the team’s focus on the non-direct results of their work can encourage them to consider these results when the next feature is implemented.
