4 things that hamper an engineering team’s performance:
Not knowing what the organization expects is a huge issue. Before an engineering team is tasked, there should be a clear and shared idea of what should be built. And before throwing a body at a task, the problem and solution should be validated.
There should also be sufficiently mature and concrete artifacts that have resulted from product discussions. Concrete is important here. While team members should always be talking, having a clearly written description of a task helps other team members test, review, weigh in, etc. Artifacts can be textual feature briefs, product designs, product briefs, flow diagrams. Anything that clearly communicates what needs to be built.
These artifacts provide a way to have a concrete conversation so engineers have an end goal in mind.
This includes all the things that haven’t gone well before: buggy features, inconsistent or poorly thought out UIs, or poorly architected code. All these prevent simple changes from being made easily.
Teams get into this place by rushing to release and failing to think ahead. Tech debt can be described as the shortfalls a team introduces when rushing. A shortfall may be an intended tradeoff, such as sacrificing scalability for early feedback. But often, the shortfall is an architectural issue that could be resolved with a refactor. Shortfalls of this nature tend to show up as bugs later on.
Rationale debt is just as insidious, but often incurred by overzealous product teams that don’t properly think ahead. With feedback, a future-proofed solution can seem obvious, but won’t always be acted upon. As a better solution becomes obvious, the real reason for going a particular direction will become lost to time.
Let’s say a team member needs a piece of customer information. Without an admin panel or BI tool, they can’t just type in the email, find the customer, and see what’s going on. Instead, they have to ask an engineer to change something in the database, provide the information, or pull a report.
Reporting often gets neglected early on, but it’s still part of tooling. Having engineers solve these problems for internal stakeholders is valuable work, but because it doesn’t directly support growth, it doesn’t get prioritized.
Similarly, the engineering team itself may lack tooling. For example, if no one knows how to do a deployment, there are no scripts to run, or there’s no automation for a junior front-end developer to push code to GitHub, get it reviewed, and deploy it because they don’t have permissions.
Implementing tooling that allows people to safely and automatically manipulate production is also a significant obstacle for engineering teams.
I’ve seen so much time wasted on this. Poorly formatted code will work for a lot of languages, no matter how you structure it. But, developers have preferences. JavaScript in particular allows you to format code however you want it.
The most productive trend in this area comes from tools like python’s black and javascript’s prettier. Both these tools are uncompromisingly opinionated. And what they lack in flexibility, they make up for in productivity gains, as both will reformat code with just command.
With the advent of these tools, arguing about a particular code style preference is a waste of time.
What else would you add to this list?