Hi, I’m Ben: Part 2 in a Series on Leadership in Technology

Leadership means exposure. I volunteered and demonstrated the work our team did today to an audience of peers, and management. Its necessary to present for a number of reasons. You need to stand out, and you need to get comfortable talking to as many people as you can. The relationships are important, and you can’t settle for being just an employee number. Essential tip: Learn their names and don’t you forget them! Find something to talk about, and if that fails, talk about work, but talk to them damnit! When you make connections you establish rapport. This is the grease that is needed to make influence a smooth process.

Looking Glass Self

After the presentation, I had a call with my mentor, and I asked him how he thought the presentation went. His answer? He asked me how I thought the presentation went! I admitted I was nervous, and that perhaps overshadowed any objective review of how the presentation actually went. I said “I think it was good for the moral of the team”, which he made me immediately quantify. I didn’t have anything ready this time. He wanted me to glance at the team chat. It was full of questions, and praise. People that had no knowledge of what our team was doing were suddenly lighting up the board! That was the proof he said. I’ve got them interested to know more. They are excited, and they want to know more about our process. I spent the afternoon talking with people I don’t routinely talk to about our presentation. People were plugged in to what we were doing.

That Death Star is Fully Operational!

The order of business for this week was to handle front-line issues. He asked me what I thought we needed as a team to proceed. I thought for a moment and told him “we need a plan of attack!”. He asked how I would divide up the work. I admitted I didn’t know what we were supposed to touch, and what was best to leave alone. The work as presented to us not organized. We also needed to button up work from our last assignments, and come to think of it I wasn’t sure if we were focusing on that, or the new work. Time to take a step back before we get in a bad situation.

Enabling Accountability

People want to succeed. And one of the attributes in gauging success is delimiting what you are accountable for. It doesn’t matter if you knock a feature out of the park, if you let two more slide past a deadline, or if you are working on the wrong task all together. You have to enable accountability by pushing back (when needed) requirements as given to you (see Kobayashi Maru). The first task wasn’t a plan of attack at all – it was defining what we were accountable for. You absolutely have to answer this before you can come up with the attack plan. Once you know, you can box off your work, and fill in the gaps.

Lowering Friction

The side I do have the most experience with is the developer role. The worst thing that you can do to a developer is to give them muddy requirements. You can’t win. A developer wants clearly defined requirements for a piece of work to be able to autonomously translate this into machine instruction, and verify that it is operating “to spec”. Its vitally important this occurs. Often the developer will encounter this high friction work. Remember that rapport we built earlier? What better way to smooth out requirements, and axe the nonsensical requirements than to influence the people making the requirements? Make sure you understand what they want so you can deliver effectively. A developer often won’t be in a position to make a decision. You have to decide and be confident in your choices. Its also about standing by those choices, and being prepared to take the heat when your choices aren’t well received.

Know Thyself: Part 1 in a Series on Leadership in Technology

Know Thyself.

That is how my mentorship started at Analog Analytics. Before we continue some background for those following along: I’ve been doing software development with web technologies for a little over three years full-time now. I have a BAS in Technology Management, and as the “M” in the title implies, I’ve had academic exposure to the topic of leadership. I was bored to tears. Reading how to influence people out of a textbook is akin to watching your favorite show by viewing a sequence of technical diagrams outlining the plot. Its pretty close to useless. In the spirit of open source, I wanted to document my journey for those considering incorporating leadership roles into their careers. Its an elusive topic for me with a few abortions, and probably just as elusive to people-averse developers. Its ironic since its a field that stands to benefit so much.

My mentor asked me what I thought leadership was. Of course I had technical answers: Its being an authoritative source on a technology; its picking up the most bugs; its working long and hard hours. He challenged all my answers and posited it’s about one thing: influence.

99% of workplace problems can be solved through Influence

All the rules are there on paper, in emails, IMs, Wiki pages. You have standard operating procedures, political hierarchies, red tape, and documentation. That isn’t how issues get solved. More often than not he challenged, its a leader’s influence that allows them to win someone over to their side. That is why Person A can ask for something repeatedly, with no response, and Person B can ask for the same thing and get results. People are not software, and do not operate algorithmically. Given the same inputs, the outputs can change based on charisma. Its a fascinating phenomenon to analyze.

Taking Burden Off Others

So how do we gain influence? You can be a technical resource, and you can put in long and hard hours, and slowly climb upwards, but its orthogonal to leadership. Simply, start by taking the burden off others. People notice when you own a problem and resolve it for them. This isn’t about doing other people’s work. Its about removing friction from the process of work so they can easily do other work. When you make your coworkers lives easier, yo build up credit. Your ideas suddenly carry weight. You now have a better chance of successfully influencing them.

Kobayashi Maru

How do we reduce friction? As I said earlier, there is plenty of red tape to go around. Push back. If a process is painful change it. Side step it. Fight it. Better to ask for forgiveness than permission. You might gain traction doing it a better way before it can be killed off in the planning phases. This is about rejecting inputs, and is one of the most markedly apparent difference in a developer versus a leader. You have to stick your next out, and build up your courage. Odds are you aren’t going to get canned.

Know Thyself

A word of caution to those attempting to be charismatic. Play to your strengths. If your not funny, don’t open with an awkward joke. Be sincere. A big attribute of charisma is confidence, hence you should know yourself. ┬áThe end goal is to influence people, but this isn’t a study on mind control. Its about influencing someone’s views to get them to see the same end result that you see. You want to win, but you want to do it by empathizing, and leaving the door open for the future.