@Kushan_Shah Also happened to ask “What is Jupiter’s engineering process like? How do you manage engg team? What is the engg culture like? What keeps you up at night?”
Interesting questions Kushan!
We are a fairly small engineering team at Jupiter and we’d like to keep it that way. We have a few engineering philosophies that we follow: one which is to ‘do-it-right-the-first-time’. This is ingrained in how we attempt to solve any problem.
Our engineering team is divided into pods. A pod is a logical group of backend and frontend engineering teams, a product manager, alongside business and operation managers. The pod then becomes a self-contained entity that works on a problem statement independently.
With that structure, we have set up a few processes that ensure that while the pods work independently, the entire team is aware of what everybody else is doing. We are also meticulous with documentation. Any new problem statement we work on is documented first. We have a set template for writing an engineering spec, which covers the problem space, various solutions, a high-level and a low-level design, the execution timelines, and also the cost of ownership, when the product goes to production.
The specs are then published on an internal wiki that the entire engineering team can read. Besides this, we have bi-weekly architecture councils – we call this a Jedi Council. No kidding. It is called a council (mainly because we wanted it to sound cool), but the entire engineering team participates. Anybody from the engineering team can nominate themselves and present their engineering spec/architecture to the wider team. It is a great forum to receive advice and be critiqued on the spec.
Apart from the architecture councils, we do bi-weekly Demo-Days. Attendance is mandatory at these Demos for the entire organisation. We use this time to present our engineering work to the wider organisation and receive feedback.
While documentation is always good, this process also creates a lot of transparency in how we operate as an engineering team. Specifically:
- It keeps everybody aware of what everyone is doing, so we don’t reinvent the wheel
- Allows folks to work on different problem statements and not be constrained to their pod
Our engineering team is self-managed. We do not have managers, but we have team-leads. The team-lead is also the developer on the team with an extra responsibility of mentoring the other team members and bringing consensus on various discussions. At Jupiter, everybody in the engineering team codes and is expected to manage their work. Team-members can reach out to anybody in the team for mentoring. Ceremonies like the arch-councils and demo days are great ice-breakers and make the team more comfortable in seeking help from one another.
What keeps me awake in the night is a really tough question, because it is different on different days. The problem statement is really fascinating (and tough), and the engineering team is really amazing. The regular nights are all about how we can meet our launch timelines. At times, I think a lot about the newer problem statements the team can solve. There is a constant itch to do better; to see the final pole sooner - that keeps me awake.