Big organisations are hard to manage. Everyone knows that. It is even harder to manage if an organisation wants to keep innovating and remain profitable and functional. How do we do that without creating a lot of bureaucratic roadblocks and wrap every single decision in a web of workflows and processes? And what data do we need to know that we are moving in the right direction with the right speed? Can we get this data with the least effort possible?

In this article, I would like to show AUTO1 Technology’s attempt to address these questions.

The problems

With the original approach, we had a few issues on our hands.

Headcount allocation

AUTO1 Technology split to 8 Business Units, each of them has its own set of functions, for example, under the Internal BU, we have DevOps, Design, Core etc. In total, we have 30+ functions and each of them has their roadmap to deliver. And, each team also will need to keep an eye on their technical debt.

Every day in A1 Technology we plan new features, define the specs, test and do tens of releases to Production. Our roadmaps are living documents and change all the time as we need to react to market events or predict customers needs.

We are a Product organisation, meaning that we split our teams into Product-oriented pods, where cross-functional engineers paired with a Product Manager and a QA. Sometimes, depending on the type of feature, they are joined by a Designer. Historically, to keep the roadmaps up to date, PMs needed to maintain headcounts in a Google Sheet.

Consider this scenario - a PM knows that FE engineer John Doe works on a Feature A and their QA Jane Doe works on a Feature B. They update the spreadsheet and then find out that the TL switch Jane to a Feature B 5 mins ago.

Now, multiplying this scenario to 30, we will see that the final allocations were not always actual, softly speaking.

We could resolve it by telling our engineers to log their time somewhere, and they will need to log every hour of their workday. This way we would see them go to another company very shortly. Engineers like to do what they were trained for and not fill up neverending timesheets.

And let’s not forget about the PMs, who were people chasers instead of being a customer/revenue/idea chasers. Finally, they spent too much time on getting these numbers instead of focusing on their daily tasks.

Google spreadsheet UI

Looking at the above issue we can also clearly see another one. To manage all of that we use Google spreadsheet UI and it has its limitations:

• It’s very easy to accidentally remove a value from a cell and don’t even notice it. Which happened a few times...

• There are no backups and it's very hard to restore some of the values there. The history of updates is hidden and it's not always working as we need to.

• The purpose of the spreadsheet is to be... well, a spreadsheet - to calculate something to present some existing data in a table view. This doesn’t work well for our use case. Managing pipelines is much more complex tasks that requires a lot more to it - see the next section.

Workflow process

Google spreadsheet also doesn’t allow to track the feature lifecycle very well and validate if some steps were missed.

NB: The above sentence is not 100% true. But it would require a lot of complex configuration and a lot of maintenance time to implement such functionality there. Which won’t make it a very robust solution.

Our process is quite flexible and depends on the type of the feature and the Business unit but in general consist of some common steps:

1. Requirements gathering

2. Writing the specs

3. Getting signoffs from the SHs

4. Demoing the increment to them

5. etc.

Using just the spreadsheet functionality it’s very easy to miss some of them accidentally or to take some shortcuts intentionally. There is no easy way to validate whether all the important steps were taken.

Lack of automation

Some of our features require designs or mobile app counterpart development. How can we track it more efficiently? In the original approach, we would need to manually duplicate records from the BU’s pipeline to a corresponding Design and Mobile team pipelines. There was no easy way to automate it.

The answer

So, how one would go about managing all these features across the Tech organisation? To help us with that we came up with TechOS, an AUTO1 Technology Operating System, the tool that would help us with all of that.

TechOS designed to tackle the issues above. It allowed us to:

• Get up-to-date data on our Engineers allocations

• Free up our PMs from a burden of chasing people

• Introduce some insurance in a form of backups and changelogs

• Add a feature lifecycle validation to all the items on the roadmap

• Automate some of the tasks and jobs

• Get this data - after all, we are a data-driven company - that we need to back-up our decisions, like:

What are the late features? Which of our MVPs were too long and too costly? Do we maintain a 1 to 3 ratio of QAs and Devs that we claim we do?

How it works

PMs create tasks in the UI that we built in house.

All our engineers receive a notification that reminds them to submit an update for today. This action only takes up to 30 seconds and it can be done from a mobile phone. We only ask them to choose a task that they were working today from the list of tasks. They choose a task as Primary or Secondary (non-mandatory) and hit submit. We don’t ask about comments or any notes. We don’t ask about the exact time they spent on it. No. Just two dropdowns, one of them is not required at all.

We don’t use these updates to measure employees performance. They are only used to know the allocations for the task:

On the screenshot above we see a pipeline view with some key data about the Roadmap item and the number of people who are working on these tasks. The decimal numbers are there because we show a weekly average.

So, how does it help us?

The best thing about TechOS is its data and how it can be used. With people linked to tasks, we can have very powerful reports that can give us insights into how we work and what needs to change.

Here are a few examples.

Tech allocation

We have a textual or a visual representation of how our PMs, Devs and QA are allocated on the task

:

Days invested

This report shows us how much effort is spent in different areas of the task: in planning, writing specs, development etc.

The above two reports combined are a powerful tool and enable us to be agile and adapt rapidly.

A few more benefits

• No more accidental deletes of data in cells

• Permissions that allow different access to different areas of the roadmap

• A lot of flexibility configuring tasks workflows. A bit more on that below:

On the diagram above you can see an example of how we can configure a life cycle of a task. Something that wasn’t available to us before.

• Automation - now we can automatically create tasks in corresponding pipelines if a checkbox was ticked. I.e. if someone creates a feature that requires the Design team’s effort, they can just choose the “Design” checkbox and a corresponding task will be created in the Design team pipeline.

• An aggregated view that allows us to show the roadmap items the way we like it: group them by goals, by ICE or any other way we like.