“Everything around you that you call life was made up by people that were no smarter than you…”
– Steve Jobs
The definition of decision fatigue is a state of mental overload that impedes your ability to make [good] decisions. I throw “good” in here because when I’m overwhelmed with decisions i find myself either agreeing or just blurting out the first thing I think of so I can get it off my plate. I think a lot of us get into this situation and are later questioned on why we made that particular decision. In retrospect, the decision is clearly wrong and it’s tough to admit it to ourselves much less the organization we’re supporting.
Here’s how I deal with it. I block an hour in the morning and an thirty minutes in the afternoon. The hour is to review my schedule, look at the agendas for all upcoming meetings and review any materials in advance of that meeting. You may find it difficult to block the time but it’s worth the effort, you’ll show up prepared and not just trying to look like you’re keeping up. Once you’re comfortable with this, push it to your teams and protect that hour for them. You may need to get consensus in the company that all meetings must have an agenda but well run meetings pay off for everyone.
The last thirty minutes of the day are for review. What do I think of each of the topics in the meetings during the day.
Give yourself and your teams that essential prep time for their day. Any meeting where they’re making decisions must be given adequate time to understand where they want to go and why, and what decisions are necessary to get there. You will find that the quality of the decisions will go up, you may even find the morale of the team going up as well.
In the Agile Manifesto you’ll find
Individuals and interactions over processes and tools
and if your teams are only talking to each other over email or Jira comments to “preserve a record” then you’re losing the team’s cohesion. They’re not a team if they only use Jira to communicate with each other, successful teams are not built this way. Ban it. Paste notes into the Jira story but don’t use it as a means of communicating.
One of my major complaints about creating “user stories” is that the discipline of writing “User Stories” has diminished and they become written so that only the person creating the story actually knows what is expected. In many organizations, anyone can write a user story. I have no problem with that as long as the person entering it has been coached and the discipline of writing them is maintained.
As a …
I want …
So I can …
With this alone you can at least get to some sort of relative estimation. Instill this discipline in the organization and you’ll see, if you’re capturing metrics, a reduction in time to get the story prioritized. But the real win, and I’m not sure how to quantify this, is that the teams will experience less confusion by having a fairly good idea of what is expected and they’ll certainly be able to relatively estimate it in less time.
Optionally, and this takes even more coaching and organizational discipline, write the beginning of the acceptance criteria as well.
It’s a starting point at least and that’s what user stories are supposed to be, a starting point, a place to begin the discussion of what is needed, by whom, and by when. User Stories are meant to facilitate a discussion between the team, they were never meant to be handed off to the team as complete requirements.
Stronghold Rescue and Relief provides protection and support for families in conflict zones. Operations are currently underway in Burma and Venezuela. You can become a supporter by visiting their website at StrongholdRescue.org.
For a video of how Stronghold Rescue began, as well as a summary of their mission, here’s a link a YouTube video. It’s worth the 30 minute watch.
Trust. I believe this is the single most important word when understanding why people work the way they do. I trust that you will do everything possible to make that customer’s experience with us outstanding. Without trust then people will not put themselves out there for clients. They know they will get blamed, second-guessed, and marginalized in the future. How do you build trust? As a manager or a leader, you take the blame when things go wrong and you give credit when it goes right. If it’s a one-off then you move on. If it’s a constant problem then you re-train. If you look deeper you may see that it’s a system’s issue, or a business process issue. Fix those problems.
I once sat in a management meeting where the topic was ‘disengaged employees’. Survey results had come back and only 60% were completed. The VP and the directors were blaming employees for being disengaged. This was a hierarchical, low-trust environment. Take a guess at who was actually disengaged. It wasn’t the employees.
It took me a long time to write this. I’ve been in companies where the main focus of the senior management team was their own bonuses. It was literally said in front of me (they forgot I was in the meeting) “Layoffs are coming but don’t worry, your bonuses are safe.” For me, leadership consists of two main themes: good stewardship of the company (it’s not a shell when you leave), and building trust and empathy with the people you’re entrusted to lead. The organization doesn’t exist to serve those that lead it.
Think of the value proposition(s) as a thread that starts with the client and runs through every part of your company. Include any first, second, or third degree touchpoint with a client. In other words, any team that affects another team, that affects a team that works with the client. At any point that thread can be cut, tied in a knot, or made stronger. The actions of these teams affects the relationship with the customer in the same way. They can destroy it, give the customer a perception that it takes forever to get things done, or make it easy for the customer to love you.
The larger the company the easier it is for people to not even realize that thread is there. Manage your business processes, ensure that the teams know how they affect the customer’s experience. I’ve found that most people don’t even know what affect they’re having on a customer. It has to be constantly reinforced that people are not simply doing a job, there’s a real effect on the client and client retention as a result.
There was a team responsible for file communication that I once worked with. The head of that team told me “…if there’s a problem then the client just has to tell us and we’ll get it fixed promptly.” This went completely against our brand promise of a high touch, boutique provider. No matter how we explained it, the team didn’t get it and customers got pissed off at it. The team just forgot that their actions reflected on the company as a whole.
Take the time to make sure everyone knows how important their jobs are to the client and to sustaining revenue.
Business processes and systems trend toward entropy. If left on their own then the only result can be disorder. The people who are at the mercy of this disorder are those that speak with and support clients and customers. We don’t make it hard to deliver great results to customers, it just happens. Take an annual audit of your business processes that customer support and sales teams need to deal with or get complaints about. Then get merciless at cutting out the junk you find that doesn’t help anyone.
In the absence of knowledge comes ‘this is how I got it to work.” People and groups will fill in gaps in knowledge. If you either don’t train people, or your product leaves areas of ambiguity, then people will take the easiest path forward – they’ll either give up, or, they’ll find a workaround that gets them what they need. And one day you’ll find these and be completely baffled as to how they came into existence.
Sit with your teams, see what they do, better yet, do it yourself. I’ve done this with every team I’ve worked with for products and I’ve found that issues going back to a customer for resolution had actually already been solved. But the solution was buried deep in a menu structure that had been forgotten about over time. If your teams are customer facing, sit with them for a day, see what you learn.
Over a year in development. Marketing staff to create content for promotion. A development team ready to fix bugs and add functionality. Lengthy arguments as to whether or not the background should be sea foam green or something else.
Total number of users: 0. After 2 years.
The platform was built to facilitate order entry because it was a lengthy process for us to complete it. So we pushed the work onto the customer and said “you’ll love this”. Well, they didn’t love it because they didn’t care. It wasn’t their problem and it was an obvious ploy to push work on to them. The platform existed for more than two years before it was finally shut down.
Ask yourself this when building a platform or product: “Why would a customer use this?” If the answer sounds anything like “because we want them to” then you should probably not spend much more effort on it. If you need evidence, create an email campaign that points to a landing page asking people to sign up and they’ll be notified for a beta. It should tell you a lot if nobody signs up, even more if nobody clicks.