6 ms·

I think you've nailed it on the head but haven't realized why you've nailed it on the head. `Why? These things have real consequences.` To a business they see

I think you've nailed it on the head but haven't realized why you've nailed it on the head. `Why? These things have real consequences.` To a business they see software/engineers as a expense. The whole focus as a business is to provide a service that people are will to pay more than it costs to provide said service. Everything else doesn't matter, what does matter for a business is $$$$$ and making sure business doesn't get sued because bill touched jill with his #####. For what my words are worth, I do think you need to take a step back and view it from a Business person perspective and attempt to align your goals with theirs. Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Then see if you two can work together to achieve their goals and bring value to the table. Even writing this I've could think of 10 or 20 different business discussions you could have.

leggomylibro 9y ago
>To a business they see software/engineers as a expense. Anecdotally, this is one of the first things I try to gauge at a prospective employer. "Are their development teams seen as cost centers, or profit centers?" If the company works with technology a lot and doesn't see technology as being particularly important to its bottom line, that's usually a bad sign. Also, discussions with C-levels tend to be pretty one-dimensional. It doesn't matter how much their infrastructure is falling apart, they'll still stonewall with something along the lines of, "our goal this quarter is new user acquisition - how does this improve those numbers?" And they won't accept, "users cannot sign up if everything is broken" as an answer.
- hackits 9y ago
  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.
- dreamfactored 9y ago
  >"Are their development teams seen as cost centers, or profit centers?" It's not a matter of opinion, but what the term means. They are cost centers unless they are closing sales (or being billed for about 3x what they cost, which is still way less than sales people will generate, being closer to 10x+ cost). Best thing any employee can do is find out how their company actually makes money and understand how they align. Unfortunately, the highest business expense is salaries and one of the most important things for most businesses is remaining runway. So there is huge pressure to keep salaries down, particularly in cost centres, which aren't directly extending runway. If it's a service business it can get worse, as the money is typically made on billable hours - creating a perverse incentive to have cheaper and less efficient people to bill out rather than a 10xer (outside a senior business facing role). As long as they are capable and not so bad that they lose the client, it's often more efficient to have cheaper mediocre people from a business point of view.
  - scrpn 9y ago
    How can a software developer fight against this salary limitation?
    - dreamfactored 9y ago
      Become a highly sought after specialist for a product offering (e.g. self-driving cars, blockchain, fintech), or get ownership (startup), or go customer facing (particularly if commission involved), or go into technical management on CTO route.
  - marcosdumay 9y ago
    > one of the most important things for most businesses is remaining runway Remaining runway is a measure that only exist for companies in the red. For most business it doesn't even exist.
    - dreamfactored 9y ago
      How long you can continue operations if sales drops off a cliff is a very important number for every company I've worked at, from startups to big multinationals. Maybe it's less of a consideration for Amazon and Apple but I wouldn't even bet on it there.
- jacquesm 9y ago
  The better question to ask in my opinion is whether or not they activate their IP on the balance sheet. If they do there is a very good chance that they care about the quality. If they don't then there is a very good chance they treat software as something disposable.
ryanmarsh 9y ago
> Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Jesus Christ listen to yourself. You don’t know anything about me or how I approach things with my clients. I care about how code affects humans but business don’t have to be responsible for how they hurt people with it.
outworlder 9y ago
> Get out of your cube and go and meet CEO's and CIO Oh right. Good luck even ATTEMPTING to arrange a meeting with a Fortune company's CEO. "Who from what department again?". Worse yet if it not even your company's CEO. Maybe, if you are lucky, you can get to skip a level or too. Software engineers are usually very far removed from the top leadership.
- ryanmarsh 9y ago
  I routinely talk to CIO’s. They’re often the ones who hire me.
tarsinge 9y ago
Yet my experience is that the issue comes from engineering a lot of times: fixing bugs is not fun, let’s rewrite everything because this time we learned from our errors, or just to use the new shiny framework. A buggy legacy code base that no one wants to touch or improve, and V2/New projects that of course completely fail to deliver in the end and the cycle repeats. Being in a customer team I try everyday to make Engineering care about non technical end users. My team and business might be responsible for some feature creep, but bad code quality comes from engineering practices. Edit: to be more clear the discussion usually goes like this: - Me: “where are we on fixing this bug? it’s been two years and customers are still complaining” - Engineering: “we can’t touch at this component it’s a mess but we are rewriting it, this bug will no longer exists and it’ll be so much powerful, just wait a few month” We all know how it ends. And when business pressure comes because it failed to deliver it’s all “business is evil we need more time to do great software!” What we really need is senior and experienced engineers IMHO
doktrin 9y ago
> Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Implied in this statement is that the parent has a myopic perspective on the business world. Based on my read of his comment, I don't think that's fair - and moreover would question whether or not your perspective is as unique as you apparently think it is. In other words, I think you're patting yourself on the back a little much for figuring out how to chew before swallowing.

leggomylibro 9y ago

>To a business they see software/engineers as a expense. Anecdotally, this is one of the first things I try to gauge at a prospective employer. "Are their development teams seen as cost centers, or profit centers?" If the company works with technology a lot and doesn't see technology as being particularly important to its bottom line, that's usually a bad sign. Also, discussions with C-levels tend to be pretty one-dimensional. It doesn't matter how much their infrastructure is falling apart, they'll still stonewall with something along the lines of, "our goal this quarter is new user acquisition - how does this improve those numbers?" And they won't accept, "users cannot sign up if everything is broken" as an answer.

hackits 9y ago
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.
dreamfactored 9y ago
>"Are their development teams seen as cost centers, or profit centers?" It's not a matter of opinion, but what the term means. They are cost centers unless they are closing sales (or being billed for about 3x what they cost, which is still way less than sales people will generate, being closer to 10x+ cost). Best thing any employee can do is find out how their company actually makes money and understand how they align. Unfortunately, the highest business expense is salaries and one of the most important things for most businesses is remaining runway. So there is huge pressure to keep salaries down, particularly in cost centres, which aren't directly extending runway. If it's a service business it can get worse, as the money is typically made on billable hours - creating a perverse incentive to have cheaper and less efficient people to bill out rather than a 10xer (outside a senior business facing role). As long as they are capable and not so bad that they lose the client, it's often more efficient to have cheaper mediocre people from a business point of view.
- scrpn 9y ago
  How can a software developer fight against this salary limitation?
  - dreamfactored 9y ago
    Become a highly sought after specialist for a product offering (e.g. self-driving cars, blockchain, fintech), or get ownership (startup), or go customer facing (particularly if commission involved), or go into technical management on CTO route.
- marcosdumay 9y ago
  > one of the most important things for most businesses is remaining runway Remaining runway is a measure that only exist for companies in the red. For most business it doesn't even exist.
  - dreamfactored 9y ago
    How long you can continue operations if sales drops off a cliff is a very important number for every company I've worked at, from startups to big multinationals. Maybe it's less of a consideration for Amazon and Apple but I wouldn't even bet on it there.
jacquesm 9y ago
The better question to ask in my opinion is whether or not they activate their IP on the balance sheet. If they do there is a very good chance that they care about the quality. If they don't then there is a very good chance they treat software as something disposable.

ryanmarsh 9y ago

> Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Jesus Christ listen to yourself. You don’t know anything about me or how I approach things with my clients. I care about how code affects humans but business don’t have to be responsible for how they hurt people with it.

outworlder 9y ago

> Get out of your cube and go and meet CEO's and CIO Oh right. Good luck even ATTEMPTING to arrange a meeting with a Fortune company's CEO. "Who from what department again?". Worse yet if it not even your company's CEO. Maybe, if you are lucky, you can get to skip a level or too. Software engineers are usually very far removed from the top leadership.

ryanmarsh 9y ago
I routinely talk to CIO’s. They’re often the ones who hire me.

tarsinge 9y ago

Yet my experience is that the issue comes from engineering a lot of times: fixing bugs is not fun, let’s rewrite everything because this time we learned from our errors, or just to use the new shiny framework. A buggy legacy code base that no one wants to touch or improve, and V2/New projects that of course completely fail to deliver in the end and the cycle repeats. Being in a customer team I try everyday to make Engineering care about non technical end users. My team and business might be responsible for some feature creep, but bad code quality comes from engineering practices. Edit: to be more clear the discussion usually goes like this: - Me: “where are we on fixing this bug? it’s been two years and customers are still complaining” - Engineering: “we can’t touch at this component it’s a mess but we are rewriting it, this bug will no longer exists and it’ll be so much powerful, just wait a few month” We all know how it ends. And when business pressure comes because it failed to deliver it’s all “business is evil we need more time to do great software!” What we really need is senior and experienced engineers IMHO

doktrin 9y ago

> Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Implied in this statement is that the parent has a myopic perspective on the business world. Based on my read of his comment, I don't think that's fair - and moreover would question whether or not your perspective is as unique as you apparently think it is. In other words, I think you're patting yourself on the back a little much for figuring out how to chew before swallowing.