A project management guide for developers working in QuickLabs.

At Crownstack, we believe in individual team members taking a proactive approach to building high-quality products. We believe people should take full ownership of their work. There shouldn't be a need to manage—let alone micromanage—individuals, and no one should have to chase team members for progress updates or remind them to update status reports. Therefore, we are outlining our product development process at Quicklabs and the expectations we have for team members working on it.

Manager of One:

We believe in being a manager of one. This means you are solely responsible for managing yourself—no one else should need to manage you, and you shouldn't manage others. Each person takes responsibility for themselves alone. Your interactions with others should be collaborative rather than hierarchical. While this approach isn't always possible, it's what we strive for. You should be able to independently choose tasks, execute them, test your work, and deploy to production with minimal guidance.

Running biweekly sprints:

Our product development cycle runs in biweekly sprints. Therefore, you are responsible for selecting and managing your tasks during each sprint. Executing and delivering those tasks to production with a biweekly pace is your responsibility as well. We do not track working hours, nor do we waste time in pointless time estimation techniques. We trust that you will select enough work for a sprint and complete it without our constant supervision. If you are working in a team, deciding who works on which task is a collaborative exercise, and team members should plan it among themselves. We will judge your outcome at the end of the sprint by looking at what you delivered.

Open-source culture:

We believe asking for permission at every step for tools, documentation, etc., slows us down. Therefore, we are open-sourced by default. All our code is open source, including design and documentation. We want you to be proactive and not to wait for anyone to give you access.

Army of One:

We believe in simplicity in everything we do. Our product design reflects this philosophy. We rely heavily on Tailwind CSS and UI component libraries like Tailwind UI, Flowbite UI, and other similar tools. We also maintain lean teams by empowering our developers to work across multiple roles. Using these UI libraries reduces our dependence on designers. Leveraging GenAI helps minimise the need for project managers since it generates user stories, PRDs, and other documentation. Our developers write automated test cases—eliminating the need for separate QA engineers—and handle deployments themselves, reducing the need for DevOps engineers. This process enables our developers to manage applications end-to-end.

Measuring impact, not effort:

While many companies focus on measuring time spent or lines of code written, we prioritise measuring the actual impact of your work. This means evaluating how your contributions improve user experience, system performance, or business metrics. We care about outcomes and value delivered, not how many hours you logged or meetings you attended. We evaluate this when our biweekly sprints end.

Buck stops with me:

We believe in taking full responsibility for our work. When something goes wrong, you take full responsibility for both the successes and the failures. This mindset of complete ownership means being accountable for the entire lifecycle of your work, from conception to deployment and maintenance. If you don't know what to do, how to do it, or who to talk to, or if you lack permission for tools, we believe you can overcome these obstacles without blaming anyone. You are better than that. Additionally, we have listed down all our processes so that you have all the relevant information available to you, all the time.

Working in cycles:

Since we work in biweekly sprints, each month gives us two sprints, First starting on the 1st of the month and the second sprint starting on the 16th of the month. Each sprint requires team members to participate in the following activities:

• We use Plane for task management. At the beginning of a sprint, developers are supposed to pick tasks from the backlog and decide for themselves what they can deliver in a sprint. If there is a team working on the same project, developers need to collaborate among themselves and plan their own work. Therefore, sprint planning is either an individual activity or a team activity depending on how many people are working on the project. But the onus is on the developer himself to get enough work planned for a sprint; there will be no Project manager or owner responsible for assigning tasks. Developers must present their plan to the product owner on the first day of the sprint, although they can ask the product owner for priorities beforehand.
• Product owners constantly try to keep the backlog filled with the next work items, but if that is not the case, developers can spend time on code refactoring, maintaining their code base, or even running cool-down sprints.
• During the execution of the sprint, developers are supposed to cover everything— code, test cases, documentation, and other development-related stuff. We are expecting polished, bug-free work which manages edge cases and error scenarios well. UI shoud be polished and should be tested on all major browsers and devices as per product needs.
• We do not track office timings or work hours during the sprint execution, although on the last day of the sprint, we will measure the impact and outcome based on what developers deliver in production. We expect you to plan enough work for yourself to keep you busy for a sprint.
• On the last day of sprint, the work should be ready for production and all work reviews happen on that day along with production deployment.
• We want team memebers to be proactive and work independently without much handholding.