Bored people quit (2011)
randsinrepose.com
randsinrepose.com
For me, this is the money quote. Like rands, I've gone back and forth on this over the years as well, but I do strongly believe that you cannot effectively manage a team if you do not understand what it is that they do, at least at a high level.
You don't need to be as good at coding as the engineers who work for you, but you must know enough to empathize with them, and to help mediate dead-locked discussions.
I'll admit that there are exceptions, and effective s/w managers who can't code do exist, and I'll also admit that finding such managers is probably not a scalable task, but I feel it's something that every company should strive for.
It is not your job anymore, and if over the next 5-10 years you start having a hard time talking to engineers, than maybe you weren't that good of a programmer to matter. Frameworks change, but general programming knowledge doesn't. Even if an engineer says something like "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" as an excuse to not deliver and if you think it is important for the rest of the project, you should easily check google to understand what is going on, but you don't need to know rails 7!
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.
I think a better analogy maybe coaching. Some coaches were players before coaching, while others weren't, but their understanding of the sport isn't linked to them actually playing the sport.
A coach would observe their players play everyday, and review their performance quite directly. Their bodies are not able to do it anymore, but they are "still in the game" so to speak. A bad development manager is often never looking at their programmers' code (or if they do, they might not understand it), only seeing and evaluating indirect results of their work. Even a good dev manager is not looking at their programmers' code very much, but at least they understand what is going on and are able to themselves in their programmers' shoes.
Organizational "visibility" is why it is so important for programmers to attend and speak up at meetings; the organization is incapable of valuing what they do directly. Also, "managing up" is the secret to getting things done with a non-coding boss.
I'm not advocating that bad managers should learn through google, but if you were a good developer and didn't program for 10 years, if the time came to decide between TDD or BDD for the project (though that should be a Team Lead or CTO job, not a PM) he should be able to brush up quickly. Maybe not decide if you should use Shoulda or xUnit or whatever, but have a general picture of what the developers they are managing are talking about.
If this manager hasn't been doing development for 10 years, he is a lot cause. But this doesn't have much to do with programming, just being involved in building software. But in cases where their experience isn't fresh enough, they will have a tendency to either be static (we will write our web project in COBOL, because that is what I used to use dammit) or be very trendy to a fault (I heard post modern node-oriented programming was hot, let's use that for our compiler).
In context, BDD = Behavior Driven Development [1], not Binary Decision Diagrams.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.
A good dev manager is able to see the good over the fad.
"Management" doesn't always mean tell people what to do (it rarely does if you're doing it right,) Managing could mean protecting your team from all the boring shit work, it could mean making sure that your team's goals are in sync with other teams, it could mean making sure that people are prioritizing their work around what needs to be done rather than what would be fun to do, etc.
If there are other teams, I would assume we aren't talking about a small startup anymore. But even if we were talking about a small startup with one team working on a product, it makes sense to delegate project management tasks to someone in the team who isn't managing the team.
A developer manager should be able to protect their team from shit work because they know what shit work looks like in the first place. They should also understand the parts at a high enough level to make informed decisions, and they at least know who knows the details so they can get input from the right people when problems arise.
That kind of manager that bases his decisions on quick google searches without understanding whole system is the worst kind of manager. If there are trade offs involved and possible bad consequences in the context of your database, your search will ignore that.
Ultimately, "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" is not level of detail non-coding manager should deal with. That is for the rest of the team to either propose other solutions or make it work with the rejected one.
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
That is exactly what I tried to say (maybe in the wrong way). A manager's job isn't to make technical decisions or help the engineer with code. It is to have an higher level view of the project, how it is going, and be able to help make it through. So, picking the rails 7 example, in this case the manager should be able to read about it and say, "Hey engineer X, have a chat with Bob in the frontend team, he may be able to help you out since he has experience with socket communication". Not decide to change rails to node because he read a blog post about how great node is.
Was I wrong? (I hope I was wrong.) My manager was a great guy, and definitely not unreasonable. But at least from my perspective at the time, the stakes were so high. Was this just some stupid fear that doesn't actually reflect what happens in real life?
I think you just have to leave with an offer in hand, saying politely no to any counteroffers. But, always remember, move jobs like Tarzan, with one hand in the next vine before letting go of the current one. (Have an offer before letting _anyone_ know at your current job).
That being said, I encourage my employees to let me know if there is anything I can do _before_ it gets to that point. I believe in letting people move around between roles, jobs, and teams if it helps them engage better. But I'm a pretty private guy about not being happy at work, so I'm not even sure I'd take me up on it unless I framed it in such a way like "boy this other team is doing some cool stuff, can I help out?"
Something about the asymmetrical power relationship makes me very careful to not harm myself with my own actions: and having been fired once in a humiliating way really opened my eyes to how bad things can go if the person on the other end wants to be cruel.
I see a parallel between this quote and a supervisor or co-worker stating some other co-worker "doesn't understand", which when translated to cold, honest English becomes:
"[co-worker] is antagonistic, aggressive, rude and stubborn. I do not want to confront [co-worker] regarding this issue because I want to avoid the hostility that will be thrown back at me, you will have to deal with [co-worker]'s hostile behaviour all by yourself because I am a stinking coward and want to brush this problem under the carpet."
From a personal perspective - I've turned to the quit mentality due to boredom after my first job after not having enough to do, and at my second job I converted over after immense deadline pressure for half a year when combined with significant underpayment (extreme frustration).
The best pre-emptor would be to be proactive in addressing these problems. If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough - I'm looking your way startups.
I've noticed this to be a huge issue when it comes to large companies who try to defend the situation saying we are "lean" and reduce forces by "cutting the fat." I'm currently in a situation where I've become "The Guy" for two entire product lines and its gotten to the point where they keep tempting me with "You'll be on Next Generation SOON". But soon, in my eyes, will never come because I'm a single Engineer maintaining hundreds of thousands of lines of code, code that deals with an OS no one else uses, in build environments no one else uses.
What I use to think of as job security has become a pill that induced boredom.
At a startup there are tons of tasks to get done and not enough people so you can easily jump from one area of the company to another. Your manager can say "Joe is getting board doing X, but Y needs to be done and its completely different." But what do you do when your job doesn't have other areas for you to jump to? We have different areas of the business but at this point I'd have to take a demotion to move...or become a manager and not code anymore.
I guess I've got more of a gripe than an actual comment. And I know a lot of people post about startups and small companies where change can actually occur. Sucks that I have to give up stability to get interesting work.
And yes of course digging for signs doesn't beat asking by far. Ideally performance reviews can fill this role (sadly, at least here, too often those are treated as just a legal obligation where the only practical goal is to discuss and most importantly document some complaint, no matter how small, so that just in case the company later decides to fire the employee, they already have a file with "evidence" that you were underperforming for a long time).