Hello, people! I am Shreyansh: one of the many engineers who’s working on the Infino platform. This post is one in the series of musings from and about the engineering team where we try to scribe the challenges we faced as a team along with our thought process which led to the solution.
Introduction
Infino’s engineering effort comprises of three teams: i) backend & infrastructure; ii) front-end (which, of course, includes web and mobile); and iii) security. While all of this sounds like we have a huge team, we really do not; the total headcount is only 5 people.
The true effort of engineering should reflect by how efficiently and effectively our code captures the business and product requirements. This, in turn, relates to how well we — as a team — manage each other, and the cross-functional dependencies which may arise from our decoupled systems’ design.
I can say with certainty that engineers do not like working with task management solutions since it becomes yet another “thing to manage” in their already-vast catalogue of responsibilities and another “forgotten password” in 1Password. We needed to come up with a solution so that everyone on the team had visibility to everything. Turns out, this really got into the way some of us did things; we changed applications and the issue persisted.
I guess we didn’t do a good enough job of finding the right tool for us and went with what the industry recommended. One may argue that something has become an industry favorite for a reason; however, every team needs something different. For example, as much as I love Jira, I find it to be quite a big pain for small teams: the pricing isn’t that straightforward and it requires a considerable amount of time to setup and use properly. And time is a luxury we do not possess in the proportions required.
This post takes you through our journey of kan-ban, and post-its, and agile, and boards, and sprints, and every project management philosophy you can think.
The Need
You might wonder what exactly was it that we wanted? The simple answer to that question is: “something which gave precise data to various teams about the tasks and requirements.” That’s the SparkNotes version; in truth, we didn’t quite know at the time.
Much like any “Quentin Tarantino movie,” let’s go through our timeline. And reflect. (No, not in a mirror. Or ILSpy.)
Big Bang
Starting with just 5 people — two in engineering, two in management and 1 in marketing — Infino’s prototype was built as a proof-of-concept. It worked great! It was loved! We had to build it. Up until this time, a simple Trello board worked like a charm. The gentlemen in management knew that their tasks at the time was to do the research and figure out all the third-party vendors we may use to build this product. Trello was great!
Once everything was figured out, it was time to put all of those jigsaw pieces together to build Infino. This is where things changed; the prototype was shielded from cross-functional teams, it didn’t have complex compliance and auditing requirements, it didn’t have a distributed architecture; it was as plain as day.
Now, however, the leaves had changed color: we had new people joining the team (including yours truly) and 2 mobile engineers. The system itself was being redesigned from scratch; it now included a distributed architecture, had imperative security controls, a custom logging, monitoring and alerting stack, included the best practices for disaster recovery… in short, it was a behemoth.
As mother fate would have it, the engineering team outnumbered management; this meant a couple of things: 1) more RedBull or there will be an uprising; and 2) we needed to change the way we tracked and managed tasks.
Sense and Sensibility
I was busy designing the architecture, ensuring that the best practices were being followed; Vibhor was (and still is) having chats with our external vendors to ensure that we get the best possible APIs amongst other things; Akanshu was… busy feeding our cats from what I recall; Sanchit was busy with the website; Kanchan and Alvin were busy decorating the mobile application to ensure a smooth user experience; Faik was still banging his head on the table because some of the API documents were a bigger tragedy than Hamlet. The gears had started grinding: our train had finally left its station and was out and about to reach the bucolic village of the “Infinonian” paradise.
Up until this point, we had started experimenting with Asana. A free task management tool which had some power-ups to make life easier. We had completely migrated from Trello because it was getting too cluttered for everyone and introduced more complexity than the problems it solved. Asana was… a pain for some of us (by “some of us” I really mean me); there were no automations, there was no way to import tasks in GitLab; o, what beautiful mess it was.
I used GitLab’s issue management system previously and I had fallen in love with it; the ease-of-use, the power to manage tasks… it was something else altogether. However, it wasn’t so friendly for the gentlemen in upper-management. While we had the luxury of closing issues with commit messages, our dear Akanshu thought of it as a pain to understand why every issue had some random code.
The Actual Need
In an aforementioned section — titled “The Need” — I briefly outlined what we needed; let’s see, in detail, what our actual requirement was at that stage.
We needed a task management system which would be loved by our engineering team and our management team; a platform which had the flexibility of GitLab and the organization of Asana.
And so I started my quest: the search for the absolutely perfect task management system which was a pleasure to use; which didn’t discriminate against non-engineers. Or engineers. Or anyone.
The Epiphany
It hit us. It was a light-bulb moment. The inner Archimedes in us interjected with an enthusiastic eureka! (On Red Bull. You can imagine.) We realized that we are trying to make a product which rethinks how you manage and use your finances; why should we stick to the vox populi of how teams manage their tasks and goals. Why are we afraid to try something new?
And so we did.
I previously used to work with the .NET framework (around 6 years ago) and we used to use products by this great software company called JetBrains (go give them some love! They deserve every bit of it!) They make products for developers, for manager, for everyone in one integrated suite.
We decided to use JetBrains YouTrack as our primary task management system. Oh, and what pleasure it was.
JetBrains is very generous when it comes to licensing; their free suite includes 10 users for YouTrack which is more than enough for us at this stage. This great pricing model combined with startup discounts is a match made in heaven. We have the ability to scale up with absolutely no issues and without burning a hole in our wallets.
The Setup
Our quality control pipelines require a very strict code review (suffice to say that every line of code which goes into production is manually checked); while this feels like overkill, it really isn’t. This helps us capture bugs before our users have the misfortune of stumbling upon one.
We currently use YouTrack as the primary task management system with JetBrains Upsource for great code reviews and Hub for central user and project management.
These tools integrate beautifully with each other. Right from Upsource, while reviewing a commit or a branch (yes, you can create formal code reviews for a commit!), I have the ability to create an issue in YouTrack and assigning it to the respective member.
Separation of Concerns
In YouTrack, I have some really great access management options; I can create an Agile board which is visible to only to the management to get a burn-down of tasks at Infino.
What we do right now is that management can see every Agile board and product teams see their respective product boards. This helps them focus on what’s necessary without the clutter and makes them get “in the zone” of fixing issues.
YouTrack, Upsource, Hub and every other JetBrains product has excellent keyboard shortcuts (they created IntelliJ, come on).
It’s perfect.
Why This!
You may be wondering why we spent so much time finding and setting up a task management system. Our philosophy is simple: KISS. I mean, keep things stupid simple. With every new service, our team members have another password to remember, another tool to learn, another process to start and finish. The friction is so much that we forget about these tools when we are “in the zone” and tasks stay stagnant for aeons to come thus giving management an impression that all we do is talk about how bad the BTC crash is going to be.
With that in mind, I am trying my level best to ensure that everyone uses one simple platform for managing their tasks, for reviewing their code, for CI/CD, for bug tracking, for writing down their grocery lists. For everything, if you will.
A great company focuses not only on the user experience for the end-user but also for their team members. And ours is now as simple as it can be. Google Suite allows us to use SSO for every service we use. :)
The Road yet to Tread
With all of this aside, there are a lot of things we still have to do in order to ensure a smooth engineering and management experience. For one, we will be moving to Okta for SSO and use it as a federated identity provider for every external service we use. We’ll also deploy endpoint protection solutions to ensure security of data with the team members.
Rest assured, we’ll be sure to pontificate upon at length of our experience with these tools and services. We want to ensure that it’s super simple for everyone on the team to work with each other and foster a sense of urgency and love for the work we do.
Stay tuned for the second part to this journey where I tell you why I banged my head on the table for 3 hours because my internal network configuration parameters were incorrect.
Adioś
With that, my fair reader, I bid thee farewell! I hope you enjoyed our journey of finding something which works with zero-to-no friction.
