I went on a sales call last week for our product Lakeway Frontier and was reminded of something that one of our first users pointed out to me: Frontier supports a methodology for how you manage engineering teams — but you have to adopt the methodology first.
I was kinda hoping the value of the methodology would be self-evident 🙂
I’ve come to this way of managing teams after a decade of observation on how engineering teams function: what happens when they run great, and what happens when they go wrong. I’ve been fortunate to have had several teams of my own on which to test out ideas on how to better manage organizations. Lakeway Frontier is a product that captures what I’ve learned and automates away the most tedious, onerous work involved in managing projects and teams.
I guess I’ve been thinking about these things for so long, that they’ve become second nature to me. I forget that for most people, these ideas represent a paradigm shift in engineering management, albeit one that has tremendous potential for improving execution, accelerating decision-making, and reducing workplace stress. Since, in effect, what I’ve been trying to do to this point is lead a management revolution, let’s just call it that.
I’ve started a blog called “Management Revolution” that will have daily posts on what needs to change in order for organizations to run better, especially engineering groups. I hope you find it useful.
It’s been about 6 months since I moved back to the Bay Area. Since then, I’ve been attending various entrepreneurial meetings and trying to network with people. I’ve noticed that there are two types of people at these meetings. The first type have an idea for a product and “only need” a team to build it. The second type of people are those who’ve built a product and “only need” to sell it (I’m in the second group).
The first group tends to be non-technologists while the second group tends to be people with engineering backgrounds (or at least technical personalities). This leads me to believe that engineers are lousy salespeople. Here are some reasons why:
According to Jeffrey Gitomer (he’s the guy that writes that little red salesbook), sales are first made emotionally and then justified logically. A good salesperson appeals to your emotions to get you excited about buying a product.
When you think of someone with a technical background, a person like Spock comes to mind. Engineers strike people as either passionless or (after you push them far enough) very angry (just like Spock).
If emotion sells, engineers are clearly at a disadvantage. The only time engineers make sales is if the customer already realizes they need a solution–when the customer is past emotion and justification and is willing to pay for something that works.
Getting Past No
Engineers take things at face value. If an engineer says, “Would you like to try this product?” and the client says “no”. The engineer will say “ok” and then stop talking. Engineers don’t get past no. We assume our clients are rational and that after we’ve presented our case, they make their final, irrevocable decision.
I have an 8 year old son who (I’m pretty sure) won’t be an engineer. He’s never taken “no” for an answer. In the morning he might say “Can I play Doodle Jump?”, and I’ll say “no”. A few minutes later he’ll say, “I haven’t played Doodle Jump for a while. Can I play Doodle Jump?”, and I’ll say “no.” At breakfast he’ll say, “Did you know that one of my favorite games is Doodle Jump?”. This level of discourse goes on throughout the day until I am finally worn down and wearily say “yes”. (Maybe in a few years, he can sell for me 🙂 )
Engineers Don’t Socialize
I think it’s fair to say that most engineers are introverts. We aren’t energized when we talk to new people. It’s quite the reverse. At the end of every networking event, I am very tired. It’s hard to maintain and keep track of so many conversations. It’s hard to remember who you’ve talked to and what they do.
Unfortunately for us, making connections is how you make sales. By networking, you can build a reputation. You become more visible. You become more trustworthy.
This tends to get easier over time, but I think that’s because you start recognizing people. The conversations start being more about “how are things going?” rather than “so, what do you do?”
Pursuit of Perfection
Engineers don’t like to be wrong. We don’t like to make mistakes. We’re trained to get the right answers (and that there are right answers!). When building medical devices and bridges, this is a great attitude. When dealing with people and potential customers, it’s not.
We need to be willing to accept failure. We need to expect failure. We have to keep trying different things until we find what works. There is no formula or algorithm that can avoid this. As a group, engineers have a hard time tolerating failure. When selling, failure is a big part of life.
The R in R&D
One thing that we should leverage more as engineers trying to sell something is the “research” aspect of our background. Research is all about trying something, understanding why it didn’t work, and then using that information to try something new. This is something engineers can relate to, and I think it’s the best way for us as engineers to figure out how to sell our products. It’s not straightforward or rational, but if we work at it, we should find something that works (I hope!)
We’ve been trying to figure this out. It’s been a slow process. I believe we’ve been doing the right things, so we need to keep finding new things to try. I think we have to give up reading about how to do this and actually talk to someone who’s done this. We need to find someone who can show us the ropes of growing a business and marketing and selling. We don’t need help writing software; we’re great at that :-).
I’ll let you know how it goes. If you have any thoughts or recommendations, feel free to leave a comment. Thanks!
With development winding down on v2.0, we’re finally able to turn our attention back to our website and our company blog. Our first post is now up, so feel free to take a look if you’d like to know why we started Lakeway Technologies.
We’ll be done with our website redesign shortly. I’ll let you know when you it’s ready. We also have a really nice newsletter in the works that will have lots of tips on managing and leading engineering teams. Stay tuned!
I was planning to spend this morning working on a talk I’m giving in January, but as I skimmed through my RSS reader, I saw that Seth Godin just put together a book containing the ideas of several dozen insightful thinkers, so I decided to read this instead. It’s a free e-book called “What Matters Now”. You can find it here.
As I was reading through this, I remembered coming across many of these people in other contexts. I bought Steven Pressfield’s “The War of Art” at Powell’s Books in Portland. I first saw Hugh MacLeod’s work at changethis.com in an e-book called “How to Be Creative“. Some of their ideas are new (to me), a few summarize books or posts, some express what’s been learned over a career, others offer an opinion or a key insight.
One of the overarching themes of the project is that if you give something of value to the community or the world, you’ll get more back. If you’re someone like Seth Godin, this will come easily to you. For everyone else, I think it’s more of a challenge. I like Steven Pressfield’s comment here:
“I must confess that so far the only part I’ve mastered is giving it away.”
I haven’t really tried this yet. But I will now. I think I’ll start by putting my talk up on SlideShare. I’ll let you know where it is when I’m done.
BTW: If you’re in Silicon Valley on January 7, and would like to see my “value-based scheduling” talk, I’d be happy to meet you!
For some time, I’ve been working every day whenever I had the chance. Today, I decided that I wouldn’t work at all (well, I did work for 25 minutes this morning, but I committed to not working after that :-)).
The last time I had to take a break like this was the last time I had to go through this particular module in my app’s code. It’s the heart of our application and our differentiating technology–and every time I have to go back in, it makes my head hurt.
I’ve always had mixed feelings about this code. On the one hand, as I look through it, I’m reminded of how difficult it would be for someone to copy what we’ve done. It’s a deceptively simple problem that has gone unsolved until now. On the other hand, I’m disappointed in how difficult it’s been to code this up so it can be easily understood. I begin to suspect that this is one of those things that can’t be made simple.
In any case, I’ve decided to spend today without my laptop (I’m typing this up on my phone) and without looking at any code. I’m going to finish up this post, read some articles, and then head off early to bed.
Tomorrow, I’ll head into the code again. Hopefully, this will be the last time I have to do any significant coding here–after all, I still need to figure out how to sell this thing.
Maybe in my next post I’ll talk about my attempts at setting up meetings, getting product feedback, and getting people to give our product a try. If there’s anything you’re particularly interested in hearing about, feel free to leave a comment!
Evidently Churchill said this. I’m not sure where or when. It’d be nice to think he said this during the darkest hours of WWII, but for all I know it might’ve been at some conference in the 50s (kind of like Eisenhower’s “Plans are worthless, but planning is everything”).
It’s an interesting quote. I think most people take this to mean “don’t give up” or “hang in there”. That was how I initially viewed this. However, I think there’s a better, more constructive way of looking at this, especially from the perspective of a startup.
Failure is active
“Going from failure to failure” is not just about enduring hardship passively. Failure is something active. It comes after actually trying to do something. It only happens after real effort. You can’t go from failure to failure by sitting around and waiting for something to happen. “Achieving failure” is real work.
Failure is also a public thing. Others can see it. In fact, others must see it because if no one sees it, you didn’t really fail—failure is a kind of social interaction. Sending e-mails to potential customers without getting responses doesn’t count as failure–maybe they were on vacation, maybe their e-mail filter stopped your message, maybe your message got lost in the hundreds of new messages they got that day. However, when you talk to someone in person and they tell you they don’t need your product, that’s the kind of failure you need to reach, the kind of failure that gives you the opportunity to go to the next failure enthusiastically. This type of failure teaches you something: your message was off, or your ROI assumptions were too strong, or the problems you’re solving aren’t important, etc. Whatever it is, you can use this to improve for next time.
When can you ever fail?
“True failure” happens when you’re too scared to try. It comes when we don’t want to look stupid or wrong. “True failure” stems from a fear of failing.
When do you ever really “succeed”?
When you go from failure and strive for the next failure, sometimes you fail to fail. I think that counts as success 🙂
I’ve never liked the phrase “Trust but Verify” (especially in organizations). To me trust means you firmly believe in someone’s integrity and their ability to do something. It means when they say something will be done, you, personally, know it will be done. No need to check. It’s money in the bank.
When you feel you have to verify someone’s work, you’re essentially saying “I’m not sure if you’re gonna do this right”. When you feel you have to look over someone’s shoulder to make sure the work is ok, you can’t really say that you trust them.
Some people may think what I mean by “trust” is “faith”. While close, these are not the same. Faith is like trust except you believe without proof. Trust is something that builds up over time. Trust develops when you’ve seen evidence of someone’s performance and abilities, repeatedly, in many different situations. Trust takes time— it’s a key part of a strong relationship.
When someone says “trust but verify”, I take it to mean they don’t really trust someone’s ability yet, but they’re in the process of observing how someone works and what they’re able to do so that they can get to a state where they can trust this person.
On the other hand…
A less charitable take on “trust but verify” is that someone is pretending to trust, and hoping that people will believe them, when in fact, they don’t really trust people at all. I believe there are people who are unable to trust others in the workplace. These are the micromanagers, or worse: highly political people with closely-held personal agendas. Because they are unable trust others, they can never develop mutual trust with their reports or their managers. While they may reach positions of power and be able to flex and distort organizations, their ultimate impact and potential will always be limited. They may be skilled and successful within an organization, but they will never be truly great contributors or leaders.
In any case…
Whenever you hear someone say “trust but verify”, watch out! Trust me 🙂