I’ve had a lot of experience working on teams that are building *Internal Tools* and one challenge opportunity of working on such teams is that your “Customer” works at your company.
They have your email and Slack. They may even have access to your repos. They can DM not only you but everyone on the team. They can reach out directly to your Manager.
That level of access changes things. Ever have your Customer directly contribute to your performance review? It’s a different world.
I want to share some of what I’ve learned about working on such teams. Before we get started, you need to know a little more about what we do at Ellevation.
Ellevation sells software to school districts that helps them manage their English Language Learner programs. To do that, we pull a ton of data from those school districts. That data comes in from a variety of Student Information Systems, 3rd party assessment providers, various APIs, CSV files, etc. One of my teams is Ellevation’s “Data Ingestion” Team. They are responsible for the internal tooling that imports all that data into our system. The Data Ingestion team supports a small but mighty team of “Data Integration Specialists”, who use our tools to work with all this data.
Ensure Your Cache Doesn’t Go Stale
When I started with Ellevation the Data Ingestion team had been working on a green field project to replace all of our internal ETL tooling with a new platform. They had been working on it for about two years. The goal was to shift from our monolithic architecture to a more modern cloud-based architecture leveraging AWS (Batch, Lambda, etc.) - (almost) all the buzzwords!
Here’s the catch; for those two years, the team did not involve the Data Integration Specialists. This was in part because some of the team had transitioned from being Data Integration Specialists to engineering so there was a feeling that “the team knew what was needed” – which was true, at that moment.
At the start, some distance between the development team and their customer is expected. It’s unlikely your customer cares how you structure your GitHub, what your Terraform looks like, or how your team handles CI/CD. However, once you start building (and releasing!) features I guarantee your customer has information and ideas you need to be successful.
Now it had been two years and the development team had stayed in that “we know what is needed” mode. The problem is, the team’s knowledge of their customer became stale. Their customer had been reorganized, gotten new leadership, and were pushing in new directions. Those directions included utilizing other technology that did what the new tooling did - duplicating work that had been done. Now Ellevation had two teams doing the same thing.
The other problem was trust. There was a belief in the Data Integration Specialist space that the new tool would never be delivered. Demos aside, the only time they attempted to use the new tool was a failure. The tool didn’t meet the needs of the newer Data Integration Specialists.
This is a surprisingly common pattern with Internal Tools. The teams using the tools have demands on their time, just like any other customer. They want something that will make their lives easier. If a tool makes their jobs harder they will do what any of us would do - avoid using that tool. A “terrible tool” that is well known will be preferred to a new tool that is unknown.
What do you do to fix this?
Find Early Wins To Build (Early) Trust
We started by catching them up with what work had already been done. We got lucky in that there was an opportunity to leverage parts of the new tool to implement a new API - a quick win. It was a good start, but it didn’t get our customer involved enough. So we did more.
We started involving them in prioritizing what should be done. What features were missing and required? What features missed the mark? We had a lot of very blunt conversations about the state of things. This caused a few shifts in the product. The biggest was a move away from the “only having a command line interface” to, you guessed it, also having a UI. Having our Product Manager really helped here as we were able to define the user personas (notice: plural) that we were now serving - more on the role of Product in a moment.
This rebuilt trust and set us up to run an experiment with dedicated Data Integration Specialists who would use evaluate the new platform in the best way possible: using it. They would work on the system for a few months.
Unlike before, we had daily “office hours” where both teams could get together to ask questions and pair on problems, meetings to prioritize bugs and features, and meetings to review how the meetings were going. We likely had too much communication. However, it’s better to have too much and scale back than to have too little and end up where we were before.
The credit for organizing all of this goes to our Product Manager. They wrangled schedules, facilitated meetings, met with our customer to learn about the problem space, and helped us to look past the requests to the underlying problems.
Value Your Product Function
An internal tools team has the same challenges as any other product team and needs someone to navigate tradeoffs and align everyone, the customer included, on the problems. Just because your customer is on Slack doesn’t mean you don’t have the same problems as other product teams (but it does mean you get feedback faster). Customers will still ask for specific solutions and you need someone to dig beneath that to find their underlying problems. This lets the team can come up with brilliant, creative solutions that may or may not be what was originally requested. That is the product function.
For internal tools, you’ll be very well-served by having an explicit conversation around who is serving that product function, and ensuring that they have the skills and support to do it well. While this could be an engineering leader (or someone from the Customer’s team) it’s pretty rare for either of them to know how to do this role well without support and coaching.
In The End
This is where you’d expect me to say we launched and things worked perfectly. They didn’t.
We missed our launch window and delivered some key functionality late. We’ll continue to work with our customer to build trust, find ways to partner deeply, and learn from our mistakes. Ultimately, I believe that we will deliver tools that our internal teams love.
