Improve developer tooling and develop tech leadership

For the newbie, wannabe tech leads out there, there’s a nice, compact thread on Stackexchange about what a developer can do to improve tooling and workflow in the team.

The original poster cites a few (stinky) smells in the environment: no tests, no automated build process, git commits straight to master, no style guides, no bug tracking, non-agile processes, etc., which “demotivates” him because it encourages bad practices in the team.

Here’s the interesting part — the seed of tech leadership –the poster wants to drive good change, and he’s had some success. He’s made suggestions and at one point the team actually started some tentative steps into agile (vis-a-vis some standups), but the suggestions don’t really “take.”

The accepted ✅ answer recommends moving

in moderate steps. You could start with the small changes, like using branches in your development for better integration and testing. This will eventually have its benefits, which will serve you as better evidence to support such “official” changes in the company.

It seems normal and reasonable, but I don’t like it because engineers place way too much reliance on technical benefits, assuming the technical points sell themselves. Why is that a mistaken assumption? Because technical “benefits” live solely in the eye of the beholder. They aren’t nearly as objective as we believe.

For example, I’ve met leads who strongly believe all git commits should go straight to master despite my belief and experience that branching methods like gitflow are “obviously” better. We’re both technologists, yet we see different benefits, different aesthetics.

So, may I suggest that my three step tech lead approach is super useful for in this very situation. Instead of simply seeing an approach you like and trying to sell it based on what you like, first focus on clarifying the vision — how will a formal git branching strategy align to the team’s goals for agility, stability, excellence, or whatever?

Second, walk around and work with each team member to make sure the vision connects with them individually. This might have to happen more than once.

Finally, people drift. They might initially like the vision and say they buy into it, but real life gets in the way. So, third, you’re going to have to continually monitor alignment and course correct — how well are they actually following the branching strategy? Are they seeing the benefits? Is the vision becoming real? If not, fix it.

My framework is labor intensive. It burns calories. But it works. And it’s the stuff that strong leads are made out of. Use it.

(By the way, I’m not just trolling on Stackexchange. Will suggest an answer on Stackexchange too.)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s