Skip to main content

Leaving Microsoft

Some of you might know this, some might not so here is the major announcement: I am leaving Microsoft.

First of all I want to tell you what I am going to be doing next. I am going to be an Engagement Manager working for DocuSign, Inc. You can check out more about the company on this website: www.docusign.com

What exactly will my job entail?
I will be managing projects which interface with DocuSign partners. It's going to be part professional services that DocuSign can bill for and part technical evangelism for other companies to use DocuSign technology.

I will also be travelling mostly to New York, San Francisco, Texas and North Carolina.

Why is this a step up for me when compared to my Microsoft gig?
First because it's a position where I can utilize my customer facing skills as well as my technology skills. Secondly because I will be working with Tom Gonser an entrepreneur and a person I respect for being able to put together businesses. Thirdly it's because both the base pay and the potential for me to make millions are greatly increased at DocuSign.

Microsoft is a great company for someone who wants to drill in deep into technology and it's also a very stable company where the benefits are great. I don't have a family and I rarely get really sick so I am effectively subsidizing benefits and "work/life" balance of 40 year old Microsofties. This is the time for me to get out, take risks and try to make a name for myself.

I do love the team I was working on at Microsoft. Windows Media Center is a great product and we all made it even better! Now it's time for me to kick butt and create something at DocuSign. The impact is going to be less global, but I am confident that with the team we have at one point in time it will be a global impact company. Online legally binding signatures are the WAY TO GO.

Comments

Popular posts from this blog

Quality of Code is Quality of Life

About 20 years ago when I started working in technology companies I remember “the best” engineers had similar patterns:
-They worked crazy hours
-They knew the systems no one else knew
-They could react and deliver something faster than anyone else
You could always hear other employees say: “Bob is really smart, no one knows how to get anything done in system X besides him!”

This reinforced optimization around being the only person who knew how to do something in some part of the code.  That in turn reinforced job security and bargaining for those engineers, but also chained them to a particular system.  We had big code bases of C++ or Java code where some “Bob” hacked up features as soon as he possibly could.  “Bob” would have occasional nuclear disasters where he’d sleep in the office or through the weekend and then everyone would thank him for how he “saved the day.”  “Bob” sacrificed his quality of life to get praise when he hacked stuff up quickly and then the second time when n…

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team.

I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me!


SDE/T or QA Engineer interview checklist from Mike Borozdin
If you like this checklist you might want to check out these posts:
Emotional Intelligence in Software Teams  and Good-bye manual tester, hello crowdsourcing!

Code versus Configuration

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of
different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers.

Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily accessible…