As a tech lead, you bother about building the features that the business has identified - and building it in the best way possible, thinking long term about the product. While as a business decision maker, you focus on what your users want - else you will be out of business fairly quickly.
It's definitely a balance. I should have phrased it as "make sure the product satisfies your users needs" rather than their wants. And this isn't to say you should add a thousand features, but I do believe it's important that tech leads goals line up to users, not only to the technical excellence of the code. You can't make good decisions on technical improvements or debt reduction without balancing users needs. It's easy to build a straw man example that is on the extreme end to demonstrate this, so I won't do that. The day-to-day is more nuanced.
If one defines gorgeousness as ease of grok, then gorgeousness directly contributes to the wellbeing of users through maximizing the technology's ability to quickly and effectively adapt to their needs as they arise. Agreed that it's a secondary concern to fulfilling the featureset.
Could definitely be true! I personally have a hard time imagining how code could be pleasing to the eyeballs by any other metric than how easy it is to understand.
IMO a clever one-liner or a hyper optimal routine that takes minutes of staring to decode isn't gorgeous, but you're certainly right that many would disagree with that. IMHO this philosophy runs directly contradictory to the one in which leaders empower those around them.
If you stand up for your product, you are standing up for your users, or your clients if that's a less ambiguous term.
For some teams, for example a lot of teams in Google and Facebook, the end-users are often different from the Product's clients; the client of Google's Chrome is Google's empire. The programmer that added the X-Client-Data header undoubtedly improved the product, at least short-term-business-wise, while actively harming it for end-users. Someday end-users may leave if they continue to erode trust, but for now it's a boon for the Product.
Edit: Please don't work on those products. Please develop products that respect people. If you develop trust, and actively respect people; I posit that a lot of people will opt-in to reasonable analytics, and even advertising. If many don't now, they might when the dust settles.
Agree. I much prefer the term ‘product engineer’ to all previous titles. It shouldn’t be a cargo-cult switch where everyone starts calling themselves one, but it is by far the best title as a guiding principle to what we are meant to be doing.
Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.
DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.
