The next evolution of KATA has arrived, our whole team and I are incredibly excited to share our Teams launch with you! 🚀

Our mission at KATA is simple, to get organizations out of the way of their builders. We do this by fixing the noise and toil in software development: reporting burdens, priority misalignments, out-of-date rituals, and siloed information.

And KATA Teams does this at the most important part of any tech company - it’s engineering team.

But what gets in the way of teams?

Well if you’re like us, you love trying new tools. But how many tools do you have to use on a daily basis to get the information you need just to do your job? Information silos anyone…

And then come the meetings to fill in the gaps. How many “quick syncs” get thrown on your calendar or 1:1’s that turn into update sessions?

When was the last time your team standup actually took 15 minutes? We have to make sure to get out every little detail because how else would people know what we’ve been up to. There’s no better way to stay in-sync so we force a mandatory meeting we end up zoning out in, and we get to repeat it tomorrow!

And do we even need to say anything more about Slack?! We’ve already tamed the chaos on engineering projects, and starting today we’re bringing that same streamlined goodness to engineering teams!

• All your team’s tool activity, all in one self-updating dashboard so there’s no more hunting around to figure out who’s doing what.
• Automatically generated standup updates to streamline your stand ups (and dare we say even start to cancel some).
• Automatically summarized Slack threads, available on-demand.
• A team demo feed (that people can actually find!) so you have a progress highlight reel to extend visibility to the rest of your company.
• No more writing team update emails, KATA AI will draft it for you from all of the work your team is doing day-to-day. And the best part, it only takes minutes to set up, with zero maintenance or coordination required. Connect your tools, create your team and KATA will take it from there.

Oh and did we mention it’s FREE with no seat or usage caps! KATA Teams will help with individual teams, and as you scale and your work gets more complex we’re there for you with KATA Projects (and KATA Groups after that for initiatives and goals).

KATA isn’t yet another project management tool, or standup bot, or some other existing category (or micro-category) thing. We’re building across categories to reflect how work actually gets done in modern engineering teams! It’s the tool we wished we all had in our former lives, but couldn’t find, so we decided to build it. And we’re just getting started. So please check it out and send us your feedback and feature requests.

We hope you join us on this journey, and enjoy a more modern way of working!

Cheers to the builders 🛠️, The Team at KATA

Make more time for meetings. Wait…. what?! Yeah you heard me, you need more meetings and you need to make time for them. And while you’re at it, write longer emails too please. And more docs, that’d be great. Thanks!

Seems antithetical in this era of teams being squeezed to the breaking point for efficiency, headcount reduction, more distributed than ever, and being told they need to figure out how to actually get MORE done than before. Then Shopify publicly canceling all meetings and people riding that bandwagon. But as a recovering engineering middle-manager I want to let you in on a little secret. Meetings aren’t bad. They are great in fact. They’re just used really poorly by default in most organizations.

A duel of words… people love working sessions. We have a hard problem to solve, let’s lock ourselves in a room and not come out until we’ve solved it. It’s fun, we’re accomplishing something together! But meetings? Nah, that’s the let’s listen to Bob run through the 32 slides we’ve already read on content we know, or let’s all go around the room and give our update while everyone zone’s out until it’s their turn. Finished our agenda early? Doesn’t mean the meeting is over, it’s scheduled for another 27 minutes. At least it’s usually Zoom now so you can get some laundry done during it.

The crux of the problem is that fast-moving engineering teams have a really hard time staying in-sync whenever you have more than a small team working on something. So we resort to expensive human time to force it, at the risk of being misaligned and inefficient. It’s hard to trust without the verify. And we don’t question it because that’s how it’s always been. Daily standups for engineers, weekly status meetings for managers, monthly business reviews, quarterly OKR reviews, yearly or worse planning sessions. I always chuckle at the adage “Plans are useless, planning is priceless”.

It’s part human problem, and part accepted cost of doing business. Which is terribly ironic given we’re the part of the organization that builds innovation and new efficiencies for everyone else!

So what’s the solve?

Make more time for meetings, the good kind. By canceling the bad kind, recurring update ones. Hard to schedule a working session when you’re triple-booked 3 weeks out. Write more i.e. more async. Random Idea: I think a calendar tool that made you write an explanation to your boss anytime you made a meeting recur would go a long way to improving eng org efficiency.

How do you cancel recurring meetings and work more async? Adopt a system where you don’t need to have a recurring meeting to stay in-sync and move things forward. Something that can extract the signal and make sense of all the noise across all of the tools. Save the time for actual collaborative working sessions not updating or information hunting. Shopify has one, they built it out of necessity. Most other iconic companies do too, they realized they needed it along the way, that’s a big part of how they scaled. And if you’re not in a place where you can build your own, we built one for you. We think it’s pretty good and would love for you to try it out, it’s called KATA.

And if you lead a bunch of people and this sounds a little scary to you, just know that NVidia, the most recent company to hit a $1T market cap, doesn’t have status updates, and the CEO doesn’t do 1:1’s. They have a clear system for seeing progress that he stochastically samples and progress is clear to everyone. If they can do it, so can you!

So here’s to getting back to building. Meetings are dead, long live meetings!

It's well documented that the pandemic-induced remote work trend has led to globally distributed teams working more asynchronously than ever before. Less well understood is the impact this has had on the way engineering teams operate, taking something that was already quite difficult - staying aligned across fast moving, autonomous software development teams - almost unmanageable in many cases. Despite having more tools, teams, metrics, and frameworks at their disposal to help teams go faster, somehow it’s getting slower to build and ship products.

In today’s business climate, execs are asking their engineering leaders and managers to meet the same business, technical, and quality objectives with fewer resources, tools and support roles. This “do more with less” mandate puts intense pressure on the middle layer of engineering management. Their teams, more async and distributed than ever, have doubled in size while supporting resources have been cut in half. So bogged down by the time required just to maintain visibility into what’s going on that there is no time for anything else.

Stop for a minute and add up all the time and energy that engineering managers spend tactically gathering the intel they need to triage issues and manage their teams. Think about the tedious work required to stay on top of how a project and teams are doing, identifying friction, and taking action. Days are wasted chasing down project updates, scheduling meetings, bugging engineers, and sorting through Jira tickets and GitHub PRs to figure out where the bottlenecks are. Buried in the trivial details crowds out the time needed to ideate, plan for, and push through high-impact initiatives.

Now consider the impact it would have on engineering managers to keep them focused on execution and strategy. Or consider the costs if you don’t. Organizations that don't find process and execution leverage for their leaders will become ever more reactive, slowly losing talented managers that get burnt out spending all their time managing information and not enough time driving execution.

Imagine if you had all the information and insights at your fingertips to debug the execution of projects and team in minutes without the unnecessary meetings, ceremonies, disruptions, and tools previously required to get it. You’d get to spend less time managing coordination, alignment, and status across projects and teams, and more time keeping them moving forward by resolving issues, mitigating risks, and accelerating decision timelines. As a more proactive manager with a more productive and collaborative team, you'd effectively unlock a new gear.

This is where KATA can help engineering leaders & managers by putting the focus back on execution. KATA is the leading Engineering Execution Platform, equipping managers with the just-in-time insights to debug progress across engineering projects and teams. All the intel you need to help your team go faster is never more than a click away. Go as wide or deep as you need, whenever you need to, absent the unnecessary meetings, ceremonies, disruptions, and tools.

Interested in seeing how KATA can generate the leverage you need to unlock a new gear for you and your team? Take a product tour to find out: https://www.getkata.com/product-tour

Practically daily we hear from engineering leaders that are scrutinizing their investments to find ways to “do more with less.” This statement affectionately translates to “If you can’t help my team operate more efficiently, I am not interested at the moment.” Ironically, there might be no better place to look for leverage than the existing tools, time, and process required to effectively run their teams.

Up till now, organizations have accepted the institutionalized visibility/coordination/alignment/status overhead that builds up over time as a cost of doing business. The abundance of available resources to throw the problem, coupled with the absence of an obviously better solution, have historically made doing nothing the default choice. But with the current business climate, combined with the rapidly evolving nature of how and where teams work, it is becoming abundantly clear that the “do more with less” mandate can’t be achieved by doing nothing.

While it’s easy to go straight into debating which tools can solve the problem, they are just a means to an end. It’s more constructive to first step back and identify the end state engineering leaders are trying to achieve and then determine which tools are best suited to help them get there. So let's do that.

An engineering manager's main goal is to maximize business value by shipping high quality software as quickly and efficiently as possible in support of organizational objectives. In meeting this objective their time is spent surfacing and resolving points of friction that get in the way. Their days are spent keeping the team focused, advancing decisions, fixing communication issues, clearing blockers, and mitigating risks, while continually driving software platform optimizations, reducing QA & release times, working down technical debt, and improving team productivity. Said another way, keeping teams running requires constantly optimizing their ability to get things done faster and more efficiently. This debugging of execution is not dissimilar to a software engineer debugging code.

When debugging code, you have a set of known inputs and you're trying to arrive at a set of known outputs. During execution, side effects arise that change the outputs in unexpected ways. This is where debugging comes in - allowing you to trace through every line of code, see what's happening in real time, and identify the fix. Applying this concept to execution in engineering, you have known inputs of a number of engineers, and time. The outputs are the things that need to be built. The side effects are operational issues, technical debt, unanticipated dependencies, poor planning, etc. Debugging in this world means being able to get into the weeds at any point and clearly see what's going on in order to react to it.

Historically, in order to get the visibility needed to properly debug execution and take action to alleviate it, leaders have resorted to some costly combination of people, ceremonies, meetings, spreadsheets, and project management tools. The tools were relied upon to capture the outputs generated from the other four resources. But the tools outputs were only as good as the inputs and tracking down all the activity and progress indicators requires a lot of heavy lifting and constant nagging that no one enjoys. And more often than engineers fail to consistently report what they’re doing so the information and metrics that end up in these tools are either inaccurate or the guesswork of PMs and EMs.

For years Engineering Managers have brute forced their way around shortcomings of this approach with a few different tactics. One path is they choose to effectively operate as a full-time project manager, spending way too much time in spreadsheets, sending status pings, attending check-in meetings, and rummaging through tools in order to provide an indication of how things are going. Alternatively, they delegate the responsibility to their most process oriented senior manager, or they hire some combination of Product Operations, TPMs, Release Managers and/or Delivery Managers to do it for them.

Regardless of the method, the goal of the engineering manager is to get the intel needed to debug the progress of their teams and the project they're working on. But the current cost and impact on the team is WAY too high and the information gathered quickly becomes stale. As projects, and the teams working on them, get further dispersed across locations, time zones, and tools, the situation only gets worse. Yet the solutions have remained unchanged.

In order to actually “do more with less”, leaders can no longer no longer afford to waste money and time trying to bandaid over the shortcomings of products that were designed for a different era.

Interested to experience what it’s like to actually “do more with less"?

Explore KATA: https://www.getkata.com/product-tour

We're clearly in a consolidation phase in engineering. Almost all of the product and engineering teams we speak with are scrutinizing their existing tool stack and trying to figure out how to use less. They certainly aren't trying to introduce new ones. The words most often used to describe the internal initiatives related to tooling are streamline, consolidate, and unify.

While it's easy to get caught up debating which tools should win out, the more important question is, what's the end game? No engineering leader we've spoken with has ever said their goal is to use more or less tools. Instead, their objective is some combination of keeping the team focused, moving fast in the right direction, and shipping killer products.

Once a clear business objective is established, a leader's time is best spent surfacing friction across supporting projects and taking action to resolve them. These are things like identifying critical decisions and moving them forward, clearing blockers, and mitigating risks. Said another way, they're debugging projects like developers debug code.

Historically, teams have resorted to some costly combination of tools, people, and meetings to get the project visibility needed to identify friction and take action to alleviate it. This explains why, up till now, we've called it project MANAGEMENT instead of project debugging. The management part was unavoidable. The tool's outputs were only as good as the time and meetings spent to make them useful.

So, for years, Engineering Managers, Product Operations, Project Owners, TPMs, and/or Delivery Managers have deadlifted their way past the shortcomings of the existing solutions. They waste time in check-in meetings, sending status pings, and rummaging through tools to get an indication of how things are going. The pattern repeats itself as many times as necessary to keep projects moving forward. However, in today's business climate, combined with the rapidly evolving nature of how and where work gets done, resource-constrained engineering teams can no longer afford to waste time and money closing an information gap created by tools designed for a different era.

With KATA, we've built an offramp from the project management treadmill. Fast-moving engineering organizations can simultaneously offload the project management burden while equipping leaders and their teams with the insights they need to swiftly debug, take action, and move projects forward faster.

Returning to where we started this post, and given the approach we've taken with KATA, we're all for the discussion about streamlining, consolidating, and unifying tools. As is, the existing options for project management have plenty of attack surface. It gets even wider when you stop for a minute and add up all the time and energy wasted on project management. Think about how it would impact your team to be able to refocus everyone on project execution.

Interested to see what project debugging looks like in action? Check out our KATA interactive demo series.

What if the nature of information flows out of Engineering to the rest of the organization looked less like a moat and more like a bridge?

For better or worse, Sales has tangible signs of progress that they can point to on their way toward a goal. They close deals all quarter and hit their number. Each deal and the % of achievement vs. plan are the clear mile markers. It’s pretty easy for everyone to follow along with how well, or not, things are going.

Engineering teams don’t have the same luxury. Progress and outcomes from key projects are more difficult to measure and don’t cleanly translate into language that most everyone across the company understands like a major deal closed or attainment of some bookings target.

The current industry response has been to try and measure productivity metrics in engineering like tasks, issues, cycle times, tickets closed and to pull requests. While these activity measures might tell you something about speed, they tell you nothing about quality or progress toward outcomes. And they certainly aren’t delivered in a language that the rest of the business understands. 

What if we made it dead simple for engineering teams to mark & communicate progress on their work and contextualize it within key projects, milestones and deliverables that everyone across the business can understand?

A really easy way to do this today is demos. Demos are the fastest way to show progress on something. Loom has made it really easy to create and share quick demos so that everyone can see how something is going. 

Now just imagine if those demos could be recorded anywhere and housed centrally inside of the projects they support? Think of it like a highlight reel or SportsCenter Top 10 Plays of the Week for the work being done across key projects and initiatives.

Making these tangible checkpoints and mile markers available for anyone that is interested in the status of key projects might go a long way toward converting that moat into a bridge.

We've been busy stacking bricks. When you're heads down building, it can be easy to forget to pause occasionally and take stock of your progress.

Today is a good day to do just that. We just pushed out a huge KATA release. It's the culmination of a lot of learning from our customers and work from the team. Over the past 6 months, we've been engaged with the first wave of customers through our Early Access Program. They've taught us a lot about the challenges engineering teams face with their existing approach to project management, how they work, and how they want KATA to work for them.

With traditional project management tools, the value you get out of them depends entirely on what information you manually feed into them. But tracking down all the activity and progress indicators requires a lot of heavy lifting and constant nagging that no one enjoys. With this release, KATA flips the script. We're completely modernizing project management by empowering project managers and the engineering teams they support, not the other way around.

The highlights of this release are defined by our interactions with customers throughout the Early Access Program; accelerated onboarding, tighter Jira integration, automated status updates, streamlined IC check-ins, and flexible project organization and grouping.

With these additions, KATA is fully equipped to offload all the project management grunt work so engineering teams can focus on the important stuff, like making decisions, removing blockers, mitigating risks, and shipping killer products. Say goodbye to the never-ending cycle of disruptions, check-in meetings, pings, and the writing and rewriting status updates. KATA is the single source of truth for efficiently tracking, translating, and communicating what's going on at any level of an engineering organization (Watch product trailer).

One of my favorite startup quotes is, "If you're not embarrassed by how naive you were six months ago, then you're not learning fast enough."* Looking back on the last 6 months here, KATA is practically unrecognizable from where it was. The same can be said for our messaging. Our website is on its 4th iteration since I joined, with each rev progressively tighter. So while I'm sufficiently humbled when looking back on where we've come from, it's more than offset by how proud I am of where we are today.

With each assumption we've invalidated, every mistake we've corrected, every deck we've tweaked, every ticket we've opened, every hole we've closed, and every feature we've shipped, we've gotten better. Add it all up, and we're 100x better than we were but still 100x short of where we need to go. At this stage of the company and product, that feels like exactly the right place to be.

Guess it's time to get back to stacking bricks.

Interested in seeing what KATA can do for you and your team? Sign up here.

*Footnote - While I’ve seen versions of this quote attributed to different people over the years, I can't track down the original source. It often gets confused with Reid Hoffman’s quote, “If you are not embarrassed by the first version of your product, you’ve launched too late.”

“As a leader, KATA makes me look like a superhuman — I am able to effortlessly know what’s going on with every project by consuming updates and key decisions for the projects that matter right from within Slack. I don’t need to have been at the meeting to feel like I was, and I don’t have to waste time in 1:1s getting updates. Instead I spend time with my team on problem solving and strategizing.”

Lynette Pretorius, VP of Ops at Carbon6

Carbon6 came to DreamTeam seeking three things from their evaluation of the KATA platform

1. Create a central place for teams to collaborate across departments
2. Build and maintain internal context and knowledge in one place
3. Allow teams to stay within the workflows they are familiar with

Recently we asked Lynette about her experience, spanning from how she chose KATA to the benefits it has brought her and others across the organization.

There are so many project management tools out there. How did you settle on KATA?

Trying to select a project management tool, I was dragging my feet - all the options were similar in functionality, similarly priced, and only alright. The steep learning curve turned me off from the more robust options out there in the market. Then KATA came along and I knew it was exactly what I wished existed - a simple and intuitive interface without the unnecessary complications, but with all the right integrations to our existing tools and workflows. Plus, KATA has a totally fresh approach to managing projects and hit on something no other tool did: creating a repository of context that will, over time, allow anyone to onboard more quickly and equip every employee to work smarter by learning from the projects that came before. We’ve never looked back on our choice to adopt KATA.

How did you do things before and how has KATA made them better?

My KATA aha moment was seeing a new hire onboard at Carbon6. In one of his initial meetings he referenced relevant context about a project — when I asked, surprised, where he came across that document, he said “Oh, I found it in the KATA project.” This is exactly why we adopted KATA - to create a hub of context and alignment across our organization that will span across projects and teams to allow everyone to easily stay on the same page.

Tool change can be hard. How easy was it to adopt KATA inside your organization?

Other project management tools have a high barrier of adoption — they don’t seem to understand that for non-project managers, expecting adoption of a tool that is completely outside existing workflows with a steep learning curve is doomed before it starts. KATA is easy to start using as a viewer or builder, and allows everyone in our company to quickly view and access context with single sign-on. Plus, it fits and integrates with the tools everyone already uses, making the product stick easily.

What process overhead or waste have you been able to eliminate with KATA?

As a leader, KATA makes me look like a superhuman — I am able to effortlessly know what’s going on with every project by consuming updates and key decisions for the projects that matter right from within Slack. I don’t need to have been at the meeting to feel like I was, and I don’t have to waste time in 1:1s getting updates. Instead I spend time with my team on problem solving and strategizing.

How has KATA helped increase visibility for key stakeholders at Carbon6?

After recently sending out a bunch of updates via KATA, I saw our CFO remark to someone in a different Slack channel about the great work they were doing on a project. Note that our CFO isn’t personally a KATA user, but he is clearly still benefiting from the visibility the updates provide him in Slack. There is no other world in which a CFO would have been able to say this if we weren’t using KATA and automatically pushing updates out through Slack. This has happened multiple times with executive stakeholders – the visibility KATA creates is unparalleled.

In the current macro climate, the mandate to engineering teams is clear, do more with less. Leaders are under significant pressure to maintain, if not increase, performance while simultaneously cutting costs. This leaves them canvassing their tools and teams to identify opportunities for operating leverage. One area that deserves real scrutiny is the bloated engineering project management stack. Teams can no longer afford to waste money and time trying to bandaid over the shortcomings of products that were designed for a different era.

In 2023, a modern project management platform should demand less time/energy from the organization to do its job so the team has more time to do theirs. It should automate all the coordination, alignment, and status update overhead that's built up in your organization so the team can spend more time building and shipping killer products. Stated simply, Less is More.

Concretely, for project owners, project managers, ICs, and leaders, this means a modern project management platform that enables…

Less check-in meetings

Less disruptions to provide status

Less time spent writing status updates

Less tool-induced information silos

Less licenses (needing visibility into what's going on shouldn't require a license to every tool)

Less people to coordinate, manage, update, and communicate all of the above

More time (and money) for building

In a perfect world, project management tools are supposed to efficiently communicate (across various mediums) what's going on with a particular individual, project, or team. The idea is that if everyone can efficiently stay aligned with what's happening and why without slowing down, the collective group can move faster. They quietly wrangle all the information that informs what's going on into some consistent and accessible format that can be updated and shared on-demand. But the current state of engineering project management tools is far from perfect.

How did we end up here?

• Tool Sprawl. Teams are still suffering indigestion from the SaaS sprawl of the last few years. With so many different tools deployed across the organization, extracting a singular view of what's happening is nearly impossible. Every team has their preferred set of tools. Rarely do tools span departments. If you want to know what's going on outside of your team, you need a person to help chase down status for you or a license to dig in and do it yourself. In the latter case, you probably don't have the time or expertise to efficiently navigate the tool to find what you are looking for. Never mind that provisioning a license to you for this purpose is not a good use of money. Nevertheless, it's faster to provision someone a seat and wish them well than it is to track down the information they really need and convert it to a format they understand. So here we are.
• Team Sprawl. It's well documented that the pandemic-induced remote work trend has led to globally distributed teams working more asynchronously than ever before. Less well understood is the challenge of keeping an organization coordinated, aligned, and moving fast amidst this transformation. Armed with project management tools designed for a different era, the people responsible for helping everyone stay on top of what was happening were ill-equipped to do so. 

The organizational response to the above dynamics has been to build out teams, acquire more tools, and establish a series of rituals, processes, and meetings to manually close the information gaps. And while everyone now has a project management tool, they still can’t easily answer the most frequently asked question of a project or initiative, “How’s it going?”

The bar is clearly higher these days for which tools make their way into the engineering toolbox, although, given the dynamics above, it seems that it’s not high enough for project management.

Interested in demanding less (overhead) from your project management platform? Sign up to evaluate KATA, and free up your team to get back to building.

Technical project managers (TPMs) get a bad rap. Below is a collection of engineers favorite "pings" they receive from TPMs on a daily basis.

• How far along are you?
• What % done is it?
• Can you update the spreadsheet?
• Do you have a new date?
• When can you get this finished?
• Can you push the date up?
• Can we jump on a call?
• "You got a quick minute?"
• Please edit the three spreadsheets that are somewhere in one of 100 teams chats I told everyone about 6 weeks ago when you were on holiday even though we have a ticket system and confluence.

As evidenced above, PMs take a lot of flack from engineers. But continuously tracking, communicating, and updating the status of a project across a large and fast-moving team is hard…and it's not getting any easier. The rapidly evolving nature of work has resulted in engineering teams that are more distributed, asynchronous, autonomous, and resource constrained. Individually these are each meaningful shifts in how work gets done. Collectively their impact is seismic, yet the tools used to help teams stay coordinated and aligned have barely changed. So it's no wonder PMs have struggled to keep up. They've been showing up to the project management knife fight with a squirt gun.

With traditional project management tools, the value you can get out of them depends entirely on what information you manually feed into them. But tracking down all the activity and progress indicators requires a lot of heavy lifting and constant nagging (which no PM enjoys). So, to keep the inputs fresh, they default to the dreaded triple crown of status management; check-in meetings, slack pings, and spreadsheets. The collective goal of these rituals is to get the information you need to communicate status on demand. But unfortunately, the information gathered quickly becomes stale, triggering another cycle. Wash, rinse, repeat.

There needs to be a better way. Project management software should empower PMs and the engineering teams they support, not the other way around. Imagine a modernized approach designed for the realities of today's engineering organizations. Imagine a platform that takes care of the grunt work so a PM can free up to focus on the good stuff, like making decisions, removing blockers, mitigating risks, and shipping killer products. Imagine a super-assistant that automatically collects and curates all project activity data, artifacts, and critical events (demos, decisions, etc.) into a central dashboard for you. Imagine a single source of truth for communicating what's going on with any project or initiative. The never-ending cycle of disruptions, check-in meetings, and status pings from your PM become a thing of the past. That's modern project management.

So the next time someone starts using PMs as a punching bag, no matter how funny the .gif is, remember, don't hate the player; hate the game. It has been a game they've been set up to lose all along…until now.

Interested in modernizing your project management capabilities? Signup for the KATA Early Access Program.

We often get asked by product & engineering leaders how we define a project. But we've never taken the time to write it down. So recently, I decided to change that, and here's what I came up with:

A project is a series of human, tool, and/or machine-driven inputs and outputs that add up to a specific outcome within some defined constraints (e.g., scope, budget, time).

Unfortunately, when compared to the reality of what we see with our customers, this definition drastically oversimplifies what a project entails. In many ways, it does a disservice to the people that have to manage them by underrepresenting the many variables within a project that need to be continuously monitored, synthesized, and communicated. We should try a different approach. Instead of defining a project generically, let's outline the attributes, challenges, and requirements engineering teams are attempting to solve for as they wire up projects in KATA.

• Projects have a core set of framing attributes, including a summary description, owners, contributors, followers, milestones, action items, and dependencies.
• Projects are usually assigned a name tied to the desired result, though it's the work required to achieve that outcome that defines the project's state at any point in time.
• Projects can be done in person, but increasingly they are worked on by distributed and asynchronous teams.
• Projects are cross-functional. They rarely align cleanly with an org chart. They often span departments, teams, tools, and time zones.
• Projects can vary in size and duration. They are usually a component of a larger organizational objective, like a goal or initiative.
• Projects are often defined by different phases they pass through over the course of their lifecycle. Something like Propose -> Explore -> Execute -> Validate. The names of these phases differ by company.
• Projects have events naturally occurring daily that mark progress. These critical checkpoints are often human-driven inputs like decisions, discussions, demonstrations, check-ins, status updates, risks, and escalations. Unfortunately, they usually get buried in the cracks of various tools, threads, and docs.
• People assigned to projects use various tools to accomplish the work required to complete the project. Similar to events, these tools, and the artifacts produced by them, serve as valuable markers of activity and progress or lack thereof.
• Projects have a status that often needs to be communicated on both a scheduled and ad-hoc basis through different channels (e.g., In-Person, Slack, Email) to various stakeholders, including executives, project teams, and individual contributors.
• Projects are dynamic, moving objects. The distributed, cross-functional, and asynchronous nature of project teams, all working within different tools, makes it challenging to stay on top of what's going on in anything close to "real-time."
• Project history must be preserved. New employees need to catch up quickly. Tribal knowledge on a project should not be lost when a key employee leaves. Rework should be avoided at all costs.
• Just as a project represents the collection of work that defines it, the collective project portfolio effectively represents the company's strategy. Understandably, companies want to scrutinize their project portfolio at different levels - some sort projects by goals or groups, others by initiatives, and others by teams.
• Projects often have named processes (Scaled Agile, SCRUM) or company-by-company protocols for how they should be managed. The former requires multi-week certifications to understand and expensive job roles whose primary function is to enforce them, and the latter often sees slow uptake after failed attempts at tops down process or tool standardization.

While not exhaustive, this is a pretty comprehensive list. Clearly, an attempt at a simple definition trivializes what a project is. They are complex & dynamic work containers, capturing all the contributions required to achieve an outcome against a specific set of constraints. And somehow, we expect project owners and managers to keep track of everything listed above, yet we arm them with a spreadsheet, task management tool, or some retrofitted OKR or roadmap tool. To overcome the limitations of these solutions and get the visibility they need to properly manage projects while continually gathering and communicating status up, down, and across their org, they resort to some costly combination of check-in meetings, ceremonies, and slack pings. Bogged down with this extra process, rework, and double (or triple) entry status "bookkeeping," it's no wonder that teams were seeing TPM team growth outpacing overall engineering. They've been showing up to the proverbial project management knife fight with a squirt gun. In the resource-constrained environment we're operating in now, this is no longer an option.

We have it backward. Project management software should empower the PMs, TPMs, and engineers working on and managing projects, not the other way around. In the context of project management, this requires a modernized approach designed for the realities of today's engineering organizations. In other words, project management without the management. This is what we're building with KATA. It delivers the highest value aspects of project management in a single platform – Automated Updates, Visibility, Human Signal, and Goal Alignment – WITHOUT the tedious overhead required to extract the same information from other tools.

Want to see what modern project management looks like in action? Sign up for the KATA Early Access Program today.

1. How’s it going?
2. Who’s working on it?
3. How can I help?
4. What are the critical discussions to be had & decisions to be made?
5. Why does it matter?

There have never been more tools, metrics, task/activity/issue trackers, performance frameworks, and data at the disposal of engineering leaders, TPMs, and delivery managers, yet when key stakeholders want answers to any of the questions above the most frequent response is “Let me get back to you” followed by a series of slack pings, status check-ins, quick sync meetings, and a frantic search across tools, threads, and artifacts for any indications of progress.

To achieve alignment up, down, and across the team, this ad hoc cycle repeats itself as many times as necessary. More often than not, the task falls to project owners, TPMs, and Delivery Managers to brute force their way past the many shortcomings of their existing project management tools in order to provide answers. Unfortunately, servicing each request is not a write-once-send-to-many operation. It’s often a custom response, manually curated to the unique needs of the individual making the request. Worse yet, the information gets stale fast. And while activity data from various tools can help piece together some indication of where things are at since the last check-in, the truth most often lies in the human context (e.g., decisions, demos, discussions, escalations, etc.) that gets buried in email, slack threads, and documents. 

Complicating things further is the rapidly evolving nature of how and where work gets done. Fast-moving engineering teams are more autonomous, distributed, asynchronous, and in this macro environment, resource-constrained than ever before. Updates are no longer a shoulder tap away…not that anyone liked that tactic anyway. And engineering teams can no longer afford to keep adding TPMs to try and close the information gap caused by project management tools designed for a different era.

As projects, and the people working on them, get further dispersed across a widening combination of locations, time zones, and tools, there needs to be a better way, a modernized approach to project management designed for the realities of today's engineering organizations. In other words, Project Management Without The Management.

Modern project management solutions sit above the activity/issue/task tracking tools you have in place today, combining data and human inputs together to deliver the four highest value aspects of project management in a single platform:

• Automated Status
• Real-Time Visibility
• Critical Human Context
• Goal-Project-Work Alignment

Most importantly, they do it without the tedious coordination overhead required to obtain, maintain, and communicate the same information from other tools, systems, and processes. Less disruptions, check-in meetings, rework, and double entry status bookkeeping.

For the project owners and project managers in your organization including Engineering leaders, Technical Program Management and Delivery teams, a project management tool should be the single source of truth for answering the most frequently asked questions of any project or initiative. Pulling from your preferred tools, including existing project management tools, task managers, and issues trackers, a modern project management platform combines work activity data, artifacts, and critical human context into a central hub of progress that increases visibility, accelerates alignment, and improves decision-making. Best of all, by supercharging your project management capabilities, your engineering team can get back to focusing on what matters most, building better software, faster.

Interested to see what modern product management looks like in action? Sign up for the KATA Early Access Program today.

The title of this post was a statement made to me by an engineering leader this past week. He'd recently adopted a new tool for tracking engineering metrics. And while pleased with the increased insight into things like cycle times, review times, and rework rates, he was still lacking any sense of whether all this work, regardless of how efficiently they did it, was being channeled in the right direction for the business.

Also missing were the critical details about the work being done that get buried in the cracks of various tools, threads, and docs. Here he was referring to the qualitative "checkpoints" that naturally occur in any project, like decisions, demos, discussions, status updates, and blockers. While difficult to quantify, these nuggets of context are absolute gold for anyone trying to understand how the work on a project is really going or for those needing to efficiently "catch up quick" in an async environment.

Every team we speak with struggles to capture and preserve this context centrally because doing so pulls everyone out of their preferred tools or requires the soul-crushing task of double-entry status bookkeeping (i.e., copying and pasting the same information in multiple different places). Absent this central hub of progress, engineering teams implement tactics to surface these details that often cause more harm than good. 

Finally, regardless of the metrics dashboard's usefulness to engineering, they aren't in a format easily consumable by the rest of the business. Still absent is the goal-project-work alignment that remains so elusive for most engineering organizations. This is the missing link to ensure that every layer of the org is running at maximum speed toward the intended business target. Critically, it also helps strengthen the partnership and trust between engineering and the rest of the business by providing visibility into what is often viewed from the outside as a black box.

In our frequent discussions with engineering leaders, we consistently hear slightly different versions of the same story. If you're struggling with these issues, we want to hear from you too. These are the types of challenges we're trying to address with KATA. Now's your chance to get into our Early Access Program and get those feature requests to the top of the pile!

Why is it that despite all the time and money spent to improve visibility, product and engineering leaders, managers, project owners, and ICs still struggle to answer the most frequently asked question of their team; “How’s it going?” The costly combination of tools, spreadsheets, TPMs, status meetings, ceremonies, and slack pings deployed to increase visibility and speed up teams, clearly isn’t working as intended. In fact, in a lot of cases their “visibility” stack is slowing them down with extra process, rework, and double (or triple) entry status “bookkeeping”.

So, what’s the issue? In >100 interactions with product, engineering, and operations leaders over the past 3 months we asked them what they needed to improve about how their org gets work done, makes decisions, and tracks progress toward goals.

I’ve pulled together some of the best responses here:

• We get work done in every way possible on every continent. I need a sensible view of all of it.
• We need a central place for teams to collaborate across departments.
• We want to build and maintain internal context and knowledge in one place.
• Give me a holistic view of all work in progress across teams and how it contributes towards company goals
• Make it easier to have goals, status, progress etc. visible both laterally and vertically
• We want all projects tracked in one place with updates pushed to those who should get them
• Make it crystal-clear and simple to visualize progress without having to update multiple different data sources
• Help engineering work with the rest of the company, and help the rest of the company understand what engineering is working on
• Connect all the tools / work streams / docs / designs for easier access for all teams Provide a single dashboard for reporting that doesn't require viewers to have access to all systems to get detail
• Easily display & communicate progress made within other tools without all stakeholders needing to access all tools
• To be able to see where various teams and individuals are trending towards their goals without slowing them down through manual or meeting-driven status update requests
• Provide visibility for product & engineering leadership into progress of projects while offering freedom, fluidity & flexibility for engineers to manage their tasks and focus on execution
• Have more visibility on work in progress & allow me to send an electric shockwave everytime someone shifts priorities on short notice

From these comments above and other interactions, it’s clear these leaders don’t have the time, and in some cases the licenses or expertise, to Sherlock Holmes their way through all their existing tools in order to stay on top of the work happening in engineering and how it maps to projects and goals.

Similarly none of their IC wants to be constantly barraged with status pings, update meeting invites, or check-in protocols that pull them outside of their preferred tools. With KATA we aim to fill this hole for both leaders and ICs by building the visibility platform for product and engineering teams that helps them go faster. To make sure we get it right, we want to hear more about the challenges you face with your "visibility” stack and how we can deliver a product that gets you more of what you need (visibility) with less of what you don't (overhead). If this tradeoff appeals to you, we want to hear more.

Let's talk.