Why is Leadership Important?
The typical path to becoming a software architect begins with years spent in the trenches of hands-on software development. You’ve accumulated technical knowledge that is broad and deep. Along the way you’ve developed your communications skills. And I don’t just mean status reports. I mean by mentoring junior developers, by giving presentations to your peers on the knowledge you have gained in a specific tool, framework or language, and by interacting with systems and business analysts.
Now that you’ve become an architect, more people will look to you as an authority, as an expert. Now you’re starting to provide guidance on software design and the usage of tools and frameworks. You notice you have more influence. You are now responsible for the technical solution of the product your team is building. You are now in a position of leadership.
Principles of Leadership
My early leadership training was with the Canadian Forces, arguably one of the finest sources of leadership training. Over the years I’ve adapted what they taught me to working with skilled IT professionals. I’ve learned many lessons, both the easy way and the hard way. Here are the principles that have served me well:
You Are Not Alone
Your boss is there to help you. I’m going to assume your boss is less technical and more managerial, such as a manager, director, or vice-president. I’ve lost track of the number of times I’ve said to my boss “Here is the situation, here is how I’m thinking of dealing with it, what do you think?” This has helped me use the right approach that is consistent with their goals, their strategies, and their leadership style. Depending on the situation, it also helps ensure you stay within the boundaries of corporate policies.
If your boss is a more technical one, like a chief architect or enterprise architect, they can also help with high-level technical questions. They can give you guidance on the overall enterprise architecture.
Your fellow architects are there to help you too. No doubt they have encountered technical and design problems similar to the one you are facing. Bounce ideas off them. They are a rich source of guidance and experience.
Represent Your Team
If a business user, manager, whoever wants to come down on a developer for an embarrassing or serious technical failure, stop them. Acknowledge the problem and its consequences, then tell them “I will take care of this”. Then follow up with the development team to figure out what went wrong. If you already know, then give constructive feedback to that person. Your team will notice you are willing to stand up for them, and this builds their trust in you.
Share the credit, hog the blame
Software development is a team sport. The team consists of individuals who are very skilled in their particular niches. But it takes the whole to produce working software that delivers business value.
When things go well, when customers, business users or management praise you for the work delivered, make a point of saying you had help. Give credit to your team. If you can single out one or two people whose efforts were key to the success, name them publicly. In addition, make sure they’re on the email thread.
In contrast, when things go bad and your team fell short, publicly state “this one is on me”, “I’ll take care of it”, whatever is appropriate. Then follow-up in private with your team members. If someone erred when they should have known better, provide constructive feedback one-on-one. Depending on the circumstances, coach the rest of the team by framing it as “This <bad thing> is starting to happen. Let’s be careful and make sure we do X, Y and Z to detect and mitigate it”.
All this does three things. One, the developers see you can be trusted to shield them from reprimands coming from so many directions. Two, they feel good about themselves when you’re willing to give credit where it’s due. Three, they realize they need to keep producing quality work.
Teach and Explain
You’ll have many opportunities to explain new concepts to developers, to mentor them, to correct behaviour or coding output. Wherever you can, explain the reason why. Why is this important? It may be to improve the readability of the software. Or to make it more maintainable. Or to improve its performance or maintainability. It maybe a critical function point for the business customer. Remember, we’re dealing with motivated, intelligent people. If they understand the reasons why, they’ll become better developers and your team will produce a better product.
Furthermore, armed with reasons why they’re doing what they’re supposed to, they become empowered to make decisions. Going forward, they can make design decisions on their own that are consistent with you want them to do. It may not be exactly what you would have done, but they will be substantially the same.
Empowering your team members is how you multiply yourself, and multiply your efforts. Empowerment is how you can get the best out of your people. Organizations place a high value on people who can skillfully do this.
Seek Their Input
You have very talented people on your team. You will find they have ideas that you didn’t think of. They often have more in-depth knowledge of a given subject than you do. Ask for their opinion, get them to weigh in on a design decision. This makes them feel valued and important. In turn, this helps your team deliver a better product.
Set the Example
People will start looking up to you. They will emulate your coding style, your written and spoken communication skills. You need to earn their respect. Treat them as you would want to be treated.
Begin By Assuming People Did Their Best
I’ve adapted this from The Prime Directive that the agile software development community uses:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Norm Kerth, Project Retrospectives: A Handbook for Team Review
Begin by assuming people performed their work to the best of their ability. They have to prove the opposite to you. Even then, take the time to dig into root causes. Were they hamstrung by inadequate information? What constraints were they working with? What did they know at the time? If they did their best, but circumstances beyond their control produces sub-standard work, empathize with them. Acknowledge they did what they could with what they were faced with. Then take steps to mitigate those external factors.
Provide Constructive Feedback
By now you’ve provided code reviews for your peers. As a software architect you’ll continue to do those, but now there will be more situations where you need to provide feedback. Some of this may be corrective action to fix a problem. At other times it will be mostly good news. Regardless, here is a technique to provide feedback without making the person feel terrible.
Begin by finding something positive to say. For example, “Overall, it was good”. Then point out shortcomings, recommend specific improvements, and give reasons for those improvements. Finally, summarize with something positive.
Communicate Early, Communicate Often
I prefer to slightly over-communicate with my team members. No one likes being kept in the dark. People want to know the big picture, what the organization’s goals and strategies are, and what their place is within that big picture, and within those goals and strategies.
Obviously you don’t want to bump into any confidential information. Work with your boss to learn of any subjects that are highly confidential, off-limits, etc. Then be free with telling your people what you know. If they ask and you don’t know, be honest and tell them you don’t know. If you know a bit, tell them what little you do know. People respond to and appreciate this level of honesty and transparency. You have no hidden agendas.
Chat them up once a week. Get them to talk about their passions outside of work, about what’s important to them. It could be family, vacation, hobbies, sports, whatever. Whatever it is, remember them so you have something meaningful to start a future conversation. People love talking about their passions. When you show a genuine interest in their passions, you build trust and credibility with them.
In Summary
Leadership skills are one of the “soft skills” that up until now you’ve had little need to think about. Leadership is a skill that can be learned. Seek out the training you need, look to your boss for mentorship. Take the qualities of the best leaders you have worked for, and make them your own.
The day will come when all the effort you’ve spent honing your leadership skills leads to your team excelling. The feeling you get from that is one of the richest rewards of leadership.