This article was published on 7/31/2017 in VentureBeat.
Technical managers are often promoted to their positions of leadership by rising through the ranks—more so than most other disciplines. This is a practical move considering that business decisions today increasingly hinge on the nuanced details of underlying technology. Technology leaders need to assess technical options, align recommendations with business requirements and communicate these decisions to non-technical stakeholders. If technology managers don’t understand the technology at a detailed level, it’s difficult for them to make the right call.
The challenge is that being a great engineer doesn’t automatically translate into being a great leader. Leadership—technical or otherwise—is not something one is born with; it is a skill that is developed over a lifetime. Unfortunately, many companies don’t have management training programs in place to cultivate leaders as they move up the org chart. And for those that do, these trainings are typically generic and conceptual. General management training is an important first step, but it is insufficient by itself to prepare technology leaders for the tactical challenges that await them on a day-to-day basis in their new role.
To help new technical managers through the transition from individual contributor to leader, I often work with them to adopt a new set of non-technical skills. Although everyone is different, I’ve found that the principles outlined below provide a strong foundation for becoming an effective technology leader—that is, one who is able lead a team, implement change and consistently achieve results.
1. Adopt a Business Mindset and Develop Empathy
As an individual contributor, it is acceptable to view technology through a purely engineering lens. You have the luxury of focusing on the “how” and not the “why.” This means that as a contributor, you can indulge in technology religion, propose solutions without regard to business impact, and leave it to management to sort out the practical considerations of the real world. When you become a leader, however, you no longer have this luxury. You are now “management.” This means you need to make decisions based on the messy realities of the business, which requires considering financial constraints, organizational culture, office politics, human foibles, and business results.
New managers often make the mistake of making the case for their initiatives in technical terms, rather than business terms, and they become frustrated when they fail to receive the proper support. They expect the business to instinctively adopt a technical perspective, instead of realizing that it’s their job to reframe their proposals from the standpoint of the business.
The best way to overcome this mistake is to take the time to understand the business metrics that the company cares about the most, and the pain points felt by other departments. This requires empathy—a critical skill for effective leadership. Technology managers should talk to their colleagues and listen to their challenges. They should unpack the key metrics of the business, and understand the forces that drive them. They must summon the quantitative and analytical skills they have developed as engineers and apply them toward a new set managerial problems. Once they have done this, then they can make their case as a business leader rather than a technologist, and they can start engaging in a constructive dialog with the business.
For example, if a manager wants to advocate for spending more time during the next few sprints to pay down technical debt instead of developing new features, she might approach the conversation in one of two ways. As an engineer she might say: “We really need to spend the next several sprints cleaning up the classes we developed in the first sprints, before we had a clear idea of the product functionality. A lot of things have changed since then and working with those base classes is really clunky. Plus, we skimped on building out unit tests, so our unit test coverage is low.”
Although this may be an accurate reflection of the situation, it is not a compelling case outside the engineering team. First, the explanation is too technical and too tactical for business stakeholders to understand. Second, it does nothing to explain the benefit that the business will derive from this approach. Finally, it completely fails to acknowledge the pain that this proposal will cause the product manager—namely, if feature development comes to a halt, his manager and/or stakeholders are going to have a major problem.
Another, more effective way a manager might approach the conversation is like this: “We’ve made great progress on the product so far, but we’ve accumulated some ‘technical debt’ along the way. We shifted course on the direction of the product and our code couldn’t quite keep up. It works, but we need to spend some time shoring up the foundation to ensure we can sustain the level of quality we’ve set for ourselves. Given the CEO’s emphasis on increasing customer satisfaction this year, as measured by our Net Promoter score, I feel this is important. Small annoying bugs increase the number of Detractors, which has a big impact on the overall NP score. I suggest we spend a third of the time over the next three sprints to pay off some of the technical debt.”
This response is better for several reasons: it uses analogy to illustrate the details, rather than relying on technical jargon; it explains the benefits of the plan using key business metrics; and it suggests a compromise for the product manager—to use a portion of the time in the upcoming sprints, but not all of it, to address technical debt.
2. Adopt a Solutions Mindset
Another aspect of leadership that new managers often struggle with is understanding how to approach problems outside their direct control. Changes within a manager’s direct sphere of influence are relatively straightforward to implement. For example, if a QA manager wants to add Cucumber to the test automation stack to promote Behavior Driven Development, he won’t need to schedule many cross-departmental meetings to make this happen. But, if an engineering manager wants to move from a Waterfall methodology to Agile for project management, then she will need to spend a lot of time working with people outside her org, as this is a much larger organizational change.
When confronted with problems outside their direct control, new managers often give up too early, and escalate too soon: “I sent an email to Tom in the Program Management group about adopting Scrum for the next project, but he never got back to me. Clearly the organization isn’t ready to adopt Agile.” In these situations, when new managers escalate prematurely, they are really just handing the problem to their manager to solve, without doing the work themselves to try to address the issue. This is acceptable when you’re an individual contributor, but not as a leader.
As a leader, you need to be able to overcome obstacles outside your direct control. This might mean persuading a manager in another department to adopt a new process as part of your initiative. Or, if you’re an executive, it might mean solving problems far outside your control, like devising a plan to increase revenue during an economic downturn. The key to success is adopting a solutions mindset.
A solutions mindset is a perspective that focuses on the objective rather than the problem. When you adopt a solutions mindset you concentrate your efforts on achieving the desired outcome and you don’t waste precious time complaining about the hurdles you encounter along the way—you just figure out how to overcome them. Your manager, then, becomes a way to help you achieve your objective, not a person who solves your problems for you. A solutions-oriented leader brings potential solutions to the table when she escalates to her manager, and she leverages her manager’s expertise and influence within the organization to pursue her goal.
With a solutions mindset in place, when the manager escalates to her manager, the conversation might go something like this: “After I failed to get a response from Tom, I called him directly and scheduled a meeting to discuss using Agile on the next project. He’s open to the idea, but is worried about employing a new methodology without the proper training. I propose that we use $5,000 of our own training budget to help fund a Scrum training session. I’ve done some homework and identified a few possible training vendors. I also recommend that we schedule a meeting with you, me and the Program Management leadership team to discuss why Agile will benefit the organization. This will help get everyone onboard.”
In this scenario, the manager brings a proposed solution to the meeting with her manager, and she makes a clear ask that leverages her manager’s position within the company to help achieve her goal. This approach is much more likely to yield results than spending the time complaining about why people don’t respond to email.
3. Build Your Network and Earn Trust
By necessity, companies need to segment employees into departments and hierarchical structures as a way to manage organizational complexity. In reality, however, these divisions are arbitrary. They exist simply to help us manage the business. The challenge is that the most interesting business problems rarely fit neatly into the arbitrary organizational boundaries that we’ve defined for ourselves—they span across the org chart. Thus, effective technology leaders need to become adept at working throughout the organization to implement change, and this requires building a strong network.
The term “networking” strikes fear in the heart of most people—especially technology geeks. But building a network of likeminded colleagues doesn’t mean you have to have awkward conversations at cocktail hour or constantly be exchanging business cards. On the contrary, the best way to build a network is to just be yourself. Establishing trust is essential when building relationships, and being authentic and straightforward is one of the best ways to do this.
Another effective way to forge relationships is by going out of your way to help other people within your organization. Volunteer to help somebody else with their initiative, or go the extra mile when someone asks you for help. This gives you an opportunity to interact with people outside your department and it helps build trust.
Also, make a point to attend company social events and use this as an opportunity to meet people outside your department. You don’t have to be a salesman-level networker at these events, just challenge yourself to meet one new person each time. (And, don’t be afraid to introduce yourself to more senior people—they’re just people too.) Even if you don’t have a substantive discussion at a company gathering, just breaking the ice with a co-worker at a social event makes it much easier to reach out to them in the future.
As you begin to build connections within your company, you will find that this network of contacts gives you super powers. When you know who to call to get things done, and they know and respect you, you can move mountains. Cross-departmental initiatives become a fun opportunity to reconnect with colleagues and tackle big problems. Changes happen faster because you’ve already established trust and you can quickly get down to business. And, the need to escalate to your manager decreases because you don’t need to go to her every time you need to reach out to people outside the department.
4. Understand that Perception is Reality
As we first develop in our career as technologists, we focus on growing our technical skills. We get promoted based on tangible and measurable accomplishments, like learning a new language or mastering a new technology. Once we move into management, however, things change. As managers, our success is based largely on squishy, abstract attributes like teamwork, leadership and communication ability. The subjective nature of these skills means that we lose our measurable benchmarks of progress, and must rely instead on other people’s perception of our efforts. This is a bitter pill to swallow for most new technical managers.
It may seem unfair, but that’s how the world works. When it comes to leadership, your effectiveness is based largely on how your managers, team members and co-workers perceive you. It doesn’t matter what your intention is when you draft an email, give a presentation, or make a comment in a meeting. The people around you are interpreting every nuance of your communication and they are arriving at their own conclusions about what you’re saying. They are also receiving information about you third hand, which is based on other people’s own interpretations of your actions.
Successful leaders understand that perception is reality and they don’t waste time complaining about it. Instead, they are deliberate and clear in their communication and they redouble their efforts when people misperceive their actions. This is why I work on communication skills with every manager who reports to me. We often dissect emails and replay verbal exchanges at a microscopic level, because the nuance of communication is so profoundly important. Simple things like body language, dress and tone are critical factors in how people perceive you, and it is difficult for people to assess themselves in these areas.
Also, by acknowledging the hard truth that perception is reality with my employees, it allows us to have a more honest conversation about how other people in the organization perceive them. We can skip the “life is unfair” discussion and move right into talking about how to align the manger’s own perception of her ability with the rest of the organization’s. In my experience, the true “reality” usually lies somewhere in between. The best managers understand that there is truth in how the community perceives them, and they use this feedback to improve their performance.
5. Adopt an Operations Mindset
The ability to implement change that is built-to-last is a crucial component of effective leadership. Unfortunately, most new managers focus exclusively on the initial rollout of their initiative, and fail to consider how to support their program over the long run. Adopting an operations mindset helps overcome this mistake. An operations mindset is a perspective that considers the on-going tasks required to support a program throughout its entire life.
Naturally, new managers are excited about the first phase of a new initiative. This is a period of great enthusiasm when they focus on bringing their initiative to life by documenting the idea, raising support and deploying the associated technology tools. This is rewarding work that requires an intense Herculean effort, but it is only the beginning. The phase that comes next is known as the “valley of despair,” and it’s when things start to go haywire. The workflows that looked perfect on paper don’t work so well in practice. New procedures get ignored and people start to bad mouth the new technology tools. And worst of all, people begin to lose faith in the initiative itself.
This is a tough time for new managers. They often react by throwing up their hands and blaming the setback on the organization itself: “Clearly, the company isn’t ready for change.” Experienced managers, on the other hand, see this phase for what it is—a natural part of the transformation process along the classic change curve. They know that if they remain persistent and keep pursuing their objective, they can punch through the valley of despair to see their initiatives come to fruition on the other side. An operations mindset helps managers sustain the initiative after the thrill of launch has faded by keeping them focused on long-term support, including:
- Adoption – Cultivating empathy for end users and developing strategies to make it easy for them to adopt the new processes and tools. E.g. Publishing information about the initiative in places that are easily accessible, and notifying people about the new program multiple times using several different channels—a single email usually doesn’t cut it.
- Scalability – Identifying bottlenecks in procedures that could cause the program to breakdown when it’s rolled out to a larger group. E.g. Ensuring there are multiple approvers for gating steps, so that a single approver doesn’t hold up the works when things gets busy.
- Redundancy – Training multiple people to play key roles so that if someone is out on vacation or leaves the organization, then the initiative itself still functions normally. E.g. If the program relies on a person to administer an application, what happens when that person is out of the office?
- Training – Setting up training to teach people about the new initiative. E.g. How do people learn about the new program when it’s rolled out? How do new hires learn about it? Is retraining required at regular intervals?
- Ongoing support – Establishing a procedure for people to use when they have questions or encounter problems. Setting up support workflows is especially critical during the second phase of the change curve. Cracks start showing immediately after launch, and your ability to learn and iterate quickly will make or break the adoption your new initiative.
It’s not sexy stuff, and it takes additional time, but planning for the operational aspects of a new program is crucial to long-lasting change. Experienced managers know this, which is why they adopt an operations mindset when rolling out new initiatives.
6. Read Management Books
As technologists, we devote a lot of time to reading technical material. It feels like we spend most of our life reading books, blogs, whitepapers, online tutorials, Stack Overflow posts and snarky Hacker News discussions. It’s a requirement for the job and something we should continue to do as managers. However, to become a strong technology leader, reading technical material is not enough. You also need to tap into the wealth of information out there about management and leadership. Sure, some business books are cheesy, but the truth is that most popular management books today are actually really good. They contain thoughtful, research-driven approaches to managing teams, implementing change, and achieving business results.
This is why I always encourage technology managers to start reading management books. It almost doesn’t matter what managers read and as long they are reading something. By reading management literature, you start thinking about leadership as a distinct discipline, and you can start to formulate your own approach to it. Below is my list of recommended reads. It’s not intended to be a comprehensive list, but rather a starting point that represents the books that have influenced me the most as a manger.
- Good to Great by Jim Collins. A fun, inspirational read about the leadership styles that lead to long-lasting financial performance.
- First, Break All the Rules by Marcus Buckingham. Argues that the most successful managers focus on capitalizing on employees’ strengths, rather than obsessing about their immutable weaknesses.
- Lean In by Sheryl Sandberg. A groundbreaking book by Facebook’s famous COO on leadership and gender. Embarrassingly, it is one of the few popular management books written by a woman.
- The Lean Startup by Eric Ries. Offers a radically different approach to product management using real-time empirical learning to drive feature prioritization. Also checkout Eric Ries’s blog. Ries is a true-blue technical dude and a truly innovative business person, which makes his writing insightful and fun to read.
- You’re in Charge, Now What? by Thomas Neff and James Citrin. A classic text that offers a strategy for earning respect and confidence in a new leadership position. Perfect for new managers.
- Leading Change by John Kotter. A classic read on how to successfully implement change within an organization.
- The Truth About Leadership by James Kouzes and Barry Posner. This is an excellent, research-based book on general leadership principles. We use this at POP as the basis for the management training program conducted by our People Practice.
- The Five Dysfunctions of a Team by Patrick Lencioni. A classic text on team dynamics. A short, fun read.
- The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. A must-read for the DevOps crowd, this book is written as a business novel about how to apply lean manufacturing principles to IT Operations.
- Harvard Business Review. HBR is a must-read magazine for managers. It always contains insightful, research-driven articles about a broad range of topics. It’s expensive, but it’s worth it.
7. Adopt a Positive Attitude
As a leader, people look to you as a bellwether for how they should feel about the organization, both consciously and subconsciously. If you are upbeat and enthusiastic, the people around you are more likely to be optimistic and happy. If you are negative and pessimistic, your team is probably grumpy and depressed. Whether you like it or not, as a leader, your attitude rubs off on your team and your co-workers in a significant way. Therefore, it’s essential to be mindful of your demeanor and to project an optimistic attitude.
Now, it is important to draw a distinction between optimism and Pollyannaism. You can be frank and honest—even during difficult times—and still have a positive attitude about the future. Being positive doesn’t mean wearing a fake smile. Rather, it means that no matter how bad the current situation is, you have faith in yourself and believe deeply in the efficacy of your own leadership ability. If you believe in yourself, you believe that you can make the future a better place. It is this confidence that people respect and are drawn to.
My advice to technology leaders is to harness their passion for technology as a source of positive motivation. We live in an insanely exciting time for technology. The tools, patterns and practices available today enable us to do incredible things that we couldn’t have done just a few years ago. As engineers, our passion for technology is probably the force that has propelled us forward in our careers. If we can tap into that energy, and adopt the leadership principles discussed here, who knows what amazing things we are capable of in the future?