You are the people manager for a team, and a team member comes to you with a concern. How should you approach it? I have been in this situation multiple times, and have admittedly made some wrong turns. After some corrections and learning, here is what seems to work well for me (although YMMV). If you like lists, here is a snapshot of the path I take.
Don’t take notes
Descend into the particular
Check with others
Socialize, if the issue is common
DO NOT become an apologist for status quo
Note that this doesn’t talk about the resolution for the issue. That is very specific to the issue at hand. What I have is more of an approach to understanding the issue in a manner that is respectful of the stakeholders. With that disclaimer, let’s unpack each of those bullet points.
Yes, I realize that this is going to be pretty controversial 🙂 Let’s dive in, shall we?
In the past half decade or so, Git has sky rocketed in popularity and is becoming the defacto choice for version control. While I understand its popularity, I have found it to be a poor fit for one specific, but popular, environment: SaaS development in a medium to large size enterprise.
Let’s take a quick look at what developing software in a SaaS enterprise is like. For the most part, it involves a significant number of developers concurrently committing code to a single master branch with frequent releases to prod and no long lived branches or versions. In a services environment, it also includes coordinated deployment of multiple services that have complementary server and client API spec.
While Git has been used in such environments with varying degrees of success, I have seen teams really trying to work around Git rather than Git just work for them. I have seen Git get in the way when teams get large, when teams get siloed into their own branches, when teams starts working with junior developers, and when having to develop across multiple services. While there are mechanisms in Git workflows and tools to mitigate this, it only adds additional complexity to developing software instead of taking it away.