An insight…

typically in a company of any size, you will have groups that are somewhat distinct (but lightly coupled) to big areas of friction.

the last thing they want to do is slow down because of *THOSE* people. that’s crazy! “Why should we take a hit if it isn’t our fault! We are the darlings of the company because we move so fast!”

The challenge with doing things like this often isn’t the people directly impacted by the change. They want it! Rather it is the people who work around the status quo and are generally unencumbered. To them, this is the major inconvenience, and it could impact comp, performance reviews, etc. It also can feel unfair. It’s “too process oriented.”

This is when leadership is so important. You need to give assurances to the teams who aren’t in the mess (but who may contribute to it by taxing downstream teams) that it is in everyone’s best interest to slow down to speed up.

Much easier said than done.

Just noting that the biggest blocker is often from the people who will not directly benefit immediately and who have influence in the org to basically say “see, we make it work without such drastic actions, why should we do something so crazy?”

I used to do this with Agile teams who couldn’t predictably deliver value every iteration. Instead of planning a full sprint’s worth of work, I’d tell them to pick ONE thing to work on. And after they finished that, take up ONE more thing to complete. It totally changed their mindset from one of “we can do anything” to “we can do a lot of things” — which was a necessary one to get them functioning in an Agile environment.

Mixed feelings. Should the backlog be cleaned up? Absolutely. Should a team on which everybody depends be beefed up or their workload spread across other teams? Yeah. Should people have clear priorities and work on high value/high priority items? Again, yes. That being said, I am not sure why drastic measures were needed. All of these could have been done in a normal fashion. Oh… And the guy is literally CTO of the company, so it’s not like he lacks authority to reorganize teams and requires less WIP or change prioritization.

What? “Deleting all jira tickets” what does that mean? Like.. current tickets because then your losing the tickets currently in development? Or past tickets because then your losing historical data. I understand this post was meant to say that we should prioritize people over processes when necessary but unless I’m missing something I don’t get this.

<sorry jira tickets not deleted. Compliance says no>

But seriously draconian constraints are the fastest way of getting on top of disorder

I’d love to learn how they got the CEO and other leaders on board with doing this? That feels like a critical piece of the puzzle to understand, especially in the current climate.

I agree with the approach. Sometimes you need to throw the circuit breaker. However, getting others, especially leadership, to agree is often the most difficult first step.

When you first introduce lean manufacturing into a production line, a great way to do it, is to press the emergency stop, and empower everyone on the line to press the stop each time they find a quality issue, so that everyone works together to fix the root causes. Of course, productivity drops to zero for the first 2 or 3 weeks, but then it starts to come back, and come back quickly soon exceeding where it was at before. This is not new thinking, these ideas are 50+ years old already. As a software engineer, it’s important to look at other branches of engineering to learn what our peers in other engineering disciplines already learned a long time ago.

It’s important for leaders to recognise that their job first and foremost is to maximise the delivery of value NOT maximising the utilisation of resources. The latter is important but should never come at the cost of the former. I see this mistake being made so often and it’s often caused by the inputs being measured and not the outputs. Usually because the inputs are easy to measure, not because it’s the most valuable thing to measure. If you aren’t measuring outcomes and focusing on that for every decision then you are blind to what really matters and your decisions will be guesses at best.

A useful pattern I’ve seen in more than one company I’ve worked for is being able to redeploy staff from one team or department to another at a moment’s notice.

This isn’t necessarily for a project, more like ad hoc contributions – a team is overwhelmed, perhaps because someone’s off sick, so anyone with the relevant skills from any team in the company (including other business streams) and the capacity to do it steps in to fill that gap.

As a specialist researcher between projects, I’d help out any other team needing help with research (market or UX), even in other business streams.

In previous roles, I worked in almost every department in the company – crunching numbers for a business case, booking hotels for a conference, coding survey responses, proof-reading tender documentation, checking entries in an operations database, drafting a contract, or working out the tax rate in Spain. It’s why I know so much stuff.

They didn’t just rotate me around teams because I was bored (I mean, that was part of it, sure) but because it was part of the culture in at least three companies I’ve worked for.

In my first job, every new hire spent a week in every team in that user journey, which was SO useful: I recommend others do it too.

All to rare. Genuine leadership has been replaced by theatre