4 ms·

Depends on how high up the ladder the management is you're talking to. Your line manager may be interested in a technical issue / improvement and understand it

Depends on how high up the ladder the management is you're talking to. Your line manager may be interested in a technical issue / improvement and understand its value without further explanation -- for instance, we're using a brute force algorithm that takes exponential time to foo the bar in the Baz module. It's got test coverage and the problem has a known logarithmic solution, so we could rewrite that in a week to be more efficient, and still be confident it's accurate. Your department head may be willing to consider fixing a problem that affects efficiency or security or expected timelines -- we've identified the likely cause of at least one class of those outage events you've raised concerns about. If you want to fix it immediately, we would have to push back delivery of the Quux feature by a week while we rewrite a portion of the Baz application, but other risks are minimal. The C-suite is mostly interested in problems/solutions framed as "how does this save us money" or "how does this make us money" -- we intend to invest a week in technical maintenance work that will allow us to save 25% of our monthly hosting costs by scaling back hardware requirements, and reduce the frequency of outage events that we have to pay out for on under our SLAs by 75%. That would cost $10,000 in developer time and delay our product schedule by a small though measurable amount, but I estimate it would save us an average of $48,000/year in costs.

rootusrootus 9y ago
I wish I could upvote your comment several times over, thank you! As a [very] new development manager who has been a software engineer for many years, it is this kind of detail aggregation that I find difficult to really understand automatically (as in, I can do it, but it's hard to translate engineering-level detail on the fly without sounding kind of dumb, IMO).
jghn 9y ago
Exactly. The other piece I've seen is being able to handle "I want Foo by X". It's easy to take on the engineer mindset and say "Sorry, that's not possible. The whizbangs alone would take more than that time!", but what do you do when they simply repeat "I want Foo by X"?. Picture the various Star Trek series where the engineer would say it'd take 5 hours to fix something and the captain retorts "you have 2". It's real. The skill which really makes me jealous are the folks who are able to read between the lines and get at why they want Foo and why they need it by X. Instead of saying "Sorry, no can do!" they're able to offer Bar instead, and because they understand the deeper motivations of why Foo is being requested they understand why the manager is likely to accept Bar instead of Baz. This is pretty similar to your C-suite descriptions, now that I reread it. But it's a different spin on it.
- twobyfour 9y ago
  I agree - the why skill is crucial and difficult. I won't claim to be any good at it (it's actually one of the things my current manager excels at intuiting and I want to learn from him). One tactic I can suggest (if your manager isn't a totally unreasonable cartoon tyrant) is to simply be explicit about it and ask "can you explain more about why you need Foo?" and then "what's driving the deadline of X?" Understanding the business case is generally necessary - though not always sufficient - for coming up with an alternative solution. I suspect that part of the gap between people who are and are not good at this is how well apprised they are of the general conditions, initiatives in other departments/teams, and short-term strategic goals of the company. Some of that is on the person who may or may not put in the effort to remain informed; and some of that is on the company's management that may do a good or a poor job of communicating those things proactively between departments/teams and from senior management down to junior management and line workers.
  - jghn 9y ago
    All true statements. I've been working at it, but then I watch my boss who is also excellent at it, and I realize I'm a novice still. In comparison I just get frustrated and wind up frustrating them as well.
ZenoArrow 9y ago
> "Depends on how high up the ladder the management is you're talking to." Depends on the individual, not on the job title. In my experience, managers of any level value information as simply put as possible. If they ask questions, then you answer them, but otherwise just tell them what they need to know.

rootusrootus 9y ago

I wish I could upvote your comment several times over, thank you! As a [very] new development manager who has been a software engineer for many years, it is this kind of detail aggregation that I find difficult to really understand automatically (as in, I can do it, but it's hard to translate engineering-level detail on the fly without sounding kind of dumb, IMO).

jghn 9y ago

Exactly. The other piece I've seen is being able to handle "I want Foo by X". It's easy to take on the engineer mindset and say "Sorry, that's not possible. The whizbangs alone would take more than that time!", but what do you do when they simply repeat "I want Foo by X"?. Picture the various Star Trek series where the engineer would say it'd take 5 hours to fix something and the captain retorts "you have 2". It's real. The skill which really makes me jealous are the folks who are able to read between the lines and get at why they want Foo and why they need it by X. Instead of saying "Sorry, no can do!" they're able to offer Bar instead, and because they understand the deeper motivations of why Foo is being requested they understand why the manager is likely to accept Bar instead of Baz. This is pretty similar to your C-suite descriptions, now that I reread it. But it's a different spin on it.

twobyfour 9y ago
I agree - the why skill is crucial and difficult. I won't claim to be any good at it (it's actually one of the things my current manager excels at intuiting and I want to learn from him). One tactic I can suggest (if your manager isn't a totally unreasonable cartoon tyrant) is to simply be explicit about it and ask "can you explain more about why you need Foo?" and then "what's driving the deadline of X?" Understanding the business case is generally necessary - though not always sufficient - for coming up with an alternative solution. I suspect that part of the gap between people who are and are not good at this is how well apprised they are of the general conditions, initiatives in other departments/teams, and short-term strategic goals of the company. Some of that is on the person who may or may not put in the effort to remain informed; and some of that is on the company's management that may do a good or a poor job of communicating those things proactively between departments/teams and from senior management down to junior management and line workers.
- jghn 9y ago
  All true statements. I've been working at it, but then I watch my boss who is also excellent at it, and I realize I'm a novice still. In comparison I just get frustrated and wind up frustrating them as well.

ZenoArrow 9y ago

> "Depends on how high up the ladder the management is you're talking to." Depends on the individual, not on the job title. In my experience, managers of any level value information as simply put as possible. If they ask questions, then you answer them, but otherwise just tell them what they need to know.