![]() 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.Īs 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. Now, however, the leaves had changed color: we had new people joining the team (including yours truly) and 2 mobile engineers. 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. Once everything was figured out, it was time to put all of those jigsaw pieces together to build Infino. 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. Up until this time, a simple Trello board worked like a charm. It worked great! It was loved! We had to build it. 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. Much like any “Quentin Tarantino movie,” let’s go through our timeline. 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. ![]() 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. And time is a luxury we do not possess in the proportions required. 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. One may argue that something has become an industry favorite for a reason however, every team needs something different. I guess we didn’t do a good enough job of finding the right tool for us and went with what the industry recommended. Turns out, this really got into the way some of us did things we changed applications and the issue persisted. We needed to come up with a solution so that everyone on the team had visibility to everything. 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. 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. The true effort of engineering should reflect by how efficiently and effectively our code captures the business and product requirements. While all of this sounds like we have a huge team, we really do not the total headcount is only 5 people. Infino’s engineering effort comprises of three teams: i) backend & infrastructure ii) front-end (which, of course, includes web and mobile) and iii) security. 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. Hello, people! I am Shreyansh: one of the many engineers who’s working on the Infino platform.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |