Category: Management

Posted on

What Makes an Effective Leader?

With a little work and the right processes, I believe anyone can manage others. But what does it take to not be just a manager, but a leader? How can you inspire others to do more and be more?

Lead by Example

I know, that sounds so trite; and how do you lead by example when your role is not the same as those you are leading? This has nothing to do with writing good code, or trying to keep a Sprint on task. It has to do with passion and inspiration.

What’s the end goal of any company? Profit. How do you make that profit? Keep your customers happy, make them feel like the company cares, make them want to not just stay, but tell others and get them to become customers too. It know it sounds a little abstract, and it is. But bear with me…

There’s a reason companies, and even organizations within the company, have mission and vision statements. They may even sound a little cheesy or obtuse, but they’re there for guiding customer experience and success, and that’s where the leading by example come in to play. A good leading is passionate about these and that passion shows in meetings, in presentations, and in how problems are solved and decisions are made. That passion helps others see how their actions can (and should to some extent) drive towards a common goal.

Sometimes it’s obvious, like fixing a major pain point in the existing system for the customer, or delivering a new solution that’s been asked for by numerous customers. Other times it’s not quite as obvious, such as improving stability. Let’s face it, most customers aren’t going to notice going from a 99.8% uptime to a 99.9% uptime, or that their larger reports now run 30 seconds faster, but that’s not the point. The point is, you improved it, and a leader’s passion is paramount to this success.

Inclusion

I would hope that it goes without saying that your team needs to feel as though they have a say in matters. They need to feel connected and in control of the actions and processes that lead to the accomplishment of the team’s goals or the final decision in an upcoming project or process change.

Soliciting feedback is great, but it’s not the only way to ensure that the team feels included. They need to feel safe to be able to come to you issues, both professional and personal. You team needs to know that they can talk to you on the side about anything that is bothering them and know that you’ll support them however you can and that it will remain confidential if the topic needs to remain between the two of you.

Helping improve the inclusion of your team is done through…

Listening

You can’t just talk to your team and expect them to go along with you, no matter how passionate you are. You need to listen. Not just hear them, but listen.

Some of the best ideas I’ve helped to implement over the years have been because I listened to what my team had to say. Sometimes it was listening to good ideas, which then lead to discussions over how to implement them. Other times it was listening to feedback about me, and how I was not as effective as I could be for them. Regardless of the topic, improvements would not have been made if them team didn’t feel as though they would be heard.

Listening to your team also helps you to understand what it is that motivates them. You can’t always give raises and promotions no matter how much you may want to. What you can do though is listen to know who on the team wants praise for their work, who needs public recognition (and who doesn’t want it at all), and who just needs a simple thank you from time to time in order to remain motivated.

Care

It sounds a little silly writing it down, but it doesn’t matter how much you listen if you don’t care about your team, their success, or their well being. If you’re not sincere in what you say and do with your team, they’ll know. There’s nothing that kills a person’s morale and productivity than a leader that is perceived to not care.

As easy as it sounds to just listen and care and be passionate in what you do so that you can lead by example, it’s not. It takes time. It takes practice.

Posted on

Patience. It Matters.

In this fast food, same day shipping, not even one hour photo processing anymore world we live in, change is expected to be visible immediately. However, just because you have put process changes in to effect, or wrote a few new tests for your code, doesn’t mean you’re going to see immediate results. Be patient with getting the results. That goes for both you not losing faith in your own work and for your superiors to understand (manage up!)

I’ll admit, I’m a bit of a speed demon. My leaden right foot has certainly gotten me into trouble a few times. But there’s one time where I’ve learned that patience is definitely worth it: heavy traffic. Over all the years of my commuting I’ve done a little experimenting. One week I’ll (safely) drive aggressively, lane change to the lane that’s moving just a little faster, hard stop and start, well… you know the drill. You’ve probably either done it yourself, or have seen others do it day after day on your own commutes. Other weeks I’d just pick a lane and relax; just go with the flow and not be impatient. Believe it or not, over a 30 mile commute, the difference in times was only about 5 minutes, but the difference in stress levels and blood pressure was significant. Thanks to a little patience on the road, I was more relaxed and productive in the office, and much happier once I was back home.

But enough of the psychology of having some patience on your commute… How does it relate to being an engineer or a manager?

A little while back I was talking shop with some old colleagues of mine. We commiserated over how bad some of the coding practices were at that old job. One thing we never were given time to do properly was write tests, and that bothered all of us to one degree or another. Since that job, he’s started his own development company, and has vowed that everything they produced would be done with proper TDD (Test Driven Development) and he always shoots for at least 80-90% test coverage. He said that in the end it paid off, as the tests did catch an introduced bug before they launched the new release of one project. Here’s the kicker: it took almost 18 months for the tests to actually fail. On the one hand, that’s awesome that his team was able to go bug free for that long. However, it also highlights where patience matters. They worked hard to follow their processes, which admittedly slowed them down from time to time, but were eventually rewarded by seeing their test work catch an issue before it affected a customer. Comparing that to the job we had both shared before where the tests didn’t catch anything in a month, so management insisted that we stop wasting time writing tests. That project ran for over three years, and never launched; partially because of the number of bugs which kept being introduced but never caught until after the fact.

Similarly, I recently held a position where I was asked to introduce new processes with the engineering team to try and speed up their delivery as well as reduce bugs and better schedule feature delivery. Before I arrived the best delivery times were often “sometime in next quarter.” It’s just a little hard to sell something to a customer on a promise of sometime in the next three months… I put processes in place, opened up communication, tracked down answers and issues (like a Scrum Master on his third pot of coffee). The problem is, old habits die hard, and change didn’t happen overnight the way my boss wanted it to. I explained that it takes time and showed data to back up the small progress which was made. I corrected course based off of the data, and off input from the engineering team. None of that mattered though, because I wasn’t performing the miracle of overnight perfection that my boss had in his mind. I wish him success, but I also wish him a smidgen of patience and a willingness to let things properly run their course to be able to judge success. Some changes really are a long game, and need the patience and strength to stay fully committed to them.

As an engineer, you’re selling yourself short if you’re not urging patience on your management. There’s nothing wrong with pushing back with a better solution that may take longer to implement. The challenge is how to explain it. You have to be able to explain that it may take an extra day, but the solution will provide even more value to the customer, stability to the system, preparation for the next feature, etc… to justify the time. Explain the reason for why you’re asking for patience. With a solid reason which ultimately positively impacts business, you run a better chance of getting the time and patience than just a “because I need the time to do it right” type answer. With each success after the request for patience, you’ll find management more receptive to the next time you ask for it. If you’re lucky enough, you’ll find that management even starts asking or offering the time for a better solution. Of course, you’ll just have to be patient for that to happen…

It’s also critical to be self-aware when solving a problem. Don’t just rush through to be able to grab the next task. Have a little self-patience and ensure that the code is done right. Double check your work. Make sure you’ve covered the odd edge cases you thought of while working on it. That patience in your own work will result in less mistakes in the long run, and even deeper tests which will cover more detail.  Of course, then you’ve got to be patient once more for those tests to catch something. But you already knew that, right?

In the meantime, I’m off to exercise that lead foot of mine. Patience is great, but sometimes you still want to go fast…

Posted on

Questioning the Boss: Challenge to Authority or Collaboration Opportunity?

I recently was declined for a job interview. Not because I wasn’t qualified, but because one of the managers turned out to be a manager that I had worked with in the past, and they felt that I would not be a good fit for their team. They didn’t think I’d be a team player.

You see, back when we worked together, I questioned him.

A lot.

I questioned everything from task prioritization (shouldn’t the ability to login and have user roles be ahead of 90% of the heavy work we need to do which is role based and not three months down the road?), to team selection (why are we putting PHP developers on a Ruby on Rails project when we have enough Ruby developers to spare?), to just about anything else you can think of. Yes, I challenged some of it because I really did think they were poor choices, and I didn’t want to be held accountable to an impossible delivery schedule. However, the majority of it I challenged and questioned because I wanted to learn more, and at the same time I wanted to share my knowledge and experience with him.

The manager saw my questions as challenges to their authority; a lack of respect. Where I thought I was being a collaborative team player, I was being seen as a trouble maker. A subversive employee whose goal was to make the manager look bad, and promote their own self-interest. I tried changing tactics to ask questions in email and in private meetings as opposed to in large meetings in front of their peers and subordinates. Unfortunately, by that time, I was still deemed a threat.

My wife was recently in a situation where a new manager came into her company.  My wife has been there for nearly 20 years, and rather than take the questions she was asking as guidance, the manager took it as a challenge.

A good manager knows that not only should they surround themselves with people smarter than they are, but they need to utilize them. My wife’s situation is a perfect example of that… someone who is new to a company should want to leverage the knowledge of someone who has been there for a long time. You cannot become a truly effective manager without fully leveraging your team and their abilities. Some of these “smart” people will have very specialized knowledge. Others will have a broad knowledge base to draw from, or they always look at the problem from a different angle. A good manager fills out their team with people which will fit the gaps in their own knowledge and experience, as well as people with different viewpoints and problem solving skills. The total of their knowledge and experience will greatly exceed the sum of their parts with a wise manager leading the way.

If an employee comes to their manager with a question, particularly one regarding the current project, processes, or even staffing, the manager should listen and respond accordingly. Sure, sometimes it will just be an off the wall question, or just someone having a grouchy day. More often than not though, the question is an opportunity, not a threat. It could be an opportunity for the manager to help mentor the employee (help them see the bigger picture, not your view of how things “should be.”). It may be an opportunity for the manager to learn something new (especially with new technologies and tools which could speed up development or delivery time).

The CTO for the company where this manager and I worked had a habit of sitting back in meetings and listening, and then just asking one question.  Granted, it was one question that sparked a series of other questions by the team.  He didn’t point out the holes, or the flaws in the plan, or come across as challenging the process – instead he simply would ask “Why? How? When?” I admired his ability to spark discussion and his openness to listen to questions from the team.  He encouraged questions, and I asked him a lot of questions.  He would constantly tell me, “You’re not asking the right question.”

Returning to my prior blog post about Who Owns the Scene, I want to elaborate on why asking questions should be taken as a compliment, and not a challenge by a manager. When people ask another individual questions, it’s generally because they want to gain something from them – besides the answer. It could be, as I’ve pointed out already, to learn something new, or to understand a process – both physical and mental. Through asking my brother-in-law questions about who owns the scene at an accident, I learned more about the processes and regulations that are behind law enforcement. He not only got to “show off” his knowledge, but he gained a bit about IT processes in the conversation. Amusingly, both of us sat down with my father-in-law to ask questions of him due to his expertise. My brother-in-law needed to understand some accounting rules as he was reconciling the books for the fire department, and I needed to understand some tax law implications as I was working on a project to try and compute tax depreciation differently. Through the conversation, I learned what I needed and more, as did everyone else sitting around with dessert and coffee. While my mother-in-law was a little bored, she made comments, which made us think differently.

If it’s the right question (you’ll know it when you hear it every time), then it gets both the manager and the employee (or the team, or in the prior example, my family) collaborating together. This results in a better understanding of the issue from all sides, and a solution which now has full buy in from all parties. If that collaboration isn’t a win for the company, then I don’t know what is a win.

I guess being shot down for an interview by a former coworker in a new company (at least this ex-colleague in particular) isn’t such a bad thing after all. Once I found out that I would have been working with him I probably would have thought long and hard about whether or not I should accept the position. The question would be, can I work with someone who is not open to questions? Can I accept that by asking questions I could be seen as difficult? Again, my intent is not to make my manager look bad, whether it’s a line manager, the CTO, or even the CEO when I reported to one. The intent has been, and always will be, to learn and ensure the project is successful.

What do you think? What is the right question to ask to make a project, manager, or employee successful?