Oh shit.https://mastodon.social/@yvonnezlam/113199649409710636
-
@polotek I don't mean to argue/debate this, and my apologies if I've come across that way. I have a role in the tech org that sits between the business, mgmt and the general tech staff. I've had the opportunity to see many sides of this discussion and my experience, at least in larger companies, has shown that frequently the "business needs" are not shown to the tech ICs until after they start raising questions. (smaller orgs are definitely different)
-
@polotek The business side often comes with a technical solution that they think will solve their problem. In these situations I need to push back and ask what problem they're actually trying to solve because that's what I'm here for - to come up with a technical solution for their problem.
It's symbiotic. If either side is trying to do the other side's job, or ignore it entirely, it's not going to be very enjoyable for anyone.
-
@polotek Appreciate it. When I hear you say that many engineers fundamentally do not believe that their judgment about technical issues will be much worse if they don't try to understand business outcomes, among other things, I think about one's relationship to risk. How it is defined, communicated, agreed upon, and how an engineer decides to take or not take on responsibility for addressing that risk.
(need one more post and I'll get to my questions)
-
@polotek It is my understanding that engineers who don't believe this don't understand how or don't have the range to participate in bearing collective responsibility to address risk, instead believing that the risk they *think* they're addressing can be solved solely with individual prowess and effort.
Do responsibilities of risk factor into how you think about understanding business outcomes, and does it line up with your own observations for why engineers do not believe they need to do it?
-
@polotek @zkat I understand fully. It’s just that requiring everything to be measurable is a sure fire way to kill your company. There’s a middle ground where you try to measure what you can, but understand that some stuff is just on “vibes” and you have to hope you hired the right engineers.
-
-
@ellesaurus but if you’re not sure the other side knows how to do their job, you’re probably gonna hedge your bets in any number of unproductive ways. Many engineers think it’s normal when they do this to other people. But they cannot fathom why other people would have cause to do it to them.
-
@touge I don’t think you can write 3 unanswered replies and then say “I don’t mean to argue”.
-
@walktothesun my definition of doing this job well definitely involves risk assessment. But also more than that. Another thing engineers often do is spend a lot of time and energy delivering what they think was asked. But they don't realize that what they're building doesn't actually meet the business need. Maybe the requirements were bad. But maybe they misunderstood the requirements because they didn't bother to ask questions.
-
@polotek The assumption isn't that they don't know how to do their job, but that they don't know how to do mine.
I don't think I expressed clearly that I'm in agreement. Engineering needs to understand the business needs, because that will drive what to build. That's the whole job. To come up with the technical solution that meets accomplishes those needs most effectively.
What I'm adding is that it's most productive for the business side to. communicate the needs, not the specific solution.
-
@ellesaurus I think we mostly agree on what a healthier collaboration looks like. I was mostly responding to the framing that people are trying to do your job when they offer solutions. I know it can feel that way. But I don't think that's the only way to receive it. And I think a lot of the dysfunction comes from people on both sides reacting to bad dynamics they've experienced in the past.
-
@ellesaurus also though. Many devs absolutely do assume other people don't know how to do their jobs.
-
@polotek This makes a lot of sense to me, and I think I see how this specifically ties to your previous posts in this thread: that engineers need to step up to take their responsibility seriously to be able to help their company determine whether the solution is the right solution for customers based on their needs. Which means putting forth the effort to ask questions (among other things, of course).
Is that the correct tie-in and framing for what you were saying earlier?
-
@walktothesun yeah it's pretty good. Thank you for seeking clarity.
-
@polotek a phrase I've been workshopping lately, as a reaction to our company switching to generic leetcode style interviews:
"I want to hire developers that can solve business problems with code, not developers that can solve coding challenges with code".
I recognize it doesn't quite fit what you're saying but it's in a very similar vein I think.
At the end of the day we're building things to support the business.
-
@withoutclass yeah this a big issue. I hope you’re able to influence things.