A mindset that helps us through the messy and destructive moments is:
“Everything is your fault.”
Dogs do dog things. And if that dog thing isn’t something I like—it’s on me for allowing an environment and opportunity for that to happen. If I want different outcomes, I need to change the setup. Their actions are a reflection of my own.
Which naturally reminded me of W. Edwards Deming.
He estimated that 90-95% of organizational problems stem from the system, not the individual (Out of the Crisis). The Deming Institute explains it this way:
Dog trainers understand this. Cesar Millan’s tagline isn’t ‘fix the dog’—it’s ‘train the human.’ Which makes you wonder whether more business leaders should stick to goldfish instead of dogs. But I digress.
This connects to a bigger idea: attribution theory—the way we make sense of outcomes. The stories we tell ourselves about success and failure. If I blame chance, others, or unfairness, I become powerless—trapped by forces outside my control. But if I recognize my part in it, it gives me a lever to change things.
For example, if I get angry at one of the pups for chewing my shoe, we both have a bad day and the cycle is guaranteed to repeat. If I realize he couldn’t have done it if I had put my shoes out of reach, the cycle is broken.
This simple principle holds true in business and life in general.
When everything is my fault, I hold the leash. I choose where we go.
]]>Just a second. But it’s a vote.
A vote for distraction. A vote for becoming someone who isn’t really there.
You know who you want to be. So why aren’t you becoming them?
The answer: Who we are is what we do.
There is no fixed self. We’re under constant construction.
Every day, through countless micro-decisions, we’re molding who we are. We don’t find ourselves but shape ourselves through our choices.
Ten years from now, you’ll be exactly who your daily choices made you. No exceptions.
And here’s the part that should make us squirm: most of this is happening on autopilot.
Right now, we may be becoming someone we don’t want to be.
Not dramatically. But through the compound effect of daily decisions: to scroll instead of speak, to drift instead of strive.
The person who wants to be an early riser but stays up late scrolling becomes someone who can’t reach that goal. They don’t mean to become that person. But they do—one unnoticed vote at a time.
Every choice is a fight between who we are (craving ease) and who we could become (requiring effort). Present self almost always wins.
The chronically angry person isn’t choosing to be angry—they’re choosing not to pause before reacting.
But the pattern of our choices becomes our identity. And the identity reinforces the choices.
Breaking the loop doesn’t take willpower—it takes strategy:
Audit your votes. For one week, catch yourself in the small moments. What are you voting for when you pick up your phone mid-conversation? Just notice—without judgment.
Design your circumstances. Stop relying on willpower. Phone in another room during meals. Workout clothes laid out the night before. Make the good choice the easy choice.
Use the 10-10-10 rule. Before deciding, ask: How will I feel about this in 10 minutes? 10 months? 10 years? This shifts from immediate gratification to long-term construction.
We’re always becoming someone—the question is whether we’re paying attention.
We are not our thoughts or intentions.
Not our beliefs, excuses, or potential.We are our patterns.
If an outsider observed your behavior for a month, what would they conclude about your priorities, your character, your values?
That outsider is seeing your real identity—the person you’ve become, intentionally or not.
Don’t sleepwalk into your future self.
What would your best self do right now?
Not tomorrow. Not someday. Not when conditions are perfect.
Right now.
Do that.
Right now, in this moment, you’re casting a vote. Make it count.
Because in the end, we aren’t who we think we are.
We are what we do.
Wikipedia defines Technical Debt as “the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.”
Financial debt is a powerful tool. Used well, it can enable the impossible and contribute to wealth generation. Used poorly, it can destroy it.
Similarly, with software engineering, knowingly—or unknowingly—leaving some concerns for another day may be the right thing to do. But we must intentionally manage that.
“Buried in debt”. That was the prompt used to generate this article’s image. The result feels a bit post-apocalyptic. Let’s consider three lessons that can help us avoid such outcomes.
Credit cards typically have higher interest rates. Mortgages tend to have lower interest rates. Which is better?
The financial impact depends on (a) the interest rate and (b) how long balances are held.
Similarly, with software engineering, some choices can sit with minimal accrual. For others, the impact and cost to unwind compounds quickly as time passes.
Takeaway: Track the types of tech debt you hold. Some can safely coast with minimum payments. But when tech debt prompts more tech debt, recognize the potential for exponential growth.
As debt accumulates, necessary purchases can become impossible. For example, imagine all my income goes to debt payments. How will I buy groceries today? What do I do when an emergency expense arises?
Similarly, with software engineering, tech debt can reach a painful point where meeting the needs of the present is difficult—perhaps even impossible.
Takeaway: Stay alert to how the accumulation of tech debt influences decisions and our ability to respond to business needs.
I’ve taken the first two lessons to heart:
But what will happen if I never make payments? Negative consequences will surely follow.
Similarly, with software engineering, we must explicitly budget regular payments into our planning cycles. “We’ll do it in our free time” is not-so-secret code for “it ain’t happening”.
Takeaway: Paying off tech debt should be part of each planning cycle. Allocate time and capacity to do the work.
I’d love to hear your thoughts. Please feel free to comment on the related LinkedIn post.
]]>Have ever had an experience like this?
You ask a question.
The other person asks you to clarify…
🤔
And at that moment, you realize you aren’t entirely sure what you were trying to ask.
Sound at all familiar? I know it’s happened to me.
If sometimes we’re not 100% sure what the words that just came out of our own mouth mean, then it seems safe to assume that we’re scoring well below that when it comes to understanding others.
So what can we do?
Clarifying questions are a great way to improve our understanding, reduce miscommunications, and show that we value and care about the person/topic.
Please let me know by leaving a comment on the LinkedIn post.
Thanks to DeepAI for the image, where its challenges with letters worked out masterfully.
]]>The scientific definition of velocity is precise and useful:
v = the change of distance in a given direction ÷ the change in time
Thus, a car that moves 60 miles east between 3:00 and 4:00 pm has a velocity of 60 mph east.
Alternatively, in casual conversation, many use velocity and speed interchangeably when referring to any rate of change. This too makes sense as a formula:
v = measurement of change ÷ the change in time
If you’re following Scrum, or another software development methodology with fixed length work cycles (i.e. Sprints), the commonly accepted formula for velocity is:
v = story points completed ÷ work cycle
Therefore, a team that completes 80 story points in a sprint could be said to have a velocity of 80 story points/sprint, or commonly simplified to 80 points.
Does this formula make sense? To answer that, we first need to define our unit of measurement. What exactly is a story point?
Ron Jeffries, likely the inventor of the story point, explains they were first used to estimate time. However, a recent informal poll on LinkedIn shows story points are also used to factor effort, complexity, risk, and uncertainty into work estimates.
Does that change anything? No.
If you use story points to figure out how much work can fit in a fixed time period—story points are always an estimation of time. Call it what you want, but know that time is the subject matter.
In the article linked above, Ron Jeffries explains the switch from Days to Points was intended to abstract estimations away from time. Why? Although Days accurately communicated that these were time estimates, the difference between the team’s definition of an Ideal Day and a calendar day was lost in translation.
With what result? This misunderstanding exaggerated disparities between estimated time and actual time, prompting stakeholders to focus on that. It’s not hard to imagine that Mr. Jeffries and team found this to be an unhelpful distraction that did not contribute to the performance of an engineering team. And thus, points. [Thank you to Ron Jeffries for taking the time to review the above 2 paragraphs for accuracy.]
As time has passed, this verbal sleight of hand has grown increasingly complex. One team may adopt the Fibonacci sequence. Another, in an attempt to emphasize the inexactness of the estimates, may use round numbers to lower the implied precision of that sequence (e.g. 20 vs 21). Still others will avoid numbers altogether and use T-shirt sizes, although they are often later translated back to… you guessed it!… numbers. The purpose of all this? To pretend we’re not talking about time.
Lest we fall prey to our own tricks of misdirection, if points are being used to fit work into a defined time period, all of these schemes reduce down to a measurement of time. Yes, this point was made earlier, but it bears repeating.
Much effort has gone into clouding the direct relationship between points and time. As a result, story points have no standard unit of measurement. We know this. It is the reason comparing points between teams is generally recognized as bad practice. Apples, meet oranges.
So back to our question, does this formula for velocity make any sense?
v = story points completed ÷ work cycle
With no standard unit of measurement for story points, velocity—in the general case—must be understood as:
v = <undefined term> ÷ work cycle
That, dear reader, is utter nonsense. But wait, there’s more! After all, you were promised this nonsense would come in gloriously compounding layers.
Can you guess what happens when management hears about velocity?
“You have a way to measure engineering speed? Great, we need to go faster!”
Meet your new KPI: Continuously Improving Velocity.
To be abundantly clear, this is not good. We established that velocity, as a general measurement, is meaningless. Now, our success is being measured by… doing more of it. 🙄
However, I’m in a glass-half-full kind of mood. So, is this KPI salvageable?
Putting the general case aside, let’s argue that within a single team a story point will be used consistently enough to make it a useful quantifier. In that setting, does increasing velocity make sense as a measurement of engineering performance?
Our fictional team has chosen to use each story point to represent the work that could reasonably be completed in one working day. Effort, complexity, and risk are factored into their estimates.
In each of the following three scenarios, the team selects 80 points of work for the cycle. They do not work any overtime.
This seems improbable, but let’s roll with it. The team completes the exact 80 points of work scheduled.
Now tell me, how does this team increase velocity? Given that story points are an estimation of time, not output, there is only one way for a team with perfect estimates to increase velocity:
A more likely scenario, the team’s estimates are imperfect. They overestimated how long tasks would take. As a result they were able to complete 90 points.
It’s critical to note that capacity did not increase to 90. Points ultimately represent time. The team did not figure out a way to make more time. So what happened? They guessed wrong.
What’s morbidly interesting is that if their prior cycle’s estimate was more accurate, then this estimation error will appear as “increased velocity”. Good job, team! 👍
But that’s a single cycle. How can the overestimating team continue to increase velocity? They have an additional option over Scenario 1:
Perhaps the most realistic scenario, the team underestimates the time required. The work cycle ends and the team completed 70 points.
Unfortunately, if prior cycles’ estimation accuracy was higher, this wrong guess will show up on KPI reports as a velocity decrease. 📉
With rumors of layoffs swirling, how does the underestimating team increase their velocity? They have the most options. Too bad they’re all terrible:
Yes, of course, the pun is intended.
One last detail that is exceptionally important to internalize is that in all three scenarios exactly the same amount of work and value was delivered. The only thing that changed was the accuracy of the estimates.
This is an example where the choice of wording, specifically velocity, has done a great disservice. I’m not blaming anyone. I mean to imply no malintent. Regardless, the outcome is the same.
So let’s drop the jargon and call things as they are. The formula for what we’ve been talking about is:
estimated time ÷ actual time
Looking at that formula, what does it describe? Accuracy of estimation. Does the label matter? Yes! If we called it what it is, estimation accuracy, imagine what would immediately become plain:
That’s a shame. Because if you’re using story points to do so, it’s not what your numbers mean.
This last piece is painfully amusing. You’ll recall from earlier in the article, story points were introduced to do what? To counteract a tendency to focus on variations between work estimates and actual time spent.
And what have we done?
Under the name of Velocity, we’ve memorialized and spotlighted this very thing as a core metric. But we couldn’t stop there, could we? Oh no. Through mislabeling and misdirection we also managed to make it far more confusing along the way.
Bravo! Bravo. 👏
]]>“Management has decided that we need to introduce additional process to keep up with the operational demands of our growing business.”
Setting aside the whole “management has decided” part, let’s talk about process. Depending upon your experiences, you may have some immediate–and possibly strong–reactions to the mention of adding process. I get it.
However, I think most of us would agree that categorically labeling process as “good” or “bad” is an unhelpful oversimplification. Instead, we can think of process like an algorithm–it’s just describing a way of doing a thing. Is that specific way good or bad? Well, that largely depends on the details. How is it implemented? Does it solve the problem at hand?
Here are three scenarios that provide one mental model to think about process.
Imagine someone sitting down to tackle a puzzle. What’s the first move? After dumping the pieces on the table, they take the time to flip each piece face up.
Why do they follow this process? Because it’s fun? Maybe–people like different things. But most likely it’s because it makes sense. They know that it helps them reach their goal of solving the puzzle.
The best software engineering processes should be like that–whether you find the activity inspiring or not–the results are beneficial. They support people by guiding them to the desired outcomes.
Next, picture some friends setting up a poker game. Before shuffling, the dealer flips through the cards to make sure they are all face down.
Why? It’s just how the game works. As illustrated in the photo above, it doesn’t matter how good your hand is, if you insist on playing faces out.
Some software engineering processes are like that too. For example, if you want to play the SOC 2 Type 2 compliance game, you’re going to need a change management control. House rules. Auditor wins.
With that said, when picking a process to meet such requirements–and multiple options often exist–let the principle found in Parable One guide you.
Here’s the last one. Someone pulls out a set of tarot cards. The cards are revealed, face up.
Why is this process followed? Some believe it unveils secrets about the future. However, this one’s a bit more up for debate, right?
And so I ask, Does the logic-driven world of software engineering have parallels with the mystical? Before you answer, consider: Have you ever seen story points cast to foretell a future delivery date? Likely so.
And what of the outcomes? When it flops, the people–not the process–are often faulted. On the other hand, when an estimate is accurate, some might justifiably wonder whether that is little more than coincidence.
Now, I’m not saying empirical approaches to estimation don’t exist. But I am encouraging readers to question whether that describes the approach they use.
And sometimes processes that start out following the principles of Parable One drift towards Parable Three. The once informed actions, repeated over time, can become empty recitations serving an unknown purpose to appease a long forgotten problem.
Processes are like tools in a toolbox. Pick the right one for the job. And keep your eyes open to recognize when the game changes. Don’t keep shuffling for poker when the cards get swapped out with a puzzle.
]]>However, looking out my window, what do I see? Trees that are red and orange along with a sky that is gray.
To make sense of the information around us we must assess context. My writing is no different. I’ll do my best to be honest and present information that I hope will be of use to others. However, the reader must critically evaluate the information. Part of that is considering the perspective that I’m viewing things from.
Here are a few details that color my perception.
Range of possibility: Sole proprietors to millions of employees.
My experience: Organizations of just under 50 to just over 1,000 people. I’ve led single teams of three up to departments of over three hundred. Prior to this I spent seven years as a sole proprietor.
Range of possibility: Some businesses were started yesterday and others, amazingly, are over a thousand years old.
My experience: I’ve specifically worked at companies that identified as “startups”. Some were founded less than two years prior to my joining, while others had been in business nearly a decade.
Range of possibility: On-site, hybrid, remote.
My experience: I’ve worked at companies that did all three and have personally worked both on-site and remotely. However, the bulk of my professional experience has been remote, exclusively so since 2008. Prior to that, as a sole proprietor, I worked for over a year from a small mountain village in Panama.
Range of possibility: Too expansive to attempt to list.
My experience: I’ve worked at technology companies. The majority of these were B2B. One was B2C. Most of these focused on providing software or services to software engineers, such as: distributed database, in-memory data grid, Ruby on Rails PaaS, log storage and analysis, etc. I have also worked at two FinTech companies, one directly servicing end consumers and one that provided BaaS.
]]>⚠ Proceed with caution. ⚠
Saying “Yes” to everything is a great way to let others down while also burning yourself out. 👍
On the other hand, simply saying “No” a lot doesn’t solve your problems either. It may make more. At one company early in my management career, my Director pulled me aside. He shared that amongst the leadership team, I had earned the reputation of Dr. No!
I wondered, How could this be?! I was responsibly focusing on the details and alerting leadership to risks. I imagined myself courageous for protecting my team, and even the person asking for the impossible, from the inevitable consequences of unrealistic expectations.
I failed to realize that people weren’t intentionally asking for the impossible. They just wanted to know if I could help them solve a problem[0] and asked in the best way they knew how. Cast in that light, my repeated Noes suddenly felt less noble.
One thing that helped me was the “yes, and…” approach. Note, this is intentionally not the “yes, but…” approach. While similar, “yes, but…” sounds close enough to “No” that it will risk putting your listener into a defensive frame of mind.
So how does the “yes, and…” approach work? It’s simple. For example, let’s say it’s Monday. Your team’s work is scheduled for the next two weeks. Then the Boss walks in.
Boss: A customer reached out to me and wants to know if we can have feature Y delivered by Friday. Can you do that?
You: Yes, and can we discuss tradeoffs? The team is already working on feature X. We’ll need to take at least one person off of that project. That will push back delivery by two or more days. Are you and the other stakeholders comfortable with that?
The conversation changes from a yes/no question, which can feel adversarial, to what is hopefully a more productive discussion of informed options.
How might it turn out?
Boss: I think they were randomly throwing a date out there. I’ll let them know we can schedule the work for our next two-week cycle.
Or maybe it will be something more like this.
Boss: I understand. However, this is a blocking issue for the customer. We need to invoice them this quarter. Who are the stakeholders on feature X? I’ll talk to them.
So there you have it. It may not always feel easy, but it is simple.
I would strongly recommend that you follow the conversation with an email. Use it to avoid misunderstandings later. For example, Did I accurately capture what we decided?
Will this one handy linguistic trick solve all your problems when it comes to impossible asks? Yes, and… well, actually, No. It won’t. You will still have to say No at times. And it will be critical that you do. But save them up for when it will count most.
Side note, the “yes, and…” technique will also come in handy if you decide to dabble in improvisational comedy.
[0] Unfortunately, this will not always be true. Some will prove to be bad actors, intentionally asking for the impossible.
]]>Sprint is commonly used in software engineering to describe a period of planned work, and frankly, it annoys me a bit. Let me explain.
I live in beautiful Boise, ID surrounded by hundreds of miles of foothill trails, like the one pictured above. When I venture out on my mountain bike, I know I have to pace myself according to the physical challenges of that specific trail. It’s rare that I find myself sprinting.
Setting aside how the software industry has co-opted the word, the definition of sprint is:
“to run or go at top speed especially for a short distance”
When I do find myself in an all-out exertion, typically climbing a steeper section of hill, my body demands a period of lower intensity rest if I’m going to be able to continue.
Neither in athletics, nor in knowledge work, can people sustain a 100% pace for an extended period of time. Only with rest comes growth. But if we expect our teams to constantly sprint towards deadlines, is it any wonder that people experience burn out?
If an unsustainable pace is not our intention, are there alternatives that add clarity? I believe there are.
By dropping the jargon, clarity of communication is improved for all audiences.
]]>During an interview this morning I was asked about how I approach deadlines. My answer began with something like:
“I’m not sure of deadline’s etymology, but it doesn’t sound friendly. It would seem to imply that if the line is crossed, death will result. Or at the very least, there will be some very serious consequences. In my experience, deadlines are often artificial and arbitrary, organizationally self-imposed, and are not a matter of life or death.”
Curiosity prompted me to later seek out the history of the word.
According to various sources, including Merriam-Webster, the word starts to appear in written records during the 1860s, specifically in connection with the Civil War.
The original meaning was, just as it sounds, a line around prisoners beyond which they would be shot dead. One work quoted by Merriam-Webster highlights a psychological angle of the tool:
“The guard lines are drawn in; making our play grounds much smaller and cutting us off from our best well of water, this is done for no other purpose under the sun but to interfere with our only enjoyment and to grind us to the lowest depth of subjugation.”
—William Williston Heartsill, Diary of William Williston Heartsill (entry Mar. 1863)
To me, a direct comparison between prisoners at risk of death and modern-day workers’ at-will employment seems inappropriate. A bit overdramatic, even for me. Nevertheless, in the spirit of this series, I do wonder whether the negative overtones carry through. Whether familiar with the word’s history or not, the picture it paints and the feeling it conveys is clear:
Cross this line and there will be seriously bad consequences.
Like the above picture of a dead tree in a barren West Texas landscape, “deadline” ominously portends difficult times ahead. It made me ask myself:
For me, the answer to the above is No. I think words such as goal, estimate, projection, or delivery date would better communicate both the thought and the intended feeling.
]]>