Slashdot Mirror
On Managing Developers
An anonymous reader writes: A columnist at TechCrunch takes a crack at advice on how to manage developers. He has some decent starting points. For example, "Basically a manager's job is to make other people more productive. What's one really good way to do that? Do the work that is getting in their way. Which means: find out what kind of important work your developers dislike the most, and do it for them." Also: "[D]on't bull$%^& anyone, ever. ... Speak the truth as you see it. Speak it diplomatically, don't get me wrong; but be trustworthy. Only then will you be able to trust others." But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context." If you are or have been a developer, what qualities have made your managers good or poor? If you've been in position to do the managing, does you experience jive with this guy's?
... As in "I speak Jive" from the movie Airplane?
Or maybe he means "jibe"?
Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.
"But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context."
Uh, what? Devoid of meaning? Maybe you should learn to read at a Junior High school level. What that sentence would tell you, could you read English, is that the religion of a specific process and procedure is not sufficient to guarantee success. A process which works correctly in one environment will result in doom in another. Nobody should have to spell this out for you; in the quote above, the text which precedes the ellipsis is sufficient to deliver this information. If you can't read and comprehend the above, perhaps you are not cut out to be an Editor (or story submitter?)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Here is my approach to managing engineers.
1. Get the right people.
2. Get the right work.
3. Get obstacles out of the people's way.
4. Get myself our of the people's way.
This reminds me of the "Fast, cheap, flexible - choose one"-idiom.
You can be a great developer, a shitty manager and a good spouse.
You can be a good developer, good manager and a shitty spouse.
Or you can be a shitty developer, great manager and a good spouse.
(Forget about being a great spouse if your mission in life is to please a company!)
One of the best managers I've had have been technical, and got the boring parts done.
One of the best managers I''ve had have not been technical at all, but championed our services well and established a good network of connections throughout the organization that made the processes actually work.
It's all trade-offs. This also goes for "agile", which is just a choice for some trade-offs over another set of trade-offs.
The main problem is when people don't work together to find the best solutions, together.
Often, new hyped-up processes and tools become yet another excuse for people to NOT work together!
This even escalates the bigger the company gets.
Oh, and you should compensate work well done.
Well, if I'm left alone (no bullshit), it doesn't bother me to work extra time to get something done well. As soon as I have to deal with bullshit from a manager, I move into my 8 hour mode. That means I come in and do 8 hours a day as per my contract and don't give a shit.
I would disagree with "Which means: find out what kind of important work your developers dislike the most, and do it for them." I would say:
"Find out what non-essential stuff is interfering with real work and protect them from it."
There often is work that is important that must be done but is not exactly fun, such as documenting code, helping tech writers prepare user manuals, listening to users and getting feedback on the UI, etc. Developers may dislike that work but they are the ones that need to be involved with it or do it. Sometimes it's the manager's job to point out stuff that needs to be done and find a way to get it done; even if it isn't what they want to do.
I'm a consultant - I convert gibberish into cash-flow.
Mostly my list of desirable qualities is similar. I disagree about the "meaningless" part though. The one about "Any particular process artifact is probably irrelevant." is instantly clear to me. He's saying that it's the result of process that matters, not the specific bits that go into it, which is something more managers need to grasp. You need to use what works for the way your team works together, and you can't get so attached to one particular thing that you can't throw it out and replace it if it's not going to be a good fit with your team. The goal, after all, isn't to fit a set of specific methods together in a certain order, is it? No, it's to get the software done on time, to spec and without errors.
told me that his job was only partially to tell me what to do (because I should know most of it) and mostly to shield me from the bureaucrap so that I could concentrate on doing it. I try to emulate that.
Two other nuggets I aim for:
- a good manager tells his people what *his* objectives are, and explains to them how that translates into the objectives he's giving them.
- there are different kinds of management for different people, and a good manager must adapt. A newbie or an incompetent *needs* micromanaging (but beware of giving the impression of thinking either one is incompetent). As they get older/wiser/more experienced the manager can go more and more hands-off, until with a senior engineer/whatever the manager should be able to just discuss strategy and budget and priorities and such.
A manager's job is not to make anyone do anything
That's true, but it's also not what he said. The work "make" goes with "productive", not "people".
His point is that the manager's job is to improve the productivity of the team. That's also a true statement, albeit pretty obvious.
superior compensation. period.
Peer reviews, client feedback, is there anything you need from us, done. As long as peers and clients are happy, the conversation takes under 30 minutes.
Hell is a pretty cool place.
Judge employee performance only by meaningless metrics that can be looked up in Jira in 2 minutes, as opposed to actually looking at some the code their subordinate wrote.
Can't stress this enough. Few developers respond well when they're treated like machines, even if they get external rewards like bonuses. Showing how valuable a part of the team they are makes a big difference in developers' morale in my experience.
Learning how to manage software developers is exactly the same as learning to be a good manager in general. I manage software developers. I'm not perfect, I wouldn't even rate myself very high, but many of my employees have told me fairly often they appreciate what I do for them. They things they seem to appreciate are: being as transparent as possible, being interested in their personal interests and development, going to bat for them when they need something (new PC, training, etc), giving them honest and quick feedback both good and bad, and not being willing to place blame but instead just looking for solutions. None of those behaviors are specific to managing software developers, but instead are some things good managers do in general.
I was a software developer before this so while I'm not up to date on the tech they are currently using, I understand the types of struggles they face. That helps, although I'm fairly sure if I went tomorrow to manage a team of mechanical engineers that I could become effective fairly quickly in that role, too.
Don't get me wrong, I'm don't think I'm a great manager, but I have had one or two great managers and I'm trying to borrow the things I thought they did well and my employees seem to respond to that.
"shit umbrella", protect the team from the crap that comes from higher management.
Two of the SDEs I manage told me in their last review I was the best boss they've ever had. Here is my advice:
1) Do not judge anyone on anything except on whether they get their job done. If someone quickly does a good job, I don't give a shit whether they take the rest of the day off.
2) Lead by example. Do the things you want your guys to do. That means the hard things.
3) Imagine your team as a machine. You're the oil. Be where there is the most friction and smooth it out.
4) Sacrifice yourself for your team. If you can't get a reward from the company for someone who deserves it, buy it yourself.
5) Understand the perspective of your boss's boss, and explain it often to the team.
6) Say you don't know when you don't know.
7) Fight for raises and bonuses.
8) Don't talk as a boss most of the time, but when you do, have a good reason to.
These guys worked on the project that won us a nomination by a government agency for Small Business of the Year. The morale earned from being a good boss repays itself in improved productivity and reduced turnover. Plus you make friends for life. It pays to be a good boss.
Until last month, I managed the 12 devs I had hired (I have 30+ years of dev experience). On my way out the door, 3 of them gave me a 'best manager I've ever had'. No one gave me a thumbs down, at least to my knowledge. My 'secret'? Honesty, kindness, and this one very important thing: I never imposed a decision unless they couldn't come to one themselves, or were going off the rails. Despite my sizable ego, I've found 'letting go' of control, and focusing on guiding the team, rather than telling them what to do, produces one very happy, productive team. And they' introduced ideas and solutions that never would have crossed my mind!
I left after a painful year of my naive boss and certain of his colleagues on the leadership team knocking us off course with their sophomoric meddling. Note to senior leaders: When you have a competent person running your dev team, let him/her do it. Just because you can spell Agile doesn't mean you know what it looks like.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Give them time, Give them resources and let them tell the marketing department how it's going to work.
If you're an MBA, remember that to everyone who works for you, that stands for "Moronic, Bullshitting Asshole".
I do not fail; I succeed at finding out what does not work.
from a distance. Say "Make this do this" and stand back, let the kids do their magic (hell, being a manager doesn't require technical knowledge) and look forward to the result. Micromanaging is for kindergarten teachers. You have a team of devs because they know how to code and you probably don't, keep thy nose in thine own trough.
While I like the overall message here of not micromanaging, I think an important distinction needs to be made between telling developers how to do their work and constantly validating that developers are doing their work. The latter is counterproductive but the former is absolutely necessary. Junior level employees often don't understand one of the major differences between managers and non-managers: in the eyes of executives your managers are ultimately responsible for the project's success or failure, regardless of who actually messed up. So they absolutely cannot just sit back and wait for developers to be done with their work and hope for the best.
While I agree with this article's advice that a good manager will find ways to take grunt work away from developers, that is such a minor part of their role as manager. The most important, and most difficult, part of being a manager is finding a way of constantly validating the project's progress without being a major hindrance to the developers. There is no easy answer to this that I can give in a Slashdot post, but it is vital to the success of any project.
As a senior level developer, one task I take upon myself is ensuring that our non-technical personnel have a method of validating our work throughout the project. I prefer having these milestones at least every other week. This doesn't have to mean you create a releasable product every other week like some Agile methodologies suggest, but you should at least find a way that your project / product managers, business analysts, and other key stakeholders can validate the project is on track.
When I join a new company (like I just did four months ago) I am very clear with my managers that I will take on this responsibility, but it means they are expected to trust me to do my job as long as they are happy with these validations. So far it has been working well for both me and my employers over the years, although that only comes from experience with two employers since I became a senior level resource.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
I disagree with the post. Don't do everyone the developers don't like. It is not your job to write documentation. Get buy from the team to understand what they are doing. That being said, you do need to make sure that things don't fall through the gap.
From my experience as a manage here are my top best practices:
1) Get buy in
a) Answer questions with, "what do you think we should do?" Then let them do it. If you supply an answer the employees will never believe they have control. You will not get buy in and you will answer the same type of questions forever. You can offer opinion. Be clear on whether it is opinion or a order. Phrasing as question can help, "what if we implemented x?"
b) Monthly review of what is good and what could go better can be a great tool. It can get to an issue before it festers among the team. This is critical in my view. Sometimes the team will not agree with one persons complaint. This can get the complainer to realize it is not such a big deal and not think you are ignoring them because the issue is really not that series. As much as you are allowed, tailor the process for the team. What matters is what works for the team. Get the team to buy in to the process.
c) Other ways to think of getting buy is delegating and not micromanaging.
d) listen and be honest
e) My best accomplishments as a manager was when I succeed in getting buy in
2) Dampen the pressure from above. One of the most successful people I have ever met said his job was to be the "fear eater". He would tell his employees, you can't fail at this. I am the one who said we should do it. If we don't succeed it is my failure. I have a hard time succeeding at this and probably one of my bigger failings as a manger. I can't help but show the pressure. I am pretty good at not blaming people which is a critical aspect.
3) Play to the strengths of the team. People naturally have strengths and favorite areas. Give people a little leeway. Let them experiment a little. So contrary to my first statement, sometime it is good to do the things the developers don't like. Just make sure it is really what they are trying to avoid and not just something they are not doing because you are doing it already.
...He has some decent starting points. For example, Basically a manager's job is to make other people more productive...
Well, if the summary starts off on such a wrong assumption, it can only get worse from there.
imo, one of a software development manager's jobs is to create an environment that allows the software developers to do their jobs. If the manager has to "make" them do their jobs or be more productive, then the wrong people are in the software developer jobs.
I agree the article starts off with a very poor assertion about the most important role of a manager, but I don't necessarily agree with your either. I like your change to what the article says, but I still don't think it is the most important part of a manager's job.
IMHO, a manager's job is to ensure their projects are a success. Regardless of which developer or business analysts messes up, the ultimate responsibility always lies on the manager. Many employees don't realize this because they never witness their boss getting yelled at by his boss, but when projects miss their due dates the developers are not the only ones in trouble. Developers probably have a more silo-ed view of the whole project so they can legitimately blame failures on factors outside of their control, but a manager can rarely do that. The buck stops with him.
Bad managers micromanage because they are afraid the job won't be done right and they know their ass in on the line. Good managers find a way of trusting but validating their senior level resources.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Censoring your own profanity is one thing (albeit kind of silly in my opinion; why is implying it worse than actually spelling it out?) But when you're quoting somebody else -- and linking to their article -- you really ought to use their own words. If you're afraid that your readers are going to be offended by profanity, then you probably ought to not be linking to those articles.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
If your developers are any good you basically don't need to do much. Give them a direction and the tech and they'll happily hack away. That's pretty much what my best manager tried to do. He made sure I had a good machine to develop on, would get them upgraded when they got old, and tried to prevent other divisions from using us as tech support. (Which can happen surprisingly easily since the devs tend to be some of the most tech savvy people around.) So he got that if I'm waiting 20 minutes every morning for my machine to start up or have to reboot once a day because my machine slows down because of all the corporate stuff on the computer that not only ticks me off but actually costs the company money. (Since developer time is actually very expensive so don't waste it.) I'm always surprised when managers can't get the budget for a new laptop or even just an SSD when they thing will pay for itself so quickly. (Back the envelope calculations even if you assume 30 minutes wasted a day a SSD pays itself off in a few weeks, the laptop pays itself off in a few months.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Or whatever your people are doing. You need to be able to understand what your people are doing so you can know if they're doing a good job or not.
The whole TPS report thing from office space was a consequence of someone that doesn't know how to code or understand the product trying to keep tabs on people that were creating that product or service.
So they create artificial benchmarks and paper work and then judge the employees by how well they comply with the paperwork.
The problem is that the paperwork is not actually anything the customer cares about. It has nothing to do with the product or service. It is an arbitrary management mechanism. And it is FINE if the manager doesn't need it. If the manager can judge your work without it, than the paperwork might make his job easier.
However, if he can't judge your work without that paperwork than he literally can't do his job at all. He can at best APPEAR to be able to do his job. And the only people that would make that mistake would other people that also don't know how any of this shit works.
How is a non-doctor going to judge the quality of a doctors work? You can't.
Same thing. Managers have to have experience in CS if we're talking about developers... ideally they should be programmers themselves.
Again, if you don't have enough programmers with management experience, then it is easier to give programmers management training than it is to give managers programming training. So do that.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Micromanaging is for kindergarten teachers. You have a team of devs because they know how to code and you probably don't, keep thy nose in thine own trough.
As a manager I hate to micromanage and I've discovered that there are two types of developers: Those that can self-manage and those
that can't. Being a small shop we are unable to efficiently micromanage the later type of employees and eventually have to let them go.
I've stayed in contact with a few of these later type that get into a highly structured and micromanaged business and they do just fine
even though they were incapable of completing even simple projects if left on their own.
Well that escalated quickly.
Locking scope ruthlessly*, use a process,and to produce builds on a timeboxed basis.
The RUP process encouraged proving all risky items would work before starting on the easy/non risky items to avoid wasting a ton of work on a new project which then turned out to be impossible (you see 100 million dollar failures in this area).
Status reports with percentage of completion are loathed by developers but necessary for all but a small percentage of developers.
Having a project plan and a schedule is helpful.
*Any additional scope should always require a new time estimation and executive approval before being allowed. The cost of "just adding this little feature" should be shown to be "another week- and we need you to sign off on the schedule change."
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
in the eyes of executives your managers are ultimately responsible for the project's success or failure, regardless of who actually messed up. So they absolutely cannot just sit back and wait for developers to be done with their work and hope for the best.
Not always. Many of my projects are special requests by VPs and directors that are ASAP with no real deadline because it needs to be done yesterday or very important projects that need tight turn-arounds for nearly everything, like bug fixes and new features, live in prod.
When the normal process can take hours, I can take minutes. It's a trade off. They know I am a single point of failure and there is good reason to have a formal process for most things, but some times customers have outrageous demands and too many hands in the pot makes that impossible. So they throw me at the problem and I design, code, QA, maintain, and tools for ops for the entire stack. Because I appreciate the role of an admin or ops, I'm on a very short list of programmers that admins trust. Many times my design decisions affect how the admins will need to support stuff. I typically give them a few options on how I could design stuff, and how that would impact them. I let them make the choice of how it will affect them instead of just being forced upon them.
I have a decade track record at my company for getting stuff done faster, fewer bugs, and handles feature creep. I can tell you exactly what can or cannot be done and what trade offs there are. I've been told I take the longest to get a product out, but the quickest to a final product and virtually no issues. I'm not the only "me" over here. There are a few others, we get shoved together and pretty much given free reign. I have a much longer design phase than most, several times longer, but I spend a lot of time thinking of edge and corner cases and how to design the system to handle them gracefully and in predictable ways. This is why I'm slow to getting something to show for my work. But the end product is completed several time faster.
Because I spend so much time thinking about the many interactions of the systems that work together and the edge and corner cases those interactions create, I rarely have a "bug" submitted. Nearly everything is a feature, designed to work and fail exactly as I thought it to.
When it comes to these kinds of projects, my manager is just there to help me when I request it.
I really hate customer deliverables, too much feature creep. I prefer to write internal tools for performance sensitive systems. I love writing scalable multi-threaded code. Lots of theory, lots of algorithms and data-structures.
Large systems are a lot like multi-threaded programs. Lots of race conditions to think about, possible pathological worst cases to make sure cannot happen, should be well structured, and are a pain to debug if you don't have a clear vision of what your design should be. I remember writing my first mutil-threaded program ever, fresh out of college at my new job. One bug in production, been running for nearly a decade now. I always thought multi-threading was easy and I never understood why people think it's so hard. Debugging race conditions is easy if you make sure certain race conditions can only happen in certain parts of the code and only under certain conditions. If you design your code such that certain states can only occur in certain parts of the code and the transitions happen in well defined ways, if a race condition occurs, it's simple to know where in the code it occurred and many times how to fix it, without even using a debugger.
We have covered this topic time and time again and all we have are opinion, anecdotes, and people pedaling the 'Silver Bullet of the Month'. Is there any real data or comparison case studies we can draw on? I am coming up without finding anything I trust as Scientific. Are they any out there? Tech is so central to the global economy these days wonder why people are not intensively researching it.
putting the 'B' in LGBTQ+
Kind of ironic? Or kind of fitting? . . . how everyone who complains about individualized treatment uses the SAME EXACT METAPHOR.
Obviously, you need them to all work together, so you need to promote immediate communication between all developers.
I suggest one large open room, with several rows of folding tables. Then place the developers along the tables, alternating sides to make best use of the space, as well as making sure they talk to the two developers facing them. Also, disallow headphones or anyone to play music. Maybe also march up and down the aisles every once in awhile and encourage them.
Sleep your way to a whiter smile...date a dentist!
Amen to that. I once had someone removed from a project I worked on, because even after a week of explaining WHAT I wanted, it wasn't getting anywhere. I later worked on another project where they brought in a new programmer - lo and behold, the person I managed to get fired walked in. As it turned out, when given explicit instructions and a template, we got passable code. It just took a bit of time to set things up at first.
Personally, I'd not have hired that person in the first place, but when you lead a team that's been selected for you, you have to play the hand you're dealt.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
My take away from the OP is that it sounds like developers are like small children and the best managers need to be helicopter parents.
You got it wrong; some developers are like small children and need intense parenting, and the best developers thrive with only helicopter parenting.
> But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant...."
This is extremely meaningful and important if you have some experience, because a lot of managers (and devs!) seem to think that a process is a silver bullet. Things going wrong? Let's switch to another version of agile, that'll fix it!
You need a process, but if you have all good developers it doesn't matter what process you're using (they'll come up with some loose form of agile if you don't supply one... and source control, and release process, and build server, and...), and if you have bad developers it doesn't matter what process you're using either, it won't work. An official process gives you a framework for mediocre developers to hang on, and maybe learn something and become better developers, I've seen that happen too. But the people who /really/ care about which process are more interested in the process game and selling you training, consulting, and books than actually getting work done. Or they're managers who think it's a silver bullet.
Don't hire assholes.
If you have them on your team, replace them as soon as you can with people who are not assholes. Take your time during the hiring process to ensure you are not hiring them. Doesn't matter how great the talent is, don't let it tempt you in to hiring an asshole. No matter what you think, you cannot manage an asshole to not be an asshole.
I guarantee that if you look at all of the dysfunctional teams that have ever existed in software development, there was at least one asshole on that team. So if you want to be a better software development manager, get rid of the assholes.
The world moves for love. It kneels before it in awe.
If you're an MBA, remember that to everyone who works for you, that stands for "Moronic, Bullshitting Asshole".
I've seen plenty of of managers without an MBA degree fit that description. Some self-taught, some who had finished college, and some who had gone to grad school. And frankly, your post is suggesting you may be heading in that direction. You are also tossing a bit of BS.
I have to confess my opinions were once probably very similar to yours. And I had a couple of cherry picked examples in mind that matched my biased and uninformed opinion. Eventually I attended business school and one of the things I thoroughly enjoyed was seeing just how misinformed I had been. To my great surprise I was being taught to do things the "right way". For example that not all people are the same. That some perform better in one environment or using one methodology while others may perform better in a different environment or using a different methodology. That it was management's job to recognize what works best for each employee rather than try to pound each employee into the same mold.
Now do all MBAs do as they were taught, do they do the "right thing"? Certainly not. Its very much like what I see with Computer Science grads. We were all taught how to create working, reliable and maintainable software but when we enter industry some of us tend to ignore our lessons and start taking shortcuts and crap software results. Just like some MBAs ignore their lessons and start taking shortcuts and mismanagement results. MBAs are very much like CS grads in this regard. Taught how to do things right, but ego and time pressures lead them astray.
What is an MBA? The reality is that what comes out of business school is pretty much the same as what went in, good or bad. An MBA is *not* like other graduate degrees where you delve deeper into a particular field of study. An MBA is *not* about bean counting. An MBA is an overview of an organization. One gets overviews of accounting, finance, marketing, operations, strategy, organizational behavior (psychology, how people behave in groups, i.e. organizations, companies), consumer behavior, project management, product development, etc. One does not become an expert in any of these. Your area of expertise is whatever you brought to business school. In my class was about 1/3 were scientists and engineers.
So if one does not become an expert what's the point? The point is that with this overview of all these different areas you can now understand their wants and needs, their concerns. So you are still the same engineer you were before but now you are an engineer that can effectively communicate with the marketing people, the accounting people, etc. And the payoff is that you become more effective at getting the product requirements out of non-engineers, more effective at communicating the technical issues to non-engineers, you become more effective in persuading non-engineers to your side of an issue. You know how to frame things for the audience be it senior management, accounting, marketing, etc. And sometimes, you will realize that they have a legitimate non-engineering issue that trumps what you want.
An MBA is just like a degree in Computer Science. You are taught to be more effective, you are taught to do things the right way. However grads of both programs sometimes ignore their lessons, take shortcuts and these shortcuts screw projects and companies up.
If managers are going to do the work developers dislike, each team will need more managers. Also, hire senior managers to do the work that the managers dislike.
Some primadonna developers need to learn what it is to be a grown up in a grown up persons job. It is not the end of the world if once in a while you need to e.g. fill in a timesheet, create a presentation for a meeting, get your hands dirty setting up some infrastructure, or work on a feature you personally find unimportant. The rest of us also don't get to only do fun stuff we want.
Actually it does or a massive fuckup due to a newbie mistake lies in your future when you mess up a "but everyone knows that" situation that nobody thought to advise you about. Some understanding of the field saves you from that much even if you don't know the tricky stuff.
A classic example I saw was an Non Destructive Testing manager who spectacularly fucked up a major quote and resulted in the shut down of that part of a company because his newbie mistake was not understanding that you can't use industrial radiography equipment when there are a lot of people standing in the area where you want to use it. Thus his plan to work shifts 24/7 was not going to work because the client wanted to actually build stuff (a blast furnace) for most of the day. That's the one that got the section laid off halfway through the job, but there were other newbie mistakes that took the place from very profitable to shut down in less than a year. His previous experience was in sales in a different company but he was confident that he could manage, he even said something like "being a manager doesn't require technical knowledge" and expressed it as a virtue because he could "look at the big picture instead of the technical details". Maybe that works with someone willing to take advice, but flying blind is a different story.
Usually, industrial radiography equipment is fairly unforgiving to people who aren't willing to learn. Maybe leaving said manager alone with the equipment, just for a few minutes, would have resolved the issue.
I have mod points, but there are times when what I want to say is more nuanced than a mod point can convey.
That in this case being, thank you for sharing your experience. Primarily because I appreciate it when someone who "just loves to code" speaks up and shows how truly valuable he or she is.
Some people don't believe in fairies. I don't believe in The Patriarchy.
I guess I'm going to be that person that raises a hand and says this isn't a binary condition.
I'm smart and highly motivated. I'm a pretty good self-starter in an environment where things are well-structured. But I'm also a trifle scatter-brained and lose focus without decent structure in my environment (where everyone is expected to be a self-starter...yes, there are environments where this happens).
Maybe we'll be in disagreement and you'd think that the second is simply a case in poor management. Well, I agree there. You're probably a good manager and keep the chaos to a minimum, and you don't work in an environment where people are expected to produce projects from whole cloth. But I'd still argue that self-management works by degrees: you can have people who are good self-starters for projects but not programs. And you can have people that order the hell out of chaos at the program level, but readily admit they'd be lost at the nuts-and-bolts level.
Some people don't believe in fairies. I don't believe in The Patriarchy.
In HD, no less: Herding Cats
I've managed a very successful team for many years, and the one thing I don't do is their work for them. They need to do their work, in their own ways, and do it well. If they do, they don't see much of me. I attend most of the meetings (though I do occasionally have to bring one or two along for specific stuff), I do all the HR stuff, I go to the boring planning sessions, and I find out how our work is being received and chart courses for sustaining and improving on that work as needed.
I don't ask for status reports. I don't get in the way of standups. I don't pretend that I'm better at doing their job than they are. I am a facilitator for their work and I am a buffer between my team and other teams. I keep things nice and calm for them so they don't have to stress out or deal with having to interpret all the BS or do BS work. Then I do all the paperwork like the budget and the procurements and make sure our slide in the executive weekly tells the story of our awesomeness.
I listen to their complaints, other folks' complaints, and smooth that stuff out so that people can get back to work. If they need longer to get something done, I make room in the schedule and get new agreements with our customers on the new scope or timeline. If another group is in our way or not keeping up with us, I get with that group's manager and hammer out something we can all work with.
I've always been a very good technical generalist, but not as deep in individual stacks to do all the work. I am, however, a people person. I'm a damn good listener, negotiator and diplomat, and a very good business relationship manager and paper-pusher. Sometimes it sucks. Sometimes I have to have very difficult conversations with others. It's all part of the job.
What is most certainly NOT part of the job is me doing the engineering work. I trust them to get it done. They trust me to get them the time and resources to do it.
.. pa-ra-bo-la, pa-ra-bo-la, 2 pi R, 2 pi R, where's your latus rectum, where's your latus rectum, 2 pi R
https://en.wikipedia.org/wiki/...
Casteism
Managing all teams takes honesty, an ability to connect, balancing the needs of the organisation against the needs of the team and so on.
However, there are some specific things that developers require or value highly that other groups don't:
1) Objective decision-making.
Developers respond and react far better to a manager who engages with a problem objectively, applies reasoned logic to it and then explains the reasoning for the decision. Other groups respond well to "lead by example", "lead by inspiration" or "lead by authority/tenure", but developers tend not to accept these quite so readily as they do leadership from objective, reasoned assessment.
2) A recognition that coding is a unique blend of creative and technical effort.
Managing creative people often means taking a more "hands off" approach, to let their creativity be expressed in a way that you may not have chosen yourself. This is why people commission works of art and give a broad brief, but rarely do they define which medium to use, which colours, even what the subject or contents of the piece are. Many managers see developers as technical codemonkeys, turning requirements into code - but a good development manager realises that developers also need creative space.
3) Control of their environment.
Many people will simply accept whatever restrictions are placed on their work and happily work away within the confines they're given. Developers tend to want to control their environment (both physical and technical), so they demand more control, more access, better security privileges, to run their own tools and support systems and so on. While fighting for benefits for your team is the role of any manager, fighting for self-determination within the environment seems to be important to developers - and better, if they have control of the environment, they will own it and start tweaking every process and system wherever possible to maximise their efficiency.