Our engineers are heavily involved in the product and their impact is crucial!
We are organised in multiple squads, where each squad has full ownership over one area of the product. Each squad consists of 1 Product Manager, 1 Designer and 3-5 engineers. The squads work cross-functionally across the business to ensure customer-centricity and bigger picture view.
Ownership of an area of the product, means being somewhat autonomous. The teams set and own their goals on what to accomplish. This goal-setting is a collaboration across the product team, where we work together to see how we as multiple squads can best deliver on our product strategy & current company objectives. Our main goal is to see what we as a whole can accomplish and focus on the full experience. Being an autonomous team at Kognity ultimately means empowering the whole product team to create the best experience for the end user.
What do we do and our success so far
As engineers in the Product team we are building modern online learning platforms for schools around the world, empowering teachers to improve learning for their students.
Technically we work mainly with python, Django, javascript & VueJS. There’s also some other tech we use to get the job done, such as PostgreSQL, Redis, RabbitMQ, as well as infrastructure like Github, AWS & Heroku.
Our product serves hundreds of thousands of students across more than 100 countries so far, and for the majority of that journey it has been built with a small product team of less than 15 people.
While we are continuously hiring and now growing our team, our ways of working and our philosophies have been keys to our success and continue to be very important for us. We are sharing a few of those here to shed some light on what working in the Kognity Product team looks like.
Our safety-net - How to go fast without breaking things
To be able to release every ticket straight to production, several times per day, we have invested in what we call our ‘safety net’. This net consists both of automation of tasks and trust in the process. It also enables us to improve and refactor code without worrying about breaking things - so engineers can get into a creative flow without fear.
The safety net includes:
- Merge checks on tests and linting rules. This makes it easy not to merge or deploy broken code.
- Automatic test environments & releases to production, to avoid any human errors.
- Zero-downtime migration strategy & tools. This allows us to carry out database migrations and changes without any downtime for teachers, and without any unpredictable one-off scripts etc.
- Clear process of clarified code review & testing steps before releasing any ticket, making it easy to get things right
- No-blame culture. Breaking things happen, and we don’t want shame or blame. We always look at any issues from a process perspective. Were you stressed? Why? Was it poorly planned? Were goals too high? Was there too little automation?
- Post-mortems. Every major incident is followed by a post-mortem to both share learnings to the whole team, but also to take actions that will prevent it from happening again - strengthening our safety net.
