This is the second part of the startup team in an enterprise series. Part 1 of the write-up is here.

where we talked about:

  • A/B testing
  • Autonomous Team
  • Development Lifecycle

Here are some other topics that we think we executed well in our team and very interesting subject matters for embracing agile mindset.

Feedback loop

This is one of the frequent meetups/standups we had. This loop ranges from team individuals to project stakeholders. We were constantly on chat about design, problems, decisions with both team individuals and project stakeholders.

This helped us to do course correction and re-priorities. This is another reason for us to adapt to extreme programming ( Embracing changes). This loop also happens with different teams ( A Team for API and infra; myjs & SS team for adapting to a new event-based flow on the consumer side. )

Failed early and failed often

We failed! Many times over and some!

Serverchat phaseout project was reverted back few times before we could successfully* rollout to MY, PH, ID & SG. Our initial technical design of uploading ~27 million resumes to s3 would have taken us 27 days.

We have so many instances of such fails. It doesn’t look as bad when we look back at those. Some might be considered as incremental performance iterations.

The point is even though we failed ( some we knew we would, some we didn’t ); we never gave up. We wanted to fail even faster so we know we can abandon this idea faster and work on something better. We were not afraid to fail! That actually gave us a guilty pleasure.

We still have some issues with our serverchat phase-out; feature team will be working on those

Monitoring

What gave us a huge boost in confidence to fail fast? Monitoring.

When we started one of the main goal team had; was to monitor each application’s lifecycle from application to our secondary storage. We had planned for recovery scripts, monitoring even before we started our API writings and system design.

Each feature/iteration we released to production was constantly producing traces of bugs (IF ANY) in our monitoring systems. Which we observed and fixed issues even before it becomes a problem for users. Some of these we could afford the time because of the shadow mode we had implemented and parallel adoption of the deployment.

Communication

We had active communication both internally and externally with different teams. A constant communication loop with other relevant teams helped us break barriers in pushing new ideas and implementations.

We have constantly kept updating feature teams about our goals, new achievements, bugs that we found, data discrepancy.

Because of our extreme programming adaptation and shorter iteration we could adapt to changes ( if any) or requests from any of the team faster.

Collaborative decision making; Sense Of Ownership

The team was given autonomy to take decisions on problems/solutions and share it back with the team. Which meant we didn’t have to wait before we could implement something. The team will share feedback if there is any major flaw in the system design; if not anyone could iterate over the architecture to enhance the system capabilities or performances.

Also, we liked to fail fast; instead of waiting and making things perfect.

Performance enhancement iterations

Because of our autonomous nature; anyone from the team could easily test out an idea to enhance performance.

  • Re-indexing data to remove unused entities from documents to make the document lighter.
  • Re-write part of the API to use a certain way of calling different API to shed out few milliseconds from API requests.
  • Re-write query to enhance the API speed.
  • Implementing partial document retrieving to make the API calls faster
  • Re-writing groovy scripts to make currency related slowness disappear*

These are some of the examples; which ALL happened autonomously. Performance enhancement was something we were happy to see and do; gave us inspiration every time we shed a few milliseconds from somewhere in whole request lifecycle.

We enhanced performance; I was excited there

Debates / Arguments

We always debated our ideas. We had arguments between teammates; which helped us to see from a different perspective. It helped us to learn too.

Being able to see from a different point of view and always able to relate the whole technical design with better user experiences was always the main priority.

We managed to achieve our goals and solve the scaling problem we had. We can enhance more on this and always strive to achieve greater result and give our hirers the best application processing experience they can have.

The idea of building features fast, iterate, deliver and monitor can be applied in any organizations with appropriate mindset and methodologies. We always push ourselves to the limit to achieve that.

If this interests you, why not join us ?