Jump to content

Escalating support issues


Recommended Posts

You can always try calling in on a new case or transfer to a different technical support engineer (I know if used to give you this option if someone wasn't picking up). You don't have to ask them the same question but they should be able to tell you what's going on at least (someone's OOO, case is in some bad state, or more often than not both people think they're waiting for information from the other).

Link to comment

Historically support is something I've said NI and Microsoft both have been done well.  Lately I'm having a harder time lately singing NI's praises for support.

NI used to have all new hires work support first before going to other departments.  This in general made support a bit green, and you'd need to escalate a couple of times before getting what you needed.  My career started as a co-op and so being thrown into the deep end of the pool certainly helped me learn quickly.  And I liked the idea of NI people all starting out having to quickly get familiar with NI's offerings, and being close to the customer issues.  I suspect NI has gotten feedback over the years that this model for support didn't work well and I heard NI was changing this policy.

  • Sad 1
Link to comment
On 11/10/2021 at 9:06 AM, hooovahh said:

NI used to have all new hires work support first before going to other departments.  This in general made support a bit green, and you'd need to escalate a couple of times before getting what you needed.  My career started as a co-op and so being thrown into the deep end of the pool certainly helped me learn quickly.  And I liked the idea of NI people all starting out having to quickly get familiar with NI's offerings, and being close to the customer issues.  I suspect NI has gotten feedback over the years that this model for support didn't work well and I heard NI was changing this policy.

You are correct that phone/email support is now being handled by a separate Technical Support Engineering (TSE) team which is now a career position (meaning they have senior/principal level engineers working in the department). As examples, you now have folks like Darren N and Norm K working as TSEs. This is still a relatively new change (2 years?) so there are still a lot of newer engineers but I think things are moving in the right direction with hiring very experienced engineers and being able to keep engineers within the department rather than constant attrition to other areas within NI. I know a few people in that group who started there out of college and are still there 5+ years later which definitely would not have happened previously.

Link to comment

When I started at NI Switzerland in 1992, things were indeed very different. For 4 months I went to Austin and I would get technical support calls that I of course had no idea how to solve. But we could walk up one floor or two and talk directly with the software or hardware engineers that were responsible for the product in question.

As NI grew, this support model wasn't quite supportable anymore. Engineers still usually started out in support and often moved rather sooner than later to another position and walking up to the developers wasn't as simple as they weren't always just one floor higher but in a different building. Support still was handled by inside engineers though, usually with a tiered level, first support was handled by first line supporters who would respond to the standard problems, and if it got to complicated it moved up to 2nd or 3rd line support. Then it was outsourced to some extend to telephone support somewhere in Costa Rica or wherever and from then on it was often pretty much impossible to get any meaningful response. The answers we would get were sometimes so abysmal that I could have asked my son and would have gotten more meaningful information and it was often impossible to explain to them the problem, as they understood nothing but what their onscreen step for step problem solving tutorials told them.

Then a few years back, like 2 or 3, NI recognized that this was not really working and changed to a more professional support infrastructure with a dedicated Technical Support Engineering model that actually deserved that name. If someone has a support contract or maintenance software contract, then this support works again very well, although in comparison to 25 years ago, it is practically impossible to get non official solutions that are just gathered by the support person from walking up to the actual developer who would throw together a quick (and sometimes dirty) solution to achieve the goal. Things are much more formalized, and unless someone is from a huge multi-million $ account, it's impossible to get a bugfix release of software or something like that, before the official release.

Edited by Rolf Kalbermatter
Link to comment
On 11/12/2021 at 7:50 AM, Rolf Kalbermatter said:

When I started at NI Switzerland in 1992, things were indeed very different.

Tell us more about that time... Was that before the release of the first Windows version?

I have the two demo disks for the 2.5.1 Windows version sitting on a shelf (never used by me, I just found them among stuff left by a retired employee).

Link to comment
19 hours ago, X___ said:

Tell us more about that time... Was that before the release of the first Windows version?

I have the two demo disks for the 2.5.1 Windows version sitting on a shelf (never used by me, I just found them among stuff left by a retired employee).

Well I started in April 1992, went to the US for 4 months in May and heard there that there was this big news about LabVIEW not being for Macintosh only anymore, but telling anyone outside of the company would be equivalent to asking to be terminated 😀. They were VERY secretive about this and nobody outside the company was supposed to know until the big release event.

In fall of 1992 LabVIEW for Windows 3.1 was announced and the first version shipped was 2.5. It was quickly followed by 2.5.1 which ironed out some nasty bugs and then there was a 2.5.2 release later on that made everything more stable, before they went to go to release the 3.0 version which was the first one to be really multiplatform. 2.2.1 was the last Mac version before that and 2.5.2 was the Windows version. They could not read each others files.

This was Windows 3.1 which was 16-bit and still just a graphical shell on top of DOS. LabVIEW used the DOS/4GW DOS Extender from Tenberry Software, that was part of the Watcom C development environment used to compile LabVIEW for Windows to provide a flat 32-bit memory model to the LabVIEW process, without nasty segment:offset memory addressing. It was also the reason that interfacing to Windows DLLs was quite a chore because of the difference in memory model between the LabVIEW environment and the underlying OS and DLLs. Only when LabVIEW was available for true 32-bit environments like Windows 95 and NT, did that barrier go away.

NI was at that time still predominantly a GPIB hardware company. A significant part of support was for customers trying to get the various GPIB boards installed on their computers and you had at that time more very different computers architectures than you could count on both hands and feet. There was of course the Macintosh and the IBM compatible computers, with all of them running DOS which Windows computers still were. Then you had the "real" IBM computers who had abandoned the ISA bus in favor of their own, more closed down Microchannel bus and also were starting to run OS/2 rather than Windows and about a dozen different Unix based workstations all with their totally incompatible Unix variant. And then even more exotic beasts like DEC VAX computers with their own expansion slots. Supporting those things was often a nightmare as there was literally nobody knowing how these beasts worked except the software driver developer in Austin and the customers IT administrator.

NI had just entered the data acquisition marked and was battling against more established manufacturers like Keithley, Data Translation, and some other small scale speciality market providers. The turning point was likely when NI started to create their own ASICS which allowed them to produce much smaller, cheaper and more performant hardware at the fraction of the cost their competitors had to pay to build their own products and still selling them at a premium as they also provided the full software support with drivers and everything for their own popular software solutions.

With other manufacturers you usually had to buy the various drivers, especially for NI software, as an extra and some of them just had taken the blueprints of the hardware and copied them and blatantly told their customers to request the software drivers from their competitor as the hardware was register for register compatible with theirs. The NI ASICS made copying of hardware by others pretty much impossible so NI was never concerned about making their drivers available for free.

Edited by Rolf Kalbermatter
  • Like 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.