Skip to main content

Lessons from my 9 Year Journey with DocuSign

After over 9 years at DocuSign I am taking on a new challenge.  It’s been phenomenal seeing the
company grow from from 25 to 2000 employees.  DocuSign has changed the way the people do business and I am proud of it.  The next chapter is going to be heading up software development at Tempo Automation - a 25 person startup that is changing the way people produce electronics.  While I am extremely excited about the future, this is a good time to reflect on my journey and share the things that contributed to the success and things that I will do differently next time around.

1: Focus on the Customer

DocuSign Developer Tools and Partner Apps Team
One of the key things that contributed to the success of DocuSign and my personal career is relentless focus on the customer success.  From the very beginning our CTO has taken meetings, listened and prioritized requests and feedback coming from customers.  People who could not be bothered by customer requests didn’t last long.  As a result over time our engineering team retained and rewarded people who had a connection and compassion for the people we served.

Our customers always noticed how responsive our engineers were.  When things went wrong we got on the phone with our users and prioritized fixing those issues.  We accumulated a lot of good will and customers were willing to cut us some slack because they knew we’d make things right.

I never shied away from giving out my e-mail, taking meetings and learning about customer needs.  Over time I have become more and more aware of what our users needed and from just following orders I have developed enough context to start crafting my own mission.  A person who can figure out what needs to be done and get it done is an incredibly valuable employee in a growing organization.  That person over time will own some product or customer segment and with it will grow their responsibility, compensation and get recognized.

For me that market segment was partners and developers.  I’ve created the team that owned the DocuSign DevCenter, opened up the API and integrated DocuSign into strategic partner applications (Salesforce, Google, Microsoft and others), over time the share of 3rd party developer transactions grew to over 50% of DocuSign’s overall volume.  My team grew and I became a Sr. Director reporting to our CTO.

2: Understand how your activity contributes to the bottom line

Initiative is a good thing when it’s applied in the right direction, it’s a horrible waste of resources when it’s pulling the company in the wrong direction.  While applying the first advice in a way that benefits everyone will get you promoted, applying it in a way that takes resources off course will probably get you fired.

Technical folks need to figure out how their technology benefits the company strategy, whether it’s getting more users, maximizing engagement or revenue.  As you are taking the initiative it’s fine to take some time and create a prototype, but very soon you need to calibrate this with some other team members and most importantly your users.

It’s also a great habit to connect the requests that people have on your time to the bottom line.  There have been many times when some Executive or Business Development Manager would come to Engineering and ask if we could create some feature.  Early on I would just take these requests at face value, but after going off and working hard on something that no one wanted I got a bit smarter.  If there was no obvious customer need I pressed the requestor to provide some evidence of the customer need.

The company and you will only benefit when you create something useful.  A lot of times creating something useful means not being tied up on something that’s not useful.  You might be the best engineer on the planet but if you work on something no one wants, no one will give you additional resources or value your work.

3: Work hard and then work even harder

It’s popular to talk about balance and about “working smarter not harder”, truth is that you are about average.  If you are just doing what you are supposed to do - don’t expect anything to be different.  You should always figure out a better way to do stuff, but if you are hoping to keep up with an explosive company - you need to run 2 times faster.

I can’t advise you on how to prioritize things in your life, but I don’t think I have worked many weeks less than 50-60 hours a week and I spent most of them at the office or with customers.  For me that was balance - I still took the time to work out in the morning before the day started.  I had time on the weekends to catch up with friends and write these blog post, but I was relentless about putting in focused time at work.

All of this focused effort was aligned to benefit DocuSign customers (Advice #1) and contributed to the company bottom line (Advice #2).  It wasn’t recognized all the time, but it was recognized often enough.  After a while if you keep on making a difference you become a key person at the company.

Forget all the people who come forward with stories about how they worked hard for nothing.  Forget all the people who blame their circumstances for not getting ahead.  People who work hard on meaningful things generally get further than people who are not working hard or aren’t working on things that matter.  The odds are not 100% but you are in charge of increasing them.

4: Network internally

I am an introvert.  I am completely content showing up in the morning and just working on the product.  I had to make an effort to connect with people on my team and around the company.

There are plenty of “life hacks” on this such as never eating lunch alone.  Another key thing is being approachable and helping people when they need help.  A lot of technical people make you feel like an idiot if you ask them something that they know - that’s counter productive.  People who ask you about a bug or how to use a feature might know a lot about a customer relationship or a business deal.  Growing the network internally will pay tremendous dividends.  I was able to execute company wide projects like pricing changes, product direction, worked on partnerships and was generally more about about what mattered.

Being in the office (Advice #3) comes in very handy here as well.  Just being around allowed me to join people for coffee, ask them what they were working on and also follow up on my requests in person.


I hope these lessons from my journey with DocuSign help you grow within your company.  It certainly helps to be in a company that is going through explosive growth and has a bright future, but it’s not enough.  Being smart about what you focus on is also incredibly important and will help you and the company.


Popular posts from this blog

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 acce

Intuitive Programming - Comments

Comments are a topic of vibrant discussion.  Ever since programmers could leave some text in the program that was ignored by the machine the debate started: “what’s a good comment, what’s a bad comment, why comment?” There are endless instructions to programmers that say many of the following things: 1) Describe your function! 2) Don’t write in the comment what you wrote in the code. 3) Tell people why you are doing what you are doing. What I think has been missing from this discourse is the audience for comments and through those audiences there is intent.  The code is being read, skimmed or analyzed by people and tools.  So what are the audiences and reading modes? 1) Maintaining and enhancing the code 2) Skimming through the entire module or file to figure out what the overall structure is 3) Reviewing the test files to check out the test coverage and edge cases 4) Seeing the docstrings of functions while being in a separate file altogether 5) Reviewi