Anita, our CEO had a fantastic time hosting session on balancing deep, focused work with effective collaboration alongside two incredible guests: Jevgeni Demidov, Director of Engineering at Pipedrive, and Jon Kern, Co-author of the Agile Manifesto from Adaptavist. Both are passionate about building great developer experiences and refining the metrics that shape them. They share the belief that deep work and strong collaboration are essential for improving both developer experience and productivity.
You can catch the full discussion in the webinar recording, and I’ve summarized the key takeaways below—hope you find them valuable!
Check out the 5-minute recap video!
Here are the key takeaways from this talk.
Time is our greatest constraint and collaboration is our key strength. How can we ensure our dev teams have enough focused time for coding while still receiving valuable input from the right people and teams?
At Pipedrive, we maintain high operational excellence and overall high team performance. I believe that deep, focused work is essential for this. – Jevgeni
Deep, focused work—uninterrupted blocks of at least two hours—enables engineers to achieve a flow state, key for high performing tech teams. By minimizing distractions and reducing time loss, dev teams enhance individual engineer productivity.
We provide two focus days per week with no recurring meetings. So, there are two days when people can just focus on their work and deal with tasks without any recurring meetings. – Jevgeni
GitHub's 'Good Day' project underscores the need for well-structured collaboration, showing that reducing work interruptions can significantly boost daily progress, with some developers increasing their productivity from 7% to 82%. Conversely, increasing daily meetings from two to three can drastically reduce the likelihood of developers achieving their daily goals, with success rates plummeting from 74% to just 14%.
If you’re constantly busy without enough time to step back, detach from the situation, and see the bigger picture, you won’t be able to make the right decisions. It’s crucial to take a moment—even a physical step back—to reflect: Am I doing the right thing? Is this still the priority? Then, you can move forward. Otherwise, if you’re always running like a hamster in a wheel, you just keep going and going—reacting instead of acting with intent. – Jevgeni
Jon’s perspective on protecting deep work was shaped early on by an older book called Slack.
I like to say, ‘You need slack, but not the tool.’ I mean, Slack the tool is great, but ironically, it can sometimes reduce the actual slack you have. So, you have to figure out when to capitalize on it and when not to. I think it’s really important to find ways to give yourself the necessary slack in your day—to think, to create, and to do, rather than just react and stay busy. – Jon
For simple tasks, interruptions are fine—they don’t really matter. But if you’re trying to innovate, create, or do complex, deep-thinking work, constant interruptions—like a Slack message—are not helpful. – Jon
At the same time, collaboration is key to defining, specifying, and aligning around the direction. Also at GitHub, collaboration is a key multiplier in the DevEx formula—driving developer productivity, impact, and satisfaction.
Good collaboration for me means having a clear intent for our interaction. We need a purpose—what we’re doing, why we’re doing this, and what are the expected outcomes of this conversation? – Jevgeni
The first bullet of the manifesto talks about individuals and interactions—that’s the essence of collaboration. A lot of it depends on aligning the thought bubbles around what we’re trying to do. Why are we collaborating? Why are we here? When we have that clarity, each collaborator can ask themselves: Is this a good collaboration? Is it necessary? – Jon
Collaboration is one of those things—you know it when you feel it. Sadly, most of the time, we don’t actually do it. Instead, we pass documents around, creating the illusion of collaboration. And often, the root cause of collaboration missteps is assuming that something was clearly stated just because we wrote it down in a document. – Jon
DevEx reports show a similar pattern, but from a different perspective. Atlassian's latest research identifies a lack of deep work as one of the top five time wasters for engineers. Similarly, a Microsoft study reveals that a bad day for dev teams typically involves insufficient focus time, excessive meetings, and—unclear priorities, requirements, and value misalignment, often resulting from inadequate collaboration.
The pressure we unwittingly put on ourselves to take the time necessary to dig into a complex problem is real. And, I often say, the ability to sustain discomfort is a really important skill to learn.So many people want to shorten things. But you have to slow down to speed up. So I think that’s what we’re fighting—the reluctance to spend too much time focusing because we feel like we have to get stuff done. It’s that constant drumbeat from the outside, and even inside some of us, that makes it a real challenge. – Jon
More deep work time also creates room for broader DevEx improvements without delaying key tasks. Engineers are eager to address what frustrates them; they just need the time and empowerment to do so. Allocating four hours weekly for DevEx improvements has led Atlassian to impressive results, including the Confluence team doubling their pull requests reaching production within 48 hours, and the Trello team cutting 24,000 lines of unused code.
For us at Pipedrive it’s very important to have uninterrupted blocks of at least two hours. This is our definition of focus time—these uninterrupted blocks of two hours allow our people to be more creative and tackle complex problems. We protect this in many different ways. – Jevgeni
There are three key approaches I observe among tech teams: (1) many reduce the number of meetings or switch to asynchronous substitutes to free up time for deep work; (2) some structure their work and meeting times more effectively; and (3) others cultivate a data-informed team-level awareness of meetings and deep work habits to continuously learn and adapt.
Shopify experimented with radical meeting cuts, which could strain collaboration. On the lighter side, companies such as Slack, GitLab and many other companies embraced 'Focus Fridays'—special days each week reserved for deep work. Slack also introduced 'Makers Week,' designated weeks each quarter dedicated to deep work. Many teams are adopting asynchronous alternatives to meetings, such as async standups, and Atlassian for instance, experimented with Loom recordings to replace meetings, reducing reliance on synchronous communication.
Uber and Stripe leverage real-time data from collaboration systems to continuously provide teams with feedback on their deep work time, valuing this information as highly for productivity as code metrics. The teams I work with are taking it even further; they not only receive data-informed feedback about how they allocate their time for deep work, meetings, and context switching during the week, but they also gain insights into their collaboration dynamics. This includes how they balance synchronous meetings and asynchronous written communication, both within and across teams, and details on the specific teams they interact with, all while ensuring 100% protection of individual privacy.
Honeycomb and Pipedrive are taking a different approach by focusing on smarter ways to structure meetings. Honeycomb initially experimented with asynchronous stand-ups, but finding them ineffective, they shifted to meandering team sync meetings. These are held for one hour a day, five days a week, during hours that accommodate different time zones. They've minimized other meetings by incorporating planning, retrospectives, and coordination with other teams into these sync sessions.
There are always challenges and room for improvement. And this is why we prioritize focused work and collaboration highly. I want to believe that we don’t just fix the symptoms, but that we solve them strategically—as much as we can. – Jevgeni
Predictability, once again, seems to be a key building block of a good developer experience. As an engineer, the exact balance between focused work and collaboration matters less than having a consistent, predictable schedule for both.
Our main approach is to follow a clear weekly rhythm. For every team across the company, we have two focus days—days with no recurring meetings, ensuring uninterrupted work. These are Tuesday and Friday. Then, we have two team days, reserved for team sync-ups and collaboration—Monday and Wednesday are dedicated to teamwork. And we try to schedule all other meetings on what we call the big meeting day. This means that major events like company all-hands, area or function all-hands, company trainings, and other relatively big meetings all happen on Thursday. – Jevgeni
Source: Pipedrive’s framework for Focus Time
It’s another one of those really simple things—you’d think managing calendars and meetings would be straightforward. So, I love seeing a bold approach. With Pipedrive’s weekly framework for structuring meetings, it becomes really clear what we’re doing and when we’re doing it. – Jon
Predictability matters—for both the overall weekly experience and every single collaboration event.
We follow what we call the 3X3 meeting format. The 3X3 means that there are three key phases—before, during, and after the meeting. And for each phase, there are three specific actions that should take place. Before the meeting, you need to prepare and communicate a clear agenda in advance. During the meeting, you should stick to the agreed topics, ensure full participation, and engage in meaningful discussion. After the meeting, we expect a summary to be shared, action items documented, and key takeaways communicated. – Jevgeni
Pipedrive created The Mission Framework, where the key is to focus on one mission at a time and eliminate interruptions—just like James Bond. After all, James Bond can’t be interrupted, right?
At Pipedrive, we have something we call the mission framework. In a nutshell, these are projects that require more than two engineers for more than two weeks. We call such projects - missions. For example, if we need to develop a new feature to summarize emails or redesign a UI to make it more user-friendly, we put people on a mission for a dedicated period. Every mission has a mission lead who defines the scope, sets the success criteria or OKRs, and gathers the right people for the mission—whether it’s a designer, a PM, or several engineers to deliver the targets. They create a backlog, estimate the time required, and once everything is scoped, they go on the mission—focusing on one thing at a time: delivering that specific mission. – Jevgeni
Teams on a mission won’t do any on-call duties or attend any irrelevant meetings outside the mission’s scope. Just one mission at a time—like James Bond. You have a mission, you complete it, and you don’t get distracted by other things. – Jevgeni
If we’re putting a team on a mission, let them focus on the mission without having to fight fires. That’s such sage advice because it sounds simple on the surface, but in reality, teams often get caught up in firefighting. If you don’t have those blocks of time for deep thinking, the odds of producing effective results, finding good solutions, and doing your best work are diminished. – Jon
To foster the right collaboration, we foster an extreme ownership mindset. This is one part of the formula. The second part is what we call customer obsession. – Jevgeni
The extreme ownership mindset helps Pipedrive break the cycle of back-and-forth collaboration
and simplify processes, while customer obsession ensures we focus on what matters most.
Pipedrive reinforces an Extreme Ownership mindset across teams, ensuring everyone takes full control of their area and prioritizes what truly matters. Every engineer owns their work—coding, testing, and deploying—using the internal tools and libraries they provide. Ultimately, this improves focus time, collaboration, and business outcomes.
We foster an extreme ownership mindset across all of Pipedrive—and we do this from day one. By extreme ownership, I mean truly taking it to the extreme, with developers taking full responsibility for every stage of the software development life cycle. – Jevgeni
At Pipedrive, an extreme ownership mindset means that every engineer is fully responsible for their work—developing changes, testing those changes, and deploying them to production. We want the engineers to click the “Deploy” button themselves—because that’s what makes them feel empowered and responsible – I’m deploying my changes to production. – Jevgeni
Of course, we provide engineers with internal tools and libraries to help them succeed. But still, when changes are ready and a developer wants to deploy them, we don’t want them to go to some release management team and ask them to click the release button. They might not fully understand all the magic behind ArgoCD, Kubernetes, DockerHub, and everything that happens behind the scenes, but we still want them to take the driver’s seat—to click that “Deploy” button and have production under their control. – Jevgeni
The same extreme ownership mindset applies to quality. We want to avoid the traditional ‘holy war’ where developers build something, throw it over the fence to the testing team, the testers do their quality checks, and then throw it back. And when a bug makes it to production, the blame game begins—developers blame testers for doing a bad job, while testers blame developers for writing untestable or poor-quality code. We want to break that cycle. – Jevgeni
This is our experience: we have 300 engineers, no dedicated quality team, and no dedicated release management team. Yet, developers do a brilliant job in testing. We still maintain four nines of availability, and the number of production bugs reported by customers remains low. Of course, there’s always room for improvement, but our experience shows that this approach streamlines processes and strengthens accountability. Without extreme ownership, instead of doing the job, people may start looking for excuses or bottlenecks. – Jevgeni
The collaboration Pipedrive deliberately fosters is with customers, using various techniques to cultivate customer obsession.
Customer obsession is something we truly focus on to improve collaboration between teams and departments. Our approach is to drive customer-centric initiatives because when everyone is aligned with the same goal—making our customers happy—collaboration naturally improves. That’s why we strive to ensure that every employee understands our customers. – Jevgeni
Customer obsession is especially important for Pipedrive and similar companies. It’s easy to relate to a product when you work at Starbucks or McDonald’s because you use it every day—you drink coffee, eat a hamburger. You naturally experience the product, see the customers, and come up with improvement ideas. But at Pipedrive, we’re building a sales CRM, and not every engineer has actual sales experience or has worked in sales at all. That’s why it’s crucial to connect every employee to our mission: helping small businesses grow. – Jevgeni
Customers at company all-hands share how they use the product.
We bring our customers to every company all-hands. We book a 15-minute block where we invite a customer and ask them, How do you use Pipedrive? What is your business about? And there’s one very powerful question we ask: If you had a magic wand, what would you change in our product? Everyone in the company gets to listen—hearing firsthand what works, what doesn’t, and what can be improved. Different customers share different perspectives. And then, let’s say I’m a member of a team developing some functionality. I listen to the customer, and they want to improve the very thing I’m working on. That gives me more exposure to the issue and makes me even more willing to fix it. – Jevgeni
Recurring customer panel discussions open to the whole company.
We invite our customers to panel discussions, which are similar to the company all-hands interviews but a bit longer, giving panelists more opportunity to introduce their companies and share their challenges. This helps us relate to them even more. – Jevgeni
Using customers’ products at company events.
We are using our customers’ products at our events. So, for example, we purchase products from our customers for things like summer days, or we use catering services provided by them. We also buy their products as gifts for employees on anniversaries, birthdays, or other occasions. And again, as an employee, you receive a gift, and it’s actually something produced by one of our customers. So then you can connect the dots and feel a stronger connection to them. – Jevgeni
A fully guided week for every newcomer to learn the Pipedrive product.
Every newcomer who joins Pipedrive gets a full guided week to learn about the Pipedrive product. During this time, they focus on just one thing—learning. It’s like a mission. For the first week, we want them to absorb as much as they can about Pipedrive. We also provide them with a trainer who explains everything. – Jevgeni
One Day in Customer Support Shoes.
Previously, the guided week for newcomers to learn about the Pipedrive product was followed by two days of working in customer support. So as a newcomer, you would join the company, complete one week of product onboarding, and then spend two days in customer support. Of course, you would be shadowing a real customer support agent. But I remember that after just one day of shadowing, I felt comfortable enough to start answering customer questions myself. – Jevgeni
Analyzing customer support tickets.
About half a year ago, we started developing an internal analysis solution—one that analyzes all customer support tickets. The goal is to help engineers and PMs understand what works well and what doesn’t. Since there are thousands of customer support conversations, it’s impossible for anyone to read them all. But now, with AI, we can summarize, categorize, and enrich the data, providing key insights. For example, we can now tell teams: these are the top topics your customers are talking about, and these are the things they are most happy with. Essentially, this solution helps bridge the gap between employees and customers, strengthening that connection. – Jevgeni
Many tech teams measure developer productivity using output-oriented system metrics, such as code commits or reviews. Some also measure delivery inputs through DevEx surveys. Top teams, like those at Pipedrive, extend their metrics to include focused work and meeting times, utilizing data from collaboration tools.
Pipedrive measures all of these metrics and more. The data doesn’t have to be perfect to guide you in the right direction—just insightful and diverse, offering multiple perspectives on the same reality.
Our data-driven approach has helped us reach an elite level in operational excellence according to DORA metrics. – Jevgeni
Rather than overcommitting to collecting, cleaning, and analyzing data from a single source, they leverage multiple data sources while embracing the imperfect view they provide. What matters most is making data-informed decisions and driving action while considering different perspectives
Data from Developer Experience surveys matters—because it reveals developers’ perceptions, helps align on changes, sets priorities, and identifies waste and friction points that other data might miss.
We use data-driven insights by running different surveys quarterly to measure various sentiments. These can cover deep work, realistic timelines, clear direction, and efficient processes. We want to take a snapshot of people’s perceptions—how they feel about the processes and what they tell us. – Jevgeni
You can gather as much factual data as you want—from Google Calendar, GitHub, Jira—but it’s just data. You also need to understand how people feel about the processes: how much dedicated focus time they actually have and what their experience is like. So, we run these surveys to gain that perspective. – Jevgeni
It’s not just about handing teams a survey and saying, ‘Here’s some data—figure it out.’ We genuinely want to help them navigate these challenges and succeed. So we have a dedicated Developer Experience PM who oversees the process, helps teams analyze the results, implements solutions, and orchestrates the overall effort. – Jevgeni
The good news is that when people experience issues firsthand, it makes it much easier to convince and get buy-in from both employees and upper management to fix these problems—because everyone wants to be productive. Upper management also wants their people to be productive since it helps everyone reach their OKRs. This collective understanding helped us prioritize improving and working on these challenges. And again, not just fixing the symptoms, but solving them strategically. – Jevgeni
An immediate example I have is from a few years ago when we started asking our developers, How many hours a week do you waste troubleshooting your dev environment? We wanted to know if there was a problem. And then we were shocked to learn that, on average, engineers reported wasting 2.5 hours every week on this. They said things like, every morning, I have to spend 20 minutes troubleshooting some issue, and then throughout the day, more problems come up. At the same time, we were growing dramatically—from 50 engineers to 100, then 150, 200, 250, and eventually 300 engineers. So, if you multiply 300 engineers by 2.5 hours a week, that adds up to a huge amount of lost time every month. And it’s not about the process—it’s about tooling. So, you want to avoid this. – Jevgeni
Calendar data matters—because it shows where we are now in terms of focus and collaboration structure, and whether we are truly moving in the right direction to execute the agreed weekly framework.
To measure meetings and deep work, we combine different data sources. We use sentiment data from our quarterly surveys, but we also gather quantitative data from the Google calendar. – Jevgeni
When you have a big dataset from the whole company, it already gives you some signs—are you moving in the right direction? How big are the meetings? When are they happening? Do people have enough focus time? But we combine this with sentiment data—the perception of employees, what they feel, and what they tell us. Do they have enough focus time? – Jevgeni
Code commit data matters—because it reflects the impact of actions taken and the contributions engineers make.
We also have complementary data from a tool that helps track the number of coding days engineers have, providing additional insights alongside our other data sources. There’s some dark magic behind how it’s calculated, but we use it as complementary data to assess whether engineers have a reasonable number of coding days, whether that number is growing, and what the trend looks like. It also helps measure the impact engineers have—such as how much code they’ve written and other relevant factors. – Jevgeni
Big meeting effectiveness data matters—because it provides instant feedback, allowing adjustments and improvements for the next time.
For relatively big meetings, we also ask participants to measure their effectiveness—was it a good use of their time? For example, when I run my all-hands with my department, I always ask this question. It’s a quick 20-second task—just scan a QR code, give a score, and that’s it. If the feedback shows it wasn’t a good use of time, then lesson learned—I’ll adjust. Maybe the meeting needs to be repurposed, perhaps I invited the wrong audience, or I wasn’t clear enough in my intent. Either way, it’s on me to improve it. – Jevgeni
You may ask, is it worth the effort to collect and analyze data from so many different sources just to improve focus and collaboration—one aspect of how teams work?
Our efforts to protect focus time and improve processes have led to tangible results. We see healthier meetings, more coding days, greater impact, and better quality. Engineers have more uninterrupted work time, which directly contributes to these improvements. – Jevgeni
Our engineers deploy up to 100 times a day to production, and we still have these four nines of availability. – Jevgeni
But it’s not just about introducing new practices or processes—it’s about sticking to them and following through. And that takes a lot of courage, or rather, the discipline and muscle to develop over time. – Jevgeni
It takes constant partial attention and vigilance not to fall back into old patterns. – Jon
Pipedrive prioritizes protecting deep work with a clear, simple framework for focus and collaboration— a weekly routine for all teams. A predictable structure ensures everyone knows what their day and week will look like.
The company also applies a clear collaboration framework: extreme ownership—eliminating unnecessary collaboration and freeing up capacity, and customer obsession—using that saved time to focus on what truly matters.
Data from multiple sources helps Pipedrive execute, adapt, and learn along the way—without overcommitting to any single dataset. Instead of striving for perfect data, they embrace imperfection, using a broad range of insights to visualize multiple perspectives.
Our data-driven efforts have paid off. In DORA metrics, there are different levels, with the highest being elite. I don’t like saying it because it feels like showing off, but according to DORA, we are at the elite level. But this isn’t just about hitting a metric—it’s an indicator that we are exceeding industry thresholds. We also consistently outperform industry benchmarks when it comes to the Developer Experience Index. – Jevgeni
PS. Both Jon and I are big fans of how Pipedrive operates. The company’s approach fosters continuous learning, growth, and operational excellence. They have outstanding internship programs, a strong career framework, structured feedback, top-notch tooling, and—most importantly—amazing people. Want to experience it firsthand? Check out Pipedrive jobs!
I think I want to sign up for one of those internships and learn. – Jon
