I’m excited to share that I’m finally launching a podcast, after a few almost successful attempts in the past.
The Align Remotely podcast will focus on leading distributed teams and everything associated with that topic, like leadership and operations to help achieve together, now that nearly everyone works from home.
In addition to the actual recording, the show notes will also include a visual representation of the discussion, a transcript, as well as any other resources mentioned during the discussion. This should help make the contents skimmable and also useful for anyone who prefers a more visual way to consume audio content.
The first episode was recorded with James Newson, who is a technical specialist around remote work. We cover any potential issues and possibilities around hybrid working, for when the coronavirus epidemic is over. And there is a lot more to it than I thought, because usually I was just leaning on company IT to “sort it out”, without having a proper think-through.
The biggest challenge I've had with building alignment as a team leader was the "silo megaphone effect". In the past, I've attended a number of surreal stakeholder meetings attended by:
head of product
head of delivery
a technical person
a head of QA
or possibly other managers.
Each participant makes statements that--on their own--made absolute sense. For example, the QA person argued for keeping a certain standard in terms of quality. The delivery person wanted to bring in the date as much as possible. The product person wanted to throw in as much scope as possible to make it easier to sell the product. I understood what they were saying. I could fully understand why they were saying what they were. They genuinely believed they were arguing for the overall benefit of the company, as a whole.
Nevertheless, if you juxtaposed what one manager was saying against the other, it was less than clear what the overall priority was. And this is exactly what I call the silo megaphone effect.
Each manager spent a lot of time with their respective team. So they had agreement amongst themselves as to the best course of action. But when meeting across department boundaries, the communication broke down. Nassim Taleb noted that firemen with much downtime who talk to each other for too long come to agree on many things that an outside, impartial observer would find ludicrous (they develop political ideas that are very similar). In particular, each manager running a department has a certain set of objectives and assumptions that are reinforced by discussions with people he's managing, resulting in rather surreal coordination efforts.
The silo megaphone effect refers to the tendency for managers to specifically argue what is best for their particular functional area. The inadvertent focus is on local maximization. This happens by default, despite everyone having the best of intentions.
I've fallen into the trap myself, of arguing for a short term benefit that will bring in the schedule at the expense of properly solving a problem at an organizational level. Sometimes the schedule pressure was just immense.
The main way that I dealt with this was to cross-reference statements from different stakeholders, and then ask for further clarification. The aim was to achieve what’s called “referential integrity” in a database. Where every data point is fully linked up to every other data point. Ultimately, in order to delegate effectively, we needed to agree what the ground rules were. This way we could communicate them to the teams, and hold ourselves accountable to them.
No one wakes up in the morning excited to go to work and look ignorant, incompetent, or disruptive. While it's not true of everyone, I think it's fair to say that anyone who gets a job wants to be there and usually wants to do well--for the purpose of self-respect. Look at how elated most people are when they accept a job after getting an offer. It's when they enter into the "systems" at a particular company, that everything usually takes a left turn.
Modern Times (1936) trailer: capturing the essence of managing
In established companies, it's sadly common for employees to be habituated in a context of fear of failure. Especially if there is a lot of pressure from management to perform at a high level. There are ambitious goals, often coupled with a lack of clarity on how they will be achieved. In practice, employees focus on looking busy (however that is defined). They end up fearing failure, of not living up to expectations.
As a manager, there is a fine line to draw here. You don't want to set the bar too low and cause everyone to just slack off. The starting point here is one of psychological safety; according to the research, this is one of the main factors driving high performance in teams. In particular, how you handle errors, failures, or surprises in a way that keeps the team accountable while enabling them to believe that they will be listened to--if they speak up.
Common error types
According to Amy Edmondson in The Fearless Organization, there are 3 different types of errors which happen professionally, and their meaning is largely driven by context:
mechanical errors in a highly repeated process that just need to be minimized in frequency: this is what Modern Times parodied
interaction errors which result from highly complicated relationships, especially in a larger company
thwarted expectations around a goal in the context of experimentation, often a surprising result of an experiment
A large part of the challenge of large companies is that they treat all errors as if they were all #1 by default. This approach may be tied to political gamesmanship. But not everything is just a deviation from a standard (regardless of who actually decides and imposes that standard). Especially in knowledge work like software, where completing something requires you to learn something you don't know up front. Edmondson quips, “For knowledge work to flourish, the workplace must be one where people feel able to share their knowledge!”
In my software experience, most of the problems encountered, especially around people and process, were due to #2. Company systems were wrong, inadequate or just misaligned. Unfortunately, this typically meant that a person or department was singled out and blamed. I tried hard to bring the discussion back into a discussion around how the work was done, and if something could be done to prevent a similar problem from re-occurring.
The last type (#3) is essentially an opportunity to improve the company, the product, or the workflow, packaged as an intellectual surprise. Sometimes, the team would come across a much better way to solve or define a technical problem than they had originally wanted to do otherwise. This was particularly common in the early days of designing a large system. The same can be true on the business side, if the company is open to experimentation on that end. These are so valuable, that most innovation circles try to maximize the number of these errors through structured experimentation and record-keeping, in order to speed up overall progress.
Be open to taking ownership and admitting mistakes
From the perspective of psychological safety, it's critical to start with assuming any error is a #2. This includes assuming that the leader in the system is responsible for the system. More importantly, he is also part of the system. Which means that the manager needs to be open to letting their ego bruised, and be willing to admit mistakes in front of their fellow team members, in the service of improving life for everyone. Once I did this enough times with my team, they realized and eventually believed that I was genuinely interested in optimizing how the team worked.
Essentially the way to solve the misaligned expectations problem (bar too high vs too low) is to view the work as a system. And that way, you depersonalize the work enough, that fears become less of a driver for action. Instead, employees follow their genuine interest in improving their own work life. This allays fears of failure. And gets everyone more involved and excited.
Ultimately, you care about the output your team produces, so focus your management on that, rather than on policing individual effectiveness. Paradoxically it produces better results.
Key Takeaways
Psychological safety lies at the heart of high performing teams
Most commonly errors are assumed to be individual mistakes, rather than the result of complicated interactions gone wrong.
"No, you see, you have to monitor what people are doing. If you don't do that, people will just do a minimum of work," Alessja said.
I used to run this same team, and everything felt faster. They were talking to each other to figure out how to pass things along. And things just happened. True self management. And now the performance fell apart. It had devolved into everyone working on their own tasks again, as I was trying to coordinate a number of teams simultaneously.
"I don't feel comfortable with that", I countered. By increasing control and trying to force people to go faster, you'd likely get the opposite effect. I had in mind my previous experience at the Lego event. Moreover, there are other ways to keep discipline in a new product environment.
"I tend to agree", the senior executive on the call diplomatically concurred.
Was I just being naive? I'd already managed this team in the past. At this point, I was running a program that included it, just shipping something new. I couldn't figure out what's wrong.
Throughout the day, people would reach out to me if they needed something during the day. And it felt increasingly like a hub and spoke system. Not like the well-optimized flat hierarchy I was hoping for. With me as the hub of anything happening. And the bottleneck-in-chief.
Instead, everyone was being held accountable individually for their contribution. By team leads. Which I had agreed on, in order to lower my own overwhelm when dealing with so many people. But now I was having second thoughts.
What happened?
Later that day, I started thinking about metrics again. The team felt like it was going a lot slower than it used to. Strictly speaking, velocity was low. Much of the current work was just bug fixing. We didn't initially have enough of an infrastructure to ship new features with integration tests; even though now this infrastructure existed, a big gap existed between where manual testing happened and where automation was.
On a lark, I checked the cycle time. And it turned out we were up to a median of approximately 9 days per item, across the whole program. Including the team who had previously achieved 36 hours of median cycle time. Something was off--systemically.
What was different?
I realized that factor I overlooked here is the team dynamic. And we previously had a team dynamic that arose, when we were introducing habits to reduce cycle time. In particular, to minimize the handoff times between functions. Like make sure that code is reviewed quickly. Or that we don't take on too many issues into the sprint, parking the majority in "awaiting" states.
In effect, cycle time is correlated enough with how well a team interacts, that it can serve as a measure of the team dynamic. The quality of the interactions. Because there is just one goal for everyone, regardless of specialty and seniority, it becomes easier to work as a team. And handoff work among people effectively.
While in large organizations, cycle time highlight how work floats between silos, it seems to work at a team level also.
Key takeaways
In addition to measuring the raw time of taking a task from start to finish, cycle helps measure how well a team is functioning, if there are no major organizational constraints.
As it is accurate in "real-time", cycle time can be used to experiment and improve delivery team dynamics.
Just to pick up where I left off last week, my daughter and I managed to get back home. And currently we are under quarantine for 2 weeks. Fortunately, without symptoms so far. We're very lucky that so far nothing particularly bad has happened. And slowly the disease is starting to hit people we know or our friends' parents.
Today I wanted to ask about your shift to working remotely, especially if you haven't done much of that so far. I've run remote teams for a few years, so I'm hoping I may be able to help with any questions or concerns you might have.
On my end, I think the biggest new challenge is the childcare one--working in parallel with becoming a full time homeschooler. That means re=prioritizing. On the fly. Overall spending more time with kids is a good thing, but somewhat painful in the short term. For example, it's difficult to pretend business as usual, when a 5 year old pretending she's a mermaid in the background, flapping her plastic tail on the ground.
Just reply to this message with your question/questions or leave a question in the comments on the blog.
As I've been working remotely for a few years, I felt I hadn't been taking much advantage of it. So when my mom invited me to Cancun with my daughter who's in preschool, I figured "why not?" As long as my team had everything they needed and were clear on priorities, I could go. Moreover, I could just work from abroad. The only real difference was my time-zone availability. Beyond that, nothing changed for them.
For me, it just meant getting up for 6 am meetings. But being much closer to the equator helped rationalize this. Particularly since I already had a team member in Columbia, even closer to the equator with 6 am sunrise, 6 pm sunset.
While there were a few news reports about Corona virus in Wuhan province in China, there didn't seem to be much to be concerned about. My wife bought a box of face masks for our flight just in case. My daughter was excited about the face masks, at least initially. Kind of like Halloween.
You can probably guess where this is going.
At the airport, when we were walking around with our face masks, people gave us somewhat awkward looks. Although we weren't the only ones, we were one of a handful of people with masks. Both in Warsaw and later in Zurich.
When we got to Cancun, the world went #CovidCrazy. Suddenly, borders started closing, starting with the Polish one (for everyone except citizens) but we still had to get there in order to cross the border. We almost boarded our return flight but decided not to, as there would be two changeovers and a bus ride across the German-Polish border, with hours of backlog. Not ideal for travelling with a lot of luggage and a preschooler.
Then to get back to Poland, all of the connecting flights became impractical, because those countries shut down their borders. Even though we'd only be changing flights, we'd have to cross the border at the airport to pick up and drop off our luggage while changing airlines.
Finally, it looks like the Polish government looks like it may organize direct flights via the national carrier back to Warsaw. But still waiting on confirmation for this. Without it, we'll be in Mexico until the international lock down resolves itself. Or more accurately, in self-quarantine so that we can travel at a moment's notice.
We live in volatile times. It's funny how I recently penned a few posts about proactivity, while remaining flexible and not locking into a rigid plan, as the optimal strategy. Clearly this is a mindset which helps now.
Like a number of friends with split up families with dependents around the globe, both kids and seniors, the realities of the advice that comes out of mathematical models are a bit more complicated than it would have been for me as a single or even childless young couple. Kids can spread the disease but not have much symptoms. Grandparents face the risk of death due to lack of absolute numbers of ventilators. All that said, I am happy that I am quarantined among family and able to take care of them and myself. I'm hopeful that this situation will play itself out eventually.
There must eventually be some kind of way to restart flights using some type of nearly automated pre-certification of health/lack of Covid-19. The Chinese have some kind of device that measure body temperature from a few meters away. We just need to start thinking through what we can change in order to continue containing the virus, while giving people some ability to remain mobile.
Also, there have been a number of efforts among makers to come up with technical solutions to the expected shortfall of ventilator masks, like that of my friend Sal: http://diyventilators.com/. If you are interesting in helping out, join the chat at that site and say hi.
Most people are familiar with the 4x4 matrix of urgency and importance that Steven Covey popularized. (Or actually misappropriated from President Eisenhower).
source: Wikipedia
Although it's true that the majority of high growth stories do include a lot of flexibility, agility, and adaptiveness, that doesn't mean that planning is worthless. Eisenhower quipped that “Plans are worthless, but planning is everything."What's most valuable in planning is being proactive--to prevent preventable crises. And if you really are going quickly, it feels like a car chase already.
How prioritizing during a rapid growth phase feels
Like cash flow crunches. The loss of an important resource. A consistent source of sales.
For example, to help prevent cash flow crises around bills for software and tools that I use in my own business, I realized I can buy annual or lifetime plans. Moreover, I can keep a cash reserve for multiple years' worth of using the tools. This way, I guarantee I'll have the option of being in this business for a much longer time horizon.
It helps shift my own focus from an early stage mentality of "low monthly run rate" which made sense as I validated different business models--to one of an efficiently run business. It also means that I eliminate the occasional surprises around not having enough cash to cover this or that bill.
Note: this is an internal change in my business only. It gives me a good amount of flexibility. All it takes is setting up a business savings account and transferring over financial buffer, so that I can sleep easy at night. In short, I am eliminating a whole category of problem in my own business with this one small tweak.
In his classic 7 Habits of Highly Effective People, Steven Covey shared a quantitative benchmark around for highly effective individuals and organizations (based on his research and work with them):
Source: Steven Covey
As a matter of habit and culture, notice that proactive businesses spend the overwhelming majority of time in Quandrant II. The important and not urgent. Such as coming up with contingency plans and being proactive, without necessarily tying yourself down and committing unnecessarily before you know what you need to.
In the example above, I still have the option to raid the financial buffer. But then I am deliberately changing my decision.
Interestingly, for people who aren't effective the numbers more or less reverse on average. Most of their time is spent doing things of low importance: quadrants III and IV. This crowds out the time needed to do quadrant 2 work, namely important but not urgent work.
Inadvertently, I fell into that trap myself.
While running an agile and adaptive process--without any real external or existential threats--it was easy to just ignore the need to be proactive. If we were honest with ourselves, most of what we did was neither important nor urgent. And it showed on the bottom line unfortunately, i.e. a team spending 2 and a half years to redevelop a product that ultimately didn't sell much anyway. Most people have some kind of a similar story.
In practice, we only really planned one sprint at a time. And that was good enough for us. Over time, I habituated my stakeholders at the time to this pattern. And allowed myself to fall into it, too. Which wasn't healthy. This was the type of product that can't just be rolled out via the internet or directly. I had good reasons to be suspicious of committing to anything beyond one sprint. If we did commit to anything, the team would need to replan everything a sprint later.
In a way, lack of longer term planning paradoxically helped in this context. Most of the volatility around the work was in the latest news on their side. Even though we knew we needed a longer block of time to get to a truly releasable unit of work, at the end of every sprint I'd hear about a new business priority--before we actually released anything.
When confronted with the need for a plan, I mutinied.
I was pretty vocal about being adaptive, later when asked to provide detailed plans, I locked up. I had forgotten what that meant. I wanted the team to be self organizing, and to be left to our own devices. But, something bothered me.
Begrudgingly, I started to assemble bits and pieces and looked through other examples in the company of "good plans" submitted by other managers. And I realized that thinking through things in more detail was helpful, especially once new products or offerings are largely validated. I'd place small details in a larger context, so that the medium term plan was internally consistent, while still leaving myself the ability to back out easily.
But planning itself is good.
For all the trash-talking about "big planning up front", I think it's worth pointing out that in an agile and scrum context, I've never heard anyone claim that planning itself is bad.
In the agile manifesto, the signatories stress they value people over process. But planning is ideally done in a way that takes into account everyone's needs and opinions. Ultimately agile values the team's need to self organize. And that includes planning, if that's what the team needs. Or what a number of teams need to ship their work.
The main reason I've found planning helpful is to realign details around priorities. If you have a large enough team, there is a car chase of details coming at you in any given moment. Being clear on the priorities and knowing how to apply them is where a purely adaptive process breaks down.
I was afraid making plans would be constraining. And only after a while, I realized that it's the proactiveness in planning that was most valuable. Not the plan itself. The plan itself is just evidence of having been proactive.
It is dangerous to use a plan as an organizational commitment device, as that shut down the ability to respond appropriately as new learnings came up. But other than that, there is a time and place for a thought through plan for a team in "execution mode" as they're going to market.
Key Takeaways
Even though high growth requires you to be highly flexible, planning is still a high value activity.
Ideally, you want to aim for spending 65-80% of your time and resources on high importance and low urgency tasks, even as you validate new business ideas.
As a team matures, there will be a longer time horizon of planning ahead, especially if it isn't possible to actually release at the end of every sprint.
Quite often, an ambition to innovate is paired with an unwillingness to change.
Usually, the latter isn't conscious. But it blocks you from finishing or shipping anything.
It can be quite subtle. In how people speak or collaborate. In pushing back. In sub-par levels of trust.
It might seem obvious at the face of it. Yet, it's probably a common issue companies face when trying to become more innovative.
So before trying to convince anyone about a new product, you might be better off trying to introduce a smaller change of some sort, and seeing where the pushback comes from. And where the fault-lines actually lie. Even though it will create a conflict of sorts, it will highlight what you are up against.
Key takeaways
An ambition to innovate is often paired with an unwillingness to change.
Introduce a small change to test how a culture will deal with a bigger innovation.
One of the common anti-patterns which comes from a more traditional project management toolbox is estimating work time. This estimate is later used as a tool to hold employees accountable. To help managers steer the ship, while making sure that utilization stays high. In particular, the measuring stick for good management is that employees are efficient. Over time, employees take less and less time to do a particular type of task.
Call me crazy, but this feels short-sighted to me.
If you are looking improving output and velocity of work (as opposed to employee efficiency) it goes up significantly when you have a solid team dynamic. Where people reach out and help one another, especially if they have different skill sets required to ship a particular feature. This a classic case of conventional management wisdom not tying true causes and effects together.
Ultimately what you care about is finished work. And finished work comes about quickly when a good team dynamic exists, not when individuals are efficient. To be blunt, this comes down to peer pressure dynamics among team members. For a team to work, they need to know what to expect of each other.
This is most obvious in team ball sports.
Any given player needs to pay attention to what everyone else on the court is doing, in order to figure out where to go next. Yes there is a coach on the sidelines, and a captain on the court, but the responsibility rests with the individual.
As the game is playing, could you imagine the coach getting off the bench and running after every player with a stopwatch? Telling them--one after another--to run faster? Anyone who the coach wouldn't be yelling at would slow down most likely. Because he's not getting grief from the coach, so why should he care? This might be more acceptable during practices, but even then, it takes away agency from the employee. And emotional skin in the game.
If you start measuring and tracking individual employee output:
You send a pretty clear message that the team doesn't matter as much as what each employee does
Success and failure rest at the individual level, how much they do relative to what their manager expects of them.
The responsibility for finishing work lays on the manager's/coach's shoulders, and more importantly, doesn't lay on the employee's.
Maybe that's acceptable, and you want the extra control, but usually this will reduce your output. Because the motivation lies solely in the relationship between the employee and the manager. A hub-and-spoke dynamic among a group of people. Not a real team.
Speaking for myself, adding elements of control doesn't feel like it addresses the real issue of people not being self-motivated to work as a real team. It was kind of like buying additional dumbbells or books when wanting to shed a few kilos, like Keith Cunningham points out. It's helpful to have a one new pair, but buying 100x more dumbbells on its own won't burn the fat that much faster.
The root of the problem lies elsewhere: a misaligned team dynamic leading to a lack of individual motivation in the form of manager reprisal.
In contrast, if a player consistently gets the ball and fumbles with it or misses shots on goal, the team won't trust him. That's much more powerful motivator. They understand the consequences (to others) of dropping the ball on any given task.
Conversely, if there are a few good players who trust they can pass the ball to one another and to move their play forward, then things start to happen. Having a team dynamic where everyone chips in matters. Where people know who they can turn to if needed. So they're implicitly clear on priorities, as they enforce them from one another.
Or if you do have a star player, at least the team self-organizes around helping that star contribute significantly on the playing field.
How does overemphasizing work time play out quantitatively?
In scenarios requiring serial processing of work to ship something, like for example a software feature, you naturally start to observe bottlenecks. In particular, a lot of partially finished but unreleased work lies in the "wait states". The amount of time a given piece of work lies in between BA, development, and QA usually exceeds the amount of actual work time spent on it.
Here's a case study. Same time, same year, same product, same technology stack:
aggregate work time vs. aggregate elapsed time for all stories
This was a team that I ran when developing a new product. And what I'm showing here is pretty common. Few delivery people can overcome their "cringe factor". To figure out how much flab there is in a delivery process. In this case above, the aggregate elapsed time was over 3x longer than the work time.
Let's say we achieve a nearly impossible feat: halve the amount of developer work time without reducing the rate at which features were completed. All that would mean is that the purple bar in the stack above would be smaller. But the overall elapsed time wouldn't budge. The story would just wait longer for QA to be able to look at it.
Or halve the QA time required without reducing quality and rate of bug discovery. That would reduce the size of the gold bar. Which is admittedly a win at the story level. Because the elapsed time to the end of QA would go down.
But then you have the next step out: release elapsed time.
How much time elapses in between when all of the stories are QAed and the release goes out the door? If you don't have a continuous delivery pipeline, it could be weeks. So it doesn't matter if QA or dev go 20% faster, because the product won't end up in the client's hands until the product is released.
In practice all features are released together anyway. So even this pinkish elapsed time stack would need to be much taller when you count the time to release.
Key Takeaways
Increasing control doesn't help a team be more efficient, if the team members aren't motivated to collaborate.
Peer pressure similar to that in ball sports is a good model for how successful teams work together.
Strong-arming team members into finishing their work faster usually won't impact the "elapsed time" before the features/product goes out to market.
Came across a wonderful article on medium.com by Jack Skeels. The starting point is Jack bemoaning that HBR is now singing the praises of Agile at Scale (re-dubbed "Agile as Anything Management Wants"). According to him, the actual results of agile are significantly below what is promised. Most companies applying agile focus on process, because that's how they think they'll get efficiency gains. But they miss key subtle points underlying the whole thing. Like moving away from digital taylorism. And towards team self-management.
Management can easily kill agile if they don't understand how it really works
Tons of insight like the following:
In fact, probably the key metric you should use to judge your Agile implementation is how differently you manage and how many fewer managers you need.
During the last couple of years, I’ve used a “Team Ratio” calculator with dozens of companies…how many managers and leads versus team members? This is an aggregate “span of control” measure that reveals how flat your organization is. If you do the calculation, a ratio of greater that 1:8 means you’re flat, and likely have a really good culture, velocity and quality.
Having a good culture, velocity, and quality...where do I sign?
Again, this post doesn't really do the original post justice. It's one I've already gone back to a few times.
