311–320 of 339 posts
If you want someone to critically think, they have to have business context and in many cases a vested interest in what they're building.
This crops up quite a bit when your engineering is primarily outsourced/overseas and your work involves an issue that might be a primarily US based problem.
How can you expect people to critically think when they don't have context around the issue?
Earlier quoted context omitted.
Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.
I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.
If you have ever been in a relationship, you know how irrational people are: ergo, ability in logic and mathematics plays little role.
Went to MIT in engineering/science, and I would do a mental face-palm when I heard other engineers try to ‘sell’ what they are working on.
It’s the “curse of knowledge” where you forget how to relay ideas because you forget your axioms have been updated but the person you are talking with has not had theirs updated.
This is to say some people (in all fields) can sell ideas, and some can’t. Just as some can do high level mathematics, and some can’t. Those curves overlap in unexpected ways.
This is a good article but there is a causality problem. I know a lot of pure software companies in the EU that work like that. If software is your core business, developers are in the loop at every decision, if your core business is building power plants...they are not. Now the Marc Andressen argument might be that software eats the world and everybody should run their business like this, and that might actually be…
I agree with the premise of the article that more engineers need to be in powerful positions, but some domains are just too complicated and require substantial domain knowledge to make "product" decisions. It's the collaboration between product and engineering that's important, not switching one for the other. The biggest problem I have with the article is that it presents the problem as too binary with only 2 possible outcomes - someone being in charge.
Tech companies put engineers in charge because the engineers are the domain experts, not because they figured out some secret sauce.
Earlier quoted context omitted.
I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.
Eh. A lot of engineers really don't have the social skills to navigate the business situations. Some do, sure, and should be given the opportunity to shine. But I would still say the majority don't. And what kind of "high level physics" do engineers know? A typical masters track doesn't cover the hard maths like in GR, sounds more arrogant than anything... kind of proving my point ;)
High autonomy is higher variance. Some of that may be good - innovation. Some of that may be bad - customer or market failures. The outcomes are money consequences to a business, and given business has some to downside tolerance to that. In some businesses tech innovations have huge realizable upside.
Maybe a way to see the autonmy tradeofff is in terms of manufacturing complexity. A business whose products reach customers via endpoints on hosted service is different than one whose products are tractors off an assembly line. Maybe that's understood as how capital-intensive it is to bring a marginal capability to market.
I'll say further than in an ideal organization, with respect to autonomy, the job of management is allocating attention and distributing context, and that management and staff alike are serving a well articulated mission through the vehicle of the business organization. In a given instance, we all can take a compass reading on "true north" for business.
A non ideal business, for starters, has a self serving and self interested control structure that views autonomy in relation to power.
Both SV and traditional companies can be ideal or not. I think the difference comes down a culture of thinking about risk - reward, and the collective, cultural engagement with mission.
Earlier quoted context omitted.
Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders. Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse. Sample phrases include: "Why did the customer ask for that - it sounds like o…
>"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses". I don't get it. Can you explain?
Staff at company A have negotiated a profit share / performance bonus.
Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
I've worked at both SV and traditional companies, and I feel like this very closely matches my experience. One of the things I worry about is that even at companies that are doing "Agile transformations" and adopting methodologies like Scrum, in practice have "Product Owners" who are there to give instructions via Jira tickets. Other roles like "Business Analysts" are there to ensure that lowly developers never have…
We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers. I suggested instead engineers get looped earlier into the pro…
Earlier quoted context omitted.
Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
Earlier quoted context omitted.
This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas oth…
Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.