Subscribe to this blog

Follow by Email

Search This Blog

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.

Conclusion

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

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!

Silicon Valley is full of advice and it frequently comes from people who have little experience on the subject matter. A popular topic surrounds hiring and terminations with the king catch phrase being: “Hire Fast, Fire Fast.” To me, what that usually means is lack of diligence, thought, communication and courage.

When hiring people love going with their gut feel, often with disastrous results. There is an obvious subject of diversity of thought, appearance and background. When thinking “fast” you are probably hiring people like yourself because humans quickly react to people who they believe are in their tribe.

A startup that lacks the resources of a big company often becomes so desperate to get technical staff that when a decent candidate comes along, excitement ensues and the employer doesn't slow down to put them through a more rigorous hiring process.

I highly encourage technical founders and engineering executives to write out their precise hiring process. Of course, y…

Software development involves a great deal of collaboration. One of the most basic blocks of collaboration on a software development team is a code review. There have been many different ways of doing code reviews over time, some of this has been dictated by the tools available. Git and online source collaboration tools created a set of best practices that are worthwhile of adopting on any team.

About a month ago I have looked at various articles about how to best create a Pull Request (PR) and do a code review and the attached presentation is the result of this research. The presentation can help you guide your team and develop a set of collaboration practices that works for your particular situation.

It’s good to start out with why to seek a code review. Having clarity about your intentions helps you guide the person helping you with code reviews and also to manage your expectations about you can get out of the code review. The reasons for seeking a code review are generally …