Oh shit.https://mastodon.social/@yvonnezlam/113199649409710636
-
@polotek I've started using https://wpostats.com/ to back stuff up after Alex linked me to it and it's so helpful
As an engineer, it's genuinely hard for me to be able to tell a story about how technical improvements concretely translate to moneydollars. I think beyond developers who don't believe in business outcomes being the top priority, those of us who do think that matters are severely lacking in tools to measure and communicate and map our technical decisions to business outcomes in the first place.
so it just ends up being easier to argue about developer experience and technical details. that's what we know. that's what we can "measure", at least in our heads and talking among each other. I just want more tools available to bridge that gap
-
-
@angermcs @polotek I honestly think that there's a lot of stuff that can be measured, and we just think it can't, or don't have the tools yet to do so, so we give up and think too highly of ourselves, and start thinking our arbitrary technical decisions are The Enlightened Way.
I don't think most managers etc are this ignorant. I think they genuinely do have much more of an understanding of how to connect the dots than engineers give them credit for.
-
@zkat @polotek Sure, but theres also the tradeoff. If its going to take me 5x longer to build the measurement pipeline to "justify", would just building it not be better for the business? And there are things like developer productivity, where people have dedicated their entire careers to "measuring" it and the answer is you basically can't measure it reliably. You end up having to rely on CSAT numbers to best approximate it.
-
@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?
-
-