Select a category
The Race
“Quit! Give Up! You’re beaten!”
They shout at me and plead.
“There’s just too much against you now.
This time you can’t succeed.”
And as I start to hang my head
In front of failure’s face,
My downward fall is broken by
The memory of a race…
By Dr. D.H. (Dee) Groberg
This poem continues to move me to tears every time I read it. It motivates and inspires me to get up each time I fall. I hope it does the same for you.
—Brandon E.B. Ward
I
“Quit! Give Up! You’re beaten!”
They shout at me and plead.
“There’s just too much against you now.
This time you can’t succeed.”
And as I start to hang my head
In front of failure’s face,
My downward fall is broken by
The memory of a race.
And hope refills my weakened will
As I recall that scene;
For just the thought of that short race
Rejuvenates my being.
II
A children’s race–young boys, young men–
How I remember well.
Excitement, sure! But also fear;
It wasn’t hard to tell.
They all lined up so full of hope
Each thought to win that race.
Or tie for first, or if not that,
At least take second place.
And fathers watched from off the side
Each cheering for his son.
And each boy hoped to show his dad
That he would be the one.
The whistle blew and off they went
Young hearts and hopes afire.
To win and be the hero there
Was each young boy’s desire.
And one boy in particular
Whose dad was in the crowd
Was running near the lead and thought:
“My dad will be so proud!”
But as they speeded down the field
Across a shallow dip,
The little boy who thought to win
Lost his step and slipped.
Trying hard to catch himself
His hands flew out to brace,
And mid the laughter of the crowd
He fell flat on his face.
So down he fell and with him hope
–He couldn’t win it now–
Embarrassed, sad, he only wished
To disappear somehow.
But as he fell his dad stood up
And showed his anxious face,
Which to the boy so clearly said,
“Get up and win the race.”
He quickly rose, no damage done,
–Behind a bit, that’s all–
And ran with all his mind and might
To make up for his fall.
So anxious to restore himself
–To catch up and to win–
His mind went faster than his legs:
He slipped and fell again!
He wished then he had quit before
With only one disgrace.
“I’m hopeless as a runner now;
I shouldn’t try to race.”
But in the laughing crowd he searched
And found his father’s face;
That steady look which said again:
“Get up and win the race!”
So up he jumped to try again
–Ten yards behind the last–
“If I’m to gain those yards,” he thought,
“I’ve got to move real fast.”
Exerting everything he had
He regained eight or ten,
But trying so hard to catch the lead
He slipped and fell again!
Defeat! He lied there silently
–A tear dropped from his eye–
“There’s no sense running anymore;
Three strikes: I’m out! Why try!”
The will to rise had disappeared;
All hope had fled away;
So far behind, so error-prone;
A loser all the way.
“I’ve lost, so what’s the use,” he thought
“I’ll live with my disgrace.”
But then he thought about his dad
Who soon he’d have to face.
“Get up,” an echo sounded low.
“Get up and take your place;
You were not meant for failure here.
Get up and win the race.”
“With borrowed will get up,” it said,
“You haven’t lost at all.
For winning is no more than this:
To rise each time you fall.”
So up he rose to run once more,
And with a new commit
He resolved that win or lose
At least he wouldn’t quit.
So far behind the others now,
–The most he’d ever been–
Still he gave it all he had
And ran as though to win.
Three times he’d fallen, stumbling;
Three times he rose again;
Too far behind to hope to win
He still ran to the end.
They cheered the winning runner
As he crossed the line first place.
Head high, and proud, and happy;
No falling, no disgrace.
But when the fallen youngster
Crossed the line last place,
The crowd gave him the greater cheer,
For finishing the race.
And even though he came in last
With head bowed low, unproud,
You would have thought he’d won the race
To listen to the crowd.
And to his dad he sadly said,
“I didn’t do too well.”
“To me, you won,” his father said.
“You rose each time you fell.”
III
And now when things seem dark and hard
And difficult to face,
The memory of that little boy
Helps me in my race.
For all of life is like that race,
With ups and downs and all.
And all you have to do to win,
Is rise each time you fall.
“Quit! Give up! You’re beaten!”
They still shout in my face.
But another voice within me says:
“GET UP AND WIN THE RACE!”
Define Success to Achieve It
The contract said the product required an "Audit log." That was it. The web app for a major hospital chain with 35,000 users wanted an audit log, and we were under contractual obligation to deliver one. Whatever "audit log" meant.
The contract said the product required an "Audit log." That was it. The web app for a major hospital chain with 35,000 users wanted an audit log, and we were under contractual obligation to deliver one. Whatever "audit log" meant.
When I say audit log, what jumps to mind? Is it:
A log of CRUD (create, read, update, destroy) activities for key parts of the system?
Is it a log of every change event system-wide?
What does this log data capture? Who? What? When? Okay, what about deltas? What about related or effectual changes?
How often is this data written?
Who has access to it?
How is it accessed?
Is it just a database, or is there a UI?
If there's a UI, what kind of visuals are there?
Is it searchable? Filterable?
What is the point of the audit log? Is it for security? Audits? Paranoia? Legal compliance?
When someone is viewing the audit log, what are their goals? Why are they there? What are they looking for?
Is there any reporting? Are there rule sets that trigger flags or alarms? Where are those managed? Who manages them, and how?
I'm sure if I asked all of you, I could triple the length of these questions. These are just the core, fundamental questions one would ask regarding a feature like this. Well, these are the questions one SHOULD have asked regarding a feature like this before promising to deliver it.
The budget was gone, time was up, and everyone was frustrated
When the day finally came to tackle these and so many more questions about the audit log, the budget was gone, time was up, and everyone was frustrated with the project. You see, this was only one of the hundreds of features that had been called out in bulleted lists in the contract without any real definitions, requirements, or criteria. Because nothing was clearly defined, every single task was a meeting requiring several hours of conversation between clients, project managers, scrum masters, designers, and developers. Everyone had their own interpretation of what each feature meant, and nothing was written down. Even when there were mockups to demonstrate how a particular feature might function, due to a lack of requirements regarding integration with other parts of the system, even fully-built "done" features were constantly tossed, re-written, broken, updated, and on and on.
The audit log would be one of the worst offenders. This project (that we inherited from another company and team) would take more than double the original budget, and 9 months longer to ship than originally "planned" (obviously, planning wasn't part of the setup process for this project). Even when it shipped, it lacked significant functionality the client had hoped for. Everyone was sad, tired, and spent.
This is a story about setting yourself up for success (or failure)
This is a story about setting yourself up for success (or failure). The good news is it's not really that hard to do when you do it at the right time. The bad news is it's really hard to do if you don't and can cause innumerable problems, heartaches, cost and time overruns, angry clients, and more. The recipe for success is actually pretty straightforward:
Define success
Set clear, articulated goals
Don't underestimate level/time of effort
Under-promise, over-deliver
Do you want your projects to be great? Make every client happy? Deliver everything on time, and under budget? Fantastic. Those four points are the key, the rest is execution. I don't mean to devalue execution, because frankly, it's everything. But as the saying goes, failing to plan is planning to fail, and all the great execution in the world can't save you from poor planning. Great outcomes are achieved when goals are clearly articulated.
What is the definition of success? This is the first (and often middle, and last) question I ask when we are proposing/planning/kicking off a new project. When we, as a team, are able to clearly define what success means to each of us, we can set up a project that will drive us towards that definition. No matter what state you're in, beginning, middle, or end, you can always look back at the definition of success and see if you're on or off track. When you're done, you can categorically point to the definition and say with confidence that you expertly delivered on your promise. Everyone wins. If you don't have a “success” definition, then it's constantly up for debate and redefinition. Clearly pivoting at crucial times is important. You may find that your original definition lacked wisdom or detail, or maybe you learned something new since then. It's okay to, as a group, redefine success when significant changes occur. What you do not want to happen is that everyone has a slightly different opinion as to what success looks like. When that happens, no amount of expert execution will make everyone happy, and the project will ultimately fail.
Clear, articulated goals pave the path to success
Clear, articulated goals pave the path to success. Now that you've defined your destination (success) you need a map to get there. That map is a list of clear, concise, detailed goals to break down "success" into measurable pieces. These are most often found in the form of BRDs (business requirements documents) and acceptance criteria in stories. For designers, our job is usually to uncover and place these landmarks and signposts to guide the teams that follow behind on the trails we blaze. Virtually every design tool (contextual inquiry, interviews, journey mapping, user study, usability study, heuristic analysis et al) are meant to mine the minds of stakeholders, users and more so we can collectively create specific goals that, all together, combine to form the product or service we're building. You skip any of these steps, and it's like taking shortcuts in the untamed wilderness. It's like telling someone to bring you a rock. They bring you a rock. You say no, that's not the rock I'm looking for, bring me another rock. Ad infinitum. Have you ever been on a project that was lead that way? I have. It's torture. Don't do it to yourself or others.
Slow is smooth, and smooth is fast
“But Brandon!” You exclaim. “All this takes time, effort, and money. We have to kick this off NOW! Aintnobodygottimeforthat!” Bless you, my sweet, summer child. The military has a nice little axiom for just this argument: Slow is smooth, and smooth is fast. This is truer in software than just about anything. Moving fast and breaking things may be fun at first, but it's costly, and we've already discussed what happens to projects that try to function that way. An old boss of mine used to say, “we need to slow down to speed up.” Sounds like The Sphinx from Mystery Men, but it's true. Stop. Think. Articulate. Define. Refine. Plan. Do these things, and your execution will be faster. But it won't just be faster, it'll be better, with fewer iterations necessary, fewer bugs wrote, fewer changes necessary. Spend as much time as you can sharpening your axe so you have to swing it less and with less effort.
Sometimes along the way, you discover the target has moved, or a million other things may have changed, and all that perfect planning is completely invalidated. Did you waste your time? No. First off, one of the reasons you're likely able to recognize that the plan/target/efforts are no longer valid is because it was so clear to begin with. You are able to recognize when something isn't right because you were following a map and you now see it was upside down. Fantastic! What a great time to slow down to speed up! Pause, reassess, adjust plans/definitions/budgets/timelines/requirements et al until things are back in alignment, then execute again with abandon! Slow is smooth, and smooth is fast! Don't cling to a mistake just because you spent a lot of time and money making it.
Measure before, during, and after
How can you know if you're off course, or if you're holding the map upside down? You know because you are constantly measuring what matters. You measure before, during, and after. You monitor. You keep your finger on the pulse of each element of the project, looking for signs of atrophy, necrosis, and rot. You're also looking for bloat, smell, and itchiness. These are all metaphors we use to understand the negative aspects of projects. I can't tell you how many times someone has said "this smells funny." And usually, they're right. If you're paying attention, monitoring, thinking, measuring, reflecting back on the plan, against the criteria, rechecking the definition of success, you'll spot things that are leading you astray, or are causing your project (and people) pain and suffering.
If it’s so easy…
So if it's so easy, why do seemingly good projects go bad? How did the audit log issue (and that project in general) get so far gone? Well, in my team's defense, we came in mid-project when everything was already on fire, and we just tried to land the project as quickly as possible before we ran out of fuel and/or burst into flames. We saw first-hand what it was like to try to execute on a project that skipped literally every single one of these critical planning steps (and some we didn't even address here). We did our best to move forward.
Looking back though, even then, we thought since it was already on fire, we just needed to finish everything as quickly as possible, rather than, you know, putting out the fire with good planning and definition. We felt that moving fast and fixing things was a better approach. We were unequivocally wrong. I can state with no hesitation that, if we were to go back in time and take on that project again, here's how we should have done it:
Pause all development
Define the actual scope (success) of the engagement and append it to the contract
Write out every epic, feature, story, and task with relative acceptance criteria
Require interactive prototypes, not annotated PDFs
Updated required budgets and timelines against new scope (success)
Once we'd adequately addressed these items, we could then allow development to proceed. I guarantee we would have delivered faster, more reliably, and for less money.
Now, as you go back to your projects, or begin the next one, don’t plan to fail by failing to plan!
Define success
Set clear, articulated goals
Don't underestimate level/time of effort
Under-promise, over-deliver
How To Succeed Towards Failure
“Startups focus on high-value activities. As a company matures, 80–90% of time [goes to] operational factors, not innovation.”
I love this quote because it makes me sad. I’ve seen it happen first-hand, and I can see it happening around me in companies I both loathe and love.
or The Three Laws of Corporations
These tweets invigorated me, and I’d like to share why.
Firstly the first:
Startups focus on high-value activities. As a company matures, 80–90% of time [goes to] operational factors, not innovation.
I love this quote because it makes me sad. I’ve seen it happen first-hand, and I can see it happening around me in companies I both loathe and love. Or, as I like to say, companies I loave. (pronounced “LOHv”)
The company begins with an idea. The idea germinates and spreads and inspires like-minded individuals to risk it all on something they believe in. BAM — it’s a success! This success leads to growth and expansion and diversification and scaling-up and, inevitably, the machine is driving itself. It’s no longer the idea, or the passion, or the creators, or the innovators — it’s the machine that has grown up and around them and their success — and now it’s become self-aware and only wants to go on breathing. It takes a look at all the things that it comprises and tries to minimize the risks and maximize the rewards. It breaks apart successful teams so their talent can be distributed more evenly. It pinches every penny while announcing its overflowing coffers from the rooftops, draining morale. It rewards the status-quo and mediocre while it punishes and marginalizes all the things that once powered it to the very success it’s seeking to protect. At some point, invariably the world takes notice that the thing they once adored and lauded is now old-hat, stagnant, and uninteresting. The world moves on, looking elsewhere for the breath of life it once found in its old, sad friend.
Secondly the second:
What makes you successful will also ultimately be your doom.
Initially, my take on this was that it seemed to contradict the first statement, which implies if you continue to innovate, create, challenge, and provoke that you’ll keep succeeding. But this isn’t guaranteed. In fact, it’s proven to eventually fail. You won’t hit home runs every time at-bat. This is why the mature corporate entity seeks to protect itself in the first place. But what I love about this quote is that it frames your success in humility. It’s much like the famous quote for the King to keep him humble when successful and buoy him up when he’s a failure:
This too, shall pass.
That thing that brought you so far, for so long, with such great thrill, will, as Icarus’ wings, melt away and leave you plummeting to your demise. So why do I like this quote? Because knowing it ahead of time, Icarus can pack a parachute. Or his dad Dædalus could build his wings out of something a little more heat-resistant than wax. It frames your success in humbling ways such that you don’t keep sailing merrily off the edge of the world, but pause for a moment, get your bearings, adjust your course, and keep moving ahead; but objectively.
As you move forward with your career, be ever mindful of what is making you successful, so you don’t let it blind you to what’s right.
As we build our organizations, let us adapt and teach them the Three Laws of Robotics, perhaps we can call them The Three Laws of Corporations.
The Three Laws of Corporations
A company may not injure an idea or, through inaction, allow an idea to come to harm.
A company must obey the orders given to it by ideas, except where such orders would conflict with the First Law.
A company must protect its own existence as long as such protection does not conflict with the First or Second Laws.
And I’m not even sure we need the 3rd one.
Don’t die with your music still in you.
As a designer and developer, there are always little solutions, ideas, affordances, improvements, etc. milling about in my head. Everywhere I go I see ways to improve and enhance, to increase performance, usability, perception, and efficiency. That’s largely why I’m keeping this blog — It gives me a voice — a way for me to take action on the random bits in my head and not just grumble about crappy UX in the POS PoS machines.
Don’t die with your music still in you.
— Dr. Wayne Dyer
I heard this quoted in a religious context the other day and it has been ringing in my ears ever since.
As a singer and composer who doesn’t get to use those skills very often, and even then, very rarely to their full extent, it’s got me thinking about ways and means I can get all of the literal music welling up inside of me out. Maybe I should audition for more groups or shows. Maybe I should set aside some time to just write or record my music. Lots of potential there.
As a designer and developer, there are always little solutions, ideas, affordances, improvements, etc. milling about in my head. Everywhere I go I see ways to improve and enhance, to increase performance, usability, perception, and efficiency. That’s largely why I’m keeping this blog — It gives me a voice — a way for me to take action on the random bits in my head and not just grumble about crappy UX in the POS PoS machines. It gets them out of me so that they may live (or die) and benefit others.
So let’s abstract this quote a little bit.
Don’t die with your X still in you.
What are some other things we should get OUT before we’re reaped grimly? Here are the first things that came to my mind:
Don’t die with your …
family
potential
ideas
best
worst
failures
successes
anger
love
life
passions
fears
designs
solutions
observations
skills
knowledge
emotions
jokes
faith
history
story
stories
… still inside you.
I’m sure there are a ton more that would work really well and speak volumes to us. What do you think you should ensure gets out of you before you die — either to be rooted out and expunged or to be released for the world to enjoy (or mock, or critique or…)?