A Leadership Experiment

I recently joined the Software Lead Weekly newsletter and have really enjoyed the weekly sampling of software leadership articles. I've learned a few things and have had a few good discussions with my coworkers. I highly recommend signing up for it if you're a leader in the software industry or wanting to become one.

Recently my company decided to forgo giving the title of "Technical Lead" to developers on each team preferring to let the team organize itself and people to fill the roles that need to be filled. I was a tech lead and basically still am, but I didn't mind seeing that formality go away. It didn't come with any increase in pay or official promotion and didn't really mean too much. Some teams did rely on their tech lead quite a bit sometimes to the point that they became bottlenecks which caused issues if they ever took time off. Other tech leads deferred to their team in an effort to help them grow.

A Thought...


One aspect of this change that I didn't want to see abandoned was an avenue to develop leaders within the department. I was afraid that by getting rid of tech leads we'd be getting rid of a career progression opportunity. So, I had a thought to create a channel in our company's Slack called #technical-leadership. When I fist created it, I set the purpose to "Discuss leadership in software engineering. eg. mentoring, coaching, providing technical guidance, etc." and gave an open invitation those that were "interested in that sort of thing" to join the channel. I figured this could be a place where we could talk about leadership skills and hopefully help each other become better leaders.

A Purpose...


With that channel created and those weekly newsletters from SWLW coming in, I started sharing some of the articles in that channel. At first I'd make a small comment about the article and share it. Pretty simple. Nothing crazy. But it didn't generate much of a response. I never knew if anyone read them or if they just sat there and I was the only one spending time on them. The head of the department joined the channel and started commenting on some of the articles, but it was basically a discussion between me and him. While good, that wasn't what I had wanted.

I had wanted everyone in the channel to at least read the articles (which may have been happening, but I had no way of knowing it). Beyond that, I realized I wanted this to become a community where people who are or who want to be leaders came to discuss leadership qualities or tactics or even share experiences they had to gather feedback so they can improve. I didn't want it to be a passive channel where you only consumed what was there. I wanted engagement.

So, I updated the purpose: "Helping each other develop into better leaders."

A Strategy...


And I updated my strategy. Instead of simply sharing a brief thought about an article, I'd write down questions that came to my mind as I read the article. When I shared the article, I'd also share the questions I had in an effort to generate discussions in threads in Slack. The first week I tried it was pretty successful. Taking this approach had caused more than half of the participants in the channel to share their thoughts. In one of these discussions, an important question was raised. From there, the management team added that question to the agenda for their next meeting and discussed how to address it.

That's the kind of thing I wanted to see. People sharing their thoughts. Improvements being discussed. Sometimes even actions being taken by the management team or other members of the department.

Going Forward...


Now, I don't expect that every week. I don't think every article will spark important discussions like that. I also don't expect us to take action every week. That would likely lead to chaos as we're trying to do improve in too many ways at once. It'd cause us to lose sight of what's really important to us. But I do think that the more we talk and discuss leadership topics, the better we, as a group, will get at it. We'll be better able to help our teams. We'll be better at identifying the improvements we need to make and the cool ideas that aren't practical for us.

We'll see where it goes from here, but for now I'll keep encouraging participation, sharing articles, and asking questions to generate discussion. Going forward, I hope to seem more engagement. More people feeling comfortable in sharing their thoughts. More honest discussions. I hope to see some people even sharing personal experiences and others building each other up and helping them grow.

Comments

Post a Comment

Popular posts from this blog

A Common Technical Lead Pitfall

"That item is nearly done. I just need to run it past the team lead to make sure it's good to go." Have you ever heard a phrase like that? What about something like this? "So, I had that finished and then I ran it by the team lead and he made some great suggestions to make this more reusable. Unfortunately I'll basically have to rewrite the entire thing, but it should make it easier in the future." Do you see anything wrong with either of these scenarios? What about this one? "The team lead is out of town, so that item will have to wait until she gets back so she can look it over." Situations like these come up every so often in development. There are some simple solutions to each of these. With the last one, the team lead should have designated someone to act in her stead while she was out. In the second one, the poor junior developer should have worked closer with the team lead from the start. The first one, though, isn't really an
Keep reading

Maze Generation in JavaScript

Image
This article will outline the algorithm for random maze generation with backtracking and show code examples of the steps of the process. This algorithm is obviously useful for random maze generation, but the concepts can also be applied to other areas where random input or path generation is needed. The basics of this algorithm are as follows Initialize an object to track nodes that are visited Generate the nodes in the maze. Generally you'll want to track the node's edges. You may also want to give the node an ID of some sort. If you want to cut down on recursive calls, you'll also want to track its possible edges (aka all its neighbors). You'll also want to store this as an object instead of an array as it speeds up lookup times. Choose a starting point in the maze Mark the node as visited while there are potential neighbors to visit Randomly select a possible edge to visit Add that node to the edges for the current node Add the current node as an edge on the selected
Keep reading

Leadership Experiment Update 2

This week was a bit of a slower week. A number of people that usually participate in the channel were out of town. Even still, we had some decent thoughts on these two articles: Every Day We Must Sweep and  From Engineer to Manager: keeping your technical skills . I'd like to share one observation I made: Be Vulnerable Often times as leaders we think we need to appear invincible. For some reason we think in order to lead, we can't show weaknesses. While that may be a good mindset to have towards an opposing force in war, it doesn't work well towards those you lead. If you want those you lead to follow you, you need to be vulnerable at times. You need to show them your weaknesses and how you overcame them or how you're overcoming them. This doesn't mean you need to be publicizing your weaknesses, but it could mean recognizing them when they come up naturally or sharing stories about them while mentoring and coaching those you lead. Why Be Vulnerable?
Keep reading