This blog is not about how Jira is too complex and over-engineered with features I don’t need.

Those complaints are well articulated by others like Justin James, Chief Architect at Cloud Development Resources.

“Jira has *never once made my life as a developer easier or better… It’s overly complicated and the workflow is painful.”*

I completely agree with Justin. He goes on to say…

“Jira is Word when it had the toolbar filled with tiny little icons for formatting only paralegals or scientists or some other specialized author needed. It does 'all this stuff' and none of it is easy or makes sense…”

Again, I agree. Though I think of Jira more like a spreadsheet. Very useful once upon a time. Outdated now. Static. Manual.

But my problems with Jira go much deeper.

Jira has been a part of my life since the moment I started my first developer job in 2007. Over the years I have arrived at the conclusion that Jira contradicts my values as a member of a dev team. It represents a way of thinking and working that goes against my beliefs.

In fact, I think Jira is a microcosm of four of the hardest challenges we face as a software development community.

1. Jira is made for the few, not the many

Justin said “I wish Atlassian would sit down with real-world developers and design this product the way we need it to work.”

This is the root of the issue. Jira was made with project managers and product managers in mind. Not dev teams. Project and product managers (collectively referred to as PMs going forward) are the primary buyers and owners of Jira. Not engineers.

Engineers love simplicity and efficiency. Jira is the polar opposite of that.

The development process is fluid, real-time, and doesn’t always follow a linear path. Jira forces you into a workflow that does not match that reality.

So why do companies use a tool that works for a few PMs and business leaders when dozens or hundreds of engineers hate it?

Two reasons. One, dev teams have control over most of the tools they use in their teams. But the decision about project management software is made by people who don’t understand how engineers think and work. Even though it has a huge effect on our day-to-day work.

The second reason is indicative of the bigger picture problem.

The bigger picture issue: Executives force top-down decision making on dev teams

We work in companies that embrace a mindset of decisions being made by a few people “at the top”. In their world, the planning process is king. The creating process is an afterthought.

The current software delivery process revolves around pushing decisions down to dev teams and forcing engineers to push status updates back up. This system ensures executives are the only ones who have context and can see the bigger picture while engineers do all of the work.

This is backwards. It holds us back from building the best product and slows us down from delivering faster.

Join our mission to end useless status meetings.

Click here for access to the dev team dashboard of the future powered by Git data.

2. Jira is a plan-first tool, not a create-first tool

It makes sense. PM’s, who own Jira, spend a lot of time on ideas, strategy, prioritization, requirements gathering, and preparing for the future. They want a tool that helps them succeed in those areas. Once the iteration starts, PMs shift from being planners to being status communicators. Jira is designed this way. It’s pretty good when you’re in the planning phase and it works well if you’re the PM receiving the status update.

But when we’re in the development phase, it’s bad. If we’re the engineer who has to constantly manually update the status, it’s really bad. We might as well be using a spreadsheet.

Take subtasks, for example. The invention of Jira subtasks is an affront to dev teams. Clearly someone who has never spoken to an engineer on a dev team created it. It’s the least dev-friendly way possible to get insight into what’s happening with a Jira story.

In general, when it comes to running iteration, Jira doesn’t do anything to help dev teams. It does not describe how we work – our efficiency, our quality. And it’s not particularly useful in our ceremonies, our meetings or our interactions. We live elsewhere like in Git and Slack.

Planning is very important. But it’s sort of like the famous Mike Tyson quote… “Everybody has a plan until they get punched in the mouth.” Once development starts, a million micro-decisions are being made every hour and things change quickly. Jira is not set up for this reality.

The problem is, 80% of the people involved in software development spend 80% of their time in the development phase. Far fewer people spend far less time in the planning phase.

So why are we using a plan-first tool to manage the full development lifecycle?

The bigger picture issue: Execs get product strategy but not product development

Business leaders think like PMs, not like engineers. Executives understand ideas, strategy, and prioritization. They’re also familiar with the process and key metrics of sales and marketing. They know the vocabulary and speak the language.

They do not understand software development. They don’t know our terms. When it comes to the dev team, they just want to know “are we on track to deliver feature XYZ by the deadline?”

This is dangerous because it holds them back from understanding our process which holds them back from engaging in intelligent conversations with engineering leaders and teams.

If sales miss their number, the CEO has 100 questions ready to analyze what levers they can pull to right the ship. If the dev team misses a deadline, other than maybe asking “do we need to work more hours?”, all they can do is wait or apply (unhelpful) artificial pressure to finish.

How we work matters. Not just the output.

3. Jira perpetuates synchronous communication, not asynchronous

Jira seems like it should encourage asynchronous communication. But really it does the opposite.

When execs have a meeting with a customer or the sales team, they need information about product delivery timelines and they need it now. They ask the PM and the PM sends you an urgent Slack. Or worse, the PM calls you into a meeting to find out what’s going on. Those interruptions are costly.

Why doesn’t the exec or the PM just look at Jira? Because it’s not up to date. Why? Things change so rapidly that, in order for Jira to be up to date, engineers would need to constantly manually update tickets. One engineering manager told me recently that even teams he’s worked on that really care about Jira hygiene only capture about 60-70% of their real work activity. Most teams are closer to 50%.

Even if Jira was up to date, it’s still missing context.

Execs and PMs want to know:

⇢ When is the bug going to be fixed?
⇢ When is the new feature being delivered?
⇢ What risks could stop us from hitting our date?
⇢ Which features are getting attention right now and which aren’t?
⇢ What % of the team is invested in features versus bugs versus non-functional?

There’s nothing on the Jira board that answers those questions. So they pull you away from deep focus mode to ask you. And it takes you a while to get your focus back. Which slows you down from delivering the thing they want most of all – more features.

The bigger picture issue: Companies run on a “manager’s schedule” not a “maker’s schedule”

Paul Graham, computer programmer and co-founder of Y Combinator, explains the disconnect between the way developers and executives get work done in his 2009 essay Maker’s Schedule, Manager’s Schedule.

Here’s a summary:

⇢ Bosses (managers) get stuff done through meetings – changing tasks every 60 minutes.
⇢ Developers (makers) and other creators need 3-4 hour blocks of time to get work done.
⇢ Each way of working is perfectly fine by itself but problems arise when the two collide.
⇢ For a maker, a single meeting at the wrong time can disrupt their entire day of work.
⇢ Most powerful people are on a manager schedule and they directly or indirectly force the makers in their company, like software engineers, to revolve around the way they work.

I couldn’t agree more. The lack of understanding execs have for the software development process, leads to a lack of empathy for software developers. Companies subject their engineers to the manager’s schedule which disrupts the flow of development.

When engineers point out they could ship more features faster if there were fewer meetings, business leaders hear that as a complaint versus what it really is, a cry for help.

4. Jira creates separation between engineers and PMs

If I had a nickel for every time a PM asked me to clarify or update something in Jira, I would own the Buffalo Bills and travel in a spaceship.

I always feel like Peter from Office Space when his lame boss asks him for the new cover sheet on the TPS report.

The PM + engineer relationship is hard enough to get right as it is. Having that additional tension built-in makes it even harder.

PMs don’t want to bug us. They feel like babysitters. Imagine what they could be doing instead… talking to customers, writing high-quality user stories… or actually spending their time with us on something useful like brainstorming ideas or sharing customer feedback. Instead, a lot of time is spent on status updates and contentious conversations.

Life is too short to use a tool that systematically creates conflict with my co-workers.

The bigger picture issue: Engineering is disconnected from the business

I’m lucky to work at a company where our CEO (Ori Keren) and our COO (me) are software engineers. We ensure everyone in the company understands the development process which helps maintain tight alignment between our dev, marketing, customer success, and sales teams.

I think more start-ups should be led by programmers and more big companies should promote their CTOs to CEO.

In the meantime, we have work to do to create alignment between engineering and business. And I believe in working big problems like this from top-down and bottom-up at the same time.

4 Ideas to solve for Jira and the bigger picture issues

Idea #1: Use Jira for planning, not for managing your development activities

Let’s start bottom up with Jira.

Justin wants to get rid of Jira. “I can’t 'wait' for someone to disrupt Jira and make it go away…”

I know many other developers that feel this way. And countless new project management tools like Clubhouse and Notion and have popped up in recent years to replace Jira.

But here’s the most important thing Justin said in his post… “Developers don’t manage tickets for a living, they write code for a living…” I think that’s why another project management tool is not the answer.

PMs will always need a place to plan. They can continue using Jira or one of the new options for planning and roadmap.

Dev teams need something new that is focused on delivery. That’s what we’ve been working on at LinearB.

LinearB Pulse: Correlating Git and Jira data for greater delivery predictability. Click to get started.

We correlate Jira stories with the associated Git branches and PRs in a single view to update everyone on what’s happening with your features and bugs in real-time. It adapts to the way you work – Scrum, Kanban, Scrumban, custom dev processes, even Waterfall.

Our own dev team has been using it internally for months and there’s a few things they love about it:

We’re seeing 75% fewer interruptions throughout the day because progress on features and bugs is updated automatically with accurate Git data so stakeholders know what’s going on.

Our daily stand-up is more efficient using filters that highlight contributors, blocked work, risks, and dependencies so we get back to work faster.

Stuck work is getting resolved faster because we get alerted in Slack in real-time when devs need help with a branch or PR and anyone can come to the rescue with a single click.

Most importantly, our developers don’t go to Jira anymore during the sprint so we’re getting more time to code.

Sign up now for free.

We would love your feedback.

Idea #2: Empower developers with context

Now let’s work this top down.

My co-founder at LinearB, Ori Keren, always says “There’s a business decision behind every line of code”. At least there should be.

Instead of pushing status updates up to execs so they can push decisions down to dev teams, let’s flip it. Innovative companies give their engineers as much context as possible.

A smart engineering leader I know, Zach Goldberg CTO of GrowFlow, told me “The biggest difference between senior devs and junior devs is that senior devs can foresee the consequences of every action they take. The cascading effects it will have on other devs, other teams, the sprint… they see the big picture.”

So how do we accomplish this? The most impactful action most companies can take right away is to bring developers closer to customers. Here’s how we connect devs to users directly at LinearB.

First, we bring our prospects and customers into Slack. This makes it easy for everyone on the dev team to see and get involved in customer conversations.

Also, a rotating member of our dev team is assigned to work with our customer success and sales teams. They get on calls with customers directly to resolve issues, architect solutions, and talk about new functionality. Customers love it! It doesn’t matter if our engineers aren’t as polished on the phone. Customers care about getting answers. And talking directly to the dev who can literally code the solution to their problem is a great experience. And of course, our devs are the first to hear about real customer problems which help them have input over what they work on.

Idea #3: Teach business leaders the software development process

Nothing will change until executives have empathy for the plight of dev teams. Empathy comes from understanding. So step one is teaching business leaders the language and process of software development.

Execs want to understand. The better they understand the more they can add value. When we have a problem, they can contribute to solutions. Which they want to do. So we can’t use the excuse that they don’t care. I think it’s on us to educate them.

That’s why I think the most important job of the CTO or VP of Dev is to translate engineering to execs. Execs understand data. So show metrics in the staff meeting every week. When they ask for a date, take the extra time to explain the dependencies and variables behind your estimate. Write it down for them. How many non-technical business leaders have ever attended a dev staff meeting? Invite them.

Patience and persistence will be required by the payoff will be worth it.

Idea #4: Embrace the “maker’s schedule”

Software engineers are the most valuable, most scarce, most expensive asset in any company. It doesn’t make sense to build a great dev team but surround them with a culture that blocks them from doing their best work.

Once we teach our business leaders about the dev process, the next step is to educate them on the consequences of all of the meetings and other interruptions.

I’m not saying just arbitrarily cancel meetings. And I’m not proposing no-meeting Friday. I’ve tried both and they don’t work.

Click here to check out a blog I wrote recently with new ideas for rethinking developer meetings.

Justin’s full Linkedin post