There is this one phrase that can quickly demotivate people. I’ve seen a number of executives use this phrase in several conversations I’ve had. It doesn’t matter whether I’m an engineer, a manager, or a director. Neither does location matter – I’ve heard it in multiple offices around the world.
And whenever this phrase gets uttered by senior executives or leads, I immediately get deflated. And I also notice people around me get deflated when they hear it, too. I could see it from their body language or their eyes when we share glances.
What is that phrase, you might ask?
“Well, you and the team will just have to work smarter.”
It doesn’t matter whether the meeting is a 1:1, a team meeting, or an all-hands. Most often, the topic covered is a pretty meaty one. It could be about a newly-announced initiative that the teams will now have to do – aside from stuff currently on their plate. Or it could be about issues relating to how teams or departments work and interact with each other.
In short – it’s usually about problems that the teams can’t solve because they don’t have the influence to affect the actual solution. It needs input from you, the exec. And some empathy.
And that is what precisely deflates me when I hear that phrase – I don’t hear any empathy. I feel that I have not been heard at all at that moment. I took the time to explain our predicament or what I’ve already looked into solving that quandary. Uttering the phrase comes off as dismissive.
There’s also a second, quick follow-up phrase that further deflates the team or me.
“You’re a bunch of smart people (engineers). You figure it out.”
Well, to put it politely, I’ve already done my homework prior to bringing the topic up. I’m a knowledge worker whose primary skill is to think about and solve problems. The team and I are telling you, Mr/Ms/They executive, “We’ve hit a roadblock and need some of your help.”
What I Need From You
As I stated previously, one of the first things that the team or I need from an executive is empathy, an acknowledgment that we have a problem. We all are knowledge workers who had put a lot of time and effort into figuring things out before we even brought this issue to your attention.
The second thing the team and I need from you, the executive, is lack of judgment. Saying that second phrase, “You figure it out,” comes off as judgemental, implying that the team or I didn’t do our work beforehand. Are we or am I suddenly not performing in that instance?
The third thing that I and the team need is honesty. I don’t expect you to have all the answers. But I do hope you to be truthful and not dance around possible solutions for the sake of giving one. We also expect you to tell us if you can provide some help – any help – in some way or form. Remember – you have influence that none of us have, which is why we are bringing this issue up.
In the end, my team and I are more than just resources (another deflating term) in your organization. We are people. Treat us as people, not as resources.
What Management Needs to Consider About Agile Transformations
Many Agile transformations are happening in various businesses at the moment. Yes, the current pandemic has sped up the need to transform organizations to be more Agile. But even before COVID-19, I was encountering transformation stories in the news, on LinkedIn postings or blog posts. I heard many first-hand experiences in MeetUps and conferences. As an Agilist, I am happy and pleased to see all these transformations.
Still, a part of me sees a problem with all these transformations, especially those made by large companies. The leaders who want these transformations think there is an end state to a transformation. They invariably will ask – how long will this transformation take? When will this transformation end?
The Honest Answer
My candid answer to this question of when a transformation will end is: Never. There is no end state. And if there is – it’s because someone defined that end state, and maybe defined it prematurely. There are a couple of reasons why.
Usually, the first and primary problem that leaders want to fix is the inability of their product teams to deliver fast, on time, or even deliver something at all. This pain point is typically the basis for starting the transformation. You send your people to take classes. You hire consultants and coaches to work with your teams to implement things like Scrum or Kanban. As the change gains momentum, you experiment with scaling tools like the Spotify model, Scrum of Scrums, or LeSS, to solve the broader coordination and focus needed to execute and deliver.
And invariably, this is where management sees the endpoint of a transformation, a myopic and short-sighted conclusion.
Transforming Delivery Teams is the Beginning, Not the End
As your delivery teams gain Agility, they will run into problems interacting with other departments. The problems encountered at these boundaries will slow them down. I first encountered this when I was an Agile coach for Yahoo from 2005 – 2008. Yahoo was rolling out Agile enterprise-wide. It was the first of its kind in Silicon Valley. And a first of this magnitude and size for the Agile community. That endeavor yielded a lot of excellent practices, patterns, lessons, and surprising results.
It also showed me the painful reality that getting delivery teams Agile was only the beginning of an Agile Transformation, not the end.
One example that highlights this issue from my Yahoo experience stands out to this day – the boundary between Engineering and Finance. As engineering teams gained speed in their execution through their Agile transformation, the procurement process slowed them down. A month or two wait to get expenses approved was the average – but I ran into several instances where it took three to four months. That’s a lot of wasted market opportunity. That is a lot of time that the teams could have used working and delivering on priority items. Instead, the teams spent a good amount of effort in managing the procurement process, instead of managing their deliverables and outcomes.
I always remember this example because I’ve seen it manifest itself repeatedly in two or three other companies after my stint at Yahoo. Same problem. Same result of delivery teams slowing down. There are other examples that I can give – the boundaries with HR, Marketing, Sales, etc.
And it manifested itself, too, in coordinating with some executives. You would not believe the wait it took to schedule a meeting with one executive for approval, let alone two or more if you had to deal with more than one.
Name the department, and I most likely have an example.
Change is Constant, Agility is Not
If you, as an executive, decide to green-light the transformation beyond your delivery teams, what then? Is there a potential end destination that you can reach? Can you consider the transformation as Done?
Unfortunately, my answer again is No. Change is constant. Agile itself is not unchanging. People are continuously experimenting and evolving with new Agile ideas, tools, frameworks, and methods.
Your company undergoes change every day. It’s a complex adaptive system. You have a constant ebb and flow of change. Ideally, teams are long-lived in Agile, but new hires come in, and veterans depart to other opportunities. Your company’s board changes. Your executive leadership changes. You go on a hiring binge when the times are good, and lay-offs when times are bad.
Your company responds to stimuli, like your customers and their changing needs and issues, the actions of your competitors, the regulations passed by the government. And yes, events like the pandemic.
You had to change your strategy and execution from all these inputs.
All these changes create an impact, and what used to work may not work again. You always have to adjust and transform – especially when it comes to addressing your company’s Agility. Doesn’t this sound familiar?
It sure sounds like Inspect and Adapt, one of the founding principles of Agile. It is the principal reason why there is no end to Agile transformations. You and your company have to metamorphose time and again into a better vision and version of itself.
What Management Needs to Ask, and The Short Answer
Hopefully, by now, you understand that defining an endpoint doesn’t complete your Agile transformation. The agility issues between the boundaries of various departments in the companies are downright challenging and complex. The constant change and stimuli require you to reevaluate and adapt your solutions.
During my journey working at various places, I’ve come up with workarounds. Sometimes, I have managed to penetrate the boundary and effect agility. But it also stopped at a point. Executives and organizations are not able to stomach the challenging changes needed to move forward continually.
As an executive, you have the right to decide and define an endpoint. You can ask and seek the counsel of consultants and coaches to help determine the endpoint. You can use them to seed and bootstrap your Agility efforts. You might copy and paste Agile, but don’t expect the results to last long term.
You are as “Agile” as your slowest department.
What Management Needs to Ask, and The Better Answer
Are you willing to go beyond what you initially thought an Agile transformation means if you genuinely want to transform your entire company? Are you disposed to let go of the notion that this transformation will end? Will you include these principles in the company Mission Statement and Values? Will you live it every day once you write it down?
Are you inclined to incorporate values of Agility in every department? Are you eager to go into areas not seen traditionally as requiring Agile, like Sales and Marketing? Are you capable of providing budget, allocating money, hiring people to help you build this continual evolution? Will you allow people to establish communities of practice within their domains and focus on helping the company see these issues of Agility and come up with solutions?
Creating a full Agile transformation goes beyond implementing things like Scrum, Kanban, or LeSS. It requires people to be vested in the mission and goal. You need people working for you to believe in it and work at it. You may start with external consultants and coaches. But in the end, you need to build this capability into your organization.
Are you prepared as an executive team to lead by example, ask help when needed, and enable the organization to follow you into this continually evolving Agile Transformation?