About a year or two ago, I started watching a lot of YouTube farming or homestead videos.

Actually, the video that was my jumping off point was a video by a YouTuber named “Imaginative Guy”. He was showing a water bottle egg incubator he’d made and hatched several chicks from.

From there, the algorithm directed me to Morgan Gold, a farmer living in Vermont who had just started raising 40 ducklings.

Since then, I’ve been following the exploits of the farmer and his varied animals, including one livestock guardian dog, four barn cats, and a whole bunch of birds, including chickens, ducks, and geese. I’ve watched as things have grown and expanded on that tiny little farm in Vermont.

He has a very easy manner that’s interesting to watch, but the best advice I think I’ve ever received was in one of his videos.

He said that rather than go into a new plot of land and start changing things around, building new infrastructure, digging up earth, and things of that nature, he advised patience. It takes a lot of time to get to know how a piece of land works. How things like the local wildlife and the weather interacts with the land.

Changing too many things at once can have negative downstream effects. It’s a lesson I’ve taken to heart in my own life, even though I’m probably never going to be a farmer.

A lot of times, when someone new joins a software development team, their first instinct is to make sweeping reforms. Let’s use that hot trendy new workflow application. Let’s implement the latest Scrum ceremonies. So on and so forth, rinse and repeat.

And for the longest time, I went along with it.

I suppose these practices were implemented with the best of intentions. There were problems with the team that weren’t being addressed.

However, I soon realized that this was a wrongheaded approach.

It’s a bit of a cliche, but each team is unique, made up of unique individuals. They have their own personalities, habits, communication styles. The politics surrounding their discourse and way of doing things will be different from team to team.

So it’s a bit odd to try to apply the same kinds of techniques to different teams and expect similar results. Some method that worked with one team in one context might not even work with the same team in a different context.

It makes more sense to me to take your time and get to know the people and personalities involved in a team. Watch them interact (or not interact) on a daily basis. Meet with the team members individually and within many different contexts.

But so often I’ve seen teams go from mildly incompetent to much, much worse with the introduction of a new team leader with grand ideas of trying to change too many things all at once. They’ll hire consultants or implement Scrum or start using over-complicated ticketing systems.

These tools have their place, but so often they’re applied without understanding the current context. And you can’t understand that context on Day 1.

Take Morgan’s advice. Be patient and learn as much as you can before changing your environment.