Skip to main content
Gun.io Home

The amazing business of being ‘uncool’ with Nav Bhachech of Microsoft and Amazon

In this episode, Ledge sits down with Nav Bhachech, who boasts an impressive CV having worked at both Microsoft and Amazon, to talk about his work with various SV-area startups.

Nav goes into detail about his work with developing Microsoft Office apps, utilizing add-on and API functionality in standard Office applications. He discusses the issues with developing systems that aren’t considered ‘cool’, but are highly valued by those that use them.

Nav also reflects on his career, particularly what he’s learned with regard to scalability. ‘Scale has a zillion different dimensions’, he says, while going on to discuss the difficulting to scaling the recruitment process – In summation, ‘we need a consistent culture – one that values excellence in engineering’.


David Ledgerwood
David Ledgerwood
· 22 min

Transcript

Ledge: Nav, it’s good to have you on. Thanks for joining us today.

Nav: Thanks for having me.

Ledge: Could you just give maybe a two or three minute background story of yourself and your work, and what you’re interested in these days?

Nav: Sure. I started out with a degree in computer science. Went through some big tech companies over the years. I worked at Microsoft for a while and then Amazon AWS for a while.

In the last several years I’ve been working right here in California, on startups mostly. It’s been I guess three different startups in the past five years.

That’s the background. Typically managing engineering for teams of anywhere from 10 to 50 people.

Ledge: A million things to unpack with growing, scaling, maintaining engineering teams.

Off-mike, we talked a little bit about some of the Office app work that you’ve been doing. I loved the topic. I’d love if you could give a little color to that and we can dive in?

Nav: Sure. Typically, most times when you talk about an app it’s a traditional web app, using whatever, React, whatever framework you have talking to some backend and presenting a nice GUI to the user, making it easy to use. Sometimes it can be a mobile app as well, sort of the iOS or whatever. Those are the predominant models for how people think of apps.

The Office apps thing is a little different in that, Office itself – Word, Excel, PowerPoint or even Google Docs – it presents such a familiar paradigm for most users that one of the things that I’ve had the luxury of doing in the past few years is actually building apps that are embedded as add-ins within this environment.

Instead of presenting the user separate, self-contained app in the browser or in their mobile device, it’s like, hey, they’re already in Office probably doing something – updating their spreadsheet or their Word document – why not bring in the business functionality into that through add-ins? That work can really well for sets of powers users who want to do more things with Word or Excel or Google Docs, as the case may be.

Ledge: If I still do any hacking it’s around Google Apps Script, and trying to write my own functions in Google Sheets to create new and interesting calculations or formulas. I’ve gotten pretty far from code but that’s still a lot of fun.

I find it, even as a guy who hasn’t coded in quite a while, that I can still hack together what I need from the documentation. It’s a very rich ecosystem. Microsoft Office offers a tremendous amount there. I do think you’re right, that there are business opportunities to meet the user where they are and to develop more things in that category.

Other than that, I’m not super familiar with it. What does the space look like, and what’s been your experience there on what worked and what didn’t?

Nav: I think it tends to work really well when the user has a very specialized need.

CertainT is one of the companies that I’ve work with, and what they provided is essentially add-ins in Word and Excel that allowed accountants to access specialized accounting data. There’s taxonomies that you present tagged data to the SEC with when you’re filing your annual reports and such. Most of that work happens right inside a fairly complicated document that’s scrutinized pretty heavily from a legal and financial perspective.

Rather than take them out into a completely different app, we kept them in there and brought in all the business functionality that they needed for the tagging and the taxonomies and all the financial information that they needed, and pulled that in into the document via just an add-in in Office. That’s kind of other thing.

Another example is at Bedrock Analytics, which is a company I also work with now. What they do is, they have very specialized sales presentations that they want pulled directly into PowerPoint. Rather than take the user out into this web app, where they’re trying to find the visualization they like and then do a screenshot of that pull that into PowerPoint eventually, wouldn’t it be nice if you just gave them the PowerPoint directly instead?

Those are the kinds of apps that I think work really well, but it’s a fairly specialized application and the endgame is to produce this Office deliverable in the form of a doc or a spreadsheet or presentation. You make it so that the user just sort of starts and ends their business process right inside that application.

Ledge: Does it become portable then? If you’re obviously using some kind of API or maybe even a direct database connection for things of that nature, does it then turn the Office document into sort of required-to-be-online type of thing?

Nav: Not necessarily. A lot of that depends on the architecture. Good architecture still applies even in these application environments. You still want your APIs and secure access and all those things in the backend. But, given that you’re operating inside Word as an add-in – and there’s many different technologies; you can use Vista, you can use Office JS, you can use some of your older legacy technologies; that technology stack has evolved quite a bit over the last several years – you still keep your separation in terms of having a clean backend. You just sort of pull that in into the Word document and then you can save locally or on the cloud, and you essentially have these options.

Architecturally, you’re not particularly limited except that most of your development happens inside the context of a single Word document or a single Excel document.

Ledge: It almost seems like the paradigm is where the browser has now become almost the de-facto container for development. That you’re really saying, hey, there’s these other applications that behave in a similar context that you can do some really exciting things with, particularly anybody who maybe is interested in approaching a large or enterprise-size market. You just know that Office 365 penetration on the corporate desktop is tremendous. You don’t really need to think about taking people out of the specialized SME workflow that they’re used to. There’s an entrepreneurial opportunity there.

I don’t know that a lot of people maybe are aware of that, despite Microsoft probably trying to make people aware of it. Certainly Google add-ons are a big deal now. These are marketplaces and they’re really app stores, but just with a different… It’s not a phone, it’s a business application.

Maybe talk about the economics and the understanding there around how entrepreneurs could really think differently about solving business problems with this tool set.

Nav: Certainly, you can sell your add-ins on the marketplace, but I think the most popular model I’ve seen for that that works pretty well is, it’s typically tied to a SaaS service. The ad in itself is a free download, but then you log into authenticated sessions with a SaaS service on the backend that’s providing the kind of data manipulation that’s happening inside the add-in. That’s the most common paradigm that I’ve seen, and that’s kind of what I’ve built also over the years.

Then, once the add-in is in, you can use it to manipulate the content of the Office document, or you can provide a task pane that allows the user to do specific business processes that might be interacting with external data, pulling in that data and pushing it straight into the content. You can add commands that augment the toolbar inside Office and things like that, to call out the specific business functionality that you’re providing in the application.

Ledge: So it’s really kind of like a growth vector then.

I know, for example, a lot of folks would want to be, I don’t know, in the Salesforce marketplace because, if I can interact with Salesforce and have distribution it’s really a growth channel to be able and available to do these things, because it causes more demand.

Nav: Yeah. It certainly is a growth channel. To the extent that those marketplaces thrive and people start looking for more kinds of apps and things on them, hopefully it continues to grow.

I think for a power user that wants to start with… I mean, you want to analyze stock history, there’s a hundred different websites that present kind of the graphics that show you, here’s the history for this stock. But if you think of something unique that you want to do, as in, maybe I’ve got these Excel sheets that have to do something like that, wouldn’t it be nice if I could actually have a little add-in that sort of plugs into Excel and pulls in the data I want, but then lets me work in Excel and do any sort of other magic that I want to do in Excel by myself?

A lot of power users want to do that sort of thing, and having these add-ins allows them to pull in data and access these backend services that otherwise may or not be available outside Excel.

Ledge: Right. You’re really going to be meeting the user where they are, which is the paying user. They want to do those things. They want to be enabled.

That paradigm in financial services and advisory is a really good example, I’ve got if I’m, I don’t know, CFA or CFP, I want to be able to have access those tools and yet present them in a non-web context to potentially non-technical users who have a lot of money that I manage.

I imagine there’s tons of use cases for that in healthcare, or in financial or other scenarios that data access is valuable.

Nav: Absolutely. You can use it as a very legitimate point to do integration, and leave behind your sales presentation for the customer after you’ve used it to pull in the data from any backend systems that you’re talking to. Integration is actually a very common scenario in these.

Let’s take on the sales case or the sales example, where let’s say I’m trying to integrate Salesforce data on the backend and try and push it into a PowerPoint slide. I’ve got the ability to manipulate the content in my PowerPoint slide in my add-in. I’ve got a task pane that calls out to my web APIs in there, and pulls in the latest data from, say, Salesforce which talks about closed deals or whatever I’m trying to present to my client. Pull in the latest, greatest data. Build the PowerPoint with the right template that is specific to the client I’m presenting to. Get all the things that I might want to present in that single PowerPoint. Then hand in that PowerPoint on my way out of the door.

The application really through these task panes and content editing and the new commands you’ve added to there, allows you to do a leave-behind for the customer that is highly customized to them, and pulls in the latest, greatest data that your backend systems are providing for you.

Ledge: Why do you think young startups maybe don’t use this very much? It certainly isn’t the most requested thing.

Everybody thinks you’re going to do your own data visualizations in the browser, maybe have export to Tableau or something of that nature, other BI tools, and yet this stuff has the most ubiquitous user base probably on the planet.

This isn’t happening as much. Is that a failure of marketing from, I don’t know, Microsoft or something? How do you tie this together?

Nav: I guess part of it is it just hasn’t been the cool, sexy thing that developers go after. All the action, if you will, has been on the cool, new web libraries. On the mobile side too with IOS and Android and things like that, there’s been a lot of like cool factor to that. Office has kind of been this thing in the back that, that’s what the accountants use, or, hey, cool developers don’t tend to use that.

I think that has started changing just a little bit because, as you said, Office JS from Microsoft and Google Docs has their own set of APIs as well that lets you work those documents.

I think those technologies are now evolving. A lot of them are now JavaScript based. When you think of Office development it’s like, VB Macros. That was so long ago. Now you actually have Office JS with basically APIs that are Excel specific, and I think they’re up to 1.8 for Excel and 1.4 for Word now. So there’s these legitimate JavaScript based APIs that let you do all these cool things, that work in the browser and in the offline or in the desktop version, I should say.

That combination, I think, is going to start making it cool again. It’s kind of been relegated to the background, but with the evolution of the technologies, I think it’s starting to become cool and interesting again. The use cases right now are still specialized in niches but I think hopefully that grows over time, because as the cool technologies are coming in, more people will see that and hopefully there’s more applications for that.

Ledge: What do you wish it had that it doesn’t, to take it to the next level? It is still evolving so, what’s missing to get to that next stage where every Office application or every application becomes a vector for just completely malleable add-on data from a web service?

Nav: I think some of the frameworks are coming by but they’re still pretty vendor-specific. Office JS has Fabric UI and this ecosystem around it that lets you do Office development. Google Docs has their own APIs that takes you in another direction.

If you want to deliver this thing as a concept saying, hey, I do Office add-ins regardless of Google or Microsoft, there’s no common ecosystem for that right now. It tends to be super vendor-specific. Which is fine because there’s zillions of Office users and, not quite as many, but several millions of Google Doc users as well.

I think those are fine populations to start with but, if you could have the application paradigm emerge with its own ecosystem saying, hey, the concept here is to present an add-in into an Office document, be it Google or Microsoft, if that kind of thing starts to take off, that would be cool to see. That could give a shot in the arm to this.

Ledge: That’s going to be your side project, right? You know, open ?

Nav: That would be fun, actually. A set of a libraries to do that.

Ledge: Universal Office plug in infrastructure.

Let me pivot a little bit. You’ve run big engineering teams, you’ve grown engineering teams. A big topic around almost every conversation I have is like, jeez, how do you scale engineering? It’s different, and it has such a critical function now. There’s so much coming together.

Thoughts and learnings from your career?

Nav: Sure. I think there’s these different dimensions to the scaling as well, has been my learning, because every time you’re scaling something different it seems, You never really stop scaling in that sense.

It could be core scalability stuff like, okay, liability, availability, number of users. That kind of technical scaling type of stuff. Scale up, scale out. You’ve got all these paradigms in place to do that kind of thing. Then on the team side it’s like, how do I scale my processes, how do I scale my people to think bigger and better as my application grows and things like that?

The key takeaway is, scale has a zillion different dimensions and most people start with it on the technical side, but really the hard part to scale is my hiring process that I am basically getting the same capability engineer even when I’m not involved in the recruiting process, or somebody completely different is running it.

Scaling and standardizing that process. Making sure that the knowledge scales across your organization so that the expectations for quality, for instance, or how an engineer might approach something are relatively consistent for senior engineers. Those kinds of things, the people things, are the harder things to scale, as you can imagine. Yeah, that’s kind of been the key takeaway.

The tech stuff tends to be easy after you’ve looked on Stack Overflow and read a few books and done all these things, that part is the easy stuff. But getting the processes and people issues to scale, that remains hard.

Ledge: Are there any resources you’d suggest for the people? Angles? I think, like you said, there’s a lot of resources that are standardized and centralized for the technical scaling, and it’s pretty easy to Google that. The other stuff is more fragmented.

What are the resources you would lean on there for people who want to learn that?

Nav: A lot of that, I’ve been able to rely on just company culture type stuff. Hiring the right kind of people, for instance, you want to make sure you have enough of your core team who’s similarly like-minded and knows what to look for. Knows how to drill down to the layers of understanding a candidate may have about an issue and then be able to do that properly.

I think there’s no boilerplate resources there but it comes down to, have the Canonical good engineers on your team who can seed both the knowledge and the culture and make sure that that propagates through the core initial team. Resource-wise, I probably can’t point you to specific resources there, but making sure that it’s a consistent culture and one that values excellence in engineering. Just start that right and then keep that flowing or going.

Ledge: Good luck and go get some experience, right?

Nav: There you go.

Ledge: Experience is recognizing mistake when you make it again?

Nav: Yeah. Or insanity, when you keep doing the same thing over and over. Something like that.

Ledge: Nav, thanks for spending time with us, and thanks for the insights today.

Nav: Likewise. Thank you. Thank you for having me.