[conductr]

While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere.

I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales, or somebody else is really pushing for the investment. That's the point where a technical person takes over and builds what's asked, or a really great technical person may ask a few questions and raise a few points nobody else considered and the whole bubble bursts as we realize it's not feasible/or we can test it in a certain way before investing big time/money into it.

Probably not mastery of SE as OP asked. But mastery as a business partner within an organization.

[healsjnr1]

That sounds amazing, sadly in a lot of organisations that isn't how it pans out.

Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.

The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.

[disgruntledphd2]

It depends on the organisation, to be honest.

For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built.

(My favourite time was when a (really smart, to be fair) software engineer rediscovered the normal distribution while looking for a way to reduce storage requirements for an analytics product).

[robertlagrant]

If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.

[disgruntledphd2]

Sure, there are pathologies at both ends of the spectrum. I do think it's worthwhile (particularly here), that software engineers/technical people are subject to their own set of development pathologies.

[robertlagrant]

That's fair, yes.

[PaulHoule]

The FANG method of software dev is extraordinarily expensive, particularly at the G.

[conductr]

True. I’ve witness all of these things as well. I’m not implying that organizational decision making is perfect if only it had better technical people providing inputs by any means.

Again as a finance guy, this is a major skill I have attempted to develop for myself/team. When projects spin up, I’m typically at forefront and involved in every project technical or not (controlling the purse strings). Many finance guys are know it all’s TBH. They build their ROI models, etc. and making dozens of assumptions it’s then treated as gospel. For some reason, it’s valid to ask “why is this project underperforming our expectations” but it’s often taboo to ask “did our expectations even make sense”. I try to change that where it exists too.

All to say, people like me find people at the onset of the project to gather inputs. If I know you as well versed with track record of valuable insights, I’m more likely to reach out early. If I have worked with you at this stage and you your input is just one of “we need specs/tell us what to build and we can build it” you’ve not added any value to the conversation and I’m likely to not include you next time because I know I just need to bring you specs once project is approved and that’s a different conversation for another day.

This is why I say “business partner”. Being able to understand your company, the politics within, how decisions are made, where you can inject value along the way. These are all traits of people with fast career growth in slower growing firms. You transform from Programmer #13 to people knowing and respecting your name. This is important in talent reviews, etc.

[vram22]

Good one. Another on the same lines, and also related to your parent comment's point about politics, is:

Getting the users in the org to, you know, actually use that well-specced, well-built project, which was delivered within time and budget (or with only a small overrun). I mean, use it at all, or use it enough for it to deliver its benefits. Real life issue. Seen it on at least a few projects I've worked on, including two early in my career. Inertia, luddite fears, turf wars can be some of the causes.

[vram22]

Here is another example of a project or feature users did not use at all, or used less than was expected / wished for. This one is from a Google Talk:

Watch "The Effective Engineer | Edmond Lau | Talks at Google" on YouTube https://youtu.be/BnIz7H5ruy0 - at about 3:21 in.

[asdffdsa]

The most difficult hurdle is that there's never that direct communication between the finance guy and the tech guy. Projects tend to get lost in translation, where you have multiple layers of departments and emails and roles playing telephone. If an organization can have that direct finance-to-tech guy/gal link, it would be the most effective way to provide the most effective value imo.

[conductr]

It’s definitely a problem worth focus. I recommend networking with some of the finance folks. It’s as simple as a lunch meeting, ask them about some of the projects that are in planning phase, offer your assistance. You’ll have to figure out what is the post-COVID equivalent.

I find some in finance and IT get along fairly well and can build a bigger rapport fairly easy. We’re all excel nerds and many of us have taught ourselves how to program to an extent (VBA, etc).

Depending on the organization, we tend to be more focused on leadership support. A junior analyst will get much more face time with VP and up than down. So that’s part of the problem is those connections just don’t always exist. When they do, it might be with an IT director which has maybe become too far removed from codebase or implementation challenges. It happens with every department within the organization, not just IT. My experience is outside the software industry so may work a little different if sole function of the company is software.