Stats vs. Surveillance: Is Jira Breaking Your Team’s Psychological Safety?

Recently, Nvidia AI released a real-time tool that adjusts live video of faces so that the subject is always - always - looking directly at the camera. Intended for use in video chat, it quickly became used for comedy. It’s particularly hilarious because the feeling of someone looking directly at you, observing you, is intense. Sometimes it’s engaging, sometimes it’s unsettling, and the difference between those is usually what you think is the intention of the person observing you.

More to the point: when I was an individual software developer, I always wanted to know everything about what my systems were doing. I wanted to be able to spot hotspots, logic errors, to know what my code was doing in production, and to know what customers were doing with it. I wanted to know how it interacted with other parts of other systems. Truth be told, I just wanted to see my work live, out there in the world doing what I hoped it would do.

As I moved into leadership roles, I learned that I’m not alone - product development leaders at all levels want the same insight into the way our systems work, be that technical or human. 

The difference between technical and human is important, of course, because our human colleagues know we’re watching, and whether that feels engaging or unsettling - if it feels like clarity or surveillance - depends on their perception of your intentions as a leader and the incentives of the environment you build around them. Below are a few thoughts to avoid some of the pitfalls that can create misalignment, friction, and distrust in your team and undermine your culture and therefore your mission.

Don’t Mistake Measuring What’s Easy for What’s Important

As a good technical leader, you know that a tool should give you actionable information, so it’s critical that you’re clear and honest about what actions or decisions that information will drive. This is harder than it sounds. So what I do is start with that, then work backwards to figure out what I need to know in order to take that action in alignment with the values of the organization I’m trying to build. 

If I didn’t start with that, it would be easy to mistake what’s easy to measure for what’s important to measure. Some team members will fear the impact on their working lives - maybe even their employment - of decisions made based on the imperfect and reductive logic of a few metrics. Without your transparent explanation of what the purpose of these metrics are, it could ruin the psychological safety in your team, slowing their progress and hampering real innovation. 

Without that trust, your team can’t really buy into the company’s mission, can’t really commit, and therefore can’t be held accountable for the results you hired them to make in the first place. 

Even if the decisions you want to drive do impact your colleagues’ jobs, by setting a high standard of effectiveness that everyone in your team needs to meet, do the work of clearly and honestly articulating to yourself and to your team what you want to achieve and how the information you seek will support your goals.

Shortcut vs. Jira: Cross-Functional Teams vs. Managerial Control

When Shortcut was founded (as Clubhouse, our original name), we wanted to build an alternative to Atlassian Jira, a system that all of us had used - and all of us hated. Jira was released so long ago it’s old enough to drink in the USA, and its philosophy comes from the challenges and thinking of the 1990s, when the companies who could afford to invest in a system like Jira were large - which means political, which means they lacked trust in each other. 

At the time, Jira was a fantastic technical advance that helped smooth and clarify bureaucratic tangles of project management, but today our thinking has evolved - Shortcut represents that evolution of thinking - that aligned and cross-functional teams can use it to work together seamlessly in one place, but I’ll write more about that another time, in another post. 

When you boil it down, Jira’s big idea was to use a database to control how a project is allowed to proceed. Engineers (who don’t subvert Jira’s controls, as many do) are required to move issues through a specific workflow, or they can’t get their work done, or at least they can’t get credit from the system that they did so. 

The metrics Jira provides makes it easier for managers to see the latencies and throughput of moving work tickets through the workflow states. Many managers used those metrics to define effectiveness in their organization: a good engineer gets their work ticket done quickly, and a good team leader’s team closes many tickets in a given amount of time. 

This incentivizes the advice one of my first engineering managers gave me: “Here, we do the minimum” - unlike Shortcut, Jira doesn’t really help you get the right work done, and of course its solution is to stall work until specific people sign off on it. Now there are people who are incentivized to do the minimum to get their tickets closed, and they have colleagues who are incentivized to block work unless it’s perfect. 

My advice probably seems obvious by this point: the tools you choose are part of the working environment that needs to align everyone involved in product development towards the results you need. Choose them and use them wisely.

If you're looking for a Jira alternative, there are a few ways to try Shortcut with minimal disruption to your organization.

Our new Jira Sync allows you to pull in your data from Jira so you can give Shortcut a try by running a sprint or small project. Check out the video to learn more.

Try Shortcut for Free

A project management tool like Jira that tries to do everything ends up doing nothing. Shortcut features straightforward configuration, an easier learning curve, two-way integrations, strong reporting capability, improved roadmapping and ease of collaborating across teams. Start your free trial today and escape the Jiratation - especially now that you can sync your existing work in Jira with Shortcut. 

‍