Ask HN: Lessons learned from building internal tool team? | Hacker News Reader

Ask HN: Lessons learned from building internal tool team?

4 pointsabuani1 comment

I am in the process of pitching building an internal tools department at my company which is has been investment free since it's inception 17 years ago. I've been with the company for roughly a year now, and one of the areas I've noticed we've struggle in is coordination. At a certain point the company grew 5x over a short period of time, and then had to quickly scale back their staff to weather the economic crisis. During this period of growth, there was some efforts made to build tools internally, but there wasn't any particular objective or goal in mind, so most of the tools were very difficult to maintain. I've gotten buy in from my boss on the idea of taking our build out of internal tools seriously again, and I want to make sure I don't set ourselves up for failure again.

Really long winded way of asking, if you were tasked with rebuilding your internal tools from scratch, what would you do differently, or what do you wish you knew today that was impossible to know 3 years ago?

My personal thought is to start with a small project that has a high value but low risk of failure. I've convinced my boss the need for an intern, and he's going to work to make it happen. When I was hired, I was tasked with what has somehow been an impossible task to finish(I'm the 3rd person that got close to finishing but got put on products before I could rationally finish it). And after much soul searching on why I personally couldn't finish it before I was asked to help out on our products, I believe the root cause stems from the perception that our internal tools are secondary to our success. In this logic, we're increasing the amount of manual labor it requires to get our products shipped out, increases the stress of many people in the process by it being wildly inefficient, and it reduces our ability to focus on generating more value from our product.

So I have a solid plan for the project, I've got the core system written so that on day one the intern can get in and familiarize themselves with the company and problem they're going to solve. I have a rough road map splitting the project into two 6 week cycles, where they'll be asked to demo something daily in the first few weeks to ensure they're not getting stuck and frustrated. I've got buy in from all individuals the system impacts to provide insight when they can.

Does this sound reasonable? This is my first foray into having a leadership role, so it's exciting and scary at the same time.

Reply on news.ycombinator.com