Developer Tea

Measuring Freedom to Change

Episode Summary

Why is it so hard for managers to create freedom and autonomy for their teams in a modern work environment? Today, we'll talk about how we can offer more autonomy to our team as well as bring value to the company.

Episode Notes

The freedom we want to create as managers is the freedom to disagree and solve problems towards a goal. In today's episode we're talking about freedom and autonomy among a team and offering different ways managers can provide as much freedom and autonomy as possible to their team.

๐Ÿงก Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

๐Ÿต Subscribe to the Tea Break Challenge

This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at

๐Ÿ™ Today's Episode is Brought To you by: Oxylabs

Scraping data is tough, but there's one company dedicated to making that better. Oxylabs is a web data gathering service provider that is now introducing a significantly improved data gathering solution -- Next-Generation Residential Proxies.

Visit to find out more about the services and apply for a free trial of Next-Generation Residential Proxies.

Episode Transcription

One of the most important things that managers can create for their teams is the sense of autonomy and freedom. But what exactly does it mean to have autonomy and freedom? Of course, we have to have some shared goals. We have to deliver value to the business. So how can we consolidate this idea of freedom and autonomy with having shared common goals and the imperative of delivering value to the organization? Today we're going to talk about a barometer for measuring freedom and autonomy on your teams. And we're also going to discuss why it's so hard to create freedom and autonomy on a team. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective and purpose in their careers. This idea of freedom and autonomy is something that you'll read in basically every management book since 2000 almost. And this reflects the change in the market from a control-based management system which worked well for an industrial-age kind of factory setting to a knowledge-based system. And this is what we work in as developers, or at least this is what we strive to work in as developers. And in this scenario, it makes sense that you would want to have freedom for the people who are those knowledge-based workers. And as it turns out, the barometer for measuring that level of freedom on a given team is the same reason you want the freedom to begin with. The barometer is measuring the freedom to change. If we zoom in on an organization and then all the way down to a team level and even down to an individual level, the imperative to have freedom on a team isn't based on an idealistic notion that you can just do whatever you want to. Magically value appears. On the flip side, value is not only generated by working on tightly controlled, narrowly defined tasks. The freedom that we want to create on software teams is the freedom to do what we believe will solve the problem. The freedom to disagree. The freedom to exercise our opinions towards an end goal. What most organizations get wrong about freedom is that people want freedom from their work. That somehow work is binding them. And in order to have a good culture, you must be able to get free away from that work on a regular basis. This is where we get the idea of flexible vacation policies as a culture building tool. And while this isn't necessarily wrong that sometimes we do need time away from work, what is more engaging and perhaps more important for a company culture is freedom in the work. And the barometer here is freedom to change. If you see a lack of change on a team, there are likely both explicit and implicit reasons for this. We're going to talk about those right after we talk about today's sponsor. Today's episode is sponsored by Oxy Labs. Oxy Labs wants you to know about their stable and fast proxy pool of over 30 million global IP addresses. These are the next generation residential proxies, their resource efficient, and they empower block free scraping. Oxy Labs has expertise on the subject. They have deep understanding and knowledge on how to acquire web data. And you're going to have a dedicated account manager for every person, every client who works with Oxy Labs. Oxy Labs is already trusted by over 500 companies for sales intelligence, market research, SEO monitoring, and more. Head over to slash Developer Teato find out more about the services and apply for a free trial of those next generation residential proxies. Thanks again to Oxy Labs for sponsoring today's episode of Developer Tea. If you are working on a team that resists change, there's likely more than one reason for this. There's two kind of categories of reasons for why you might not have change on your team. One is the unintentional implicit reasons. The second would be the explicit or intentional reasons for reducing change. The implicit or unintentional reasons are based on our natural way of operating. We want to maintain consistent. And this goes back to our social hierarchies. This is why politicians very rarely will admit to changing their minds because even though changing your mind is probably the rational thing to do when you learn new information, if you break with a former decision, then the underlying signal, the instinctive signals that we get that we've evolved to have over millions of years, is to distrust someone who is not consistent. The danger of the inconsistency to our prehistoric ancestors outweigh the importance of adaptability. If we think about this for a moment, it's very likely that the best kind of balance is somewhere in between. We don't want someone who is constantly changing their mind. They can't settle and make a decision to move forward. They can't find some operational ground to stand on. But we also don't want to operate at the other side of the spectrum, where we hold on to views because it was the first one that we had. A related topic to this is the idea of fundamental attribution error. The idea that we can excuse our own mistakes, we can excuse our own changes of mind based on our contacts or experiences, but for others, when they make mistakes, we're more likely to attribute it to their personality or their underlying core values. And so for all of these reasons, we have some implicit pressure to maintain a consistency of position, to maintain a consistency, really in almost everything. If we say one thing is important, we're very likely to hold that that thing is important, even when we face evidence that that thing isn't very important. This is one of the reasons why it's incredibly important for leadership, for people who are in some kind of position of leadership or seniority, to be the ones to break the ice, to be the ones who facilitate and encourage change. Not only encouraging it for others, but also showing that they themselves change their minds. And this intentionality brings me to the second type of reason why we don't see change on teams and why that freedom to change is very often missing. That is explicit systems that are built to reduce variability. Once again, these systems are incredibly impactful in factory work. Having a checklist to follow, for example, when you are piloting an airplane can be very important to reduce variability so that something isn't lost. This is based on the assumption that the variability, the human error, may have an outsized negative effect on whatever you're trying to accomplish. This is certainly true when you're taking off in an airplane you want to know that everything that is critical to be checked has been checked. Reducing variability in this way is incredibly important and freedom and autonomy become very unimportant. However, in the same setting, in a cockpit, you want to also have the freedom to change your mind about a decision that you've already made. For example, a flight plan. When you're on that path and maybe the weather is getting worse than you expected, it is necessary for crew members and for the captain to have facilitations for change. So in this one picture, you can see systems that are intended to reduce variability, but also systems that are intended to empower variability. You can dig more into this topic by googling the term crew resource management. And once again, it's very easy to imagine as a manager that I can increase efficiency if I reduce variability, if I streamline all of our efforts into one direction. These systems exist throughout most workplaces, finding ways of operationalizing everybody's work day, their habits, the way they write their code. These systems can be very helpful, but it's important as a manager to be mindful of times where reducing variability is helpful and gives you the margin necessary to empower variability where it's needed. Specifically, when it comes to decision making about the work. Thank you so much for listening to today's episode of Developer Tea. A Huge Thank You to slash Developer Teato get started today. If you enjoyed today's episode, if you found something valuable, then I encourage you to subscribe and whatever podcasting app you use. It's free and if this has any positive effect on your life, then it's worth that free button click, I think. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.