> For the complete documentation index, see [llms.txt](https://stepsize.gitbook.io/stepsize-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stepsize.gitbook.io/stepsize-documentation/team-and-collaborators/talking-to-your-head-of-engineering-about-stepsize.md).

# Talking to your Head of Engineering about Stepsize

**Stepsize works with organisations like yours to unlock unprecedented improvements in velocity, quality and employee retention.**

## **Proving impact with Stepsize**

You understand the transformative power of tracking issues directly in the codebase.

But how can you get buy-in from the person at the top of your engineering department?

Getting the most out of Stepsize requires both the **tool** and a **process**.

In this guide, we'll describe a tried and tested experiment that you can run with your team to prove the impact of Stepsize in **driving behavioural change to maximise the impact your team has on achieving company goals**.

## **Expected results from your experiment**

On average, we expect that over the course of an experiment, engineering teams will...

* [x] **Create 10x issues** 👉 Visibility
* [x] **View 20x issues** 👉 Awareness
* [x] **Resolve 10x issues** 👉 Actionability

## **The experiment**

> *Track one, fix one.*

1. Select a time period for your experiment. This could be 1-2 weeks or a sprint, for example.
2. Get on the same page. Hold a meeting to kick off the experiment.
3. **Track one**. Each engineer documents at least one new issue over the time period.
4. **Fix one**. Collectively agree on an issue to resolve as a team. We suggest holding a short meeting to do this.

{% hint style="info" %}
If you can, record anything you observe which might be relevant to make your case, such as behavioural changes in the way engineers use Jira.
{% endhint %}

## **Reviewing the experiment**

* **Visibility** - How many issues got created? How does this number compare to your normal number when using your standard issue tracker alone?
* **Awareness** - How many issues were viewed? How does this number compare to your normal number when using your standard issue tracker alone?
* **Actionability** - How many issues did you resolve? How easy were they to prioritise (e.g. using the codebase visualisation – *for more information, see our guide*)

![Using the Visualisation tool in Stepsize](https://res.cloudinary.com/drvhrxrne/image/upload/v1671455776/samples/product_guides/visualisation_zoe31i.gif)

What qualitative data do you have? For example:

* What feedback did the engineers have?
* What changes did you observe in the quality of issues?

## **Talking to your Head of Engineering**

You've conducted and recorded your experiment. Before you talk to your Head of Engineering, ask yourself...

1. *What are the company goals your Head of Engineering is invested in?*
2. *How might the experiment enable your team to maximise impact towards these goals?*

## **We can help**

**Stepsize works with organisations like yours to make the most out of your engineering resources and manage tech risk better**

## [**Set up a call with us**](https://meetings.hubspot.com/alex527/tech-debt-management-with-alex-stepsize) 🤙


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://stepsize.gitbook.io/stepsize-documentation/team-and-collaborators/talking-to-your-head-of-engineering-about-stepsize.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.