Atlas · Details
(Not) Managing Software Developers
AI Notes
The headline promises tips, and Steve spends a fair chunk of the essay explaining why he mostly won't give any: cataloguing everything a tech manager can get wrong "would fill fat books," so what's on offer is three meta-tips — advice about finding your own mistakes. The good material lives in between. There's a taxonomy of suspect motives for wanting the job (mother hens who smother, process people whose process "can be used to disguise incompetence for an entire career," empire builders quietly lowering the hiring bar), a rude one-word label for the aspirant who mainly wants the pecking rights, and a blunt rule of self-assessment: if you don't know whether you're a bad manager, you're a bad manager, because that's the "start-state" for managers everywhere. And instead of the usual leadership-book fantasy, Steve aims the whole thing at the job most readers actually have: inheriting a roomful of miserable engineers on crufty legacy code, no new headcount, where leading anyone anywhere is strictly a long-term project.
Anyone arriving for actionable technique will leave hungry. Steve's method for acquiring the one trait he says everything else hinges on is to get a dog or cat ("preferably not a pit bull") and learn to love it, which is his way of conceding it can't be taught from a blog post. The concrete tips were deferred to a promised sequel, "How To Manage," that never materialized in the twenty years of writing since. What keeps the piece from being an anti-manager screed is that Steve puts himself in the lineup: after fifteen years of managing and "a hundred managers with a hundred different motivations" observed up close, every reason he has ever heard for wanting the job, his own included, now looks to him like a psychological problem waiting to land on some unlucky engineering team.
Related listings
-
2006
Good Agile, Bad Agile
The other 2006 piece on engineering culture and the management overhead bolted onto it — written four months later from the inside of the company this essay is talking around. Read together: the diagnosis, then the field notes.
-
2008
Done, and Gets Things Smart
Two years on, the hiring-side of the same conversation. (Not) Managing is about not destroying good engineers once you have them; Done, and Gets Things Smart is the bar to set when bringing them in.
-
2023
Death of the Junior Developer
Seventeen years later, the same instinct on a different decade. Both are pieces about the cultural and structural choices a company makes about its engineers — the long arc of Steve's writing on engineering culture.
From the peanut gallery
Read the rest of the thread · 31 more
-
Thanks for the insights. Im keen to hear why your company functions so effectively because their is less management overhead. What bad management is prevented by having no management?
-
Seriously, thanks a lot for taking the time to write about this subject. As a senior software engineering student, I'd also recommend students and preferably teachers to read this kind of information for further professional and personal improvement. I forgot where I've seen this written before, but I'll never forget it: "Managers will set goals for you, but leaders will help you to achieve them". Keep up the great writing!
-
Its interesting to read this as underlying theme fo this blog and secret sauce is EMPATHY to manage lead software engineers. Specially cos in my profesional experience SOFTWARE ENGINEERING professionals are the most UNEMPATHISING of all the professionals I have interacted with...
-
I think it is better to train software developers in fundamentals of politics.
How to become number one politician? -
Or worse...
"Empathy is believing everyone is like you." Which is a sure way to misunderstand the 99% (fake statistic;') of people who aren't like you. -
To "anonymous"... RTFA. Steve said empathy is believing that other people are pretty much like you in many ways, which is a far cry from "Everyone is like you"
-
I agree on the empathy statement. In a previous job, I managed a team of 12 developers/DBA/Sys admin in a dotcom operation. There was intense pressure and every day brought on a new challenge. One approach that I found to work well is to nurture a "team" environment not a manager/employee relationship. On many occassions, we had to be at the office at 3:00am to do upgrades/maintenance. I was the first one there with the coffee and doughnuts!! I also lobbied upper management for extra days off for staff who had to work during christmass and other holidays. One more thing. It really hels to recognize the work of your staff. I always sent company wide emails acknowledging the work of individuals especially if it was done under a lot of time/resource pressure. A simple email like that works wonders for the loyalty and chemistry of your team.
-
I just started to read... An eye-opener. Sounds like a description of my department. Right on the ball.
-
I've been managing software developers/programmers/engineers whatever for about 6 years now and I would concur with about 99% of this. No mangement is useless though 'cos most people will simply surf del.icio.us if left completely alone.
-
One modification that I would make is that this is not just for managers. It applies to everyone on the quality assurance team, too. (I am sure it applies to everyone, everywhere, but I only speak of what I know.) We all-to-often attack our developers—even if unintentionally, and if only from their point of view-over bug-ridden code and underperforming applications. Your advice will help everyone have a better understanding of everyone else. Empathy is all too uncommon in our world.
-
Truer words have never been spoken. It 's astonishing that most of the software managers fail to understand the need for empathy.
-
You may be interested in Peter Seebach’s Manager FAQ and Hacker FAQ.
-
Thank god we you wrote another blog entry I've been waiting all month.
-
There's at least one honest reason for wanting to manage development: It's the force multiplier. You have tasks you know how to accomplish. And the team doesn't. Marshalling your forces -- programming the people -- to accomplish those tasks gets you there faster than you could do yourself. The team won't mind you programming ^H^H^H^H^H^H^H^H^H^H^H leading them if they're really learning and accomplishing.
-
Brilliant! I wish you'd been born 20 years previously so I could have read that when I started "managing".
There seems to be confusion in the comments here between "empathy" and "sympathy" - Stevey's got it right, go look it up.
I would confess that I wanted to become a manager - but only to escape the crap managers and dysfunctional colleagues and actually get something achieved. Today I don't manage - I help lead my own small, brilliant, agency in Valencia, Spain. -
Hi Steve,
Do you think there are any situations in which developers can become managers without suspicious motives?
I wanted to become a manager. Does this mean I'm a megalomanic? I hope not, I completely understand the feeling that any one who wants to become a manager should not be allowed (same rule as for politicians).
I wanted to manage because I was just so sick of the previous management, they had no vision, motivation, basically they did nothing for the team. When they left it was a chance for improvement, to put into practice all the things we'd complained about for so long. -
I would argue that 'empathy' is just a form of 'respect' and respect is what subordinates really seek in their manager. My personal experience led me to believe that by respecting a person who works with you and making sure this respect is visible, you stand an excellent chance of achieving your goals (with him/her) and specifically managing properly.
-
You might want to check out http://randsinrepose.com - more technical management stuff.
-
"Managers will set goals for you, but leaders will help you to achieve them". - A very true quote.
"There's a difference between having to do versus wanting to do."
Love the donuts, as I used to do that for my team as well.
You will be surprise how a pat on the back or words of appreciation goes a long ways. -
The Oblivion blog was much better. Empathy doesn't work. Trying to be nice will get you fired or arrested. Leading, managing - they are just words. I prefer being managed then led, because I want to achieve goals on my own.
-
i just left the company that steve used to work for, & one of the reasons i left was because i just felt my manager didn't empathise with me. He was great at discussing with the management above, but he never asked me how i felt, what did i want, or how he could improve. It really pissed me off & I should have told him how I felt but I just gave up - decided it was best to leave (among other factors). Also, I don't think it helped that my manager was in a different country - not sure how much of it was cultural.
-
Great read, Steve. I'd also comment that your column is applicable to far more than just software development: I can see parallels for all sorts of other fields--some principles are pretty much universal. In fact, I'm forwarding it to my sales-rep wife, as your comments address concerns that we've both echoed throughout our professional throes.
If I must be managed, being managed by someone who encompasses your values is more pleasant than some of the situations in which I've found myself. -
we all miss your great management philosophies :) at least some of us are following in your footsteps. todd sent me your blog, and i am really glad you started it up again, you are a great writer!
-
Liked this one quite a lot.. [:)] neat tips.. will come back for more!
-
Check out this best practice for managing developers. http://home.austin.rr.com/eyasin/bpmanaging.htm Most of us will not agree with all his ideas but he does make some good points.
-
"I mean, I'm all in favor of MVC, but I think Common Sense and its kissing-cousin Conceptual Integrity will both tell you that M, V and C don't need to be three separate languages."
That's the best line I've heard in a while! You're great -- keep it up! -
Good piece and for people that would like to read more about Steve's rant, I would suggest picking up the book Unnatural Leadership: Ten New Leadership Insticts by Dotlich and Cairo.
-
Thank you, Steve. Once I was bad manager for some great engineers. I'll never become a great enineer myself. You're right - great engineers run things themselves, just add some empathy as a glue or lubricant. _But it is not necessary._ Great engineers achieve goals even without empathy from a manager's side.
-
Thanks a lot for blogging such a elaborate article.
-
I agree with most of your staements. You shoud check out this company that all came from a techincal backround and all became Loan Officers, Processors, Credit Repair Specialist, and developed there own management style with an HR dept and all the other departments that "Corporate" America musy have to survive. They were all $60 and $70k sofwatre engineers now millionaires! http://www.gfyenterprise.com/
-
Download software, Free software download : http://www.techsofts.com
Wow, there's absolutely nothing in there.
So, if I want to manage, I've already started wrong, and will probably be a bad manager, because it's all about leading.
Have empathy, whatever that is.
And what's leading? Too complex to explain.
Ok, so how can I not suck? Too complex to explain.
Google is great, but you can't explain.
How to manage engineers? Next post.
Absolutely 100% fat-free article. No meat at all.
— Anonymous · 6:21 AM, May 30, 2006
leadership is all well and good, and certainly necessary for inspiration, but the reality is that the stuff startups create with no process, etc., is viable for the life of the startup, but simply cannot achieve long-term success and scale without the discipline that good management imposes. That said, good managers are worth their weight in gold, and are about as rare.
In my book, the ultimate purposes of a manager are (1) to figure out what you need before you need it and make sure you have it, and (2) to give you honest feedback about what you're doing well and what you need to improve on. Anything else is just an obstruction.
A balanced process that accurately communicates what it is one is building -- so that all the folks involved with the product (development, qa, sales, marketing) understand what it is you're building and what it's supposed to do -- is vital to running an efficient company where people don't burn out. If a startup had a reasonable process, people wouldn't have to work insane hours to get something out that was good and sustainable. You'd only have to work 60 hrs/wk in order to get the thing done before the money ran out.
— Adam de Boor · 9:37 PM, August 05, 2006
oh hell, i was eager to read until i went to the line "they are not managing - they are leading".
Sounds so much like "it's not a unit (or group) - it's a team!". The word really doesn't make a difference - the content is. If you have met tons of bad people who call themselves managers, then you write stuff like this. On contrary, if you meet tons of bad managers who call them leaders, you will write the opposite.
— tm_lv · 2:39 PM, September 28, 2006