Project Management Tools are Plan-First, Not Develop-First. 3 Solutions.

This blog is not about how project management tools are too complex and over-engineered with features I don't need.

Those complaints are well articulated by others. 

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

Justin 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..." 

Most project management tools are highly configurable which, depending on your company's configuration, can be a good or a bad thing. 

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

It's true. Many project tools are 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 project tools. Not engineers.

Many engineers say that the development process is fluid, real-time, and doesn't always follow a linear path but project tools force dev teams 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 dislike it?

Many of the complaints can be attributed to the project tool itself or the configuration of the tool. But, in my experience, many of the complaints have nothing to do with the project tool. The root is actually a problem with culture, management or process. 

Join our mission to end manual status updates forever.

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

See the potential "real issue" behind 3 common complaints dev teams have with project tools: 

1. "Project tools are plan-first, not develop-first"

It makes sense. PM's, who own the project tool, 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. Project tools are 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 not ideal. If we're the engineer who has to constantly manually update the status, it's bad. 

When planning ends and coding starts, 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. Many project tools are 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 life cycle?

The real issue: Business leaders get product strategy but not product development

Business leaders think like PMs, not like engineers. The CEO understands 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 as well. They don't know our terms. When it comes to the dev team, many 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?"

How we work matters. Not just the output.

2. "Project tools perpetuate synchronous communication, not asynchronous"

It seems like project tools should encourage asynchronous communication. But really they do 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 the project board? Because it's not up to date. Why? Things change so rapidly that, in order for it 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 board hygiene only capture about 60-70% of their real work activity. Most teams are closer to 50%.

Even if the board 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 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 real 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 some business leaders have for the software development process, leads to a lack of empathy for software developers. Some companies (knowingly or unknowingly) 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.

3. "Project tools create separation between engineers and PMs"

The way some devs describe interactions with their PMs reminds me of Peter from Office Space when his boss asks him for the new cover sheet on the TPS report.

I've worked with some great PMs in my life. The good ones not only bring great customer ideas in to the mix, but they do the things most devs don't want to do which allows devs to do what they do want to do - write code. 

But the PM + engineer relationship is hard to get right. Having additional tension built-in makes it even harder.

By the way, 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. 

The real issue: Engineering is not connected enough to 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.

3 Ideas to empower dev teams and solve common complaints about project tools 

Idea #1: Use project tools for planning, not for managing team dev team activities. 

Justin wants to get rid of Jira. "I can't *wait* for someone to disrupt Jira and make it go away..." 

I know many developers that feel this way. Countless new project management tools like Clubhouse and Notion and have popped up trying to be more dev-friendly. But I don't think another project management tool is the answer. 

Justin said in his post... "Developers don't manage tickets for a living, they write code for a living..."  This is the key point for me. 

PMs will always need a place to plan. Project tools are great for that. PMs should continue using Jira (or whatever works for them) for planning and roadmap. Our PMs at LinearB like Jira for planning. 

Dev teams need something new that is focused on coding and delivery. Something that is more integrated with Git and Slack. That's what we've been working on at LinearB.

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 goes way behind the ability to attach a branch to a project ticket. 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.

I would love your feedback. Comment and let me know what you think.

Idea #2: 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 #3: 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