I ultimately left that job because the work was not challenging and I thought I was being forced to produce mediocre products. After some serious reflection, I realized that what really bothered my about that experience was the “Because it’s a requirement” thinking.

That moment represents the systemic problem that was present through out that job. There is a fundamental problem in the thinking: we are doing things a certain way because that is how they are done. As an engineer, it is really frustrating when you can’t ask “Why are we doing this?”. Eliminating the ability to question features or an approach to any project is a sure fire way to create scope creep, bloated software, and unhappy employees.

Here are some suggestions on how to prevent this from happening on your project or at your company.

For high level managers and executives:

Hire people you trust and then let them do their work. Allow for work to be done that isn’t directly measurable, a week of refactoring code can make a whole engineering team much more efficient.

For product and project managers:

If an engineer or designer pushes back, take the time to understand why. Don’t be afraid to adjust a requirement, someone added the requirement at some point, so someone can delete it too.

For engineering managers:

Fight for your team and for a level of autonomy. Review why you have a certain development process. Are you using a bunch of agile techniques just to be agile? Allow your engineers to take care of technical debt and refactor code. If you have push back on taking care of technical debt from non-tech people see the first sentence of this paragraph.

For engineers:

Fight for what you think is the right approach, but don’t be bull-headed. If there is push-back make sure to understand the counter point. If you continually find that things are being done just because that’s how they are done, look for another job, it won’t change.

The post Because it’s a requirement. appeared first on Insert Culture - Web Development - Brooklyn, NY.