Cut through the noise of team communications. Find important workplace updates in seconds. No more getting lost in threads. Create a post in Qatalog.

Share updates that get read | Qatalog

Qatalog posts reach the right people at the right time.

Too much noise in your org?

There they are. Short posts tagged in the right projects and teams — Sarah can focus on milestones and blockers.

Find updates easily with tags

She then posts an update for her team — it's automatically routed to the right Slack channel and her teammates' inboxes.

Share automatically in any channel

Sarah wanted to open a tap, not a firehose. She applies some filters to screen out the updates she won’t need, and pins a few she wants to read later.

Never miss relevant updates

Be more connected without more meetings or messages. Share updates in the right channels automatically.

Posts

Over the past two years, I&rsquo;ve spoken to more than 500 operations leaders in tech, from big tech giants to high-growth startups, in all sorts of different verticals. Despite this, they all have one thing in common; they are still trying to figure out remote work.&nbsp;
More than two years after the entire industry started working from home, it&rsquo;s still proving a challenge. That got me thinking. . . why is it so hard, and how do we get it right?
<h3>Too many tools&nbsp;</h3>
First, some context. The tech industry has evolved unbelievably fast in the past two decades. We&rsquo;ve built new technology for almost everything and incorporated it into how we work. We&rsquo;ve acquired deep, specialized knowledge, created new, better ways of doing things, and new teams and functions to do them. That should have supercharged our productivity, but it came at the expense of simplicity. Now, with all this new complexity, we&rsquo;ve lost the shared context among teams, there are silos everywhere, and it&rsquo;s become harder and harder to actually get work done.
Let&rsquo;s look at a modern software company. There are typically more than 10 teams involved in the development process. Front-end developers, back-end developers, devops, reliability engineers, data scientists, growth engineers, designers, product managers, project managers, and that&rsquo;s only product. If everyone isn&rsquo;t aligned, it breaks.
Yet alignment has become harder because each team has a different set of tools and a unique way of working. Engineering might document tasks in JIRA and follow agile methodology, while the Design team uses Asana, Figma, and a design thinking approach. Product Managers use another shiny new thing. Sales and support, another still. Everyone ends up working in their own little silos, speaking their own languages.
Meanwhile, work across teams still needs to be done. So, we fall back on one of the three things teams still have in common: Email, Slack, and Zoom.&nbsp;
<h3>The unholy trinity</h3>
Email, Slack, and Zoom have become the de-facto coordination layer within a company. We send hundreds of emails and spend hours on calls, just telling people what we&rsquo;re doing, translating it from one tool&rsquo;s language into another.&nbsp;
Company announcement? Email. Project update? Zoom. Looking for a doc? Slack. Who&rsquo;s working on what? The dreaded &ldquo;@here.&rdquo; It&rsquo;s pure brute force. Scale this process up to 5,000 people and it falls apart completely.
But it&rsquo;s not realistic to expect Email, Slack, or Zoom to be the foundational coordination layer of your business. These tools don&rsquo;t have enough structure. They weren&rsquo;t built for it. We default to them because they&rsquo;re the one thing everyone still has in common. A lot like a tourist grunting and gesticulating to get by in a foreign country where they don&rsquo;t speak the language. But we can&rsquo;t operate this way at scale.
Cornell University&rsquo;s Idea Lab partnered with Qatalog to investigate this idea. According to the <a href="https://language.work/study/" rel="follow">research</a>:
<ul>
<li>69% of people report that finding the information to do their job is time-consuming</li>
<li>59 minutes each day are spent finding information trapped in different applications</li>
<li>48% said they had made mistakes because they can't keep track of information stored across online tools and apps</li>
</ul>
<h3>Technology has failed</h3>
This explosion in specialized tooling started as a way to enhance productivity and improve collaboration. Now, it&rsquo;s wasting our time, driving us apart, and causing mistakes. It has failed. We&rsquo;ve lost our shared context and we&rsquo;re forced to operate at our company&rsquo;s lowest common denominator: Slack, Email, and Zoom. We spend hours in these systems each week, translating our work from one language to another. It has become unsustainable. According to Asana&rsquo;s Anatomy of Work Index, it now consumes over 60% of working time. That&rsquo;s not just a problem, it&rsquo;s a fatal flaw in the way we&rsquo;re working today.
<h3>Anarchy or tyranny?</h3>
In my experience, once companies identify the issue, they go down one of two paths:
1) Total anarchy - &ldquo;Let everyone use whatever tool, system, or methodology they want. We&rsquo;ll deal with it.&rdquo;
As the company grows, teams will get disconnected from each other and any work happening outside their own bubble. Next thing you know you regress to brute force processes.
2) Tyranny - &ldquo;Everyone has to use the same tool stack and they have to operate in the same, standardized way. I don&rsquo;t care if people don&rsquo;t like it, they&rsquo;ll do it.&rdquo;&nbsp;
In this scenario, the team gets slowed down by process, stifled by the one-size-fits-all approach, and ends up stuck with outdated tools.
<h3>A common language</h3>
Thankfully, it doesn&rsquo;t have to be a choice between the two. Instead, we can give back to ourselves what the great unbundling took away. We need to rebuild our shared context and introduce a common language and shared structure to organize the work of myriad diverse teams. Something designed for how work happens today, not just messages and calls, and not a poor imitation of the office. A <a href="https://qatalog.com/blog/post/what-is-a-work-hub/" rel="follow">new way of work</a> that drives unity through visibility and connection.

Are we using too many tools at work? Qatalog research suggests we are, and it's become a barrier to collaboration and communication.

The unholy trinity of work tools

The tools designed to boost productivity and collaboration are driving us apart. Learn how to build a common language and create a new way of work.

Qatalog recently came together with the <a href="https://designopsassembly.com/about" rel="follow noopener" target="_blank">DesignOps Assembly</a> to host a panel discussion on the growing strategic role of DesignOps in the new world of work.&nbsp;
The session was hosted by the founder and <a href="https://qatalog.com/blog/post/qatalog-founder-ceo-tariq-rauf/" rel="follow noopener" target="_blank">CEO of Qatalog, Tariq Rauf</a>, who was joined by three DesignOps leaders:
<ul>
<li style="font-weight: 400;" aria-level="1">Kamdyn Moore, Head of DesignOps at Spotify</li>
<li style="font-weight: 400;" aria-level="1">Frances Yllana, DesignOps Lead at Coforma</li>
<li style="font-weight: 400;" aria-level="1">Sarah Klein, Lead Design Program Manager at Cisco&nbsp;</li>
</ul>
It was a brilliant discussion, so for those who missed it, we&rsquo;ve summarized some of the highlights and learnings that explain why DesignOps roles will continue to become more important, how to put your people first, and the need for a single source of truth.
<h3>What is DesignOps?</h3>
Kamdyn Moore: At Spotify, we have over 300 designers across a broad range of disciplines. For me, DesignOps is about supporting and enabling those designers to do what they do. We are a centralized function that supports a decentralized team, and we have to scale alongside the design org, to ensure we can continue to support each of our design verticals.&nbsp;
Frances Yllana: I support a growing 70+ person civic design and technology team of designers, researchers, engineers and delivery leaders. DesignOps empowers the work design teams do, by facilitating everything except the actual design work. That&rsquo;s supporting career growth and development, optimizing tooling and project frameworks, encouraging better collaboration across teams and departments and much more. This work has always been done or needed, but it&rsquo;s still relatively new as its own discipline, so we still have a chance to define what DesignOps can be.&nbsp;
Sarah Klein: I would echo what Kamdyn and Frances said. Thinking about my role at Cisco, I would also add that it&rsquo;s about allowing people within your organization to see the value of design, and ensuring that designers have a voice that is listened to. This means we can start to bring design thinking into requirement setting processes, where previously it was just design-focused conversations.
Kamdyn: Yes, that&rsquo;s interesting, because we have structured our team around two strands of DesignsOps roles now. We have the type that Sarah describes, which is about the execution of the design work itself, and they are much closer to the end product and business decisions. Then we have folks who are focused on the designer experience, prioritizing the people aspect, which involves onboarding, talent, growth, culture and the sense of belonging.&nbsp;
<h3>The crucial role of DesignOps in the new world of work</h3>
Frances: With the rise of hybrid and remote work, DesignOps becomes much more important in every sized organization. We can&rsquo;t have helicopter management anymore, so you need frameworks and systems in place that give your team the autonomy to do their best work, which can be harder for managers when they&rsquo;re not in the same room. That&rsquo;s where someone in DesignOps can help.&nbsp;
Kamdyn: One of the reasons I love operations so much is because I think people have realised it&rsquo;s one of the ways we can make radical change within organizations. We are the systems, the infrastructure and the processes that actually orient a company in a certain direction. And over the past two years the shift to new ways of working has forced companies to look again at all of these things. This means we have the opportunity to implement very meaningful changes in our organizations, which gives us a critically important role.&nbsp;
Sarah: Building on what I said earlier, the increased prominence of designers within Cisco can largely be credited to leaders that now embrace human-centered design and see value in transforming from an engineering centered org to more of a design-centered org. That is something that DesignOps has helped facilitate and naturally, means we, as DesignOps leaders, have a bigger seat at the table too.&nbsp;
<h3>Balancing a tech first and a human approach</h3>
Sarah: As a large organization, one of the biggest challenges we face is communicating across large teams and across departments to get alignment on objectives. We&rsquo;ve taken a balanced approach, making use of certain software tools, implementing certain processes, but also thinking about our culture more widely. It&rsquo;s always going to be a combination of these things to sew it all together, but it&rsquo;s a constant work in progress to stay aligned. It doesn&rsquo;t stop.&nbsp;
Kamdyn: At Spotify, we place a lot of value on giving designers autonomy, but that extends to tools too. That does mean there is some fragmentation, which can be difficult to manage, as it means we have information spread across tools like Excel, Jira, Coda, and every single project management tool you can imagine. Our job is then to figure out the tools that people feel incentivized to use to stay connected.
Frances: We collaborate with so many different experts and clients, each of them with their own ways of working and systems. That&rsquo;s why a single source of truth is so important, as it means when someone pings the team asking a question, you can point them to the relevant resource that already exists. This is crucial for ensuring consistent delivery and quality control. But everyone learns differently. So we&rsquo;ve also done some work to ensure there are different ways of consuming that knowledge, whether it&rsquo;s a video, information cards, or training sessions we can arrange when needed.&nbsp;&nbsp;&nbsp;
<h3>Building consensus with distributed teams</h3>
Sarah: It can definitely be difficult to build consensus remotely, but we&rsquo;ve been distributed for a long time at Cisco, so it&rsquo;s something we have got used to. We generally take a human-centered approach, because when you have people from multiple orgs coming together to make a decision, frequently the blocker is personal. That&rsquo;s where we as DesignOps folks have been able to come in and break down those walls and have more human conversations to remove those points of friction.&nbsp;
Kamdyn: Whenever I look at a problem our team is trying to solve, I often think about what we are optimizing for. Because if you are focused on consensus, you are not necessarily optimizing for speed. There may be situations where a consensus approach doesn&rsquo;t make sense, because speed is important, and a disagree and commit approach is more valuable. Knowing what you are optimizing for helps you to focus on moving forward in the right way.&nbsp;
<h3>Setting up a knowledge base</h3>
Kamdyn: When you have an organization as big as ours, the reality is that you can&rsquo;t just have one centralized place where all of this information lives. That exists, and it hosts our main design system, but we also need something for each vertical that is unique to their needs, which then ties back to the centralized place. It&rsquo;s more of a hub and spoke model. We then have individual programme managers in the DesignOps team who are responsible for each of those verticals, and that&rsquo;s the only area they have to focus on, which means they become specialized.
Frances: Knowledge bases are great, but being able to see who worked on a project is critical too because it means you have the ability to go and ask that person questions, and there are always some important bits of tacit knowledge that weren&rsquo;t captured. Something else we do is to curate &lsquo;Brown Bag&rsquo; sessions with key individuals, often external people, which we record and add to our knowledge base. That means anyone who joins the company later on, can still access those insights on demand when they need it. Again, it&rsquo;s all about creating that single source of truth across the organization.

Industry leaders explain what DesignOps is and why it matters. Read our highlights from Qatalog's DesignOps Assembly panel.

DesignOps in the new world of work

What is DesignOps and why has it become more important in this new world work.

Tariq Rauf is the CEO of Qatalog, which he founded in 2019. The company has grown quickly since then, helping to power thousands businesses, with a distributed team of almost 50 people spread across four continents.&nbsp;
I spoke to Tariq to understand more about Qatalog&rsquo;s unique approach to software for work, why his background in architecture gives him an edge, and how he sold his first piece of software at 12 years old.
For those who are new to Qatalog, how would you explain it to them?
Qatalog is an entirely new way of using, thinking about, and building software for work. It&rsquo;s a Work Hub that centralizes your people, teams, projects, goals, documentation and processes. Think of it as the single source of truth for work that makes cross-functional initiatives visible, processes more efficient, and gives your work structure.
There are lots of productivity tools already. Why is Qatalog needed?
The &lsquo;software for work&rsquo; market is enormous and has produced some of Silicon Valley&rsquo;s biggest success stories. But the reality is that innovation has been stagnant for a very long time. We&rsquo;re still using primitive tools that have remained the same for many decades.&nbsp;
Yes, they have slicker UI and more granular features, but the foundational structure of these products has barely changed. Slack is effectively the same as Internet Relay Chat from the 1980s. Microsoft Word&rsquo;s original incarnation in 1983 looks remarkably similar to today&rsquo;s. Dropbox is an online version of the same file manager that&rsquo;s existed for almost forty years.&nbsp;
The consequence of this stagnation is that the productivity software we use doesn&rsquo;t actually make us more productive. It has failed in its promise. This is largely due to the fact that while the products themselves haven&rsquo;t really changed, their scale has increased massively, often by ten or even one-hundred times. Suddenly, you have 5,000 or 10,000 person organizations using software that was initially designed by a small team for another small team. The ergonomics don&rsquo;t fit and it starts to break.&nbsp;&nbsp;
Qatalog is different because we set out to solve this challenge from day-one. Our goal was always to build something that considers how organizations actually function at scale and help them to operate and collaborate efficiently.&nbsp;
Why have you thought about the problem differently, do you think?
Perhaps it&rsquo;s just a difference of perspective. I am a trained architect and I specialized in large technical and transport buildings. I&rsquo;ve worked on designs for an airport terminal for 60 million people annually and a $400m large scale cancer research center. My mentor was Charles Correa, who designed these buildings, and the experience was transformational.&nbsp;&nbsp;
When designing these types of buildings, you always have to think about how many people are going to be in that space. Take the airport terminal, which might have more than 200,000 people using it on some days. With that many people, you need corridors of a certain width, a certain number of toilets, check in counters, gates, runways, and so on. If you don&rsquo;t get one of these right, everything falls apart. Thankfully, we know what works, because these are analog-native solutions that have been iterated on, tried and tested over decades and sometimes centuries.&nbsp;
But when it comes to the workplace in the digitally native world, engineers and designers are still figuring out what works at scale, and you need to think from first principles to deliver an experience that&rsquo;s new.&nbsp;
Have we built true digitally native solutions in any other industries?
Yes. Tinder, Airbnb and Uber are examples of great digitally native solutions. They all work by leveraging economies of choice and scale that just cannot be replicated offline. You can&rsquo;t meet 100 people in 10 minutes as you can on Tinder, you&rsquo;ll never have a friend with a spare room in every city, as you can on Airbnb, and you cannot connect to every taxi driver within a mile radius as you can on Uber. These are all entirely new possibilities enabled by the digital paradigm, rather than skeuomorphic digital solutions to an analog problem.&nbsp;
And how does this compare to Qatalog and work software?
When you look at work software today, most are first order solutions to collaborating online, addressing a single use case. Notion for documentation, Asana for task management, Slack for messaging, and so on. This generation of software does not understand who each person is in a chat, document or file. It doesn&rsquo;t know which teams they&rsquo;re on, what projects they&rsquo;re part of, or what their objectives are. Nor does it have any metadata meaningful enough to automate lots of the manual work around their jobs.
At Qatalog, we&rsquo;ve rebuilt the organization itself, along with its people, its teams, and projects, and made it digitally native, whilst allowing information to flow naturally between these entities. This allows it to understand intentions, objectives, and org-charts, and it has the necessary metadata to automate a lot of the grunt work.&nbsp;
Taking a step back, how did you go from being an architect to a founder of a software company?
Software was actually my first passion. I was born in India and started coding when I was around six years old. We later moved to Saudi Arabia for my father&rsquo;s work, which led me to start my first business when I was twelve. He was a photocopier salesman who sold computers on the side and I would talk to his clients about their computer problems and build them software for managing databases with Microsoft Access.&nbsp;
My second business came a bit later, when I was around 17. By this point I had moved back to India to focus more on my education. It was a software consultancy that advised on complex system design, covering everything from large-scale booking systems, websites to building bespoke technical software. That was when I first started to think seriously about how to build software for scale, and it also gave me a taste for business.
Given all of that, what made you decide to study architecture?
People ask me this a lot. While I loved coding and computer science, I had taught myself so much outside of formal education, and I knew that would continue without a formal setup. Architecture was a brand new challenge that combined lots of the engineering and design problems that I love about computer science. It also gave me a new creative outlet for my interest in software.
In those days it was also quite rare to design buildings using software and by the time I graduated I had won two national architecture awards. All of this helped to open doors that would normally have been closed to someone of my age. That was how I landed my role with Charles Correa, who is credited with the creation of modern architecture in post-independence India. He was my mentor, and we worked on some iconic projects all over the world, such as the <a href="https://www.fchampalimaud.org/champalimaud-foundation/champalimaud-centre" rel="follow noopener" target="_blank">Champalimaud Center</a> in Lisbon, the <a href="https://www.dezeen.com/2015/06/04/charles-correa-completes-crystalline-islamic-centre-ismaili-toronto-aga-khan-museum-canada/" rel="follow noopener" target="_blank">Ismaili Center </a>in Toronto, the Mahindra Research Valley in Chennai and a bunch of other projects.
And so why didn&rsquo;t you continue on that career path?
I had never really moved away from software, and I found myself wanting to focus more of my time on it. It takes years for blueprints to become a building, and there&rsquo;s something magical about writing lines of code and seeing the result in a matter of seconds. I was still doing some software consultancy on the side so, when one of my clients asked me to come to Oxford (UK) and work on projects to find new IP applications for NASA, I made the leap.
What came next?
In 2014, I joined Transferwise (now Wise), leading the Product &amp; Engineering teams responsible for driving new users. I eventually got on Amazon&rsquo;s radar and they invited me to work on similar projects, but on a global scale. I worked on projects spanning Prime, Prime Video, Alexa and Twitch with hundreds of colleagues in teams stretched across 32 different floors and 17 different countries.&nbsp;
Work was about as disjointed as it could get. The Alexa organization alone was around 8,000 people, with all kinds of dependencies on the Video organization of another 4,000 people. I started to notice valuable nodes sticking out between the two teams that would fail to connect. Despite Amazon&rsquo;s incredible documentation culture, there was nothing that could bring everything, from internal wikis, to messages, teams, initiatives, together in one place.&nbsp;
And this was when the idea for Qatalog was planted?
Yes. Everywhere you looked, there was the same fundamental flaw in the modern workplace. The design was messy, the system was breaking, there were huge inconsistencies from team to team. A lot of these costs were paid by employing more humans, incurring more manual effort to make it all work together. Work was not working, and the architect in me was screaming. This was a valuable ergonomic problem, and there had to be a systemic solution. That&rsquo;s when I saw the potential to create something that tied all of this together into a single source of truth. The day after I got my permanent residency in the UK in 2019, I left Amazon to start Qatalog.

Blueprints for a new way of work. Qatalog founder and CEO, Tariq Rauf tells us  about his journey from architecture into software.

The story of Qatalog and its founder & CEO, Tariq Rauf

Blueprints for a new way of work. The story behind Qatalog and its founder, Tariq Rauf.

Too much noise in your org?

Qatalog posts reach the right people at the right time.

Sarah needs to catch up on...everything

Be more connected without more meetings or messages. Share updates in the right channels automatically.

post

ˈpoʊst / noun

It’s time for a new way of work

See what’s important

Search across your tools

Centralize projects

Align on goals

Automate processes

Build belonging

Unlock your work potential

More from Qatalog

The unholy trinity of work tools

DesignOps in the new world of work

The story of Qatalog and its founder, Tariq Rauf