Here’s a great section from Start With Why: How Great Leaders Inspire Everyone to Action by Simon Sinek.
Great leaders, in contrast, are able to inspire people to act. Those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained. Those who truly lead are able to create a following of people who act not because they were swayed, but because they were inspired. For those who are inspired, the motivation to act is deeply personal. They are less likely to be swayed by incentives. Those who are inspired are willing to pay a premium or endure inconvenience, even personal suffering. Those who are able to inspire will create a following of people—supporters, voters, customers, workers—who act for the good of the whole not because they have to, but because they want to. (Kindle location 163)
This raised some good questions for me:
- Am I following leaders because I am swayed or inspired?
- Do I lead by sway or inspiration?
- How is the outcome different when I’m swayed versus inspired?
I see sway in this context as an external motivator, the most common being money or authority. You work extra hard because you want more money. You complete a project on time because you don’t want your boss to be mad. It’s an exchange–one thing to get or avoid another thing versus something you do simply because you want to.
I think Sinek’s observations have a profound impact on the workplace. You get a different type of employee and workplace when people are inspired and living from their own WHY, particularly when that WHY is shared throughout the organization.
I see this clearly where I work. Many people join because they are passionate about open source software, a particular programming language or technology they love. They are innately driven and inspire the people around them, including the people that work for them. It has a multiplier affect within the company.
I’ve seen the opposite too–people who come for other reasons. They have different passions and are inspired by other things. There is nothing wrong with these differences, however this misalignment often creates a less positive environment and results.
More good stuff from Everything That Remains, this time from pages 114 and 115.
We hold on to jobs we dislike because we believe there’s security in a paycheck. We stay in shitty relationships because we think there’s security in not being alone. We hold on to stuff we don’t need, just in case we might need it down the road in some nonexistent, more secure future. If such accoutrements are flooding our lives with discontent, they are not secure. In fact, the opposite is true. Discontent is uncertainty. And uncertainty is insecurity. Hence, if you are not happy with your situation, no matter how comfortable it is, you won’t ever feel secure.
It turned out that my paychecks made me feel less secure, afraid I’d be deprived of the income I’d grown accustomed to and the lifestyle I’d blindly coveted. And my material possessions exposed countless twinges of insecurity, leaving me frightened that I’d suffer loss of personal property or that someone would take it from me. So I clutched tighter onto those security blankets. But it’s not the security blanket that ensures a person’s security. People latch onto security blankets because there’s a deeper fear lingering at the ragged edges of a discontented reality; there’s something else we’re afraid of. The fear of loss. We’re afraid of losing love or respect or comfort.
A lot of irony here I think. Interesting how it’s easy to think more money will make us feel more secure and yet in this case it was covering up the real issues.
I was talking to someone recently about blogging and how there just didn’t seem to be a way to make consistent progress or posting to their blog. They talked about their schedule and how other things were often more important than writing on their blog.
They said they wanted to publish consistency on their blog and that it was a good thing to publish and yet they weren’t publishing on their blog. It turns out they have a business blog where they do publish every day, but it is easier to publish to it because it is a different type of site, etc.
I kept thinking something was missing… if they say it is important but aren’t getting it done, how important is it really? Is it mistaken priorities? Easy for me to say, of course. I kept coming back to the sense that something else was at play.
As we talked more it sounded like the real impediment was what posting to that blog meant. It required topic ideas, completed posts, etc. which since it wasn’t a regular activity felt daunting and hard to tackle unless there was a big enough block of time. That’s when I figured it out.
I think the real block was their definition of success: “A well written, decent sized post, must be composed, written and published” to call that effort worth it, or a success. It was all too much.
I suggested chunking and changing the definition of success. Maybe instead of needing to “publish” to declare success, success could be “spending 15 minutes trying to write something every day whether it gets published or not.”
Thinking about this inspired my challenge for this month of writing every day. I’ve had so many posts that are “almost done” or things that wouldn’t take very long to write floating around in my head. And, I defined success in a way I thought I could achieve it.
I first got the idea of clearly defining success from Tony Robbins. It changes so much. The best part about defining your own success is that since it is YOUR definition you can define it anyway you like.
If you are a recovering perfectionist like me, defining success is a great way to loosen its hold, and decide beforehand what “good enough” will be. Then when you reach “good enough” you’ve been successful!
For my 30 day blogging challenge I defined “success” as publishing at least one sentence a day. Someone else could disagree with my definition of success for my blogging challenge and say it is too easy or too hard or whatever. It doesn’t matter. This is for me, not for them.
One person teased me that I was achieving my challenge by quoting other people. And maybe on some days quoting people made for an easier post, however I’m meeting success in the way I defined it. That’s the important part.
In Die Empty, Todd Henry pushed things a step forward and suggested defining failure in addition to success. This can make a profound difference.
I recently heard someone define “failure” in a great way. For them, failing was not failing to achieve a particular goal. For them, failure was to stop trying.
Anyone out there have special definitions you’ve created for success or failure?
Like many people I’ve never made it all the way through David Allen’s popular book Getting Things Done. One of the most valuable take-aways I did get from Allen’s system was getting really clear on what the “next step” is for a particular project. In fact I think It’s the most lasting take-away I got from the book.
As simple as it might sound, determining the next step is an extremely useful quest as a project manager. It’s easy for a team or yourself to get overwhelmed by all that there is to do on a project, but the reality is that usually you can only do one thing at a time anyway. So getting clear on what that next thing or things that needs to be done is, and writing it down pays off big time–particularly in today’s world of constant context switching and interruptions.
I’ve never been a fan or user of complicated Microsoft Project schedules or Gantt charts. I managed some of my biggest project at Red Hat using a simple shared text document and maintaining a simple schedule by hand. Ocassionally there were important dependencies to call out and coordinate, but a majority of the time it was weekly project meetings, making sure the “next step” or “steps” from last week’s meeting were done and getting clear on the “next steps” to be completed before the next meeting.
Don’t get me wrong. Scheduling tools can come in handy when you have a lot of dates with hard dependencies. Then by changing one date you can automatically calculate how far out your launch date is. Although that’s often met with mixed results because a lot of projects have to launch by a certain day, no matter what, at which point the hours spent configuring the fancy schedule to calculate dates automatically goes out the window while everyone buckles down to figure it out manually.
I don’t think I’ve ever ended a project wishing I’d spent more time tuning the schedule in a tool. The most successful projects I ran always came down to consistent execution and knowing exactly what we needed to do next.