On leadership
Dinner conversation turns into a career retrospective. Food for thought for leaders and leaders-to-be.
Charge of the 4th Hussars at the battle of Friedland, 14 June 1807 (source: Wikimedia Commons)
Over a recent dinner, my conversation with Toss Bhudvanbhen meandered into discussion of how much our jobs had changed since we entered the workforce. We started during the Dot-Com era. Technology was a relatively young field then (frankly, it still is) so there wasn’t a well-trodden career path. We just went with the flow.
Over time our titles changed from “software developer,” to “senior developer,” to “application architect,” and so on, until one day we realized that we were writing less code but sending more e-mails. Attending fewer code reviews but more meetings. Less worried about how to implement a solution, but more concerned with defining the problem and why it needed to be solved. We had somehow taken on leadership roles.
Learn faster. Dig deeper. See farther.
We’ve stuck with it. Toss now works as a principal consultant at Pariveda Solutions and my consulting work focuses on strategic matters around data and technology.
The thing is, we were never formally trained as management. We just learned along the way. What helped was that we’d worked with some amazing leaders, people who set great examples for us and recognized our ability to understand the bigger picture.
Perhaps you’re in a similar position: yesterday you were called “senior developer” or “data scientist” and now you’ve assumed a technical leadership role. You’re still sussing out what this battlefield promotion really means — or, at least, you would do that if you had the time. We hope the high points of our conversation will help you on your way.
Bridging two worlds
You likely gravitated to a leadership role because you can live in two worlds: you have the technical skills to write working code and the domain knowledge to understand how the technology fits the big picture. Your job now involves keeping a foot in each camp so you can translate the needs of the business to your technical team, and vice-versa. Your value-add is knowing when a given technology solution will really solve a business problem, so you can accelerate decisions and smooth the relationship between the business and technical teams.
Someone else will handle the details
You’re spending more time in meetings and defining strategy, so you’ll have to delegate technical work to your team. Delegation is not about giving orders; it’s about clearly communicating your goals so that someone else can do the work when you’re not around. Which is great, because you won’t often be around. (If you read between the lines here, delegation is also about you caring more about the high-level result than minutiae of implementation details.) How you communicate your goals depends on the experience of the person in question: you can offer high-level guidance to senior team members, but you’ll likely provide more guidance to the junior staff.
Here to serve
If your team is busy running analyses or writing code, what fills your day? Your job is to do whatever it takes to make your team successful. That division of labor means you’re responsible for the pieces that your direct reports can’t or don’t want to do, or perhaps don’t even know about: sales calls, meetings with clients, defining scope with the product team, and so on. In a larger company, that may also mean leveraging your internal network or using your seniority to overcome or circumvent roadblocks. Your team reports to you, but you work for them.
Thinking on your feet
Most of your job will involve making decisions: what to do, whether to do it, when to do it. You will often have to make those decisions based on imperfect information. As an added treat, you’ll have to decide in a timely fashion: people can’t move until you’ve figured out where to go. While you should definitely seek input from your team — they’re doing the hands-on work, so they are closer to the action than you are — the ultimate decision is yours. As is the responsibility for a mistake. Don’t let that scare you, though. Bad decisions are learning experiences. A bad decision beats indecision any day of the week.
Showing the way
The best part of leading a team is helping people understand and meet their career goals. You can see when someone is hungry for something new and provide them opportunities to learn and grow. On a technical team, that may mean giving people greater exposure to the business side of the house. Ask them to join you in meetings with other company leaders, or take them on sales calls. When your team succeeds, make sure that you credit them — by name! — so that others may recognize their contribution. You can then start to delegate more of your work to team members who are hungry for more responsibility.
The bonus? This helps you to develop your succession plan. You see, leadership is also temporary. Sooner or later, you’ll have to move on, and you will serve your team and your employer well by planning for your exit early on.
Be the leader you would follow
We’ll close this out with the most important lesson of all: leadership isn’t a title that you’re given, but a role that you assume and that others recognize. You have to earn your team’s respect by making your best possible decisions and taking responsibility when things go awry. Don’t worry about being lost in the chaos of this new role. Look to great leaders with whom you’ve worked in the past and their lessons will guide you.
Public domain image on article and category pages via Wikimedia Commons.