Should Our Egos And Positions Be Kept Separate?

A way of thinking and living that I’ve been trying to cultivate is the idea that our positions (meaning our beliefs about an issue), and who we are as people (our ego, for lack of a better word) — are two separate things.

In other words, if I allow my ego to become tightly coupled to an idea or position, it is easy to lose objectivity and the pursuit of the higher truth or reality. This can look like trying to prove you’re right just because you’re the one with the idea.  We’ve all been there.

Further, if your position is later refuted or proven wrong, it’s easy to become emotional and feel a lack of worth as a person.  These feelings can haunt us and further corrode our ability to think clearly.

Decoupling ourselves from our positions is much easier said than done.  Here’s what I’ve found helps in these types of situations:

  • Foster a culture where ideas are the things that may be right or wrong, not where people are good or bad because of their ideas. Don’t attack the person, but rather seek to understand why they believe the idea is true.  Instead of going after the person, keep in mind that it is likely they have reasoning that seems perfectly logical to them, and that you need to uncover those reasons in order to fully understand the idea.
  • Be open to the idea that your position may be flawed.  Lead by example in actively seeking input from a variety of sources to gain perspective.  Don’t attach your personal ego to the position, but float the idea as a thing of itself.   You may begin to see others doing the same.
  • Build a culture where the data are used to get at what is true. Otherwise, you may run the risk of succumbing to your own weaknesses and blind spots, or the opinion of your HIPPOs (Highest Paid Person’s Opinion). Data can become the great equalizer, helping you get to what is true and beyond personal biases.

What else?  Do you believe that keeping our egos and positions separate may help us make better decisions?  If not, why?

Mind Hack: Increase Your Ability To Foresee The Future By 30%

I’m not a negative person, but here’s something I’ve noticed: projects fail at an alarming rate.  One reason seems to be that people are afraid to speak up during the planning phase.  Unless you’ve fostered a safe environment that encourages people to raise issues, concerns may fester in silence and only become evident when its too late.

A premortem is a technique (pioneered by a psychologist named Gary Klein) for minimizing this kind of risk.  Instead of being held after an event like a postmortem, the premortem is Read more of this post

Screencast Recording Tips: Preparing A Script

Screencasts are very helpful for communicating ideas, features, and information about your product.  We’ve recorded a number over the years, and I have experimented with a variety of methods to produce the best results in the shortest amount of time.  I’ve found there are some processes that make preparing, recording, editing, and sharing screencasts easier. (I’ve included an example at the end of the post which uses the tips contained here — let me know what you think.)

In this post, we’ll focus on preparing a script — although I have found there are situations where extemporaneous recording works well too.

Here’s what we’ve found helpful in preparing a script:

  • Create a document with two columns: the column on the left contains the words you intend to use for your video, and the column on the right contains short descriptions of what you intend to show on the screen, like “Show Login Page” or “Show the user searching for a widget”.  If you create this document using Google Docs, it makes it super easy to share with people you want to get feedback from.
  • Create a rough outline of the major thoughts you want to communicate. Don’t worry about the specific words; just create an ordered flow of ideas you want to communicate.  Try to put them in a logical order.
  • Sit in a quiet place; using your outline, start speaking as if you’re talking to someone sitting next to you. I’ll often record what comes to mind, and then create my first draft by transcribing the recording.  At this stage, don’t worry about making it perfect – you just want to capture the spirit of what you want to say.
  • Read your draft out loud, and refine it so that there are no major errors. Check to see if your ideas still seem to be in logical order.

After creating a first draft, I’ve found it helpful to review it with a group of 2-3 people who have subject matter insight or are clear thinkers.  Inserting this step into my process has dramatically improved the end result.

Here’s how I use this feedback and review session:

  • I ask everyone to read the script in advance.  If they don’t, I’ve found that their input seems more limited and less helpful, so try to give everyone enough time to prepare.
  • Do a read through.  I’ll usually read the script out loud from top to bottom, and ask for general feedback about the flow. Does it make sense? Are the thoughts in a logical order?  How’s my inflection?
  • If necessary, we’ll make changes to the flow, and then begin to work on each sentence, one at a time.  I’ll ask if each word is the best choice to communicate the idea.  I’ll also try to cut out as many words as possible.  This is an iterative process and can be a lot of fun if you have a good group!
  • After you’ve revised your draft, let it sit for a bit. Maybe wait a day, and then go back and re-read it (out loud — not in your head) and see if it still makes sense. With a clear mind, you can make additional changes you think are appropriate.

At this point, you should have a relatively good draft to record from.  Get your vocal cords ready!  In another post, I’ll cover some of the things we’ve found helpful in recording a screencast.

What about you? Have you found any tips that are helpful in recording screencasts? If you’ve recorded them in the past, which part of the process is most difficult for you?

Here’s a 3 minute example that used the methods described in this post.  Enjoy!

[Video] Daily Scrum Stand-up Meeting: A Real-Life Example

At MindFire, we’ve been using a daily stand-up meeting for our multi-channel marketing automation platform.  We’ve also applied it in other areas, including our Leadership Team, which does its stand-up at 11:00 AM.

Here’s how we run the engineering stand-up meeting:

1) We start promptly at 9:00 AM.  We experimented with having the meeting at 4:00 PM, but meeting towards the start of the day seemed to work better.  I personally enjoy the buzz from getting everyone together in the morning, hearing the prior day’s activities, and charting the day’s course.

As I walk into the meeting, I make it a point to greet everyone, shake hands (or a quick fist-bump), and look everyone in the eye and smile.  I don’t always succeed at this, but I like to try and give everyone a good start to the day.  I feel it makes a difference.

2) We time-box the meeting to 12 minutes.  We use an iPhone timer to keep us honest.  These days, we usually finish with about a minute to spare.  We used to get lazy and go for 20 or 30 minutes, but now that we stand up and use a timer, we’re good.  I check the timer from time-to-time during the meeting and sometimes call out the number of minutes remaining.  Even though each person only has a few minutes, you’ll notice that it doesn’t seemed rushed; everyone has plenty of time.

3) We go in the same order each day, cycling through 7 people.  The people involved are:

  • The Product Owner (me).  I report on both my product-related tasks, as well as whatever I’m working on with the Leadership Team or any other part of our company.  If someone listens carefully, they can get a pretty good sense for what’s going on elsewhere in the company.
  • Our QA lead, who also is involved with our Professional Services.  He goes first, and you’ll hear him mentioning working from home the prior day.  We do this from time-to-time to improve focus.
  • Our senior architect and 3 engineers, each of whom are responsible for a different sub-system.
  • A member of our Support Team, responsible for communicating Clients issues, escalated cases, and any other meaningful data (we use SalesForce.com to track all cases).  We added this person to our daily stand-up just recently, and we’ve already seen it pay dividends.

Even though we go in the same order each day (and it is written on the board!), I often forget.  Senior moment!

4) We stay fairly disciplined.  If something comes up during the meeting that requires additional discussion, we’re disciplined about putting it in the “parking lot” and discussing it later.  I have to resist asking a lot of questions; you’ll see me ask a few quick ones, but I try to keep us focused and moving forward.  If anyone is blocked, it’s my job to make sure that I do what I can to move them forward.  You’ll hear me ask about blocks after some of the updates.

5) We update the Sprint board.  We usually start updating User Story status (as a percentage towards completion) a few days into the Sprint, once we’ve started making progress.  We recently changed what we display on the board, and it seems to have made an improvement.  We can cover that in another post.

The meeting runs well if everyone is prepared (which is most often the case). Some come prepared with a summary of what they worked on, others seem to have great memories and can recite their work without notes. Personally, I write everything down in a Google Doc, and just reference this document during the meeting; otherwise, I’d never remember anything — maybe I’m getting old!

Here’s the video from one of our recent Scrum meetings; excuse the brief interruption around 1:45.  Enjoy!

Do You Measure Your We-We?

The next time you’re talking with someone in a position of authority or responsibility, try this: Count the number of times they say “we” or “us” — versus “me”, “my” or “I”.

For example, imagine you work at a company that makes gizmos. You’ve worked hard with a group of people to create the gizmo, and someone in a leadership position relates a story about meeting with a potential Client and says: “I want them to see the value of my product.

Oh really, it’s your product?

Or, are they more inclusive, and instead say something like: “We want to show them the value we can provide.

I would argue that in certain situations, leaders who use words that are inclusive (like “we” or “our”) resonate more strongly with the people around them than those who make things about themselves.

Personally, I am put off by a person who makes it all about them.  I’m sure this is much more about me and my issues than them and their words, but I often wonder how people would respond to their leaders if more inclusive words are used.  I’m sure there are studies that have looked at this.

So the next time you’re thinking about how to communicate to your team (or listening to someone in leadership), consider measuring your (or their) we-we factor (not wee-wee, come on kids!), and see if you notice any difference when inclusive words are used.

What do you think? Are you turned off by people who make things about themselves? Does it make any difference in how you feel?  Or, are people like me just too sensitive?

Things You Wish You Could Say At Work

The other day I heard one of our engineers say that he had to take vacation before the end of the year.  It seemed he actually wanted to work, but that he had to use the vacation — or he’d lose it.

Wait a sec.  Here’s a guy who wants to work, but for whom our “use it or lose it” policy is back-firing.  (Of course, he could still take time off and work anyway [I won’t get into that here], and that’s not the point.)

But before I get to my point: I am a big believer in taking time off.  In my earlier days, I had a very hard time pulling myself away.  I went through what felt like extreme emotional duress, worrying about this, that, and the other thing.  I couldn’t sleep, focus, or be present with the people around me.

I was somewhere else and nowhere at all.  Maybe you know the feeling.

But over the years, something strange happened.  I started learning how to unwind, and began forcing myself to disconnect.  And in doing so, I didn’t become lazy (one of my fears), or miss out on something (another fear).  Instead, my thinking was enriched, my soul refreshed, and my body renewed.  Vacation and time away is a wonderful thing and can actually improve your results.  I encourage everyone around me to do it and feel good about it.

So here’s the point — something I wish we could say at work: Why do we even have a vacation policy at all?

I wish we (and other companies) had the guts to implement a policy like this:

  • Official Policy: Be Reasonable And Use Your Head.  That’s it.
  • What does that mean?  It means we don’t track vacation or sick days.  Take as little or as many as you need to feel creative and productive.
  • This doesn’t mean people take time off without getting their job done.  Instead, it means that we track their results  – and people make sure their work gets done.  They’re adults.

I’ve thrown this idea out to people, and I usually get the same question: “Dave, you’re smoking something.  What do we do if someone abuses this policy?

I think that’s easy: We’d let them know they aren’t meeting our “be reasonable and use your head” policy, and we’d say “bye-bye” if it doesn’t improve.  They wouldn’t fit in and I fully expect their peers would call them out.   I realize there are legal implications that would have to be worked out (especially here in CA), but I feel that (maybe?) the right people would be attracted by a policy like this.

Your turn: What do you think of doing away with vacation policies?  What are some things you wish you could say at work, but don’t have the guts to utter?

Why Are Homeschoolers Weird?

Here’s something I like to do: When I’m with a group of people discussing our childhoods, such as where we went to school, sports we played, etc., I’ll say something like “Did you know any weird homeschooled kids?”

People will often say some of the stereotypical things about homeschooled kids.  Things like: they’re odd ducks and socially awkward; they make their own clothes and electricity.  I’ll usually throw in a few wisecracks like “Oh, and they don’t bathe” or “they’re usually freaks!”.

Then, once everyone has poked fun at homeschoolers, I’ll say: “I was homeschooled.”

Silence.

The awkwardness is pure awesome.  But it’s true.  My mom homeschooled me until the seventh grade.

Inevitably someone will say, “Oh.  That.explains.a.lot.”

Wait a sec.  What does that mean?  I’m not offended, but over the years I’ve heard a number of commonly believed things about homeschoolers.  Some are true, others are blatantly ignorant.  Like anything, there are pros and cons.

I don’t know about other homeschoolers, but here are a few “pros” homeschooling gave me:

  • The realization I could teach myself anything.  I think this is the most important gift my childhood education gave me.  This might be why I don’t understand what people mean when they say, “I don’t know how.”  I have a hard time understanding how this is possible, especially with the accessability of information (have you heard? they have internet on computers now!).
  • How to interact with adults.  This came in handy years later as I made my way through my first few jobs, and while starting a company in my late teens and another in my early 20’s.  I never really felt out of place (in fact, I usually felt more at home with older people).
  • How (and why) to work at something I love.  My first passion was music.  It required hard work, dedication, and sacrifice — but I saw results.  Being exposed to this cause-and-effect dynamic equipped me for the work required by entrepreneurship.  In addition, I was blessed with the gift of learning that fulfillment can be found in doing something you love, despite the hard work.

Those are just a few of the things I believe to be true about my homeschooling experience.  Each of these things have deeply impacted me.  Now that my wife and I have a child of our own, we’ve discussed what kind of schooling experience we want to give our daughter, and whether homeschooling might be an option for us.

What about you?  Do you think homeschoolers are weird?  If so, why?

How To Expose Yourself In The Workplace — And Not Be a Creep

A few years ago, I realized that nearly all of the things that irritate me about my interactions with other people are a result of my own lack of communication.

Here’s what I mean: In any given situation where you feel disappointed, angry, or frustrated at an outcome you’re experiencing with someone, have you stopped to think about why it is you’re feeling this way?

What first comes to mind may be helpful — but if you continue asking yourself “why” after the first thought/reason (and repeat this process a few times), you may come to a more refined understanding of what’s driving your discomfort.

What I came to realize is that in my interactions with others, I was becoming upset — or feeling let down — because I operate from a set of viewpoints that are fully to known to me, but completely unknown to the person I’m working with.  From one perspective, these viewpoints are all I know, and because they’ve been with me for 30+ years, I somehow feel others know these things about me too.

But of course that’s silly and nearly impossible.  They’re not mind-readers!

Once I realized this, I decided to write out these viewpoints in a simple list (particular to the work environment), and share/discuss them with everyone around me.  I make it a point to do this with new hires.

It takes some vulnerability — and I’ve often received very surprised looks when I do this, especially during an interview or first day on the job — but I think that this exercise has helped me give the other person a frame of reference for why I behave, respond, and think the way I do.

My hope is that this makes it a tiny bit easier for us to do great work together.  And through leading in vulnerability, I also seek to give them a platform to feel comfortable with me.

If you’re interested, here’s my list, which I call “This is Dave”.

What do you think? Have you ever stopped to think about what’s on your list?  What are some of those things?  Would exposing these things be scary — or liberating?

Attitude Check: Are You a Pig or Chicken?

Our chief software architect, Aref Memarian, recently shared “Essential Scrum” with me.  If you’re looking for a great review of scrum from someone who has obvious hands-on experience, I’d definitely recommend it.

While reviewing the various roles involved in agile development, the author describes two types of people: Pigs, and Chickens.  Imagine this scenario:

A Pig and a Chicken are walking down the road.  The Chicken says, “Hey Pig, I was thinking we should open a restaurant!”

Pig replies, “Well, perhaps, but what would we call it?”

The Chicken responds, “How about ‘ham-n-eggs’?”

The Pig thinks for a moment and says, “No thanks.  I’d be committed, but you’d only be involved!”

This analogy is based upon the Pig providing bacon, an act which requires total commitment to provide (i.e., death), in contrast to a Chicken who provides eggs — a task requiring participant but not his life.

In other words, in a bacon-and-eggs breakfast, the difference between a Pig and Chicken is that the Chicken is involved, but the Pig is fully committed!

In most organizations, you’ll probably need a combination of Pigs and Chickens involved on any particular project. You want your Pigs to be committed, which means they should have autonomy and freedom, in exchange for being held completely accountable and responsible for the project’s success. Your Chickens can provide input and support as required.

Now, what if you apply this concept beyond a particular project, and apply it to an organization as a whole?  For example:

  • If you’re a leader, what’s your mix of Pigs and Chickens?  Do you want more of one and less of another?  (And think: Which are you?)
  • If you’re in a non-leadership position, what’s your perspective? Are you a Pig, committed and accountable for your organization’s success, or a Chicken — involved, but only to a limit?

Is there anything wrong with being a Chicken?

6 Lessons Learned Creating a SaaS MVP (Minimally Viable Product)

Over the past few years, we’ve become big proponents of developing new products by creating an MVP: a minimally viable product.

An MVP is the smallest set of functionality required to meet the needs of your targeted User.

The goal of an MVP is to rapidly validate your product hypotheses. Every great product should have an opinion, a way of seeing the world. That view may (and should) evolve, but at some fundamental level, your product is based on some view of how something should work.

As a company, founder, or product owner, your goal is to get real feedback as early (and often) as possible to validate and refine your hypotheses. While it sounds easy, it can be difficult, especially learning to say no to things in order to remain “minimal”.

At MindFire, we’re 16 months past our MVP milestone for one of our products. While we’re still learning and iterating by gaining feedback from 400+ users, here’s a bit of what we’ve learned about developing an MVP:

  • The idea of an MVP may be hard for people accustomed to more traditional development methods to understand. You may find yourself working hard to remind your organization why everything isn’t perfect. The goal of an MVP is not perfection.
  • Creating a successful MVP requires that your engineers understand the User’s domain, their struggles, and the job they’re trying to do. In the absence of this understanding, it is very difficult to communicate an idea (or User Story). Without domain experience, you may find your team asking for detailed instructions. If this happens, you probably need to spend more time introducing your engineers to real Users.
  • The sooner your MVP is in the hands of real Users, the better off you are. Nothing counts until this happens. Customer feedback and usage is oxygen to your efforts.
  • You’ll have to work hard to resist over-engineering things. Don’t try to get things perfect. It’s better to acknowledge that its hard to predict the future, and thus, to instead get working software into the hands of users ASAP. The goal is not perfection; rather, you seek feedback on the question: do you have a product that provides value to your Users?
  • On the topic of feedback: be prepared for lots of it. If you’ve got a real MVP (one that although buggy, inherently works … at least most of the time), rest assured things will be missing. Users will ask for features, improvements, and sometimes flat-out tell you that something sucks. You may even hear “How on earth could you not have feature x?!?”  If you hear things like this, you’re on the right track. That’s oxygen!
  • A part of the MVP philosophy is an understanding that there is no one specific release point. In traditional methods, everyone works from detailed specs for months (or years!) towards a huge goal — often, in the end, falling short (been there, done that). In the MVP philosophy, you still have goals and milestones, but what’s more important is a deep respect for valuing fast iteration based on user feedback, rather than working towards monumental releases. What happens if you’re wrong when you get there? Much better to find out sooner.

Developing an MVP certainly hasn’t been easy, so perhaps in another post, I’ll share some of the things I’d do differently with an MVP the next time around. But what I can tell you from first-hand experience is that the benefits far exceed the difficulties.

What do you think of the idea of an MVP? In what situations is it best? If you’ve developed an MVP, what lessons have you learned?