« swipe left for tags/categories
swipe right to go back »
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!
tl;dr – Yes.
I’m on the email@example.com list for a number of the companies I’m on the board of. CEOs and entrepreneurs who practice TAGFEE welcome this. I haven’t universally asked for inclusion on this list mostly because I hadn’t really thought hard about it until recently. But I will now and going forward, although I’ll leave it up to the CEO as to whether or not to include me.
In an effort to better figure out the startup board dynamic, I’ve been thinking a lot about the concept of continual communication with board members. The companies I feel most involved in are ones in which I have continual communication and involvement with the company. This isn’t just limited to the CEO, but to all members of the management team and often many other people in the company. Working relationships as well as friendships develop through the interactions.
Instead of being a board member with his arms crossed who shows up at a board meeting every four to eight weeks to ask a bunch on knuckleheaded questions in reaction to what is being presented, I generally know a wide range of what is going on in the companies I’m on the board of. Sure – there are lots of pockets of information I don’t know, but because I’m in the flow of communication, I can easily engage in any topic going on in the company. In addition to being up to speed (or getting up to speed on any issue faster), I have much deeper functional context, as well as emotional context, about what is going on, who is impacted, and what the core issue is.
Every company I’m involved in has a unique culture. Aspects of the culture get played out every day on the firstname.lastname@example.org email list. Sometimes the list is filled with the mundane rhythms of a company (“I’m sick today – not coming in”; “Please don’t forget to put the dishes in the dishwasher.”) Other times it’s filled with celebration (“GONG: Just Closed A Deal With Customer Name.”) Occasionally it’s filled with heartbreak (“Person X just was diagnosed with cancer.”) Yet other times it is a coordination mechanism (“Lunch is at 12:30 at Hapa Sushi.”) And, of course, it’s often filled with substance about a new customer, new product, issue on tech support, competitive threat, or whatever is currently on the CEO’s mind.
As a board member, being on this list makes me feel much more like part of the team. I strongly believe that board members of early stage companies should be active – and supportive – participants. My deep personal philosophy is that as long as I support the CEO, my job is to do whatever the CEO wants me to do to help the company succeed. Having more context, being part of the team, and being in the flow of the email@example.com communication helps immensely with that.
There are three resistance points I commonly hear to this:
1. “I don’t want to overwhelm my board members with emails.” That’s my problem, not yours, and the reason filters were created for people who can’t handle a steady volume of email. If you are a Gmail user, or have conversation view turned on in Outlook, it’s totally mangeable since all the messages thread up into a single conversation. So – don’t worry about me. If your board member says “too much info, please don’t include me”, ponder what he’s really saying and how to best engage him in continuous communication.
2.”I don’t want my board members to see all the things going on in the company.” That’s not very TAGFEE so the next time you say “I try to be transparent and open with my investors”, do a reality check on what you actually mean. Remember, the simplest way not to get tangled up in communication is just to be blunt, open, and honest all the time – that way you never have to figure out what you said. If you don’t believe your board members are mature enough to engage in this level of interaction on a continual basis, reconsider whether they should be on your board.
3. “I’m afraid it will stifle communication within the company.” If this is the case, reconsider your relationship between your board members and your company. Are you anthropomorphizing your board? Are you shifting blame, or responsibility to them (as in “the board made me do this?”) Are you creating, or do you have, a contentious relationship between your team and the board? All of these things are problems and lead to ineffective board / company / CEO interactions so use that as a signal that something is wrong in relationship.
Notice that I didn’t say “all investors” – I explicitly said board members. As in my post recently about board observers, I believe that board members have a very specific responsibility to the company that is unique and not shared by “board observers” or other investors. There are plenty of other communication mechanisms for these folks. But, for board members, add them to you firstname.lastname@example.org list today.