4 ms·

You're 100% right but also 100% wrong. Like I said before you're viewing it from the perspective of a developer but not from the perspective of a Business pers

You're 100% right but also 100% wrong. Like I said before you're viewing it from the perspective of a developer but not from the perspective of a Business person. Instead of saying `Users cannot sing up if everything is broken` you need to see it from a Business perspective, and communicate it to them in the language they understand. For example, `From our quarterly earnings report we need to have 10,0000 new clients signed up by the end of the month to reach the goal. We have on average 2,000 sign-ups per day. On the 2nd, 3rd of last month two of the critical system's fell over, and this result in a estimated 4,000 failed client acquisitions. The estimate from our quarterly earnings each new customer bring's in a revenue of $300 net profit from each client for the quarter. As a result of the system crash our quarterly earnings will be down 1.2 Million.` Your job is to communicate clearly in the language they understand how it will achieve their goals. You're not the only department/manager who is requiring resources from the Business. As I stated before you're there to serve the business to achieve their goals.

tfigment 9y ago
The corollary here that it is perfectly acceptable for business users to not understand significant parts of their own business operations. In fact, everybody should work around your shortcomings in understanding that "technical" stuff. As the guy with the MBA, you are the most important person in the room and everybody else is there to serve you.
- DamnYuppie 9y ago
  You are a team. Not everyone has the same background and experiences. You would be amazed at how many people in an organization have incredible knowledge of their business domain and little to no knowledge of IT systems, their costs, and benefits. As an IT leader it is your responsibility to help bridge that gap, and the language of business is business not tech jargon, so I would caution against dismissing it. Another way to think of it is as of user acquisition problem. You have to highlight the benefits in a way that is compelling to them. At the end of a day all progress/fiascos in a company comes down to consistent and effective communication.
lotyrin 9y ago
Still doesn't work. I've done clandestine work over weekends to speed up an application, then as part of shipping it also add a split test with half the audience having a delay similar to what was in place before I fixed the problem and brought that to the table with the "business" guys, and everyone nodded their head "wow" but every sprint after that was just full of new features.
- user5994461 9y ago
  I hope you got the lesson. Please stop working over the week ends for free. You are devaluing yourself and you are devaluing all the developers who don't want to ruin their week end at work.
  - jjoonathan 9y ago
    Agreed, but don't take this as "don't work hard," merely as "don't donate time to your employer." There are far more worthy causes out there.
  - lotyrin 9y ago
    I obviously didn't bring to the demonstration that I had volunteered the time, it suited my point to make it seem like it was something easy I could do as an aside... Problem is, they don't care about $ either, they care about what makes them look good, what makes their boss look good, what the sales guys are bugging them about, and it's features and visual polish and never quality or performance. I had to break it down to one of them "Listen, we've seen that the site being faster gets us X% more conversions, if the site was down, or if the site was ugly X% of the time and cost us those conversions, you'd be breathing down my neck to fix it, why is this any different...?" reply after a few seconds of thought "You're right, but you'll never convince Leadership"
    - yetanother1980 9y ago
      > it suited my point to make it seem like it was something easy I could do as an aside... Thus fuelling the idea that this sort of thing will just be done as other work is happening with no time budgeted for it.
flukus 9y ago
So we just have to do their job as well as our job?
- jimbokun 9y ago
  Making money for the company is every employee’s job.
  - flukus 9y ago
    So the janitor should analyse and quantify what difference he will make to the companies bottom line before he wipes those skidmarks off? Not everything is quantifiable like that. If I'm writing code and I take the time to make it 30% faster then it won't make a difference to our bottom line. If that's done everywhere then customers will like us more, be more likely to stay with us and be more likely to recommend us, but that can't be quantified in my day to day work.
    - webmaven 9y ago
      Probably the biggest change looming over our industry is coding to - and deployment on - platforms that definitely are instrumented to capture exactly how much value a developer is adding (or subtracting) from the bottom line with every commit (it's a natural outgrowth of Function As A Service architectures). It is already possible to more-or-less show how a code change (bug/fix, new feature, change in storage backend, etc.) directly affects your IAAS bill at the end of each month, and taking it a step further by tying in some instrumentation and formulas (of the sort often used to calculate the effectiveness of marketing funnels for optimization and A/B testing) to show the concomittant effect on revenue allows ROI to be calculated. So, I am pretty sure that Finance-Oriented Programming is going to be a thing not so many years from now, tied into the whole toolchain, and very few - not developers nor their managers - seem prepared for that sea-change (some Operations folks are probably a bit better off in terms of mindset and processes).
oceanghost 9y ago
The core conflict is this: The engineer is trying to optimize/normalize his free time by acknowledging quality issues, the management is trying to optimize their income by sweeping them under the rug. The engineer is ultimately liable for the problem. Quality is insured with his reputation and free time. The business guys almost always leave at 4:00pm and their bonuses are based on a metric not related to quality.
jdmichal 9y ago
Honestly, this is pretty straight-forward stuff, and I'm surprised you're getting any argument. If a technologist cannot explain how a proposed implementation is going to provide value to the business, that project is probably better off left alone. Prettier code and better tests don't provide value. But fewer customer-facing P1/P2 tickets provides value. That prettier code and better tests leads to fewer tickets is an implementation detail. Let's put it this way: Netflix has one of the most robust microservice architectures I know of. I promise you will find zero mention of it anywhere on their customer-facing pages. Because that is not the problem that Netflix solves for their customer; they solve a media library and streaming problem. The business is your customer. You need to understand their problems and how you're going to fix them. Everything else is an implementation detail.
- AnIdiotOnTheNet 9y ago
  >Honestly, this is pretty straight-forward stuff, and I'm surprised you're getting any argument. I'm not. Our industry is full of academics who've been told "this is the right way to do it, everything else is stupid" for the entirety of their education. They're academics, trained by other academics, ignoring the broader reality of why we do these things at all.

tfigment 9y ago

The corollary here that it is perfectly acceptable for business users to not understand significant parts of their own business operations. In fact, everybody should work around your shortcomings in understanding that "technical" stuff. As the guy with the MBA, you are the most important person in the room and everybody else is there to serve you.

DamnYuppie 9y ago
You are a team. Not everyone has the same background and experiences. You would be amazed at how many people in an organization have incredible knowledge of their business domain and little to no knowledge of IT systems, their costs, and benefits. As an IT leader it is your responsibility to help bridge that gap, and the language of business is business not tech jargon, so I would caution against dismissing it. Another way to think of it is as of user acquisition problem. You have to highlight the benefits in a way that is compelling to them. At the end of a day all progress/fiascos in a company comes down to consistent and effective communication.

lotyrin 9y ago

Still doesn't work. I've done clandestine work over weekends to speed up an application, then as part of shipping it also add a split test with half the audience having a delay similar to what was in place before I fixed the problem and brought that to the table with the "business" guys, and everyone nodded their head "wow" but every sprint after that was just full of new features.

user5994461 9y ago
I hope you got the lesson. Please stop working over the week ends for free. You are devaluing yourself and you are devaluing all the developers who don't want to ruin their week end at work.
- jjoonathan 9y ago
  Agreed, but don't take this as "don't work hard," merely as "don't donate time to your employer." There are far more worthy causes out there.
- lotyrin 9y ago
  I obviously didn't bring to the demonstration that I had volunteered the time, it suited my point to make it seem like it was something easy I could do as an aside... Problem is, they don't care about $ either, they care about what makes them look good, what makes their boss look good, what the sales guys are bugging them about, and it's features and visual polish and never quality or performance. I had to break it down to one of them "Listen, we've seen that the site being faster gets us X% more conversions, if the site was down, or if the site was ugly X% of the time and cost us those conversions, you'd be breathing down my neck to fix it, why is this any different...?" reply after a few seconds of thought "You're right, but you'll never convince Leadership"
  - yetanother1980 9y ago
    > it suited my point to make it seem like it was something easy I could do as an aside... Thus fuelling the idea that this sort of thing will just be done as other work is happening with no time budgeted for it.

flukus 9y ago

So we just have to do their job as well as our job?

jimbokun 9y ago
Making money for the company is every employee’s job.
- flukus 9y ago
  So the janitor should analyse and quantify what difference he will make to the companies bottom line before he wipes those skidmarks off? Not everything is quantifiable like that. If I'm writing code and I take the time to make it 30% faster then it won't make a difference to our bottom line. If that's done everywhere then customers will like us more, be more likely to stay with us and be more likely to recommend us, but that can't be quantified in my day to day work.
  - webmaven 9y ago
    Probably the biggest change looming over our industry is coding to - and deployment on - platforms that definitely are instrumented to capture exactly how much value a developer is adding (or subtracting) from the bottom line with every commit (it's a natural outgrowth of Function As A Service architectures). It is already possible to more-or-less show how a code change (bug/fix, new feature, change in storage backend, etc.) directly affects your IAAS bill at the end of each month, and taking it a step further by tying in some instrumentation and formulas (of the sort often used to calculate the effectiveness of marketing funnels for optimization and A/B testing) to show the concomittant effect on revenue allows ROI to be calculated. So, I am pretty sure that Finance-Oriented Programming is going to be a thing not so many years from now, tied into the whole toolchain, and very few - not developers nor their managers - seem prepared for that sea-change (some Operations folks are probably a bit better off in terms of mindset and processes).

oceanghost 9y ago

The core conflict is this: The engineer is trying to optimize/normalize his free time by acknowledging quality issues, the management is trying to optimize their income by sweeping them under the rug. The engineer is ultimately liable for the problem. Quality is insured with his reputation and free time. The business guys almost always leave at 4:00pm and their bonuses are based on a metric not related to quality.

jdmichal 9y ago

Honestly, this is pretty straight-forward stuff, and I'm surprised you're getting any argument. If a technologist cannot explain how a proposed implementation is going to provide value to the business, that project is probably better off left alone. Prettier code and better tests don't provide value. But fewer customer-facing P1/P2 tickets provides value. That prettier code and better tests leads to fewer tickets is an implementation detail. Let's put it this way: Netflix has one of the most robust microservice architectures I know of. I promise you will find zero mention of it anywhere on their customer-facing pages. Because that is not the problem that Netflix solves for their customer; they solve a media library and streaming problem. The business is your customer. You need to understand their problems and how you're going to fix them. Everything else is an implementation detail.

AnIdiotOnTheNet 9y ago
>Honestly, this is pretty straight-forward stuff, and I'm surprised you're getting any argument. I'm not. Our industry is full of academics who've been told "this is the right way to do it, everything else is stupid" for the entirety of their education. They're academics, trained by other academics, ignoring the broader reality of why we do these things at all.