Wrike Engineering: How We Work and What We Value in Engineering Culture
Every day we have roughly 250+ engineers developing Wrike. We create new features, optimize existing ones, and take care of the quality of the code. Code style, code ownership, code analytics, unit tests, and internal R&D directions are common practices at Wrike.
Here we’ll explore the structure of our R&D department, our engineering culture and values, and what our hiring process looks like.
How we work
Our units consist of two to four Scrum teams that work on one large product vertical.
The Product Scrum team creates new features and improves existing ones. This is a truly cross-functional team that connects Wrikers from different functions: the product, UX, product analytics, engineering (backend and frontend developers, QA and automation engineers, and UI developers). Some specialists may contribute to the success of several teams at once. There are 30+ Scrum teams.
For example, the Platform UI unit focuses on the base product, the scope of Wrike functionality that all Wrike users experience every working day regardless of their job roles or company specifics. This includes general UX; navigation; content structuring and organization; work creation; main product views like hierarchical tables, Kanban boards, Gantt charts, dashboards, custom fields, theming, and messaging, and much more.
The Internal unit teams are responsible for improving the development experience in product teams. They provide the tools and features that speed up the development process, ensuring the flexibility of the system in terms of using technology stacks, and guaranteeing that the code base is stable and up to our quality standards.
The main projects of the unit are:
- Tools and metrics for controlling the quality and stability of code during development and production.
- A library of visual components (UI Kit).
- Core mechanics of the client architecture (e.g., independent applications, routing, and transports).
- Improving the accessibility of the product.
DevOps, ITOps, SysOps, and SecOps engineers from a separate department are responsible for infrastructure and security. Expert architects work across units and monitor the product.
How do we prioritize and set goals for our teams?
The product manager typically shares their vision for a feature based on the company’s product goals. Then, the team discusses corner cases and creates a high-level plan to roll out this feature, including its fit into Wrike’s overall architecture and other product tracks.
We believe that only an engineer who fully understands the needs of the business can work out, plan, and implement a feature in the best possible way. All of our engineers take part in the decision-making process for anything that goes out to our customers.
What does the path from task to deployment look like?
- The product owner and UX designer come up with a product story.
- The team refines the requirements based on those initial inputs.
- The backend and frontend developers work on the feature and review it.
- The UI developers make a solid layout and styles for the completed frontend part with all components and business logic.
- The QA and QA automation engineers work together on manual testing and autotests.
While we do have engineers with different areas of expertise, we encourage them to develop T-shaped skills and to help their team in different areas.
We release daily. You can make a feature that users will see as soon as tomorrow. No “manual deployments” — all branches are built by robots.
Frontend engineers at Wrike are engineers first and foremost. They solve problems using solutions, which don’t lie on the surface. They deal with bugs in the framework as well as in the language parser. If we’re unable to find a suitable solution on the market, we can always independently make a proprietary low-level library for our needs (e.g., we have our own complex tables component).
UI developers: We have individual specialists in our team who create layouts, are familiar with the intricacies of various browsers, and are responsible for the visual component of frontend development. Separating business logic and interface layouts allows for speedy product development with high-quality output. At the same time, UI developers work closely with frontend developers — to solve accessibility problems together — and with UX designers to implement ideas in exquisite detail.
UI Kit: We use a standardized component library (UI Kit) with documentation and API, which has over 100 components for quick interface creation. If it’s not enough, together with the UI Kit team, you can develop your own component according to all the canons of UX/A11y/ Design. The UI Kit functions as a full-fledged separate team and consists of UX designers, frontend developers, UI developers, and QA engineers.
Metrics: We appreciate metrics and constantly collect data on assemblies, component usage, tests, quality, and amount of code. Internal Unit teams help Product teams and accelerate development. They collect feedback from developers and designers, analyze data, identify problems and their causes, and prototype solutions. After such research, we decide how we’ll proceed and roll out the update to the entire company.
Going beyond the team and the unit, proactive engineers can deal with the quarterly goals of the frontend department and even participate in setting those goals; this is a huge chunk of work to improve the architecture, frontend infrastructure, and processes within the department.
Stack: The main part is a combination of Dart and AngularDart. We’re now in the process of moving to a micro-frontend architecture, so we develop new parts of the product as independent applications using TypeScript + React stack, wrapped in Web Components. Each application is delivered to users within minutes. If something doesn’t go according to plan, we can roll back the changes in 10 seconds.
Being responsible for the backend in Wrike means being responsible for the most valuable thing a company has: customer data, app performance, and service availability.
We invest in our architecture and it gives results. We deploy daily and rarely encounter merge conflicts despite working with a distributed monolith (this has historically become a thing).
To give teams the flexibility to work and instill a sense of ownership of their features, we’re moving towards a microservice architecture. Product teams are supported by technical teams to help them implement new functionality in individual services.
Engineers can vary their work and not get stuck in one area. Developers from product teams can invest in the technical foundation of the backend and conduct research. We also have the opportunity to influence product tasks; before planning, product owners (PO) consult with engineers, and listen to ideas and suggestions from colleagues.
Main stack: Java 11 (we try to use the latest version of Java LTS), Spring, PostgreSQL, and MyBatis (for greater transparency of working with SQL)
Messaging: RabbitMQ and Redis
CI/CD: Maven, TeamCity, and GitLab CI (for new modules)
If a team needs a specific technology, we start using it. For example, that’s one of our teams started using Snowflake. We try to use a modern stack, but we’re not afraid to implement our own tooling. We have a Migration Tool to manage data schema migrations, and a framework for code markup.
We’re responsible for ensuring quality and creating test scenarios using QA methodologies, and performing manual tests to deliver the best product to our clients. We believe in the Fullstack QA approach without a strict separation of QA and QA Automation.
The Quality Assurance team develops internal tools and services, which are written in Java spring boot, Kotlin, and Scala, and enhances test infrastructure (e.g., improve dockers configurations and our own http_session balancer, move & deploy & run test_infra & test_builds & application in GCE and Kubernetes). We contribute to open source software, as well as use and create OSS solutions.
We believe in quality and speed. That means speedy feedback and delivery are crucial goals for our QA engineers. The faster we provide feedback, the faster and easier we can fix issues.
We move fast with our large application and have 30+ teams working on it, thanks to thousands of automated tests written in modern frameworks that are run on a dynamic infrastructure.
We believe that work should be challenging, and that challenge should be fun. Our QA engineers have opportunities to grow and find modern, innovative ways of working, from tools to the Fullstack QA approach. Any Wrike QA engineer can grow into a QAA engineer, test developer, software developer (BE or FE), QA analyst, or QA expert/architect.
Stack: Java 11, JUnit 5, Selenium, Retrofit 2.0, Allure report + Allure EE, and CI/CD tools
Android: The Android team at Wrike is small but effective. It currently has three Android developers. With this team, we support a significant part of what web teams do within the mobile application, and implement specific use cases and experiment with mobile-first features.
The strong point and main feature of our Android application is support for offline mode, including the ability to edit data so you can use Wrike even when commuting on the subway.
We work with a small team, and therefore try to invest in the quality of our internal solutions to minimize the cost of changes. In our team, you can always find a task to your liking and promote your ideas to improve the product and its technical component.
Stack: We write in Kotlin, actively use Coroutines and Flow, use the MVVM approach to build UI (not tying to Android ViewModel), and SqlCipher as a database with its own non-ORM wrapper over it, which is also written in Kotlin.
Much of the functionality is covered by UI tests.
iOS: The iOS team is developing and supporting the mobile version of our product for iPhone and iPad. We support most of the features of the web version of Wrike and try to implement the latest iOS features such as Widgets, Siri Shortcuts, and Voice Control.
Our application is large and complex; we support several languages, offline mode, adaptive navigation, and we’ve developed a system of visual themes and our own library of UI elements for the app.
We care about our users and try to implement accessibility. This includes Invert Colors and Increase Contrast, Dynamic Fonts, and VoiceOver. Each new screen of our application must support the entire set of these features.
Recently our iOS app hit the WWDC 2021 presentation.
Stack: Swift, Swift Package Manager, Combine, MVVM. Realm as a local data storage. Modular architecture of application screens. Most of the application is covered by UI tests. We’re implementing SwiftUI and abandoning Objective-C.
Agile Delivery Office
The Agile Delivery Office team distributes Agile values and is responsible for delivery at the unit and team level. We work in an ever-changing environment, and our mission is to spread the culture of iterative development and be flexible in our response to changes.
Agile Delivery Office includes two teams: Scrum Masters and Unit and Team Managers. Both teams work together at three levels: team level, unit level, and the product engineering organization level.
Each Scrum Master is assigned to a specific unit, where they work with two or three teams. The Scrum Master is also an Agile leader and change agent in the unit, who interacts with the unit’s management team.
Unit and team managers are responsible for building and executing roadmaps, lineups, and synchronizing plans. Unit managers operate at the unit level and are responsible for the delivery of the entire unit. Team managers operate at the team level and optimize their work speed.
At the product engineering level, we support and develop common practices and approaches to design and processes. With adjacent departments, we develop and improve the team performance system, the Project Portfolio tool, processes for a regular exchange of feedback with key stakeholders, and other aspects of the SDLC process.
Each of us strives to build a healthy dialogue between the product owner, functional managers who maintain proper technical excellence, team managers who help with planning and execution, and Scrum Masters who propel Agile thinking and Agile development practices.
Data Science/Machine Learning
As the leading collaborative work management platform, Wrike has a large amount of data, so our goal is to leverage it and apply data science and machine learning to improve user experience and productivity.
In Wrike, ML can be used in a number of different ways, such as:
- Personalization, e.g., recommending tasks, assignees, and other entities as well as providing a personalized UI.
- Enabling users to easily search for the information they need.
- Optimizing work and mitigating risk, e.g., project risk estimation.
- And more!
A major track is continuously improving our data science infrastructure by working on an internal framework for automating data extraction, training, comparing, and serving models. We’ve also built a diverse set of tools to improve the productivity and reliability of our data science work.
Our technology stack: We use a wide range of DS and ML tools depending on the goals and constraints of each ML project.
- Cloud: We use the Google Cloud Platform as our primary cloud solution (e.g., BigQuery for storing data and AI platform for training and serving models). We’re planning to transfer to Vertex AI soon.
- Coding: We mostly code in Python. Black, Mypy, and Flake8 are our main libraries for code stability and style.
- pandas, NumPy, SciPy, and Scikit-learn for data wrangling and building baseline models.
- XGBoost, LightGBM, and CatBoost — we often work with tabular data so gradient boosting libraries are a must.
- TensorFlow and Keras for deep learning.
- SHAP for model interpretation.
- Optuna for hyperparameter tuning.
- MLFlow for tracking experiments.
- Dagster for building pipelines.
We automated the code markup process to clearly understand which team a particular piece of code belongs to. To do this, we made a markup language and wrote a system that collects and visualizes information. Each employee can see which features are in the team’s scope and which product owner is responsible for them. We automatically weed out errors in production and send a notification to the member of the team responsible for this piece of code. Learn more about code ownership at Wrike in this article.
We believe technical debt is a common concern for all engineers. That’s why we’ve created a mechanism of engineering initiatives that allows us to introduce engineering-wide improvements like migration to new UI components or to a new version of a framework.
Initiatives work in different departments: frontend, backend, QA, QAA, and crafting
For example, engineering initiatives helped us implement the Code Ownership project. We marked up all our code and now we know which team is responsible for a specific fragment. Also, with the help of initiatives, we’ve made consistent toolbars in different product views.
Application for initiatives monitoring: mobile and web versions
Over the past two years, we’ve implemented 141 initiatives and completed 8,655 tasks.
The mechanism of engineering initiatives not only helps solve the company’s problems, but allows engineers to prove themselves as the owner and driver of the project.
Sharing knowledge and out-of-the-box perspectives is a huge part of our engineering culture. Knowledge sharing is a platform for people and a club for communication. We get together every other week and listen to our fellow Wrikers talk, mixing useful work-related topics (e.g., switching to a new stack or accessibility) and anything else that’s interesting for our developers. Each engineer can suggest a topic, and we help them prepare a presentation and review their report.
Wrikers discuss processes and technologies not only at Wrike. Our engineers participate at conferences and meetups with their talks, write articles, promote Wrike at exhibitions, and contribute to the open source community. We help with preparing reports and writing texts, and we conduct training workshops for authors and speakers. We hold an internal hackathon every year, and more than 15 features developed during the hackathon have become a full-fledged part of the product in five years.
With: IT Recruiter
Duration: 20–35 minutes
During the first step we tell you about Wrike, your role’s responsibilities, and the team, and ask questions about your experiences and expectations. You’ll also have an opportunity to ask us anything about Wrike that might interest you.
With: Developers from the teams and/or your future manager
Duration: 1.5–2 hours
We’ll discuss several code-related tasks depending on your experience, focusing on approaches and solutions that you propose. You’ll be asked to write sample code, but we don’t require you to run it during the interview. In addition, we’ll talk about your previous projects, our stack, and projects, and ask you some technical questions.
Our candidates are always encouraged to share their stories and experiences, ask questions about our stack, challenges, processes, and how we work within our teams.
With: Your future head/director of the department and HR
Duration: 1.5–2 hours
The main objective of the final interview is to match expectations on both sides. We’ll discuss Citrix’s core values and processes as well as daily life in the office, and discuss your previous experience. Finally, we’ll talk about the projects you’ll work on, as we’re always looking for ways to improve how we work. We’d love to hear your thoughts on these topics. Our goal is to address any questions you may have during this step.
If you like what you see and want to join our team, we’d be happy to meet you!
Apply to open positions on our career page.