Oh shit.https://mastodon.social/@yvonnezlam/113199649409710636
-
@polotek it's also important though that the business people understand the technology behind the business. Too often this requirement of understanding is only one way and it leads to massive tech debt, inefficiencies, lost productivity, and eventually employee retention. Both groups of people need to understand where the other is coming from so that they can better communicate and have empathy for each other. Of course that's also general life advice not just in the corporate context.
-
@touge I think there should be effective communication. But I don't think the burden of understanding goes both ways. It would be great if we could ask everyone to understand technology more in depth. And people can certainly do a bit better than what we usually see. But technology is a high value field precisely because it's a specialized skillset that is difficult to replicate.
-
@touge I know some people are going to chaff at what they perceive as an unbalanced dynamic. But balance isn't really a goal. The goal is a mutually beneficial agreement where both sides are getting the tradeoffs that work for them.
-
@angermcs @zkat I think you're overestimating how much of your stance hinges on "just trust me". Especially if you're not acknowledging how often engineers entirely fail to deliver what they promised. I know nobody wants to hear this. But in software we don't actually do the things that earn trust. We undermine our credibility constantly. And we still wonder to ourselves why people won't just let us go off and do something without some kind of measurement or guarantee.
-
@irene way too many people are comfortable doing their own thing and then letting someone else be responsible for whether it ever delivers any real value.
-
@Ashedryden ah. Gotcha. I do think the siloing has a big impact. Neither side is really incentivized to create a shared set of goals.
Sales often views eng as a service provider (and they are horrible to service providers). Eng often doesn't think of sales at all except as a source of frustration and headaches. We don't tie their work directly to how our paychecks get filled.
I've had a lot of ideas about greater collaboration. At least in b2b SaaS where I have the most experience.
-
@darius in my experience most engineers are not connected to how their tech is used for business. They have a bunch of *assumptions* about this that are very often wrong.
-
@walktothesun please do. And thanks for asking.
-
@polotek from a social/power dynamic though the responsibility falls on the manager to ensure that balance happens not the IC (the "tech" person). The mgmt team trained to understand the business implications of projects so it's their responsibility to teach/educate the tech teams on goals so they can implement solutions in the best manner possible. Otherwise the realm of responsibility for both aspects is being asked of the tech team & that isn't feasible because it's a different set of skills
-
@polotek if the mgr of a tech team doesn't understand the technology used by their team(s) then they are not properly engaging with their ICs. They wouldn't know when to bring in the tech team to help shape the product decisions so that the best possible outcome is made for the business.
-
@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.