The best way to approach a situation, that I’ve learned, is making sure you ask the right questions. That’s it. As a manager, you don’t have to have the answers, some answers sure, but not all. That’s why you are a manager, you are the router on a network of really smart people.
You do quality of service, you filter out what content reaches the network from the outside, and you make sure packets (ideas, comments, etc) get properly from one node to the other, or if they are going to the wrong node, you make sure they are redirected. That’s it.
It’s not an easy job though, and you as a manager should be guarded by a wall of good questions to distill the right answer out of the right minds. Sometimes the right mind is yours, but the process is the same.
On top of all that, you want the people you manage to be happy. I personally just like being a piece in a puzzle that makes somebody else happy. But regardless of that, happy people work better, interact better with others, have more ideas, and take less sick days. If you want to think about this in the purely practical sense, it’s super practical to manage happy people. And a lot easier.
How is a question right
This is arguable. As I see it, there are two ways of seeing this subject:
- There are questions that aren’t wrong, but they aren’t as useful as they could be
- There are ways of asking the same question that might be more helpful than others
The problem here is that a lot has to do with of whom you ask them. You need to pay a lot of attention and get to know the person you work with.
At the very least, a question is right if just the process of thinking about it, not necessarily answering it, makes the issue at hand progress in a positive way.
Sometimes it’s not about finding the answer, but asking the right question to steer somebody into a better path, so that they ask themselves the right question.
Identifying the problem
This sounds obvious at first glance, but it’s important to be able to ask “what went wrong?”, not whose fault was it that something went wrong, it’s not about pointing fingers. Yes, it’s extremely important to, as part of understanding what went wrong, identify who was involved in the process so that things can improve. But it’s important not to point fingers or blame.
Each person needs to be responsible for the part they did wrong, or didn’t do well enough, so that each person can grow on their own. So blaming somebody is not the way, but the person that might’ve been responsible for an issue eventually needs to recognize that on their own.
99% of the time, it’s shared blame. So don’t be too hard on yourself if you realize X problem is your fault: everything is team work.
And at the end of the day, the actual fault is the manager’s, because he/she didn’t ask the right questions at the right time.
So ask in one way or the other “what went wrong?”. Which sometimes might mean asking rather often “how are things going?”. The ideal team is one where everyone is hands off, they are independent and accomplish their tasks without supervision in the expected time. The real world team on the other hand, has a variety of different people involved. It’s important to recognize who’s who and leave some of them alone, be on top of other people, and somewhere in between the two for others.
Changing the problem to one that suits you better
Sometimes it’s not about solving the problem at hand, but it’s about changing it to a different problem that you can actually solve or at least handle.
In the ideal world, you have a lot of money and infinite time, and you do things “the right way”. You write well structured and maintainable code, with 100% test coverage, everything is documented properly, there are no architectural pitfalls that will come back to bite you in the future.
In the real world though, you’ve got deadlines, you’ve got market opportunities, and they are either unreasonable or they become unreasonable as issues or speed bumps appear. In the real world, that thing that sounded simple sometimes turns out to have a couple of corner cases that you haven’t considered. Those corner cases make a hell of a difference in how you approach the issue, and you notice them halfway through your current implementation, so either you hack something together or you redo your work.
This is when is super important to know the team you manage. Some of them might be super vocal, so as soon as they face a situation like the one described above they are going to tell you or the team. Maybe just to blow steam, but you’ll know right away. Some other team members might try to quietly keep on working on the issue, for days.
Sometimes, that’s the way to do it. There are problems that can’t be circumvented, they are complex, they take time, you need to spend that time. Deal with it.
But most of the times, there are ways to approach the issue so that it’s a win for everyone. You are the manager, the developer facing the issue and blocked by it is the expert on the issue. So you need to start asking questions:
- Can we release without this for now? You can keep working on it, we’ll ship it in the next release.
- Can we reduce the amount of things X handles?
- Would it help if we bring in Y to help you think this through?
If the issue is about scale:
- How soon will we hit the amount of data that will make this implementation super important?
- Can we implement something different that would work for the estimated amount of data that we will handle in the next month and build the right solution in the meantime?
Sometimes it ain’t pretty, shipping sometimes requires getting your hands dirty. If you’ve never gotten to that point, then you’re either the luckiest manager/developer alive, or you haven’t been through a lot yet.
- What are the easier corner cases we can take care of and how bad would it be to ignore the rest for this release? We can take care of them progressively.
Sometimes it’s about getting 80% of it right.
- Can we handle X, Y and Z right, and explain the workaround to Costumer Support for the other 3 cases that are less likely? We can fix them for the following release.
Sometimes you want to make 80% of your users happy and give the other 20% some answer or workaround while you get the rest done.
- Can we hire that guy that solved a similar thing? How hard would it be to get him up to speed with our codebase?
Sometimes it’s about spending a bit more money.
- What if X stops working on her feature and helps you here?
Sometimes it’s about delaying something else.
Scope
“… and you know what would be amazing? If it also did …”
Famous last words.
Scope creep is a problem. There are two sides to this problem: sometimes, somebody from the “business side” of the company decides to talk to a developer directly and change the scope after they tried the alpha version of that feature they wanted so badly.
Flat hierarchies are amazing in many ways, but they can go sideways if people aren’t careful. Sometimes you need to be the wall that divides your team from the outside world, so things that sound “reasonable” to others aren’t stressing out the people that actually make them happen and understand how much they really cost.
The other side to this problem is internal. Sometimes people get carried away, with similar reasoning as the previous case, and they want to tackle more than a given task specifies. Maybe simply because it’s a cool thing to work on.
This last case is more tricky, because sometimes you need to simply contain the situation and make sure the scope remains the same. But a lot of the times, you want the developer to remain working on the cool thing they like in some way. So it’s a tricky balance.
Future and growth
A lot of management work is not about shipping things, it’s about making sure the engine is properly oiled and it’s operating as it should. And for that, you need to understand what makes people tick, what makes them sit down in front of a keyboard with a smile. If they don’t have a smile on their faces, learn what does give them that, and figure out how to blend the two together somehow.
You need variety in your teams, you can’t have a whole team wearing the same hat. So this kind of detail is super important to know.
Some developers are happy working on bug fixes or small features. They are the happiest going through tickets and turning them into code. One after the other. Your job there is to know who these developers are, and keep that pile of tickets big and interesting for them. These developers are key to every team.
Some developers are building themselves, they are building a career, moving up the chain somehow, progressing. A lot of them don’t even know how or what they want to build towards, they might just feel it’s not enough at a given point in time. This is where the right questions are the most important. The question here is simple to ask but really hard to answer: What do you want?
It’s hard but it’s key to have it in mind, hanging in front of the comfiest couch in your mind palace so you never miss it: What do you want?
Sometimes it’s also important to ask the negative version of the question: What do you not want? Maybe they have what they want, except for that thing that’s been bothering them for a long time.
Another good approach to this is: In 5 years, if everything goes right, where are you exactly? How about in 10? If you understand the end goal, you can help them plan the intermediate steps.
Maybe they are happy where they are, but there are smaller things that help keep the day to day interesting: What would you like to learn next? Sometimes it’s about allowing parts of the day to be not about work exactly but about self improvement. A lot of the time, spending time on not work related things ends up being work related, if they are chosen carefully.
Process improvements
There are many books and experts about processes, techniques, their pros and cons. But regardless of which one you implement, how you implement them is important.
- What do you hate about your day to day?
- What do you love about your day to day?
- What would you do differently? Why? How?
It’s certainly not an exact science. A lot of time you need to experience the wrong version of it to learn what the right version is. Or go through it, see it fail, analyze, improve, repeat.
Tomas Touceda 