Ingrid is a young company with growing pains. As of time of writing we are around 30 people in our engineering department. We have a lot of product to build and therefore have to be smart with our time. But what does smart actually mean in this context?
You have to think smart. You have to observe the environment and your work and notice the recurring patterns that steal your time. You want to automate low leverage tasks in order to free up time to work on high leverage tasks.
My personal motto is the following: If you have to do something manually more than three times try to automate it.
Building product is a high leverage task. Looking up things in the logs or in a database is a low leverage task.
Many small things add uppermalink
Context switching is a real productivity killer. Every developer knows what happens when you are interrupted even just for a few seconds for a short question while you are in a deep work mode. Company growth means more customers. More customers mean more questions to answer. Luckily our Customer Success team was growing almost on par with our customer base, but most of members of the team don't have to knowledge to answer deep technical questions. The workload for our developers was getting heavy. A lot of requests coming from customer success team were trivial, but often required spending time and energy to look things in the database or logs.
Enter team SWATpermalink
At Ingrid we have gone through many team constellations in the past and only recently landed on something that we believe in - Product Teams. However, if every developer works in the product team who will help our Customer Success team answer all the hard questions?
Enter Team SWAT. This is a virtual rotating team where one member of the product team joins it for the duration of the sprint. The SWAT developers job is to assist our CS team and fix urgent bugs that are uncovered.
Being a member of the SWAT team is exhausting as there is usually a lot going on. Some developers dread it while some are enjoying it because of the versatility of work it brings with it.
When observing the SWAT team's work we noticed that developers were still doing a lot of things manually like searching through logs or doing ad-hoc manual SQL or BigQuery queries. It wasn't the optimal use of their time. These things should be easy and fast to do!
That's when we decided to try and solve this by building an internal helper tool.
You have to make time to save timepermalink
Said and done. We assembled a small team of people who wanted to solve this and said that we are going to treat this as a small time-boxed experiment. Free hands and free choice of technology. What's not to like?
Small internal projects like these are a perfect and safe way to experiment with new technologies, because they are often not mission critical. For this project we chose Sapper (now SvelteKit), mostly because I am a fan of Svelte and the team members were more of backend developers with limited knowledge of the modern frontend stack.
A couple of weeks later we had built a simple web app that allow us to look things up without using a REPL or SQL command line.
There were no project requirements, only our own ideas, and there were no direct stakeholders. We wanted to solve our own problem because we were tired of doing repetitive tasks manually and we also wanted to empower our Customer Success team to reduce the number of questions from them.
We were not sure if this was even a good idea. Will people use this tool? Looking back it was a great idea! Today, almost all of the engineering and Customer Success team use this app daily and it has become an essential tool in our toolbox.
This was just one example of one internal tool we have built at Ingrid and I am sure we will build many more. Hacking on internal tools is a great and safe way to learn new things. Below are my thoughts of how I view them.
Hack months instead of hack dayspermalink
Internal side projects don't have to take the whole day. Neither do you have to do them continuouly. Take some time when you have some slack time, need a break and want to do something else. You can always find some slack time when things are less hectic.
Because we are in the e-commerce space Black Friday is the biggest day of the year for us. We start our preparations already in September and things ramp up from there. It's a tough, busy, but exciting time. After Black Week things usually slow down a bit. Times like that are perfect opportunity to unwind and build something fun on the side. Something that you believe in.
Creating an internal tool is a perfect way to learn something new. Want to try out this new framework that you found? Go for it! Want to write it in a new language that you are curious about? Why not!
Want to build something, but don't know what? Talk to people outside your department. Observe things in daily work.
One easy way that is almost always appreciated by people is some kind of visualization app. Connect different systems together. Massage the data and make it easy to present and understand. Maybe a dashboard?
Below is a screenshot of such app. At Ingrid with work with e-commerce deliveries and our work is not always visible. I spent a couple of days to create a visualisation dashboard that let us watch deliveries in near realtime.
The app itself is ridiculously simple. The backend API server is one Golang file that taps into our existing Pubsub flow and displays the data we already have flowing in our systems in a web app built with RxJS and Svelte. It's also incredibly soothing to watch, especially during Black Week.
Internal apps like these are not mission critical. They are helpers. Therefore it's totally fine to try some new technology if you feel like it. You don't have to write tests either if you don't want too, because it's a hack, an experiment.
But what about the maintenance if the app takes off? I find that a good
README file takes you far. Also good, rich comments in code are invaluable.
If there is some kind of server setup involved I often keep an install log in a file to document all the manual steps I took to get everything up and running. Despite the simplicity these install logs have proven their value many times in the past.
Choice of Technologypermalink
While the choice of techology is free when building external apps you might still want to use something sensible and not too exotic.
Not everything stickspermalink
We also have built a couple tools that didn't take off the way we hoped. For example we invested some time building a semi-advanced Slack bot using Google Dialogflow. It's actually really cool and smart and can answer a lot of questions, but people tend not to use it.
That's OK. At least we tried and the intention was good. Building something is learning and an indirect way of providing value to the company. It might not be a direct investment, but it may pay off in the long run when some project comes up that requires the technology used or if the technology we already know seem like a perfect match for the project.
At Ingrid we always have plenty of interesting ideas. We keep things simple and have a catch-all inbox Slack channel where we post them. Ideas are fleeting and it should be easy and simple to capture them.
You can never know if something will take off, but you can always try and at the same time have some fun on the way too. At Ingrid we take learning seriously and don't say no to many things. We love to live on the edge of technology and experiment with new shiny things, only not in production.
Go on and build something today for fun and profit! It can be a tiny script or a simple web app. As long as it does one thing well and helps someone, even if that someone is you, it's time well invested. If it didn't fly at least you had some fun building it and hopefully learned something on the way.