« swipe left for tags/categories
swipe right to go back »
Before we started the strategy meeting, Matthew Bellows led us in a brief ritual where we “bowed in” to the meeting. At the end of the meeting, we all “bowed out.” I loved it – it set the tone of respect for each other at the start of the meeting and signaled the end of the meeting when we bowed out.
A few weeks ago, we had a Yesware board meeting. Matthew once again had us bow in to the meeting. This time there was a little bit of nervous laughter around the board table as it was the first time the full board had been exposed to this ritual. It wasn’t a negative tittering, just the sounds of a group encountering something unusual, interesting, and requiring some emotional intimacy while trying to process it in the moment.
Once again I loved it. It got me thinking about two things: (1) the importance of respect as a core value and (2) traditions that scale across the company.
Let’s start with respect. I’ve written about this many times on this blog. In 2004 I wrote a post titled TDC (Thinly Disguised Contempt). I learned about TDC from Alan Trefler, the CEO of Pega, who I don’t spend much time with but view as a long time friend and someone I’ve learned a lot from over the years. Early on at Feld Technologies, I learned how incredibly toxic TDC was and how critically important respect was. Respect for the people I work with, and the elimination of TDC from my mental state and behavior, is a core value of mine. Sure – I fail at it sometimes, but I keep practicing.
I have immense respect for Matthew as an entrepreneur and CEO. I’ve learned a lot from the few years I’ve worked with him. His calmness, even in moments of stress is powerful. The monastic culture he’s created at Yesware is inspiring. His execution as a leader, and the performance and cohesiveness of his team, is delightful to be part of.
Bowing in and bowing out made me gleeful. It was another wonderful example of something I could use in lots of other places and another thing I learned from Matthew. As I mulled it over, I realized the specific act wasn’t the key thing, but the power of a tradition that scales across the company. Bowing in and bowing out before and after each meeting. The gong that gets rung at Gnip every time a new sale is made or partner deal is signed. Or Paid PAID vacation at FullContact.
The combination of respect for every individual in the company combined with scalable traditions are incredibly powerful.
On Wednesday my partners and I had our monthly offsite. One of our rituals is a “check in” where we go around the table and each of us talks for as long as we want about how we are doing. Sometimes it’s a short discussion, other times it’s a long discussion. Since we do it monthly, nothing can build up. It’s similar to the monthly life dinner that I do with Amy - introspective, emotionally aware, and open. Some of these sessions have been incredibly powerful – on this one I had tears in my eyes at one moment as I was expressing appreciation for something my partners had done for me. And all of us had a powerful moment of calibration for everything we are feeling right now.
On Thursday I spent the morning with the Bullet Time Ventures team. This is the fund that David Cohen, the CEO of Techstars, founded. My partners and I are investors and huge supporters. The team was having an offsite and they asked me to participate in some of the discussion. I gave them a lot of suggestions and answered a lot of question, but one moment near the end stuck out in my mind when I was asked how my partners and I have managed to develop and sustain the deep personal and professional relationship we have, even with all the stress and conflict inherent in our business. I said that one of our deeply held beliefs is that we “never wear our armor to a meeting.” We call this being intellectually honest and emotional pure with each other. And it’s another example of linking respect with a scalable tradition – we never want to wear our armor in any of our interactions with each other.
Matthew – thank you for the gift of bow in and bow out. Both the specific action, and the reflection on the meaning of it.
My post on How to Fix Obamacare generated plenty of feedback – some public and some via email. One of the emails reinforced the challenge of “traditional software development” vs. the new generation of “Agile software development.” I started experiencing, and understanding, agile in 2004 when I made an investment in Rally Software. At the time it was an idea in Ryan Martens brain; today it is a public company valued around $600 million, employing around 400 people, and pacing the world of agile software development.
The email I received described the challenge of a large organization when confronted with the kind of legacy systems – and traditional software development processes – that Obamacare is saddled with. The solution – an agile one – just reinforces the power of “throw it away and start over” as an approach in these situations. Enjoy the story and contemplate whether it applies to your organization.
I just read your post on Fixing the Obamacare site.
It reminds me of my current project at my day job. The backend infrastructure that handles all the Internet connectivity and services for a world-wide distributed technology that was built by a team of 150 engineers overseas. The infrastructure is extremely unreliable and since there’s no good auditability of the services, no one can say for sure, but estimates vary from a 5% to 25% failure rate of all jobs through the system. For three years management has been trying to fix the problem, and the fix is always “just around the corner”. It’s broken at every level, from the week-long deployment processes, the 50% failure rate for deploys, and the inability to scale the service.
I’ve been arguing for years to rebuild it from scratch using modern processes (agile), modern architecture (decoupled web services), and modern technology (rails), and everyone has said “it’s impossible and it’ll cost too much.”
I finally convinced my manager to give me and one other engineer two months to work on a rearchitecture effort in secret, even though our group has nothing to do with the actual web services.
Starting from basic use cases, we architected a new, decoupled system from scratch, and chose one component to implement from scratch. It corresponds roughly to 1/6 of the existing system.
In two months we were able to build a new service that:
- scales to 3x the load with 1/4 the servers
- operates at seven 9s reliability
- deploys in 30 seconds
- implemented with 2 engineers compared to an estimated 25 for the old system
Suddenly the impossible is not just possible, it’s the best path forward. We have management buy-in, and they want to do the same for the rest of the services.
But no amount of talking would have convinced them after three years of being entrenched in the same old ways of doing things. We just had to go build it to prove our point.
Phin Barnes at First Round Capital just nails it today with his post To get the most out of your investors, turn them into rubber ducks.
Go read it – I’ll wait and will be here when you get back.
I love Rubber Duck Debugging. I use this approach when writing, which I call “Writing with Yoda.” I have a little Yoda figurine staring at me at all times and when I stall out I just talk to him for a little while and then get started again. He always looks serene and wise and I almost always get going after talking to him for a little while.
Phin describes five steps to turn your investors into rubber ducks:
- Frame the problem you are facing: describe the challenge in enough detail that I can understand it without being an expert (because I am probably not an expert)
- Create context for an answer: Explain why this problem is a priority for you and the business and why you need to solve it now (because I am not involved in the day to day operation of your company)
- Propose a few solutions: Describe a few paths you might take and talk through how you would choose between them (this helps me understand the outcome you want to achieve)
- Be patient: Be open and engage deeply in the questions that I have and explain your answers with specific detail (even if it seems obvious)
- Be active: The goal is to debug the system and the builder is most likely to find the bugs we seek (and to see others along the way)
These are similar to how to engage a great mentor, which we teach over and over again in Techstars – both to the entrepreneurs and the mentors. If you’ve ever done a Top of Mind Drill with me, you’ll recognize the Rubber Duck approach with one twist – storytelling.
I’m a storyteller. I learned this from my dad. It’s part of why I love to write – it’s a way for me to think out loud and figure stuff out while telling stories. So – my favorite Rubber Ducks are the ones who can also tell stories, at the right time.
The risk of a Rubber Duck only approach as a VC is that you become overly socratic. We all know the VC who just asks question after question after question. The questions are often good, and they drive you deeper into the problem, but at some point you need to take a break. You need a breath from answering more questions. You need an analogy to relate to.
This is when the Rubber Duck should tell a story.
At a board meeting recently, the CEO looked at me and said “just tell me the fucking answer.” So I did. And that works also. But not until the CEO wants that. Until then, be a Rubber Duck.
Remember – the CEO makes the decision, not the VC. Unless the CEO explicitly asks. And – if as a VC you don’t trust the CEO to make the decision, you have that discussion with the CEO right now. And if you are a CEO who’s VCs aren’t letting you make the decisions, buy them some Rubber Ducks.
I love Scott Kveton, the CEO of Urban Airship. He and his team are building an amazing company in Portland. If you do anything mobile-related and use push notifications of any sort, or real-time location targeting, you need to be talking to them. But even more impressive is how Scott leads his company.
The other day, I got an email from my partner Jason with a photo of the Urban Airship Meeting Rules posted on the wall. They are so logical as to be rules that should apply to every meeting at every startup from now until forever.
0. Do we really need to meet?
1. Schedule a start, not an end to your meeting – its over when its over, even if that’s just 5 minutes.
2. Be on time!
3. No multi-tasking … no device usage unless necessary for meeting
4. If you’re not getting anything out of the meeting, leave
5. Meetings are not for information sharing – that should be done before the meeting via email and/or agenda
6. Who really needs to be at this meeting?
7. Agree to action items, if any, at the conclusion of the meeting
8. Don’t feel bad about calling people out on any of the above; it’s the right thing to do.
I particularly love 0, 1, and 4. I rarely walk out of a meeting when I’m not getting anything out of it. I’m going to start paying more attention to this one.
This first appeared in my LinkedIn Today column titled Give Before You Get. I post unique content on LinkedIn a few times a month (I ultimately reblog it here) but if you want to get it when I first publish it and you are a LinkedIn member, simply follow me on LinkedIn.
As 2013 begins, I encourage you to adopt one of my deeply held beliefs, that of “give before you get.”
I’ve lived my adult working life – first as an entrepreneur, next as an angel investor, and now as a venture capitalist and a writer – using this credo. It’s a core tenant of the Boulder Startup Community, which I discuss extensively in Startup Communities: How To Build an Entrepreneur Ecosystem in Your City. And it’s at the heart of how I live my personal life and is part of the glue that holds together the awesome relationship I have with my wife Amy Batchelor.
In order to give before you get, adopt a philosophy of helping others without an expectation of what you are going to get back. It’s not altruistic – you do expect to get things in return – but you don’t set up the relationship to be a transactional one.
In a business context, my favorite example of this is the difference between a mentor and an advisor. The word “mentor” has become very popular and trendy recently, yet few people really understand what it means, and many mentors are actually advisors. To understand the difference, here’s an example. An advisor says “I’ll help you with your company if you give me 1% of the equity” or “I’d be happy to spend up to a day a month advising you if you give me a retainer of $3,000.” A mentor says, simply, “how can I help?”
As a partner at Foundry Group, I interact with hundreds of entrepreneurs each week. I’m an investor in a few of their companies, but many of the people I intersect with are entrepreneurs whose company I’m not currently invested in. While a few of these companies are potential investments, the vast majority of them are companies I won’t end up being an investor in. Yet I try to be helpful to everyone who crosses my path, even if it’s an answer to a simple question, feedback on their product, or simply a response to their email that what they are working on isn’t something I’d be interested in investing in. Sure, I’m not perfect at this, but the number of entrepreneurs who have helped me in some unexpected way because of my approach to them dwarfs the energy I’ve “given.”
I believe that I’m playing a very long term game in business, and that my actions today will impact me in 20+ years. I feel the same way about my non-work life. My goal is to life as happy an existence on this planet as I can and, by giving before I get, I maximize my chance of this.
As you begin 2013, consider adopting a give before you get approach. It might surprise you what you’ll get!