Illustrated by Matt Peet

Very few people who make the leap to engineering leadership receive a how-to manual. Yet companies expect managers and other tech leaders to generate high performance. Most leaders also strive to maintain a strong sense of integrity, whether or not it’s written in the job description.

The transition to leadership is familiar to other transitions in our lives, says engineering leader Christopher Logan. “It’s a bit like when you go through high school to college or university,” he says. “In high school, a lot of things are spoon-fed to you. Once you get into college, all of that’s gone. It’s the same thing as an individual contributor, you can concentrate on and get good at the things you’re directly responsible for. But once you get into management, that structure goes out the window. You have to do all of it. And no one ever teaches you how.”

Logan, like many engineering leaders, learned by doing. After working as a software engineer at Honeywell, he climbed up the career ladder to Development Manager and Software Architect at Sirca and RoZetta Technology, Development Manager at MYOB and Engineering Lead at Tyro Payments. Most recently he led the technical organization at Deputy, where he emphasized the importance of helping engineers succeed and innovate, because companies can no longer rely on technical skills alone.

We caught up with Logan, and he gave us a peek inside his mind on staying relevant and maintaining integrity. 

Logan witnesses an interesting dichotomy in how tech companies construct managerial roles:

• Some companies compartmentalize managers by their oversight duties. This type manages people; these ones manage projects; over here, they manage deliveries. Each of these three kinds of managers tends to take a higher-level approach to that specific domain.

• Other companies require managers to get into the thick of the entire process. Managers check code, conduct reviews, make architectural decisions—in addition to the higher-level management of people and projects.

Logan has found that the balance of the latter option has contributed significantly to his ability to lead. “Being technically able enough to understand the technology that everyone is talking about is critical,” he says. “Same with being able to understand architecture, design, as well as the pros and cons of different ideas and different proposals.”

Every engineering team faces unique problems. That’s the challenge of building new solutions. But break those problems into their pieces, and they’re usually built of component problems that an experienced engineer or leader has seen a dozen times before.

“If you’ve got a wealth of experience, you can lend that to everyone on the team,” Logan says. “Your key attribute as a leader is your experience more than anything else.”

Technologically involved and experienced leaders can still leave a lot of decisions up to the team, but lending their wisdom offers value both to the product delivery process and to managing a team of people. It offers a hands-on approach that reveals passion and knowledge yet continues to respect the autonomy and expertise of the development team.

Those in turn strengthen the team.

“People will trust you more,” Logan says. “The more technical you are, the more trust there is in those relationships, particularly from other engineers.”

Managers and leaders who lack technological knowledge can unintentionally send detrimental ripples through the team’s workflow well into the future by not having well-founded opinions about the products the team uses.

“Being able to judge a technology for its appropriateness is critical, because if you can’t make a value judgment on that, you can cost your team years of tech debt and horrific integration problems,” Logan says. “As you get bigger you’ll have scale problems and performance problems. So I’ve found it critical to be able to manage people as well as technology.”

The thicker their cross-section of understanding, the better off leaders are. Logan rattles off that they can strive to understand front-end and back-end engineering, good test practices, tech writing and project management as starting points.

“All of that goes into how you frame yourself with your tech skills,” he says.

Logan recently reflected on the most recent years of his career. He realized he has drawn himself farther away from the technology component. Farther away from the day-to-day code writing.

“I feel like that’s weakened my ability to be an effective technical leader,” he says.

So he has returned to spending more time in the code, learning a new language, familiarizing himself with certain technologies. More importantly, he has committed himself to keeping up that momentum by carving out a set percentage of every week for his own tech development.

He dedicates that time to assessing the technologies and tools in his team (both present and future) and educating himself where his expertise lags. Keeping his skills fresh is the important thing, he stresses, whether or not he’s actually going to use them in practice. He needs to stay technically relevant in order to stay relevant as part of the team.

“The question is: Do you understand what it's like to be an engineer who works in your company?” he says.

Technologically involved leaders don’t need to become technological dictators. Logan doesn’t declare to his team that they must use Tech X or Framework Y. Instead, he creates a conversation around the goal the team is trying to achieve: get faster, increase stability, improve efficiency and so on.

“The premise of the leader is to set the bar to jump over,” he says. “Then it is up to the team to figure out how.”

How to set that bar in different ways is a key to effective leadership. Logan discusses how a tech leader can facilitate an independent team while still offering necessary direction and perspective.

Creative teams may produce tens of ideas to solve any particular problem. Logan stresses that a leader’s responsibility is not to contribute more ideas to the pool. His approach is to aid the team in figuring out which good idea among all the good ideas to pursue.

Yes, the way to do that starts with considering everyone’s opinion. Then the leader becomes the arbiter.

“Ultimately, you have to throw your weight behind something,” he says. “If you’re just a mediator, you’ll go slow when the company needs to move fast. You need to be the person that says which ideas have merit.”

Logan realizes that a leader’s decision-making capacity has the potential to stir strife within an organization. Wrong decisions clearly result in negative consequences, but every decision has consequences that others on the team may not like or appreciate.

The way to minimize that? Remove as much bias possible from those decisions.

“The way I’ve found to do that effectively is to set up core principles and ways to make those decisions,” Logan says. He highlights three distinct principles he uses to guide his own decision-making:

1. Establish goals and outcomes for the problems you’re facing. “These are the things you’re trying to stay focused on,” Logan explains. “The metrics you care about.” For instance—trying to move faster? Define what speed looks like, and what pace you want to reach.

2. Demonstrate how your decision addresses that problem. “Sometimes you make the boring choice,” he says. “But you have to be very clear that the goal isn’t to take risks. The goal is to achieve a business outcome. You have to make the decision that’s right for that problem.”

3. Push the conversation toward how the customer will care about this decision. (And if the customer won’t care, ask how the business will.) Every decision has a business cost for both the customer and the company. “It’s very easy to lose sight of the ultimate goal of the business,” Logan says. “It isn’t just to create new tech. It’s to service the customer. Bringing it back to the customer usually takes out a lot of the bias in those technology decisions. It actually makes them feel easy.”

Logan used to teach agile and scrum, but as laden in process as they have become, his approach these days is actually to avoid bringing in process altogether.

“I’m very open to how the team wants to execute,” he says. “I set the goals we’re trying to hit. If they can figure out a great way to hit them, they go do it. I don’t care what process they use.”

All he really cares about is that his team members strive to improve themselves every day, while also improving the team and its products. Development teams never stop getting better. That’s the nature of both engineers and engineering. Leaders need to keep pace with the bars they set for those teams.

“Setting a big enough goal helps people to break out of monotony or a sense of status quo,” Logan offers. “I find that by setting that goal as big as I possibly can, people use it as inspiration to create their own vision of that outcome.”

Metric-driven goals are still necessary steps to accomplishing those grander visions, but such goals can feel mediocre and uninspired if they’re the primary target outcome. Those goals become a numbers game, and many developers won’t feel motivated to create beyond those bounds.

But when Logan sets goals like becoming world-class or we’re going to teach people how to improve what they do—and he believes in their ability to go solve those problems and creates space for them to shine.

Even when shining means his own job becomes redundant. In fact, Logan has tended to change jobs every year or two, because he aims to build teams that don’t need him.

“If I can take a holiday for six weeks and that team is still thriving, my job is done,” he says. 

Every problem creates a certain amount of friction in an organization.

Logan discussed the idea above that a leader, by making decisions, sends ripples through a team. However, he has experienced more conflict about those decisions at the executive level than he has ever had on his teams—and more often to a point that challenges his sense of integrity.

“At that level, I get into discussions of which customer shouted loudest, if we’re going to reach a monthly quota, if we’re going to hit financial numbers,” he says. “You can have all the best practices and processes in the world, but some of the emotional things that go on at that top level of a company can still clip ultimate success.”

These types of challenges aren’t technical. They’re challenges where executive perspectives conflict with a development team’s and a business’s success, and have challenged Logan’s integrity more than anything that has ever happened within a team underneath him.

The power dynamics at play between tech leaders and executives can challenge even the strongest integrity. Leaders who stay on top of their game and understand everything a team needs to succeed, may still be asked (or ordered) to go against that expertise. That sets up a lot of leaders with a choice between maintaining their integrity or keeping their job.

“You’re faced with that quite often,” Logan acknowledges, “particularly at a high-growth company where changes happen constantly. I think you always have to ask yourself: What’s the thing that I care about most?”

The unfortunate truth is that leaders’ ability to prioritize integrity is proportionate to their level of their current stability.

“If you are in a position where you’re struggling with money and you need to keep your job, but your CEO asks you to make your team work nights and weekends for the next six months, you might have to do that,” Logan says.

There is no shame in choosing to keep a job. Logan simply asks leaders in those situations to be really clear with themselves on what the tradeoffs are. Honesty, and making a difficult choice, are themselves forms of integrity.

The developers on a team also rely on their leader’s integrity. Leaders making decisions that align with their own compass must often also assess how their decisions will impact their teammates—and what asks are acceptable.

“They rely on you not to throw them under the bus,” Logan says. “They rely on you to stand up for them. More than making technical decisions, they rely on you to be the one safeguarding their jobs. And you have to take that job seriously.”

For leaders finding themselves forced to frequently question both their internal personal integrity and the external integrity they must maintain for their teams, Logan offers a piece of wisdom: “If you believe you have to compromise your integrity, either it’s the wrong job, it’s the wrong company, or the wrong time for you to take that position.”

Logan understands that leaders and engineers can train their integrity. Strengthen it, just like any other skill. After all, he had to work his own integrity to improve his own leadership abilities.

• Coaching for leaders

The boldest influence on that journey is not exactly one he can prescribe to other leaders.

“The best thing that contributed to making me a better leader was having kids,” Logan says. “More than any work experience I’ve ever had, more than any leadership book I’ve ever read.”

So he can recommend reading parenting books and learning from other parenting resources. Many leadership or management books he’s read talk about how to get the best out of employees for your own or the company’s needs. Parenting tools, on the other hand, teach people how to show patience and encourage other people to grow.

“Your job as a parent is to help that kid be ready for the world,” Logan says. “It isn’t to make them rely on you, impart your own sense of bias to them, make them better for your family. It’s the same in a business sense. The outcome of leadership is: Your business is going to grow and your team is going to be more diverse in their thinking. It is going to benefit from different levels of judgment and decision making and autonomy. You’re going to have people who trust you to make the right decisions for them and who they are.”

• Coaching for developers

Engineers on his teams also ask Logan for advice about developing their integrity. Even when they don’t, he has to demonstrate it in his own behavior. And integrity isn’t always about the big decisions, sticking up for what’s right, fighting the powers that be on behalf of workers down the line.

In fact, it’s much simpler than that. “There is always a level of integrity that you can show in your own job,” Logan says. “It usually comes down to day-to-day decision-making.”

Engineers, for example, can get a piece of code out the door fast just by writing core functionality—or they can make sure not to create more tech debt by taking the time to test it. Different scenarios call for different approaches, and engineers must decide for themselves which one suits the moment.

“Integrity includes being autonomous and responsible for your own job and your own work,” Logan stresses. “I think that's the same with any level of employee, any level of engineering. Whether you’re an engineer or a product manager or a business analyst, you can show integrity every single day, often in the form of the technical work you’re doing.”

Showing your own personal level of integrity shouldn’t often risk your job or cause conflict. (Not in a healthy environment, anyway.) “But it’s all those little microtransactions of integrity that build up to the big thing,” Logan says.

Over the years, Logan has refined his toolkit for successfully leading engineers. It starts with staying sharp around the technology and staying true to yourself and your team. He believes leaders who stay mindful of these principles are the ones who can truly make a difference. 

Leaders who involve themselves with technological decisions remain more relevant and trusted. Wisdom comes from experience, so managers who continue to train their technical skills are better able to share meaningful insights and become the arbiter for technical decisions.

Leaders who allow teams to solve problems bottom-up improve the teams’ efficacy. Managers can establish the core principles that guide a team’s work and actions. Yet effective leaders also enable teams to choose their own processes, jumping in to help make decisions rather than contributing more ideas.

Integrity is made up of both large actions and smaller, everyday choices. Integrity is a formula of privilege, and certain sacrifices to leaders’ principles may force them to assess whether they are in the right job, at the right time, with the right company. Yet all leaders can strengthen their integrity, like any other skill; Logan draws particular parallels between learning to parent and learning to lead.

In fact, most engineering leaders naturally act with integrity and excellence. We all just need to be reminded from time to time what our pure intentions are. “We’re trying to build businesses that are serving customers for a specific purpose and solving a specific problem,” Logan says. “That's why most technology people get into technology in the first place. We want to help solve problems. We want to go and do something challenging, and we want to make a difference out in the world.”