The hard thing about easy things

It’s the first sprint planning meeting of the quarter and you’re leading a small team. It is determined that the first ticket on the board is an easy one and everyone agrees on the size of three points ​​– something that should be knocked out in the next sprint.

Fast forward to the end of the quarter. That seemingly easy ticket took way longer than expected and the team has finally finished it. Other work has been stalled because this ticket took so long and the engineers are burnt out. During the retro, you try to understand why this took so much longer than expected. You ask the team, “This was an easy ticket, right?  We all agreed it was only three points? Why did it take so long?”

In this article, I explain several patterns that turn easy problems into hard problems: artificial constraints, lack of quality process and tooling, knowledge radius and silo issues, poorly designed systems, and people issues. In addition, I provide several methods to minimize or prevent these challenges.

Artificial constraints

Artificial constraints can be a project’s worst nightmare. An artificial constraint is a requirement put on a project that is not actually necessary but makes the project significantly harder. Often these constraints have good intentions, but the project could easily succeed without them. Artificial constraints can come from both product and engineering. Here are some examples:

1. Overly aggressive performance requirements. Good performance is important, but great performance isn’t easy or cheap.
2. Overengineered architecture. Engineers love to make a simple problem complicated by adding 300 layers of technology.
3. Antipatterns that have become core to the system. Forcing developers to build jenky solutions just because that’s how it always has been.
4. Non-requirements. When a lot of engineering leads and product managers get together, they will push for a product to have every bell and whistle, 100% code coverage, etc. These are not at all a requirement for launching.

My recommendation is to ask why and ask for data and research to back up the request. Data-driven decision-making is the cornerstone of good product design, so push for it. It also helps to be upfront about the cost. It will take X developers N weeks to build the feature, the hardware to support it will cost $Y a month, and the continued maintenance will cost M engineering hours a month.

If all else fails, see if you can punt it to a future milestone – you want to release the product in an iterative manner, get the MVP out first, etc. Maybe it’s a future milestone that never gets prioritized 😉

Lack of quality process and tooling

Lack of quality tooling is when engineers do not have the tools in place to effectively complete a task. These tools are not laptops and chairs, but systems and scripts that allow engineers to easily accomplish non-coding tasks. Lack of quality process means that your team either lacks the process to help get things done or has a process that gets in the way.

Some examples:

1. Lack of quality release tooling. Releasing should not take up too much of an engineer’s time and it should be easy. It’s not that some magical CI/CD system is required, but ‘scp and deploy’ is not good.
2. Inability to test a change. Unit tests are great, but often you need a higher level of testing a change within your greater stack.
3. Local environment setup. It’s never easy to get a laptop in perfect shape for development, but it should not require some archaic magic knowledge for an engineer to start writing software.
4. Process for the sake of process. It should be easy to understand the reasons and benefits of a process.

Many problems with tooling stem from a lack of investment. Sometimes, a company will create a dedicated team to handle these problems for the organization. More often, it’s on each team to address the issues along with the rest of their work. Project plans should include how to develop, test, and release the software. Some of the tooling might not be part of the first release (as it could be an artificial constraint), but it should be part of the plan that is addressed at some point.

Process should not be viewed as a static concept. A process that works well for one team, may not necessarily work for another. Additionally, a process that might have once worked well, may not continue to be successful over time. Revisit processes to make sure that they actually make sense and are as beneficial and effective as they should be.

Knowledge radius and siloing

Solving problems sometimes involves understanding many tools and systems. Acquiring this knowledge can be quite frustrating when there is no easy way to obtain it. Some examples:

1. Not knowing when and how to get help. Engineers will sometimes struggle with technical problems that are not directly related to the project like build tooling, getting tests to run locally, etc. Some engineers struggle to know how much time to spend on these problems versus when or how to seek help.
2. Understanding an entire complex stack can paralyze an engineer and project. Not being able to understand how a change fits into a stack makes it hard to know if a change is correct and what effects, good or bad, it will have.  
3. ‘Linchpin’ engineers in the company that have some special knowledge that no one else shares. These engineers have limited time to help and often get flooded with questions and requests. For some reason, this knowledge is not passed down and people become dependent on the linchpin to help solve their problems.

Engineers should not struggle to understand something when the information already exists in the organization. To combat knowledge siloing, it’s important to make it easy to share information and learn. It should be simple for engineers to write and find documentation, share videos, set up classes, and create certifications. Teaching and learning should be incentivized. If your organization actually values it, then it should be part of OKRs. Teams need to be capable and incentivized to assist one another by providing help and knowledge for the systems and tools that they own.

Organizational problems

Organizational problems are probably the most difficult to fix. It’s not the technology that’s the problem, but the people building or supporting the system.

1. Bureaucracy. Common at larger companies, there can be rules and hoops that engineers must jump through in order to do their job. While rules and structure can be helpful, too much can make everything slow down to a crawl.
2. Favoritism. Management can sometimes favorite certain teams. In their eyes, this team can do no wrong, and every other team must learn how to work with them. Engineers can spend a considerable amount of time and mental effort dancing around these people.
3. Poor performers. I know it is a tough thing to say, but not everyone at a company is great. A poor performer or mean employee can be a huge drag on productivity.

There should be some machinery in place to improve employee performance. The feedback from reviews (including 360° reviews) should be taken seriously and the employee in question should react accordingly in order to improve over time. If there is no improvement, he or she might need to be let go. It is hard to fire people, but it is even harder to lose multiple good employees who cannot stand working with a poor performer.

Bureaucracy and favoritism tend to come from the top. It is either created or condoned by senior leadership. Unfortunately, if senior leadership is not compelled to make things better, there aren’t many choices. I personally do not know of any company that has successfully overcome either bureaucracy or favoritism.

Poorly designed systems

Even with the best of intentions, sometimes a system is just not fit for its current purpose. When systems are not designed well, it can be very hard to make simple changes.

1. Systems that are past their prime.  They were great when they were designed and implemented t, but time and scale have taken their toll and the system is now outdated
2. Peculiar anti-patterns or hacks that have become an integral part of architecture and cannot be changed. No one is capable of changing these; they make all changes needlessly complicated and prevent innovation.

You should instill a culture where employees strive to improve the system. There’s nothing wrong with replacing software after a few years, and engineers should feel safe to do so. Of course, I am not suggesting that every piece of software should be replaced every year, but when there is a good argument for iterating or updating something, it should be heard. When this happens, there should be no blame – engineers should not be made to feel bad that their systems require reworking. All too often we roll our eyes at what a prior engineer built, but that is very unproductive.

Conclusion

You don’t want to be caught in a situation where an easy, one sprint task unexpectedly takes the entire quarter to complete. Other projects then get delayed, which upsets the product team. Engineers are burnt out from an inability to deliver and frustrated that they cannot work on solving more interesting problems. In my experience, the majority of issues stem from artificial constraints, lack of quality process and tooling, knowledge radius and silo issues, poorly designed systems, and people problems. As a leader, it is important to uncover these setbacks. Listen to your team, try to identify any underlying issues, and address them.  Don’t let your team burn out and quit as a result of time sinks – take action early so that easy problems remain just that.

Side note, the title of this article is a tongue-in-cheek call out to the book, The Hard Thing About Hard Things by Ben Horowitz.