Get your team’s shit together…and own it.
Remember earlier when we explored how responding erratically takes a chaotic situation and amplifies it?
I want to talk about one of everyone’s favorite ways to do this.
One that won’t show up in your burndown chart, and that focusing on your team’s productivity metrics can even ENCOURAGE you to try.
That’s when you take the difficulty your team is facing, and in order to reduce the chaos you are dealing with, make a decision that makes the difficulty exclusively some other team’s problem.
By randomly shoving your team’s difficulty onto another team, you’re amplifying the chaos. And the most likely reaction from the team that you’re sticking this on is that they will also react poorly and amplify the chaos. Overall for your organization, it’s going to be a net negative even if it helps you avoid this one tough situation today, and over the long term, you are contributing to the net amount of chaos you, yourself, and your team experience.
So how do we catch ourselves doing this, and what can we do about it?
Not so long ago, at small consulting firm …
Webity was web and mobile development firm, and we were always working on multiple projects at a time. We had a very small team and everyone worked on all the projects. We were constantly being pulled in different directions.
This is at 10x worse than having to work on several priorities for the same company. Our customers did not give a s*** that we had other customers and other work to do that had to be balanced. They wanted to feel like we only worked for them, and there was very little that we could do to fight that perception.
In our first year, sometimes we would start to get behind on a project, and our first reaction was to start rushing around trying to make up time. We’d start putting in extra hours and anything that wasn’t actual work on the project would get shoved by the wayside. Having meetings, asking questions, double-checking code, documenting what we were doing, communicating fully with each other, checking in with the client to make sure they were okay with minor design changes, things like that. We would start to think of all these things as niceties, and would just throw them out the window when everything started to get chaotic.
The problem was that would always come back and bite us in the ass.
Every. Single. Time.
There was always some decision that was made during the chaos to “save time” that would come back around, and end up costing us 5x or 10x in client follow-up and rework than the amount of time that it ever saved us. We knew this initially just based on a gut instinct of how much behind schedule we had ever been, and then how far beyond the deadline the work would get drawn out.
Even without strict data, that long-tail was always obviously longer.
Putting all the shit in a backpack (a.k.a. spreadsheet…)
It turned out when we followed our process, we had really good instincts for what our clients needed. We rarely had to do rework and regardless of if the project closed on time, it stayed closed.
When we got behind and started working wildly to “save time,” the project would invariably fail to meet acceptance criteria and get stuck in a long-tail of rework beyond the deadline, even if we initially did catch up and get to check the box of shipping by the deadline.
So we said, “Hey, this is all costing us time anyways, we’re just going to commit to always tracking our time on things so we can really see how much, where and why.” We had already been settings estimates for work, but now we started tracking our time on a pretty granular level and didn’t let anything keep us from doing that. At the end of the project, we were super honest with ourselves about how accurate our estimates were, and why or where they went wrong.
This was immensely helpful in 4 different ways:
- The obvious one: This helped us get better about estimating time in general so we could set more realistic expectations with customers up-front so we didn’t get into “chaos” situations as often.
- It immediately helped us get a sense of how costly our chaos decisions were because we tracked all the long-tail time spent on projects against the original decision point that caused it. It helped us understand how decisions that felt good in the moment led to even more pain down the line.
- Weirdest of all: The simple act of committing to tracking our time during the chaos was enough to make us think critically about the actions we were taking, and start to break the cycle of severe instinctual overreaction to stressful situations. Just committing the commitment was enough to improve our decision making well before we actually looked at the results and identified specifically bad decisions. (I found out later that this is a known psychological thing called “check-pointing” and is a great way to reduce all kinds of bias!)
- Finally: it helped us see which of our internal activities had the most impact on the outcome if skipped or altered. For example, minor, minor design changes always felt like a “cheap” way to save time, but if we did not get specific customer approval up-front, those changes demolished us in the review phase or post-launch. No matter how we structured the language around mock-up delivery ahead of time or tried explain that the changes were necessary to meet the deadline after the fact.
Now, You’ll notice that “getting less behind” is not in the list.
If getting stuff out the door on time is the only thing that you are judging yourself on, tracking your effort is not going to solve your problems.
What it will do is:
- Make you better at forecasting over the long-term so you are less likely to get behind in the first place and
- Reduce the amount of unestimated (and in consulting, often unpaid) work you do overall.
But in the initial moment of behind-ness, it will only prevent you from kicking the can down the road…where it shatters into a thousand pieces and is much harder to clean-up.
There is no “painless” option
Let’s be clear, once you are behind, it is not a matter of choosing between doing a hard thing and not having to do it.
You can either honestly deal with the situation now and go through that difficulty immediately.
Or you watch it trail out over the long-tail end of the project in all these tiny requests and issues that were created from your team’s chaotic response to what was already a difficult situation.
It’s either ripping off the band-aid or death by a thousand cuts.
And more importantly for the customer, it’s either being able to end on a high note even if the initial deadline was missed, or it’s getting more and more frustrated with a project that they thought was done months ago.
The result of this information at Webity was that there were a lot of times that I personally had to look at customers and say “This is taking longer than we thought, here’s the reasons why and the new date when it will get done.”
And that sucked. Nobody likes to admit you failed, and if you are only judging yourself on meeting the deadline, then this will be a big, fat failure. Not to mention there were several times where clients were very angry with us. As the manager that was something I had to deal with and learn to work through with clients.
If you are judging yourself on providing the best product and service to your customer, then it’s obvious which is the right decision and it’s the one we made. Maybe not surprisingly, being open and honest about why things were taking longer and why we weren’t rushing usually got a very positive response from clients. Who wouldn’t rather have it done well?
And we had numbers to back up how long skimping on the process would cost us. This allowed us to convince them to stick with it, or to design very, very clear contract amendments to protect ourselves if we decided to scrimp.
Overall, sticking to our process and doing the “time-consuming” internal tasks that didn’t seem to directly lead to launching the project, cost us less time over the long run, both on individual projects and overall in a reduction to our unpaid rework time as a team.
Because Difficulty is a Real, Physical Thing
What I learned from this was that when you get into a difficult situation you can’t make the difficulty go away. There’s no space-time pocket where you can stick the difficulty so it doesn’t exist anymore. You’re either going to deal with it now or deal with it later, but you’re going to have to deal with it eventually.
So if you’re making decisions to try and NOT deal with it, to try to avoid the pain entirely…those are dumb decisions. It’s not possible.
That’s like making decisions based on gravity suddenly not existing. You can go up to your roof and pretend that’s true for a bit by jumping off…but you’re in for a rude awakening when you hit the ground.
When we get stressed out that’s exactly what our brains try to do — make decisions to get us out of danger and away from difficulty. We have to learn to be smarter than our brains.
If CERN can’t do it, You can’t either.
Tracking our time and the results of our decisions was incredibly fast and effective at Webity because we were a small, tight-knit organization. The effects of our decisions were obvious, and it was easy to see that we were just moving the difficulty around from one place to another like a kid that doesn’t want to eat their vegetables.
In a larger organization, it becomes much easier to fake getting rid of the difficulty. Depending on how interconnected teams are, it’s actually not that hard to take your team’s danger/difficult and sort of disperse it throughout the organization. Your team gets behind their schedule, so you cut corners to launch on time. Now you might have built something super buggy, undocumented and inefficient but you got the product out the door so your team is off the hook. The difficulty was averted right?
No! Come on, you know better.
If Difficulty is a real, physical thing, then according to E=mc^2, that shit has to end up somewhere…
And just because you can’t see it anymore, doesn’t mean it’s not affecting you.
- Now the Support team is dealing with a huge new ticket burden without any information or resources to debug the issues in your service
- The Systems team is getting dragged out of bed at 3AM to restart your box because at least once a day you knock the database over with some randomly spiking query load.
- Not to mention another Product team was supposed to be leveraging the platform you built for the company’s next bug, ahem, I mean BIG launch, but the code you turned over made their lead developer have a stroke, putting them at least 2 months behind schedule.
Your team might get feel like you averted the danger, but again, do you want to judge yourself on meeting deadlines or the actual value of what you are contributing to the organization?
When you’re running your own business you have a really, really small feedback loop on this question. Everything is your problem, so you can’t just toss it over the wall to some other team.
When you are in a larger organization, it’s not that we don’t see the effect of things, we just have a lot on our own plate and chose to put on blinders. Some large organization have good communication channels and high integration between teams that make it clear when one team’s avoidance strategies are affecting another team, but most startups don’t.
So it’s up to you to keep things accountable if you want to reduce the chaos in your organization.
That means there’s even more of a burden on you to be honest in reporting and reviewing the full spectrum your team’s outcomes, including how they affect other team’s metrics. If you are, you’ll be able to see how you’re taking danger or difficulty, and sticking it on someone else in your organization.
If you’re really committed to improving the maturity of your organization in the long-term, you have to start by holding you term accountable for dealing with the difficulty.
