How to handle when your team creates short-sighted features?
We are building a separate product with in a product based company most of the features are crafted just to impress the managers.
During the demo hacks are used to adjust the situation. Though I've recently realised even the API design and system design is not scalable. They are just build so that the current UX is displayed, too much hard coupling and meaningless design.
The HTTP response is dynamic as the demos were build on web and the back -end developers are not understanding that it is difficult to handle in a strictly typed languages.
I get by saying today, I'll write clean code and do my work neatly no matter what others are doing. Though I want to know how do I communicate well with them and build solid products, so that we make something re-suable and independent and sell it not just part of the current product but in terms of public APIs like Twitter, Reddit.
Lately I feel like simply discussing in these lines creates friction, but I have to speak in gentler way to get the job done effectively :)
Discussion
(2 comments)- 3a year agoTech Lead @ Robinhood, Meta, Course Hero
I resonate with this a lot - People at Meta were constantly trying to get cut corners 😂
Here's my some of my tactics for dealing with this:
- Take advantage of retrospection - You can only fake it for so long: If you have real deliverables and you're shipping jank, things will eventually blow up. It's entirely possible that your team (especially the leadership) isn't willing to listen to you right now as they haven't been burned yet. In this case, let the "product" ship and then fail, and you can swoop in at this moment of opportunity to convince folks to do things the right way. You can say something like "Alright, we put in a good effort, but it wasn't enough in the end. Let's see what we can learn from this and how we can tighten our development process to prevent this from happening again."
- Be willing to compromise - There are going to be times where you're 100% right, but you don't get everything that you want. This sucks, but that's just how life works. Don't let perfect be enemy of the good (or even of the slightly better) - Be prepared to ship a halfway solution that improves just some of the quality. Here's another way to think about this: If you're able to make the process and culture a little bit better each time, eventually your team will be perfect. 😊
- Follow 80/20 rule - It is impossible to write the perfect code and unless you're working at peak of Big Tech scale with 1 billion+ users, you don't need to write code that covers >95% of all possible edge cases. Look for the solutions that give you 80% of the quality and polish with 20% of the maximum possible time spent. Stuff like "Hey, if we take the time to pass an auth token to our API instead of having it be completely unprotected, this prevents any random who knows how to use Postman from hacking our entire database."
To help with all this, I highly recommend my communication series: Alex's Guide To Effective Communication. There's even a video which covers how to communicate in a disagreement scenario.
Every software engineer does things a little differently - It's very tempting to be a stick in the mud when you're confident you're right and you see things being done in a sub-optimally. However, this isn't productive, so it's best to suppress those instincts and genuinely act in an empathetic, bridge-building way. 🙌
- 210 months agoTech Lead/Manager at Meta, Pinterest, Kosei
Perhaps a dumb question, but may I ask why you want to build solid products?
What is the impact of the shoddy engineering work? If the incentive structure is created by the managers, are they aware of the situation, and why are they not concerned?
Before creating friction with your fellow engineers, I'd spend time understanding the mindset and priorities of the management team. Perhaps they're deliberately making the choice to cut corners for expediency, in which case, you will lose any code quality battle you try to take on :)
