Leadership
Everyone has their own variation of what leadership means. For me, leadership means empowering others to accomplish their goals and providing assistance when they need it. There were a few articles that came up on LinkedIn this week that I wanted to share with everyone and discuss how they fit into my perspective on leadership.
Articles
- Does Your Team Work With You Or For You?: Kwame Manu-Antwi opens up the article in an interesting fashion. When I read the title of the article, I figured this was going to be the typical leadership vs management debate. However, Kwame goes into describing a scenario where he had a humbling experience from one of his team that made some sacrifices for him. This was truly an example of working for him.
The entire second half of the article shares a bunch of leadership traits that I think are really beneficial. For example, being transparent and encouraging growth in your team members. I think the point that is being made in this article, although I don't personally feel like it was made as obvious as it could have been, is that as a leader, if you want to feel like your team is willing to make sacrifices (for you, or for the team) then practicing being an excellent leader is the way to get there. Thus, the tips he provides to do so!I'd say there's a lot of takeaway in his bulleted leadership points.
If you're an experienced leader then it's probably mostly stuff you've heard before. However, it never hurts to be reminded of great leadership responsibilities!
- How Do I Hire A Good Employee: Insights on Leadership Traits: In this article Kendall Matthews talks about the specific things he looks for when interviewing. It's not about how picking the smartest person in the world or the most skilled person according to Kendall. It's all about finding people that have that curious drive that can think on their feet. Have you given into the status quo?
When it comes to leadership and hiring, your responsible for building out a well rounded team. In my opinion sometimes this will require hiring the smartest or most skilled person, but more often than not, you're just looking for go getters. People that are curious by nature and always looking to push the boundaries make great candidates for your team because they're adaptable. This means you don't need to go finding someone with the perfect skill set because you can hire the person that's willing to evolve into that person.
Again, it's not a blanket rule in my perspective. Sometimes your team will require that super-skilled person to be up and running from day one. Being a good leader in charge of hiring requires you to understand your teams needs though.
- Can Skipping a Meeting Make You a Better Leader?: I find that Ilya Pozin always has some interesting articles up on LinkedIn. If you don't follow him yet, I suggest you do! This article is all about shaking things up to align them to your leadership strategy (and not just accepting meeting invites and then not showing up).The first part of the article is really about taking charge of your daily routine. If you get into work and your ready to make a big dent in your todo list, then moving meetings until later in the day might have a huge benefit. Similarly, it helps you plan out and prioritize the rest of your day. For me, I plan the night before and since I'm still largely a developer, I find that if I have meetings in the middle of the day when I'm in my groove then that's when I have the biggest problems. Try tweaking when your meetings are to suit your leadership style.
The second part of this article talks about the idea of a devil's advocate and is personally my favourite part. I can't stress enough how important healthy debate is for continuously improving. I had a colleague the other day say that he doesn't like how often he hears "because it's always been that way". I jokingly responded, "because we've always said that"! But the point is, he's not sticking to the status quo and doesn't want to settle. I had another colleague argue against my perspective even more recently, and it really got me thinking about how our perspectives were different and where we might need to go next. Healthy debate is awesome. Your goal is not to put your "opponent's" face in the dirt, but to understand their perspective as much as possible and ensure they get your perspective as much as possible.
- Heisenberg Developers: In his article, Mike Hadlow talks about how a new (what seems to be scrum-based approach?) was introduced to a software development team and how it negatively impacted them. Mike's argument? The process that was put in place took away autonomy from developers--they should be given free reign to implement a feature as they see fit.
While the general consensus in the comments on his blog indicates that people agree, I actually don't. I'm well aligned to the first two sentences in his closing paragraph (autonomy and fine grained management) being important, but I think direction is incredibly important. In an agile shop, often the customer proposes features to go into the product (and when the customer isn't available, product owners acting on behalf of the customer propose the features) and the developers work to get them done. Maybe this wasn't the implication of the blog post, but I don't think it makes sense to just let developers randomly choose which of the features to work on next and decide on their own how to do it.
What works better, in my opinion? Have product owners provide acceptance criteria for what would make the feature successful. Have software testers and software developers mull over the acceptance criteria and bounce ideas back off of the product owners. Did they think of how that would affect feature B? Do they realize it will be a support or regression testing nightmare unless feature C is in place? What's my point? Collaboration. The article doesn't even mention it. It's only about how process takes away from the artistic nature of programming. I feel like people should stick to hobby programming if it's art they want to express, but when it comes time to business, it's about delivering rock solid features that the customer wants.
Back to estimating and tasking out features. Why break a feature down? What's good about doing it that way? If you hit road blocks or need to pivot, it's great to have a part of a feature done and realize that in it's current state it might be classified as acceptable for a deliverable. Maybe it doesn't match the original acceptance criteria, but perhaps the pivot involves adjusting that and now it's acceptable. Task breakdown brings insight to the people working on the feature. What's involved in making it? How are you going to test it? How are you going to support it?
Autonomy is important. But I think that there needs to be some level of process in place for leadership in management to have insight as to what's taking place, and there needs to be enough autonomy for developers and testers to do their job to the best of their ability. Sometimes the time invested in collaborating is one of the best investments in your development team.
- Why The Golden Rule Sucks: Joaquin Roca has an awesome article on "The Golden Rule" and why it doesn't apply in leadership. Joaquin starts by discussing why building a diverse team is incredibly important and why you should take advantage of the tensions it can create. So why does The Golden Rule suck? Well... not everyone is like you and not everyone wants to be engaged the same way you are. Everyone is different and it's important to adapt your ways to the person you are engaging with--especially when your team is diverse. There's also a cool leadership quiz that he has posted at the top of the article!
- Did I Make a Mistake in Promoting This Person?!: This article is about something that happens in the tech world all too often. Caroline Samne talks about how skilled professionals are promoted into leadership in management positions--except they don't have any expertise in this area. I'm actually a prime example of this. I was hired on as a developer early on at Magnet Forensics, and before expanding the team, I was chosen for a leadership position without any past experience. However, like the article says, I had great mentorship through our HR manager and I was empowered to seek learning opportunities to grow in this space. The moral of the story is, just because someone is skilled at X, it doesn't mean they'll turn out to be a great (people) leader in this space. Leadership just doesn't work magically like that.
- Corporate Hackathons: Lessons Learnt: Christophe Spoerry's article is all about hackathons. It's a great way to spur some innovation in your organization if you're allowing it to happen naturally. He shares his learnings from past experiences such as having leaders with past experience in hackathons present and having teams and/or themes picked out ahead of time. Once the hackathon starts, you don't want to be wasting time with logistics... You want to be participating! Discuss what the outcome of the hackathon will be. Who's going to take ownership over what was created? How will the outcomes be shared with the other participants or the rest of the organization? Get hackin'!