Developer Spotlight – Shankar Sethuraman

This edition of Developer Spotlight features Shankar Sethuraman, a Development Lead, Scrum Master, and Integration Architect at AOT Technologies. Shankar has been working on a project with the Ministry of Finance, where AOT is engaged to work on a multi-year project to simplify and modernize the tobacco and fuel tax exemption program.

Can you tell me a bit about what you’ve been working on?

I’ve been working on the TAFT project – the Tobacco and Fuel Tax exemption simplification program for the Ministry of Finance, since the start of this year. I am the development lead and scrum master for this project. Additionally, I also run DevOps for the project.

What does the day-to-day look like, and what do you love about your job?

My day-to-day is to primarily run scrum meetings, track the status of stories and progress in the sprint. This means getting into meetings in multiple areas such as API meetings, UI / UX meetings (sometimes), meetings with the product owner and the business analyst on various aspects such as planning, scope, priorities etc. There are also periodic team-wide meetings to “groom” user stories for subsequent sprints, tracking the workload for the current sprint, to see if the work can be completed on time, sprint planning, and retrospectives.

Since I do the DevOps for the project, I do spend a lot of time on technical tasks, such as deployment and scripting to ensure that the apps (APIs, database, web UI, etc.) are available and ready to be pushed into environments as required. I also work with the technical architect on finer aspects of the solution.

What I love about my job is the complete change of role from all of the other projects that I’ve worked on thus far. While I’ve almost always been an individual contributor to development, this project and role have afforded me an insight into how teams are organized (and this is a fantastic team!), how they work together to deliver a high-quality solution within specified time constraints.

I love how I’ve changed directions technically, from being a middleware developer previously, to doing things that are new to me, such as working on Red Hat Openshift, bits and pieces of javascript, and typescript. I am still learning about these new technologies, but I am already excited to see how it goes, and I hope to build on these to contribute more meaningfully in the future.

I also like working with the product owner and the analyst directly to lay down roadmaps, make decisions about what we want to do, when we want to do it, and forecasting what the project might be like for the next specified period of time.

Throughout this project what are some of the obstacles that you faced? How did you handle these challenges, and what did you learn from them?

I haven’t really faced any obstacles so far – the team from the product owner, the team members, to AOT as an organization have been extremely accommodating in all aspects. From handling a lot of the communication with the Ministry to procuring software to working hard to complete development and testing.

I must admit – I was slightly nervous at the start of the project about the change of roles, and I thought I would be the main obstacle, but the project has gone really well so far.

I would say this is primarily because the team really does work as a unit, and there is always the focus and desire to just get stuff done, and done well.

Looking back on your time on the project, what are three key takeaways from the experience?

To be honest, I am still in the middle of it! But I’ve already learned a few things:

1. Plan and be organized. It’s important to have a clear direction at least for the short term (a few sprints ahead at the very least). This gets the team focussed on what’s coming up, and helps identify challenges and dependencies early.
2. Team-to-team communication between internal teams is vital to reducing rework. I can see how the teams’ communications improvements have contributed to a decline in rework, defects and issues in integrations between components. The teams are constantly talking to each other, resolving issues as they go along, without resorting to long meetings and spending time going back to the drawing board.
3. Accept and be prepared for things to go awry. This seems very obvious but is hard to take for granted. This includes technical issues, change in direction, team / team members being blocked for whatever reason. Work with the team, product owner and the analyst to see how we can compensate, and what we can do to move forward with the least impact.

What do you enjoy about working at AOT, and what advice would you give to people starting out in their career as an integration specialist?

I’ve been working for AOT for more than 5 years now and I’ve been one of the few people that have seen it grow the way it has. AOT has a crack team of specialists – all of whom are terrific in their areas, and just looking at the work they do definitely is one thing that keeps me in awe.

Working at AOT means working on many different things – both technical aspects as well as different projects. This means being challenged routinely and stepping outside your comfort zone to take on completely new things. I’ve often repeated to my friends and colleagues that the time I’ve spent at AOT has allowed me to learn more than everywhere else combined.

As for tips for people who want to start and become integration specialists:

• Work on or learn as many different integration frameworks and technologies as possible
• Focus on various integration patterns, and how they can be applied to arrive at efficient and scalable solutions.
• I would also encourage them to focus on not just development (coding) areas, but also administrative and infrastructure areas, such as installation, server setup, scripting, automation, and DevOps, to be a well-rounded integration technical specialist.