General purpose

introduction a core concept to echoes' approach is that it help you connects engineering efforts to their purpose, the why you can customize the why through the configuration of dimensions docid\ uxus3v0gsqwygpp3v5h14 and initiatives docid\ auolbydwwbaqfuxrazrpx while your objectives typically offer a good starting point, echoes is perfectly usable outside of any particular goal setting framework efforts will be categorized along the taxonomy you define they must therefore be understandable to most, and must encompass all engineering efforts outside of these general principles, how you want to define them is entirely up to you default intent dimension the default set has been chosen to be applicable to most engineering organizations, but naturally are specific to none for example customer value may capture all the work directly visible to your users, either through delivering features, bug fixes, or improvements risk mitigation may capture the obvious such as legal compliance, or fixing security issues, as well as the commonly invisible work of updating obsolete dependencies maintenance may capture the work we put into automation, refactoring, testing, and all of these things that make software development sustainable note that the default odes are deliberately phrased as positives they are valuable to any company creating in house software, and none of them can safely be ignored many of our customers are happily using this default set without further customization! you also don't have to decide on day 1 you can start using echoes to get a feel for its reports, and adjust your use of it over time outcomes are not set in stone and are meant to evolve with your organization example configurations there are many different ways to customize dimensions, and no good or bad answer it's all a matter of capturing what is valuable to your organization in this section, we only give a couple of hints inspired by real world usage of our customers mapping company goals company goals are a natural fit to use as they already are a universal language for the company one key thing to keep in mind here is that while most engineering efforts contribute to company goals, not all of engineering work does it is recommended when mapping your goals into echoes to preserve a space for things unrelated to an objective see our more complete guide on objective and key results docid 0q5cdtut2z71okff8 nr8 expanding on the default set many customers start with the default set, and get progressively more specific about the things they intend to track for example, we might see "acquisition" under "customer value" as to capture changes specifically intended at acquiring new customers capturing multiple personas or businesses it is common for companies to serve multiple types of customers (e g , a marketplace serving both buyers and sellers), to manage multiple businesses (e g , ride sharing and food delivery), or to offer multiple products (e g , a source control manager and a knowledge base) this a very natural mapping which helps align engineering investments to business expectations on those different verticals starting from scratch we have seen customers interested to identify the share of work that was planned versus the work that wasn't planned (e g , arising for customer calls or sales requests) we have also seen customers interested to identify the work originating from internal feedback (e g , qa or product reviews) versus external users feedback again, there is no good or bad answers there, it's all about what makes sense for your particular context need help? we've worked with hundreds of organizations and have seen a variety of different patterns please reach out ( support\@echoeshq com ) , we'd love to help!