Part 6 in a series on managing programmers
April 17, 2014
It’s my experience that many technical managers aren’t -- and don’t really want to be -- managers. See, we generally start out as engineers or developers, and probably show some strong competence as individual contributors. Maybe we’re also one of those rare engineers who can keep their cool with customers and has a knack for explaining technical solutions to non-technical types. Then something happens -- someone resigns, a team gets too big, a new project starts -- and we’re thrust into the job of "leading a team", perhaps "just in the interim". And we try to continue doing things like we had been doing, but now we’ve got all these extra meetings to go to and emails to answer and we have to hang out with the guys in sales and marketing and the project manager keeps asking me questions about when we’ll be done and I have all this PTO to approve and then Sally’s dog died and Jason’s getting married and I’ve got hire an intern for the summer and all I really want to do is write code!
This isn’t the fault of the poor sap who just got thrust into management. This is a problem with the organization, because most organizations don’t pay enough attention to succession planning and training their managers. I find this is a problem with how most places define the role of manager, and how they expect to find manager. Put simply: The best engineering managers aren’t normally the best engineers on the team. Sure, they can do the work, but they’re more often the guy or gal on the team who knows exactly who else in the organization might be better at a given task than they are. So I wanted to share some of my thoughts on what the job of technical manager actually is and isn’t.
A manager’s job is about...
- People. This one’s obvious, right? You saw it coming, sure. But the problem is that most organizations don’t make this point crystal clear to new managers: "Your people are your number one priority. Period." Not your code, not the new architecture. Your people. Their productivity, their effectiveness, their professional growth, their ability to work as a team, and, yes, even their "happiness" is your single most important responsibility. That means your job is to listen more than you talk. That means if someone on your team wants to talk to you, you should very seriously consider dropping everything else on your plate to have that conversation. That means everyone on your team should have your cell phone number and personal email address. That means emails from folks on your team are the very first emails you read and respond to (and yes, you always respond!). That means you make time to meet with everyone on your team one-on-one in private at least once a week, and that your weekly team meeting is something you prep for and retrospect on afterwards. That means thinking about how to resolve interpersonal conflict between your team members is something that keeps you up at night. That means you are concerned with the professional development of your team members over the long term, not just with their performance in the moment. And yes, that means all these things are more important than you getting to write code or build robots.
- Productivity. Ultimately, your job is to help the folks you manage be as productive as possible. This is a good thing for the company, obviously, but it’s also a good thing for the people on your team. Studies have shown that happy people are not necessarily more productive, but that productive people are usually happier. This makes sense: If you can help the folks on your team get stuff done, then they are rewarded by a sense of accomplishment and having made a real difference that day. So, when considering someone for the manager role ask: Is this someone who by hook or by crook makes other folks more productive? Are they the ones you find moving the furniture, putting away the dishes, making sure the coffee is hot, walking over to marketing to get clarity on deadlines, and running interference with the sales team -- just so that the folks doing the work can have the physical space, mental tools, and emotional focus to be effective and productive?
- Priorities. One of the ways you help make your people more productive is by being creating exceptional clarity around priorities -- both for the folks on your team and the stakeholders outside your team. Ask around and you’ll find that most developers have a half dozen "top priorities" at any given moment. But again, studies have shown that most of us are actually pretty terrible at multitasking, so it’s just wrong to believe that someone with more than one (or maybe two) priorities is actually going to be effective. One of a manager’s most important jobs is to stretch those half dozen tangled priorities out into a clearly ordered list, and then share that list with everyone. So is your manager always the one ordering and re-ordering and clarifying and communicating priorities? And making sure everyone knows what everyone else is working on and why they won’t/can’t/shouldn’t get to priority number seven until two weeks from now? They should be.
- Positivity. Engineers are problem solvers, and therefore problem-oriented. It’s very easy for most of us to identify what’s wrong with any possible solution -- the risks, the holes, the probability of error, etc. But the danger is that a room full of engineers can drift toward negativity and inaction (we are also a data-driven lot, and there’s almost never "enough" data). The manager’s job is to keep the team focused on the positives, help the team create a workable plan, and drive toward an acceptable solution. You are not necessarily the smartest person in the room, so your job is to get those folks thinking, and thinking about solutions not roadblocks. Are you supposed to have a vision, a plan, and be a bit of a cheerleader for your team and the organization? Yes. And are you supposed to smile and give positive feedback for things done right? Yes. Negativity is very easy for engineers, and it’s part of your job to set an example and focus on what can be done and what’s getting done correctly.
- Teaching. A manager needs to be a teacher, and the job of a teacher is to help their students learn and grow their knowledge and skills. It’s important to note that most great math, science, or history teachers are not themselves great mathematicians, scientists, or historians! Great teachers ask great questions -- the kinds of questions that inspire their students to think and rethink, to question what they thought was true, to become curious about alternative paths and different ways of doing things. Likewise, good managers ask more than they tell. "What do you think?" "What are some other ways of doing that?" "Is that really the best/only way to solve this problem?" "How could we do this faster/better/stronger/differently?" Good managers recognize that learning is about the student growth and ask these questions with the intention of leading the team to the best possible solution, not simply to demonstrate how smart they themselves are. Good managers recognize that it’s sometimes okay to let someone choose the wrong path and fail if it helps the larger goal of learning and growth. And good managers are always thinking about how to engineer a better learning process.
- Trust. We gain trust when we do what we said we’d do. It’s really that simple. And a manager’s job is about brokering trust within her team and within the larger organization. Managers need to trust team members, team members need to trust their manager and each other, and the company needs to trust the team. This all boils down to a process of setting expectations, communicating clearly about those expectations (including letting folks know when they change), and then meeting the expectations you’ve set for yourself and your team.
- Leading. It’s the manager’s job to stand up and lead. Yes, leading usually means public speaking. It’s your job to run the daily stand-up and the team meeting. And it’s your job to call and order the pizza. And it’s your job to present the team’s latest work at the company demo. And to shake hands with new customers and new employees and meet and actually talk to actual people. Of course, not all of us are great at this part of the job (since many of us are introverts), but it is indeed part of the job. Good managers know that they are always on stage, and everyone is always watching. But leadership is more that just public speaking. It’s also about creating a shared vision and mission for your team. Who are we? Why are we here? Sure, we’re engineers and we’re here to solve problems and get paid. But most high-functioning teams have some understanding of how their group fits within the larger organization, and why the work they’re doing matters. It’s the manager’s job to articulate this vision and help forge this identity through goal-setting for individuals and groups, positive and constructive feedback, and communication with folks inside and outside of the team about how awesome the team is.
A manager’s job is not about...
- Always having the (right) answer. Your job is to help solve people work together to solve the problem and come up with answers. Most often this means you’re the person who knows the person who might know a person who probably has the answer. The manager’s job is to connect smart people and thereby magnify or focus their impact.
- Being the smartest person on the team. See above. I’ve worked with some horrible managers who were absolutely brilliant engineers. This, in a nutshell, is why if folks can’t get behind all the "soft stuff", and can’t bring themselves to "schmooze" and "deal with all the politics" then they’re probably better suited to continue in a role as an amazing individual contributor. The manager’s job is to know who the smart folks are, get them in a room, set some goals, and help them work toward a solution and a commitment to getting the work done. They need to be smart, but they’re probably not the best scientist, engineer.
- Doing the work themselves. The manager’s key skill is to be able to accomplish more through other people than they would themselves. If the manager is the person who’s constantly called into play to fix the problem, write the key algorithm, or save the day, then something’s wrong. It’s not that the manager couldn’t necessarily do the work. Rather, it’s that the manager is supposed to be leading a team, and when the team does the work the team works better.
- Perfection. It’s amazingly easy for engineers to let "perfect" become the enemy of "good enough". Smart managers know that their job is about people, and people are rarely perfect, and rarely produce perfect work. Smart managers know that a solution that meets 80% of the customers needs today is about a million times better than a solution that meets 95% of the needs but gets delivered too late. The 80/20 rule is the right way to approach things about 80% of the time.
Part 5 in a series on managing programmers
May 11, 2013
Here’s a list of some of the things about management that I expect from myself, and from people I work with and for:
- I believe that 95% of all problems can be solved with better communication. Good communication is appropriately clear, comprehensive, timely, and frequent. Good communication adopts the right tone and is and channelled through the right media. Communication is often more about listening and asking than talking.
- It is the responsibility of leadership to be honest and forthright in their dealings with people inside and outside of their organization. Leaders are able to share both good and bad news in constructive ways with peers, team members, and customers. Good leaders encourage people to be honest with them.
- Believe in people. Actively demonstrate confidence in their abilities. Look them in the eye and openly affirm your trust, keeping any private doubts locked away. These are things that empower. Delegate actively but always with a commitment to help, to teach, and to learn. Tell people you have their back, and then be there when they need you. We gain trust from others when we actually do what we committed to doing.
- Fear, uncertainty, doubt, and randomness are the enemies of productivity and happiness. Work to make sure expectations are clear. Strive to minimize surprises at all times. Timing is everything.
- Stand up and take ownership of the situation. Generate solutions, not additional problems. Be willing to take the blame, and quick to admit mistakes. Do not make excuses.
- Embrace servant leadership. Lead with humility, and be ego-free when searching for the best ideas and solutions. Do what needs to be done, and believe that it’s never not your job. Treat people with respect independent of their status or disagreement with you.
- Expect the best from yourself and from the people you work with. Challenge yourself and others to deliver quality. Know, follow, and create new best practices. Identify root causes. Note that true mastery is intensely pragmatic, and avoids letting perfection become the enemy of good enough.
- Always be learning. Always be improving. Always be seeking a new and different perspective. Admit what you don’t know, then go find out. Avoid stagnation, and embrace change even though it’s always hard.
- I believe there are two sides to every story, and that people generally have a reason for doing what they do. Reserve judgment as long as possible, and avoid assigning blame before you have talked to everyone involved. Deliver bad news in private whenever possible. Work to build up relationships built on mutual respect and understanding, and prefer talking with someone to talking about someone. Never say anything you wouldn’t say to their face.
- Laughter really is the best medicine, and also a fantastic way to forge a common bond. Humor is a tool that should be used very intentionally, always with compassion, and always with the goal of building up rather than tearing down. Humor can soften harder blows, and can delivery feedback with subtlety. And if you can’t at least act like you’re having fun then do not be there.
- People expect leaders to act like leaders. Stand up on stage and play the role to the best of your ability (yes, everyone is always watching). It is your job to make (hard) decisions, so make the call, take the shot. Leaders understand that inspiration is better than motivation, and that people matter more than processes, systems, or things. Leaders radiate positivity and celebrate wins. Leaders are often friendly but rarely friends with those they lead. Parenting may be a useful mental model if you remember that good parents are always responsible, always making mistakes, always learning, always doubting themselves, always and deeply caring, and always willing to make sacrifices and put the needs of their family in front of their own desires.
This is definitely a work in progress, but it sums up a lot of what I think and feel are important.
Part 4 in a series on managing programmers
April 25, 2013
When I was first thrust into management, I would come home at the end of almost every day frustrated at how little I had accomplished. You see, like most technical managers, I still tried to keep myself involved in the task of actually writing software. I was a “working manager”, and still a developer (“75%!”). On my daily to-do list I had code to write, diagrams to draw, and databases to query.
But I felt like I “never get anything done” because, dammit, now that I was “the boss” everyone kept interrupting me. I found that even on days when I only had two or three meetings scheduled I’d still end up spending most of my day in hallway chats, impromptu one-on-ones, emergency client meetings, and responding to about ten times as many emails and phone calls as I’d had to deal with before I became a manager.
It took me a good deal longer than it should have, but I’ve since made three key realizations:
1. A manager’s job is more about people than about code.
A manager’s primary job is to make sure his or her team members are operating at optimum efficiency. That means your job, as a manager, is to remove barriers and pave paths. Your job is to work with and through other people to accomplish goals. You are no longer a do-er. Your primary contribution to the organization is no longer embodied in the code you write, but rather in your performance as the “glue” between individuals, working on stage and behind the curtains to connect people and teams. You are a leader, and your job is to inspire, motivate, mentor, guide, and help other members of the team do the actual doing. Toward this end:
2. A manager’s job is to keep their team in “flow” as much as humanly possible.
In “Flow: The Psychology of Optimal Experience“, Mihaly Csikszentmihalyi’s defines a state of flow as “the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia). Most creative professionals, including programmers, do their best work when the are able to achieve a state of flow. This is the moment when as a programmer you’ve got 18 different variables, 7 competing business requirements, and the entire architecture of the system you’re building loaded into your brain as you work through a challenging implementation. It took most of the last hour for you to get yourself to the point where you’re in flow and able to make forward progress toward a solution, and all of that can get flushed down the toilet with one single interruption. Which is why:
3. Managers endure life in interrupt mode in an attempt to prevent their team from having to step out of flow.
You no longer get to spend as much time in quiet solitude, working for hours crafting a nearly-perfect solution on a single problem. Rather, you are supposed to be there to run interference and, yes, to run errands for your team. Your new role expects you to be able to juggle multiple balls, multiple projects, and multiple priorities. Which requires, at most times, multiple personalities. In one moment you’re the wise mentor, working with a junior developer to clean up some code or get a test to pass; the next moment you’re the project manager politician fighting to balance a half dozen emergency requests across only three developers or write three dozen user stories before noon; and minutes after that you’re playing the gadfly, prompting your fellow developers to reconsider potentially problematic architecture decisions. And all of this talking and walking and meeting is in selfless service to the goal of trying to keep the rest of your team in flow.
This life in interrupt mode is very hard to take, and is very likely one of the main reasons why many new technical managers bail out of the job. But it also makes for very interesting and exhausting days. Because after you get home and get the kids off to bed you still have your fair share of code to write, diagrams to draw, and databases to query…
Part 3 in a series on managing programmers
February 6, 2010
The third installment in this series is about something I learned well before I got into management. In fact, it’s probably the reason why I got into management at all:
Get up out of your chair.
As geeks we’d rather just sit there. Sit in our chairs and send yet another email and hope enough folks read it. We spend a whole hour crafting a brilliant treatise on an Important Topic and assume that our written words alone are motivating enough to get people to do what we need them to do. And we hope (in vain) that people will read our words carefully, reflect deeply, and return the favor by drafting a well-written response of their own.
But when it comes to managing people email simply doesn’t work as well as we wish it did. It’s often the wrong tool entirely. You know this as well as I do. People simply don’t read your emails carefully. Or they miss it entirely. Or the message gets to them too late. Or too soon. And even when they do read your email, people can almost always manage to misinterpret the tone of your message and you end up spending even more time clarifying and apologizing and re-iterating. Et cetera.
In my experience, the only thing that does work is to do something that is entirely unnatural for most in the world of high tech: Get up out of your chair and practice some “MBWA“. MBWA stands for “management by walking around“. It means you go and walk over to somebody and actually engage in conversation. Talk to them. Talk first about the weather or their kids or whatever they’re working on at the moment. Then transition the conversation to what you need to talk about, or just drop in your request casually at the end. And sometimes, just like magic, you learn things without even having to prod. It goes like this:
Tammy sitting reading email. Manager enters, stage right.
Manager: “Hey, Tammy. What’s new?”
Tammy: “Just reading the latest missive from the client. They’re being a little less insane than usual today.”
Manager: “Nice! Always good when sanity prevails, eh?”
Tammy: “Yeah, absolutely. We can use a little bit of a break after yesterday’s server issues.”
Manager: “Wow, really? I must have missed that somehow. We had server issues yesterday?”
Tammy: “Yeah. It turns out the new audit trail feature caused our logs to fill up and we ran out of disk space.”
Manager: “Ouch! But yeah, that makes sense. You’ve got it fixed now though, right?”
Tammy: “Yep. We’re purging logs every 30 days now.”
Manager: “Good deal. Client seems happy?”
Tammy: “Sure. They seemed to like that we responded so quickly.”
Manager: “Excellent. Thanks for jumping in there!”
Manager exits, stage left. Elapsed time: 45 seconds.
3 reasons why MBWA can make you more effective
- It’s faster. Yes, it is. You might think you don’t have time to get up from your desk and actually go through the hassle of walking over, interrupting the person in the middle of their Facebooking, and actually talking about what needs to get done. But in the same 5 minutes it would have taken you to write an email you’re able to not only make the request but respond to questions immediately.
- It builds relationships. Being face-to-face with someone puts you in a position to tailor your message to the individual and respond immediately to questions in a way that is most effective for that person. Moreover, engaging people one-on-one helps build the relationship — you learn more about each other. This learning is the foundation of trust, and having trust means your conversations will end up getting faster and more effective over time, especially during a crisis or when speed is of the essence. And having more face-to-face conversations also ends up making it easier for the other person to interpret your “tone” when you only send email or IMs.
- It helps you learn and know more. As a manager you deal in information, and you’re missing out on at least 50% of the data feed if you’re not there in person. As I’ve already said, actually getting up and talking to other human beings seems counter-intuitive and at least somewhat stressful to most of us in technology. And here’s the thing: Most of our team naturally tends to avoid the face-to-face conversation as well. Yet the example above shows that it’s through the quick face-to-face interactions that we’re able to learn much, much more about what’s actually going on in our organization. Your team member may be too busy fighting a fire to send a detailed email, and maybe he’s not the type to swing by and chat either. But being there allows you to sense and prod and follow hunches, all of which end up providing you with more information, making you more effective.
So don’t just sit there in your corner office typing on the computer. As a manager your job is all about making everybody more effective by getting the right information to and from the right people at the right time. You just can’t do that with email alone. As my good friend and colleague Derek Olson likes to say: “The weeds are waist high. Sometimes you just need to stand up to see over them.”
Part 2 in a series on managing programmers
December 18, 2009
The second lesson I learned after being thrust into management was this:
Make the call.
Management didn’t confer any secret knowledge or special skills. Nothing about me had really changed from one day to the next. Except that all of a suddenly folks around me expected me to make the tough decisions.
Suddenly people would approach me with an issue. I’d listen and try to figure out what the problem was, and maybe think up a solution or two. Then I’d try to ask them what they thought about it. Hey, you’re smart. We’re paying you to know this stuff. So what do you think?
And more often than not they’d respond with something like: “Well, um, I’m not sure. That’s why I’m asking you.”
So here’s the crazy thing about being in leadership:
People expect you to lead.
I’m lucky. I get to work with wicked smart folks. So I expect them to have thought things through. And I’m usually no where near the most qualified person to make this decision. But there you have it. When the going gets tough your team members will expect you to make the call. That’s right, you’re “The Decider“, for better or for worse.
And this is a Good Thing. Making the call is, after all, why you’re there. Yes, it’s your job to make tough decisions in the face of uncertainty and lack of information and time pressure. What’s more: If you want to keep on making “the big bucks” and retain that fancy manager title then those spur-of-the-moment decisions will need end up being right more often that they’re wrong.
At the end of the day, being asked to make the call with insufficient information day in and day out is one of the major reasons why I see plenty of smart geeks quickly leave management roles or try to avoid them at all costs. It’s not really in our nature, because most of us technical types are information-driven. We’re type “C” in the DISC model, as the cats over at Manager Tools like to remind us. Our default mode is “ready, aim, aim, aim, aim…”. So making decisions quickly without enough information makes us really nervous.
Moreover, problems are often political. Yep, that’s part of the job too. Often the best technical answer to the problem is pretty clear to see, but implementing it means somebody’s feelings are going to get hurt. That’s why your team is coming to you. And while taking responsibility for something that might get somebody fired seems like a tough gig, it’s really the most important and best thing you can do. Really.
So if you’re a geek who’s suddenly found him or herself in a leadership role, and now everyone’s looking to you to make the decision, how do you do it?
Tips on how to make tough decisions
- Accept responsibility for the decision. This is really important because it’s where you get a chance to exercise your role power and political power in a really positive way. By accepting that it’s your job to make this tough call, you’re helping to take the pressure off of your team member. It’s very often this pressure to make the right decision that’s brought your team member to you in the first place. And removing some of this pressure will help free them up to focus on solutions and not consequences.
- Ask for recommendations again. It goes like this: “Hey, thanks for coming to me with this issue. It’s definitely a problem, but I’m sure we’ll figure something out. So tell me… if time/money/politics weren’t an issue, what would you recommend we do?”. So first take the pressure off them and then try to get them to re-engage. Remember, they’re usually the one with the most knowledge. And it’s always good to take another quick look around before jumping.
- Go get consensus. If you need to get up out of your chair and ask other folks what they think about a given problem, do it! Not getting up out of your chair is probably the number one mistake technical managers make. So stand up. Call a hallway meeting. If Kevin’s brought you a problem that Jake might have insight into, then drag Kevin over to chat with Jake. And make sure you get to a point where folks agree. Consensus is important because you need this to help make the decision stand.
- Don’t delay. Avoid the temptation of avoid putting off a decision indefinitely. Commit to a date and time. “I’ll let you know what I think by COB.” Or: “Let me check with Bob and get back to you within the hour.” It’s very natural for us to want to wait, but remember that your teammate brought this issue to you because it was important. While you sit and ponder your team is very probably at a standstill.
- Link decisions to principles and goals. When you end up at an answer to the question or a solution to the problem, it’s a good idea to try and frame it in terms of a general principle instead of a specific solution. Choose a direction (“North”) instead of trying to specify a specific path (“42 paces to your left”). Leave yourself and your team some flexibility by letting the folks who are going to have to do the work handle the details of a specific implementation. It sounds like this: “Well, I hear you on how we’re running out of time on this project, but since we’ve all agreed that we need to do as much testing as possible even on legacy code, I’d say let’s identify the 3 most critical features and write tests for those, for starters. Do-able?”. Focusing on principles means you’re focusing on what’s reasonable based on a larger context and previously established norms.
- Decide on plans not rules. “We must have 100% test coverage” is an empty decision without a corresponding plan for how you’ll achieve the new goal. Recognize that a decision is nothing without a plan for acting on it. While it is useful to make a general principle the foundation of your decision, it’s important to end with a plan for how the decision is going to be implemented. Here’s how that sounds: “Yes, we I agree we need to attack some of the underlying problems with the architecture. So why don’t you begin by make a list of sections of the code that already have good test coverage? Then we’ll know where we can start with the least chance of breaking things.” At the end of the day plans are more flexible, more comprehensible, and more likely to succeed in the real world than arbitrary rules.
Of course, it’s not as easy as I make it sound. But at the end of the day it’s what your team needs you to do. So make the call. It’s what you’re for as a manager.
Part 1 in a series on managing programmers
November 22, 2009
If I have any management secret, it’s this: Every now and then, when one of my team members asks for my opinion, I try to pause and answer with one simple question:
What do you think?
I’ve been managing programmers for over five years now. That’s a long time in internet years, and I’m to the point where I don’t think it would be too out of line for me to start sharing some of the tips, tricks, and techniques that I’ve learned about how to manage software developers and engineering types.
The first management tip I’m sharing dates back to the very first day on the job as a manager. I’d been working with my fellow web developers in a small-but-growing shop, building a couple of fairly substantial applications used by the collections and law enforcement industries. Then one day my boss took me out to lunch for my annual review and I got promoted.
On the drive back to work I realized that I was suddenly in a position where I would be managing some of the folks who’d hired me. I had deep respect for every single one of these people. All of them were wicked smart. Most had engineering or science degrees of some sort (easily trumping my history degree), and many of them had more practical experience developing web applications than I did. I’d already learned a ton from each of them during my time with the company, and I knew I still had lots left to learn.
And that’s when it hit me. Before I’d read a single book or blog post or listened to a single podcast on how to manage software developers I realized that the one thing I couldn’t lose was input and feedback from the folks on my team. In that respect nothing had changed. Being in management hadn’t magically conveyed any special abilities or secret knowledge. Just because my title had changed didn’t mean that they had nothing to teach me or that that I no longer had anything to learn from them.
So I from that moment forward I made it my practice to try to pause and ask this question at least once a day. “What do you think?”
I didn’t have all the answers at the time. And that hasn’t changed in five years. And, in fact, the key realization was that as a manager it’s actually not my job to have all the answers. My job is to work with my team to find the best answer to a given problem.
As managers of knowledge workers it helps if we start by recognizing that our teammates have probably already come up with at least one or two answers on their own. Programmers, engineers, and scientists are problem solvers by nature. It’s what they do. So I try to get behind this. In fact, I specifically try to use my role power as a manager to encourage and support this whenever possible.
Moreover, we can use this one simple question to make it clear that we’re not just merely curious or playing to their egos, but that we expect our teammates to come to us having already thought through the problem, and to have a possible solution or two in mind.
In my experience, asking “what do you think?” helps accomplish three things:
- It empowers team members by letting them know that I will actively solicit their ideas.
- It sets the expectation that team members should have already thought through the problem themselves.
- It demonstrates that I care more about finding the right solution than about being the one who came up with the solution.
In five years I’ve read plenty of books and articles and blogs about management in general and managing knowledge workers in particular. But I still come back to what I learned on my first day of management. “What do you think?” is a specific, practical technique that flips the power structure on its head and helps me demand the best that my team can bring.
So every now and again stop to ask your team what they think. You and your team will be better for it.