Unfortunately, we see polls almost daily about this politician's popularity and that politician's popularity. If we elect people to become leaders, it's impossible to lead and remain popular. A leader has to make hard choices. Someone will be hurt by the decisions made. The more decisions made, the greater the pool of those hurt, and the more unpopular the leader is.
That's inevitable.
It's no secret that I disagree with President Obama on many issues, but in the areas where he wanted to push change, it was change he pushed and change he got. He telegraphed many of the changes that have come to pass when he was a candidate, such as his plans for energy costs to "necessarily skyrocket."
Did that get a lot of play in the media in his campaign? No. But guess what - you're seeing that philosophy played out today in higher gas prices. His refusal to issue permits for offshore drilling constricts our ability to rely on ourselves for oil and gas, therefore we're at the mercy of others. He told us that would be his plan, he's executing that plan, and his choice to do so will upset those who are affected by it and disagree with it.
That's the nature of leadership - you make hard choices.
Similarly, in Wisconsin we see Scott Walker carry out the plans that he communicated in his campaign for governor. Are they unpopular? Increasingly so. But to achieve a balanced budget, he's doing what he believes he needs to do.
A leader has to make hard choices, or they're simply not leading. It is what it is. If you don't like the leader, then critique the leader, galvanize people against the leader, and seek to change the leader. For the time being, that person is in the position of leadership.
The final questions in the evaluation of any leader are:
Did the leader correctly assess the situation?
Did the leader take the appropriate action?
Did the leader succeed in implementing the appropriate action?
Polls are a really lousy way of conducting that evaluation. Skewed by samples, the way the question is worded, the answers allowed, and the choice of what to publish in the polling results leaves the results to be sketchy. Personally, I find it necessary to dig into a poll's methodology. That extra effort makes me disregard more and more polls.
Further, the outcome of the change sought by a leader is more important than the process.
Said another way, childbirth sucks, but the baby rocks.
What's important to understand is whether or not the change pursued has any historical or logical basis to recommend it as a course of action.
I know a lot of people who voted for Obama who are now shocked at the outcome he's producing. Gotta tell ya - he's pretty much doing what he said he would do, which is why I started talking about it way back then. To those folks, I've told them to pay attention next time.
Likewise, there are plenty of people in Wisconsin getting irritated with Scott Walker's process. But if the result is less debt for the state of Wisconsin and a balanced budget, I think most will have a hard time arguing with that outcome.
Some of our nation's most celebrated leaders were at times very unpopular. What spelled their ultimate recognition as great and good leaders were the long-term results of their leadership. Before election, what's important to know is what they intend to do and how they intend to do it. And then to understand that the process of change is often difficult and at times riddled with mistakes. Patience with that course is often hard for people who don't have the stomach for it.
I'm having some amazing discussions lately with people looking at 247Toolset. One guy said he wanted to buy it as his own personal LinkedIn. Kinda cool.
But going forward in the company, when I start adding employees, I'll migrate my role to that of Chief Listening Officer. Hearing how the market wants this platform to solve problems for them is riveting.
I've often thought that I might write a book on business listening. I have a title and a tagline in mind...
The dumbest business move in the world seems to me to be when you look at the market and you say "No." In this economy, who can afford that response?
If you want to have impact and influence, be where you need to be. No whining when you're away from the action despite having plenty of time to be in the thick of it.
Today, I wrap up the RSVP functionality in 247Toolset's robust calendar of events / event management module. This going on while having to get two projects out for clients over the weekend...
But as I put this together, I have to consider every request I can recall from people about working with a calendar of events. The payments system won't come online until sometime in May, but other than that, there's the list of features requested:
Easy-to-enter recurring events
Cancellation management
Mass messaging attendees by email or text
Behind-the-scenes staffing and task management
Joining an organization's calendar to several others
Geographic and descriptive search
Restricting admin privileges to event entry only
Event capacity management
Allow for private and invitation-only events
All of that should be in the rollout on Monday.
In May, tiered payments will be allowed. Later, that payment system will work with the donation / fundraising module to be rolled out in August, which will integrate with events and email campaigns within 247Toolset.
To get to all of this - because it's a lot to consider - I have to do plenty of thinking. No coding, no anything - just what I call "feet on the desk" time.
To some, that might look like doing nothing. But in my head, scenario after scenario plays out, juxtaposed against the data schema, thinking through the usability of the system.
And I have to say that all of the effort is creating a mighty powerful calendar system. As I'm playing with and testing its capabilities, it does more than many calendars I've used. I'm excited to show off its features in future demos.
ETC: That was a thing. RSVP became pretty much a complete ticketing management system.
Said another way, the media loves failure. Failure sells.
America's Funniest Home Videos and Wipeout chronicle the epic stumble. Most successful action movies showcase killing. When corporate titans and politicians fall from heights on high, it's front and center.
Failure is delicious. Kitchen Nightmares succeeds because you simply can't believe how filthy that walk-in cooler was. The nightly news covers disaster and mayhem more than anything else. YouTube loves Charlie Sheen and tsunami footage.
You gonna fail? Let me get my camera.
But...
The better story is the climb to success. It used to be that we esteemed the person possessing competence and composure. Now we make heroes of those who make a peculiar "talent" of the public bellyflop and we shine unwanted light on victims of tragedy.
I wrote about something Frederick Douglass said long ago. His words are worth reading.
If you go here and click the Events button, you'll be able to see the first public version of 247Toolset's Event Calendar.
I've got more work to do on it, and some tweaks, but it works fine. And from the demos that I've been doing, the calendar and its RSVP system are moving sales forward at a strong clip. I had two sales yesterday, and I think in the next month I'll average one sale a day, which is almost enough to make this my full-time job. When I finish the work on the calendar and implement the email newsletter functionality, I suspect I'll have driven enough value into the platform to make that happen.
April is when I'll work on the payment processor (credit card, PayPal, Dwolla, and manual entry) and incorporate that with the calendar, which will give it the ability to handle tickets. It will allow the administrator to create multiple options for each event - such as attending the seminar ($100), or attending the seminar and the dinner ($150).
End of May is when I hope to the tiered options for events up and running.
And June is when I begin writing the donations / fundraising module. One non-profit and one politician that own 247Toolset have indicated that they want input into the development of that piece. Sat and talked with one of them yesterday for about an hour. I have a pretty good idea of what I need to provide.
All of that functionality for $19.95 a month. I just need to keep driving value into it.
Sales are indeed accelerating, and interest is picking up with almost every interaction I have with people.
I gave a demo last night to 15 people. Afterward, 5 stepped forward and asked for my card. "My high school's marching band needs this..." and "My new start-up needs this to manage the people we're bringing on..." and "I work with hospitals and we could really use this..."
I gave a demo yesterday to a woman who bought it for her organization. We met at Panera. After I finished my demo, the woman at the adjacent table said, "I'm sorry, but I overheard what you have there, and before you leave, do you have time to show me your product?"
Back in 1995, I attended a software conference in Manhattan and Jim McCarthy was the keynote speaker. In a sea of suits, he showed up in a Hawaiian shirt and jeans with holes in them.
He gave the best talk I've ever heard around software development.
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.
Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don't know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.
The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.
You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven't comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.
Genius.
Today, as I continue to marvel at what I'm learning from each demo that I do and the feedback that I hear, I realize how much I don't yet know about the solution people need. But I also realize that I'm pretty far along in understanding what's needed. It's funny how often they'll ask a question just as I'm getting to that feature, and how often they'll remark that it flows really well.
I can't take the credit for any of that. It's just me listening to a bunch of smart people telling me how I can help them succeed better.
Always beware working with the person who refuses to admit ignorance. You'll pay dearly for it later.
I've been wrestling with a need that's been expressed to me for some time, and today's development has led me to what I think is the answer. I won't say explicitly what the need is, but here's what seems like the answer:
A person should be able to create their own reality without the hindrance of others checking their homework. Because Facebook, Twitter, LinkedIn, and so on have taught us one thing - which is at odds with reality - few people will publicly correct our homework.
Said another way, being part of a network shouldn't require that everyone agree with everyone's version of what's really going on. Everyone should be allowed their own version.
Today, after looking at 247Toolset, two people at the demo echoed comments that I've heard before - 247Toolset is like an organization having its own personal LinkedIn, but with functionality more targeted to an organization's needs.
Back in late January, I wrote this post, explaining that the secret to great writing is rewriting - as I learned in college.
It's become obvious over the past 3 weeks that I need to completely rewrite the permissions and approvals engine for 247Toolset.
When you first approach a problem to solve, you come at it with your best information and your best solution. As you think it through, you learn more, and you make your first implementation. But the strength of any system is its flexibility to adapt to new needs. As new information comes to light, and as the initial unknowns are flushed out, the model implemented will either allow for enhancement or limit the business.
At the point of limitation comes a decision: does the cost of limitation outweigh the cost of rewriting?
If the answer is no, then you handicap your business through the known limitation and create workarounds, where necessary.
If the answer is yes, then you embark on a rewrite and re-approach the problem with the new information you have.
I first wrote the permissions and approvals engine four years ago. Now that I have a few dozen clients using 247, and now that I'm smarter for having listened to and watched the way in which they use it, it's time to rewrite.
I've been involved in many organizations that encountered the rewrite vs. workarounds fork in the road. What I found is that companies almost never trust their own people to start from scratch and build it from the ground up.
That's just dumb.
I mean, it's one thing if you simply don't have the talent in shop to do it, as most small businesses do not. But for larger companies, they likely do have that talent in house. For whatever reason, they just don't trust that talent. So they end up buying into a system that meets most of what they need, and expend no small amount of effort squeezing that foot into the limitations of that new shoe.
The problem with that approach is that it is still a system that limits the organization. Every time. They convert the fork in the road to become workarounds in current limiting system vs. workarounds in new limiting system. Writing and owning the entire system is not an option, and limitation becomes a way of life.
Peter Drucker said: "Management is doing things right; leadership is doing the right things." Ever since I heard that, I knew that the optimum is:
Do the right things right.
Why choose between doing things right and doing the right things?
In my experience, it is always better and more sustainable to solve the right problem in the right way at the earliest opportunity. In my experience, the only time that something is too costly to implement is when it is impossible, otherwise it's doable and the only challenge is choosing when and how.
The only way you know the right problems to solve is by being as close as possible to the market.
The only way to solve those problems in the right way is to implement as close as possible to the market.
See the pattern?
The problem with most of today's management is that they don't make a concerted effort to put themselves and their people close to the market.
Therefore, ineffectiveness and inefficiency ensue, which paves the way for disruptive innovators and fearless competitors - which always costs the existing players far more for the avoidance and can threaten their very existence.
In addition to writing a ton of code, I'm writing the user manual, and I would argue that every developer needs to write their own manual.
Not because it's for the user to read, but rather because it's for the developer to be forced into eating his own dog food, step by step. There is no better debugger than documenting your own path for others as they would use it.
That process has been helpful to me to figure out the best way to help a person manage their activity as a non-administrator in 247Toolset.
Beyond creating their initial profile, a person has three reasons to return to the portal:
Record their response to a request for engagement
Manage their current assignments
Manage their RSVP's to eventsI've spent three hours so far this morning walking through this experience for the user again and again, clarifying my words and cleaning up the interface to give them what feels simple.
When on an assignment, the administrator can issue tasks for the person assigned, and the person can record their status on the task.
They can also record their time on an assignment.
This is not only applicable for the recruiters who use 247Toolset, but for non-profits as well, who have told me that they need an easy way to log a volunteer's hours - because sometimes the "volunteer" is compelled to be there because of a community service requirement.
Walking through it, I thought of the enhancements I'm sure I'll be asked to make down the road. That clarity in what exists and that vision for down the road wouldn't have come were it not for the exercise of writing it out.
Today, I sat with an organization that purchased my platform and walked them through the features and options.
I used to be able to do a pretty thorough demo in 10 minutes.
I'm not sure I could do it in an hour now.
I said last year that my primary purpose in life is driving value.
Driving value is an additive force in the economy. It creates purpose and use from nothing and makes it attractive to purchase, which increases the velocity of money around those driving value.
A few years back, the daughter of a friend of mine went to China, and being an excellent photographer, she took pictures of the communities she visited. Being an artist, she didn't focus on the "sights," per se... she instead took pictures of the small details of a well-crafted fence, or the ornate carving in a door, or the exquisite curve of a piece of glass blown into perfect shape. Over centuries, the community was improved by everyone, so that even the smallest of touches had great meaning.
I hope that can be said of my life - that I added great and beautiful value.
One of the best ways for an organization to gain members and promote its mission into the community is to attend the events of others.
It's impossible for an administrator to keep abreast of all of the events in the community that would prove beneficial to attend. But across all of its members, collectively, they might know all of them.
So this morning, I'm creating the ability for members to suggest an event to the administrators through the events calendar.
As I'm writing more functionality this morning in the events calendar, my own software caught me by surprise.
247Toolset has the ability to create private events that don't show up on the public calendar. When a person is logged into the system, they see the private events to which they have access.
I always thought of this as internal admin meetings among the group. But frankly, if I create a private event and issue no one access to the event but me, each person in the organization could use this as a personal events calendar.
Would they want to?
I had a conversation yesterday with someone who owns 247Toolset and they're looking at ACT as a contact management system in-house. She asked the question, "Could I just use 247Toolset for that?" Her reasoning, which has been a principle goal of the platform all along, is that it brings all of their information into one place.
There are a lot of cool tools out there, but never discount the beauty of simplified integration as a point of attraction.
Here's the thing: because 247Toolset actually allows those in my network to manage their own information for me, which makes it more accurate and less time-consuming, and because it's coming awfully close to a full-fledged contact management system, I think I have some interesting angles I can play here with just a bit more thoughtfulness as I code.
What's really blowing my mind: 247Toolset allows organizations to network their calendars together. That blend of personal calendars with organization calendars with niche community calendars... holy crap!
ETC: Here are some screenshots, if you'd like to see them. Just click.
For two days, I've been running through the scenarios for invitation-only events, and it's proven a lot more work than I expected, especially since everything for private events was so simple. But the workflow is quite different, and some of the scenarios raise some questions about how the rest is handled.
All I know is that I want to put this piece of it to bed tonight before I go to bed. It's getting in the way of my development timeline, dammit.
1999: I built a shareware application called Project Tracker and had a few hundred sales.
2001: Newsletter Ease, email newsletter software, was born.
2002: After a board meeting for NLE, Cindy Rockwell asked me what I was going to do next. I told her that a résumé is only a list of things that people have allowed me to do, but it's a poor indicator of what I want to do or what I think I'm capable of doing - so I wanted to work on something that would allow a person to showcase their skills and passions. At that time, I bought the domain TalentBench.com (which I still own). (As an aside, all of the tables in the 247Toolset database are prefixed "TB_" for this reason.
2004: After separating from Jackie, I started working on something I called Ezolo, which featured a geographic search engine. I then bought the domain EverybodysCalendar.com and built what become the prototype for the EverywhereCalendar technology that is in 247Toolset today. I stopped working on that in 2005.
2006: I approached John Myers of Paragon Employment Solutions and told him of the TalentBench concept and wondered how that might work for recruiters.
2008: Paragon and I worked out an agreement where I would build what then became known as the 247Toolset platform. I would own all of the IT, and they would share some of the revenue that they made through it. Unfortunately, it didn't really fit their model, and we parted ways later that year.
2009: I was one of the founders of the Des Moines Tea Party, and it occurred to me that all of these passionate people were dying for a way to get involved. I started retooling 247Toolset for volunteer recruitment, and released an early version in June that was reviewed by my good friend, John LaMarche, who also purchased the first portal for $2,500 (TalentNetIowa.com).
2010: Realized that my pricing model wasn't right for the market or for the economy, so I mothballed my sales efforts until I could arrive at the right model, which occurred 4th quarter in the year.
2011: Significant enhancements and 80-hour work weeks on it. Sales are regular and word-of-mouth is strong
I wanted to make two points in all of that.
1) Entrepreneurship isn't just an idea and financing and suddenly you're rich. It's evolving ideas and experiences and a service attitude and a lot of elbow grease. Everything rides on the single-minded belief that the effort will pay off. Whenever I read of people who think that business owners are just lucky folk who make their money off the backs of the poor, I'd love to sit down with them and share my story. Across the entrepreneurs I know, mine is not an unfamiliar story, and people who think "the rich" are just lucky people are deeply ignorant of the extraordinary work that makes successful folk "lucky."
2) I want my kids to know this story. I write my blog mostly for my family to have my history. Dumping stuff out of my head helps me to get ready for pulling more stuff into my head. But my chief reason is for them... someday, my kids and my grandkids will read through all of this.
THE STATE OF WISCONSIN HAS stopped withholding union dues from employee paychecks. And despite all the sound-and-fury, this is what the Democrats are really upset about. Plus this: "With the law now in effect and paychecks getting an increase since union dues are not being withheld, Democrats are the party arguing for a reduction in state worker paychecks."
If a person chooses to give their money to a union, more power to them. But forcing union dues deduction is theft, plain and simple. It's now up to the unions to prove that they're worth the freewill contribution, just like it's up to the rest of us to prove that our service or product is worth the money we ask.
Welcome to the free world, unions.
And as an aside, I wonder how many of those formerly-auto-deducted households will quietly be very, very grateful for the extra income.
When I first built 247Toolset, it was a tool for administrators to find people, and since there was no need for administrator to discover herself, she never filled out a profile.
But the market talks and I do my best to listen, and 247Toolset is becoming a CRM suite... which means more rewriting to make it clearer yet.
People aren't always explicit in telling you how a product isn't clear yet.
Vivian from Florida called me two days ago with this question: "How do I access organizations?"
I told her that it was on the People tab, but what her question told me was that the interface wasn't clear. So now it's not the People tab - it's the People and Organizations tab.
At the moment, I'm creating a Communication tab, which will house Conversations, Email Newsletters, Email Blast, and Text Message Blast.
The writer Stendhal said: "I see only one rule: to be clear. If I am not clear, then my entire world crumbles into nothing."
Yep - pretty much. And universal clarity is hard work.
