17 ms·

How to manage software developers without micromanaging

237 points by gk1 5y ago

peter303 5y ago
Lots of free doughnuts.
skeeter2020 5y ago
>> Asking a developer to report to a manager with no software development experience ... This is gonna big a big problem. The article focuses solely on the setup but IME you rarely have the luxury of starting from zero. What would be really helpful is telling me how I step into a role and start moving in the right direction, or what do I do when things go off the rails? Also, how could a manager without dev experience quantify peer review requirements, or validate key metrics and results?
ThalesX 5y ago
I wonder why I've never worked for a company where the managers shared a task board with us. If you plan on answering with a 'because our tasks are too hard to quantify' I would like to remind you that some people on this board implement hard to quantify things every day, so please make an effort to give realistic counter examples.
mythrwy 5y ago
I managed people for a long time (not software developers but think some of this transfers). At times well over 100 people with sub managers in some outfits. I did pretty well at it from a results perspective watching others who came before/after me. Here's some observations: -People are emotional creatures. They will behave irrationally much of the time without realizing it. Everything isn't logical game theory when the rubber meets the road. -People want to feel valued and not in a fake "You folks did a really good job" when everyone knows it isn't true way. They want to feel important and needed. It's something instinctive in the human psyche. You have to give people the space to become heros. Also you need people to feel what they are doing makes a difference to get the best out of them. -Most people will put out given the situation allows them to do so. Some people very simply will not. Don't tolerate those few people and don't let it get started. Nothing threatens a team's morality like those not pulling their weight with no consequences. Also if someone plain isn't happy in their situation (and everyone has bad days and even weeks) it's time for a change. Helping those people make that change when it's needed resolves friction both for them and the organization. -Ambiguity and complexity are mind killers. As a manager your job is to make the path forward simple and make sure the resources are available. People shouldn't have to doubt and guess much to do their jobs. That's your job. Fine grained and very clear tasks are best. -Humility is key. And honesty. Also a leader that wants to be followed is on the front lines with a sword. Not slacking off in comfort and showing up periodically to upbraid or threaten. Not throwing his team members under the bus. The leader is ultimately responsible and lack of results fall on their shoulders. -People have to feel fairly compensated and not taken advantage of to be "happily working". If these are missing in the org don't try to manage it, it's a shitshow revolving door and not somewhere you want to be. On the other hand money doesn't buy everything. People will do amazing things for reasons other then money. -People have an innate sense of fairness dating back to our earliest times. You can be strict in your expectations, and in fact must be to have quality results. But if you have uneven expectations or don't subject yourself to the same standards moral goes out the window in a hurry. Never "pick on" a person. Try your best not to favor people. Don't get cliquish. Employees are not your friends in this context. But do everything in your power to help people working under you. It's easier if you don't go out drinking etc. with your employees. Keep your relationship at a professional level. -A feeling of being a team is very powerful. Create this. But don't create a gang. It's not "us against upper management, other departments, irrational customers etc." The gang instinct is also powerful, and it can work for a bit, but it's a lie and ultimately harmful in the larger picture. Try to avoid negativity. There's a lot more I could write. People are much more complex then say, dogs, but there are general stimuli people respond to and they can be induced in not dissimilar manner. But at the end of the day they also need to eat. It's not about "tricking" people or even "training" people (you train plants, you teach people and "training seminars" is an utterly abhorrent term). It's a ton of work and stress effectively managing people. It made me very tired after some years and I just wanted to write code.
- wobbly_bush 5y ago
  > It's easier if you don't go out drinking etc. with your employees. Keep your relationship at a professional level. This topic is interesting to discuss, the book The Culture Map goes into detail about how different cultures handle relationship with colleagues differently. Apart from that, agree with you.
d--b 5y ago
Jeez, this article is all wrong, this sounds like cattle hoarding... I've worked with two good non-technical managers in my career. First thing is that they keep their measurements to themselves. You know they're tracking how fast bugs are resolved and these kinds of things, but they don't talk to you about it. Second is that they don't pressure you to finish things with stupid release cycles. Third is that even though they don't know how to program themselves, they should at least be interested in the content of what's being produced and how. Cause programmers aren't all good at the same things, and knowing what to do means that you understand who needs to do what. Fourth is they take the heat if shit's not in time or buggy. Fifth is they take the tasks they can do to make people happier. And Sixth is they can't micromanage cause they're not technical, so the whole premise of the article is moot, and in fact, they should micromanage as much as they're able to.
LAC-Tech 5y ago
My most eye opening leadership experience was last year. I was made tech lead of a small team, and asked to to accomplish something with a hard and somewhat unrealistic deadline. It was a success, but it had nothing to do with me being an incredibly inspirational leader. Or being a brilliant developer - I don't think I actually contributed any code. It honestly wasn't much to do with me at all. I basically just set the stage for them to work effectively: - I booted out all the non-coding people from our standup. The CIO in particular would waffle on, and it was draining everyones will to work (and possibly live). - I ruthlessly pared down requirements. We had some written specs, and whenever there was a question about which way we should go I chose the one that either didn't involve us doing anything, or was easiest. - I handled dealing with the stakeholders myself, and reported back to them the relevant info. The end result was that they were the first dev team to deliver something on time in the history of that company. No one had to work any over time (demo was Friday mid-day, so I got clearance for them to leave early). So yeah, the best project I ever lead, I barely 'lead'. I was a supporting player. I played interference. I made sure everyone left them the hell alone, that they had the information they needed, and told them that if it fucked up it was all my fault so relax (always blame the contractor). And and they pretty much did it all by themselves. Turns out developers can develop if you trust them and get out of their way.
- brightball 5y ago
  All true, but you did plenty. You got things out of their way. You made the call on trimming requirements when that normally would have resulted in scheduling a meeting to get approval. Bravo for that. Getting decisions made is one of the biggest hindrances to moving forward.
  - LAC-Tech 5y ago
    OK sure - I didn't do nothing. But let's be honest - what I did was nowhere near as difficult as actually developing software.
    - faangiq 5y ago
      On the contrary. Dealing with bullshitters is much more difficult than writing code.
rhizome 5y ago
I'm afraid that in a lot of cases, particularly with dollar-chasers in startups, this involves becoming a different person. Some people are just bad managers. It doesn't have to be that way, people can learn, but in any particular instance there can be the wrong specific person for any job that involves underlings at that stage of a company's growth, wherever it is. I'm not just talking about spergy devs getting Peter Principled into supervision, I mean founders/CxOs of any stripe. Extroverts, even! Citizenship and bedside manner can feel like disappearing arts sometimes.
bedobi 5y ago
> Meet sprint and release commitments consistently: Scrum blabla Aahhahha ok nonsense confirmed I've NEVER seen Scrum work, at any cadence, anywhere, ever, even in shops with good developers, BAs and PMs The list of reasons why is endless but usually boils down to vague requirements, (or clear requirements for what turns out to be the wrong thing, which is basically the same problem) and unrealistic expectations from stakeholders. Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. There's also the fact that bundling all changes over a whole week or two into a single giant release is more or less guaranteed to fail since even a small bug or problem means the whole release has to be rolled back. (even though there was nothing wrong with most of it) Contrast this to continuous releases where every small change is released independently all the time, where, if something breaks, you can likewise just roll back that single small change while letting everyone else carry on as they were and release their stuff whenever it's ready. I could go on
- kqr 5y ago
  > Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?" If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?" If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?" The discussions get much more productive this way. And I get more information about how valuable the different problems are.
Knuth69 5y ago
hizxy 5y ago
I question the value of management everyday.
FourthProtocol 5y ago
Get out of their way. Software developers know how to develop. Your job as manager is to remove any obstacles that keep developers from developing. And so you manage interfering people away from your project. You head off anything that might distract your developers. You remove ceremony, and you take the heat when "management" has issues with your team or anyone in it. You put your team front and centre, and step into the shadows when it's time to harvest the fame. You're like a bouncer at a nightclub door, protecting all who are within.
gyulai 5y ago
This article frames management as being quite an adversarial process, framing it as managers vs software engineering ICs. It seems to say that it's quite natural that as an SE manager you'd have no actual SE experience and that micromanagement is the ideal you'd naturally want to strive for. The problem being addressed is that you can't actually have that, because SEs will quit. So now you have to find a way around that problem. In my opinion: If you subscribe to all these premises, you don't need to read the rest of the article, because you've already lost.
js8 5y ago
I liked what my old boss did, it's quite traditional way of doing things. He gave us a long-term task/project (order of months) to work on, that would challenge us enough, by patiently explaining what has to be done. He gave us complete authority of how we want to do things that have to be done (the longer perspective of the work you have, the better you can get at optimizing yourself doing it). Then he made sure that we are making steady progress (about weekly, but could be shorter), and also made sure that all other external pressures go through him, so we wouldn't be distracted from that one goal too much. I think this is the best system, and I read the top comment and that's pretty similar. The article is not a particularly good advice, nor is "agile self-managing teams". IMHO management is not a rocket science, it's just people's intuitions about how to do it right are often very wrong.
- yvrev 5y ago
  I find this is the best for teams with competent developers. I have seen it abused however, which I guess is why micromanagement is popular in the first place.
  - js8 5y ago
    From what I saw, at least 90% of the people can work like that. They don't need to be particularly competent, unless by competent you mean "show up at work and do something". It really is a very flexible system as far as complexity and hand-holding on the tasks can go. Are you really gonna worry about 10% who are unable to learn to work in such a system? At some point, you will probably have to dismiss them anyway. I think the key point is to give people enough perspective (and stick to it if possible) so it makes sense for them to learn something in a bit of depth, new skill, new module, etc. (Sometimes "code ownership" can be good too - if you know you're gonna continue working on it in the future, you might as well do a better job now.) This is what micromanagement doesn't provide, in fact, it gets you used to the expectation of the opposite - there is no need and motivation to learn and study anything a bit deeper than to just accomplish the next small task. Micromanagement is literally motivating people not to grow, and not to think for themselves.
- astura 5y ago
xyzzy21 5y ago
This really depends on the type of programmer. A major cut is "packer" vs. "mapper". Often packers need more micromanagement and linear details of the plan; they can't "see the map" and run with that like a "mapper".
core-utility 5y ago
Nothing I've read in this article sounds more appealing than what I've dealt with in the past. Performance metrics at my recent careers have really become "Write what you did well in the last year aligning to these and we'll give you what we think you earn." It's a flawed system, but it's understood and doesn't get in the way all that much (especially when you start building templates year-after-year). Those who receive the highest performance rating are pretty well known by everyone, as are those who receive the lowest. Everyone else just wants to be left alone and will deal with this little bit of red tape to get by.
- commandlinefan 5y ago
  What I've always dealt with is "goal setting": at the beginning of the year, you're supposed to write down all the goals you're going to accomplish by the end of the year - usually five or so. The goals you write down are usually based on whatever random priorities are most visible during goal setting time (if you actually try to make up your own goals, your manager just tells you you have to change them before he'll sign off on them), but then priorities change, management demands you work on dozens of other things, so at the end of the year you write down some lame excuse for why you didn't accomplish any of the things nobody cares if you accomplish any more and if your manager likes you he rubber stamps it and if he doesn't like it he uses it as a stick to try to get rid of you.
  - naasking 5y ago
    Here's some goal setting: I shall endeavour to document how much monetary value I bring to the company and break it down as a dollar by the minute, then document how long it takes to fill in all of unnecessary the bureaucratic red tape so as to quantify their exact opportunity cost.
  - JonChesterfield 5y ago
    Try writing the goals for the year at the end of the year instead. Significantly more accurate.
    - 5y ago
TheGigaChad 5y ago
zwieback 5y ago
Surprisingly perceptive and useful tips, I think peer-review is something that's both underused and hard to get right. We all love to self-manage but SW development can be a bit insular and some feedback from peers, if they are respected, can really help.
- deleted 5y ago
  [deleted]
rchaves 5y ago
This article provides nothing new to me, my current company has it all and I don’t like Does anyone here actually feel personal goal setting as beneficial anyhow?
- Trasmatta 5y ago
  I hate goal setting. Goals plain don't work, except for maybe as a way to set your direction.
- DerArzt 5y ago
  It's beneficial to your manager in that they can tell you exactly what to write on your "personal goals list" and then string you up with those words come review time when they weren't met due to things out of your control and they will feel like the onus is on you for not delivering.
- openknot 5y ago
  >Does anyone here actually feel personal goal setting as beneficial anyhow? Personal goal setting has helped me a lot, though I haven't developed many personal goals at the request of a supervisor (they're created just for myself). The assumptions that make personal goal setting work are: i) Time and energy is limited, so I can't pursue all my interests at once. ii) If time isn't made for personal goals, they won't happen, as requests from other people (or unfocused activity) will occupy my attention. iii) By keeping goals in mind, it's easier to maintain boundaries on time, by politely declining certain tasks or opportunities to focus on my goals. This has helped with developing skills outside the workplace (which have indirectly helped with my work), as it provides clarity whenever there is uncertainty about how to spend time and energy when there isn't external structure. In a past workplace, I've set personal goals with a non-technical supervisor (e.g. suggestions to add features to a website). This helped with skill development and showed initiative that was appreciated, as the supervisor wouldn't have thought about these potential features (as their primary responsibilities weren't in development).
- wpietri 5y ago
  I don't. But I have found it useful to think about personal development in a kanban-like sense, with various queues and WIP limits. E.g. for physical/health stuff, I have a limit of 1 must-do change and 1 stretch-goal change. My stretch goal for December was moving back toward intermitting fasting. That went well, so my main goal for January was doing the intermittent fasting for real. That also went well, so my main February goal was about starting to train for an upcoming race. I have a whole backlog of physical/health goals that I could do. Having a WIP limit forces me to decide what's most important when a slot open up. That involves a bunch of thinking about goal-like things, but in a way that makes more sense to me. It also helps me balance desire with capacity; when I tried goal-setting outside of a kanban-like framework, it was easy for me to dream big and then crash when I couldn't hit the goals.
Oras 5y ago
Micromanagement is a behavior related to the obsession with being in control. I don’t think the article will change how they manage their teams. Not even sure if micromanagers identify it as an issue. A better title might be: how to improve your developers' performance.
irateswami 5y ago
Literally the way to "manage" developers is to enable them to do good work, and then get the hell out of their way. The git logs, uptime, and slack messages are all the records you need for evals.
- drblast 5y ago
  Or do away with performance reviews entirely. In my entire career I've never once seen a review cycle that was a net positive, and more often than not they cause the best performers who normally don't care about such things to become disgruntled and leave. As a manager they create perverse incentives especially if you have a high performing team (which you want to have) that all deserves a promotion but a limited budget. The incentive is to keep that low performer around so you have the budget to promote the others. It's a systematized way for management to shoot itself in the foot. But for whatever reason we think something must be wrong if we're not giving and getting report cards at the end of the year. Waste of time and counter-productive.
- beebeepka 5y ago
  Does that actually happen, though? Do managers have enough time to go through git commits, chats, etc. Sounds like a full-time job on its own
  - sdesol 5y ago
    Full disclosure: I'm trying to find a way to use development insights to help us develop software better, together. I tried a lot and I mean a lot of ways to see if we could use git commits to help us better understand productivity, but I've found commits by themselves lacks a lot of context. Especially since some commits may never be merged. What I've personally found so far, is that using pull requests is a very good way to help us understand development effort. By looking at pull requests, like the following for cockroach: https://oss.gitsense.com/insights/github?t=crc-insights&tb=all&v=cockroachdb%2Fcockroach%3A%3Agithub%3Acockroachdb%2Fcockroach%3A%3A%3A%3A https://oss.gitsense.com/insights/github?t=crc-insights&tb=a... it is much easier to grok what everybody is working on or has worked on. Having studied a lot of open source projects, it is kind of shocking how some developers can move and manage so much. As a side note, if you are wondering what the lightning bolt icon is for, it means another pull request is modifying a similar file. The left arrow means the pull request has a file that is not up to date with the target branch.
drewcoo 5y ago
Manage them with listicles! Everyone loves those. They solve every problem. Have a problem that seems complex and want to make sure you give a nod to everyone who matters but really just make a bunch of words and no cohesive strategy? Listicle it!
- commandlinefan 5y ago
  Whenever I'm presented with a problem that I don't have enough information to meaningfully estimate, a "helpful" manager suggests "breaking it down into subtasks". I usually end up breaking it down into tasks something like: 1) Figure out what's going on 2) Fix it
  - guavaNinja 5y ago
    It's ok to break it down iteratively, so after figuring it out you can get back to the list of subtasks and update them
golf_mike 5y ago
Interesting read, but it feels like a catch 22. Any organisation that is mature enough to practically implement stuff like [non-negotiable KPIs, quantified peer-reviews, mentoring programs, work-life goals, ...] seems like a place that does not need advice against micro-managing. The places that do need that advice are in my experience ill-equipped to practically implement such measures. In order to get an organisation to such a maturity level you need strong leadership that is sensitive to the changes needed and how to get their people to actually make those changes in a constructive and permanent way. So if an organisation needs changes like this, take a hard look at who lead you to the current state and ask yourself if it is worth the battle. Because chances are that without change in leadership (be it approach or replacing people) you will not be able to get the things in place mentioned in this article.
wpietri 5y ago
This is missing one of my biggest tools: establishing the right feedback loops. For example, there was a novel situation where we thought we might be able to do something for the internal team of experts that was handling it. So we paired one of their people up with one of the developers and said, "Take a few weeks and try out things that might help." That short feedback loop between need and solutions let them iterate through a variety of things to see what had the highest ROI. Or at the last company I co-founded, we started out by doing user-testing every Tuesday afternoon. My co-founder and I would try things and see how they worked on real users, iterating from there. Later, as we got more developers and enough users, we gradually built up a sophisticated set of tools for conducting experiments. Developers were closely involved in that work and we had a ship-early, ship-often approach that let people release something, see how it was working, and then adjust. I think of it sort of like game design. If you can structure things so that teams can develop a rewarding emotional connection via an overall purpose and frequent feedback, they'll just do the right thing naturally. Through that lens, the need for a lot of active bossing people around can sometimes be seen as a sign of bad management.
- JacobThreeThree 5y ago
  >If you can structure things so that teams can develop a rewarding emotional connection via an overall purpose and frequent feedback, they'll just do the right thing naturally. I love the idea of connecting developers with users as a way to motivate. Not everyone's job provides motivation intrinsically, and a big part of the manager's job is to motivate people in a genuine way.
  - wpietri 5y ago
    For sure! Most software has a purpose. If we can connect developers with that purpose they can be much more effective. There are a zillion ways I can build a feature. But if I learn about the business context and listen to the actual users, often the right choices become obvious.
sleepingadmin 5y ago
Micromanagement is a negative and is unhealthy. If you are being micromanaged, that's grounds for finding a new job instantly. Absolutely nothing to do with what industry you work in. Performance reviews is another bag. That is bag of issues. My last job, I got my first performance review. I was expecting a good raise. I was a leader of the team, people would come to me constantly looking for help with their issues. Out of a team of ~30 sysadmins, only 2 people(including me) had any networking skills. I was valueable. I was available afterhours regularly, I billed ~50-60 hour weeks. I worked on multiple teams for clients, I had many clients who wanted me exclusively. When a coworker ended up in a disaster, I was often dispatched to help in the situation. I often gave out kudos to my coworkers and thanked them for the good work they did. Positivity in MSP is so important because everything we deal with is negative. Something broke, someone ran a virus, etc. Went into my performance review. I got very poorly rated justifying no raise. So I went into it... why was I so poorly rated? I had over 40 lates to work. Except that wasn't true. I was often one of the first people into the building in the morning. So what gives? Oh, every time I worked a weekend and clocked in at say 10am to respond to an emergency... I was late to work. I had worked 40+ weekend days. So if I worked a saturday and sunday, I was late twice. When actually properly evaluated, I was late once and that was with pre-approval for a doctors appt. That wasn't all, my boss was under the impression that I had no friends there. That I was out of the office too much to build interpersonal relationships with coworkers. That there was 2 people who at the time were anonymous in that they didn't speak highly of me. Turns out... I was being harassed. I had one of my clients provide me a phone recording of my coworker badmouthing me pretty badly.
- kenferry 5y ago
  It's extremely strange that your boss could be so unaware, and honestly quite a red flag. Did they have 100 reports?
- Twisol 5y ago
  Did they formally update your performance rating? Did you end up getting the raise you were expecting, or did they give an excuse like "well all the raises have been allocated at this point"? The immediate situation sounds like it sucked enough, but if it had continuing ramifications, I'd be beside myself.
dbodin11 5y ago
[dead]
Waterluvian 5y ago
I’m gonna say something pedantic and perhaps obvious. You don’t manage people. If you do, you’re a bad manager. You manage problems and projects and enable people to do their jobs well. You facilitate conversations and make sure they have what info and tools they need. People are not robots you control. You are not better than them. You aren’t above them. In fact you’re usually far easier to replace than them. Maybe I have a chip on my shoulder but this is core to bad managers: they think their reports are their subjects to lord over.
- deleted 5y ago
  [deleted]
- senko 5y ago
  > You don’t manage people [...] You manage problems and projects and enable people to do their jobs well. This is, like, the definition of managing people. Let's call a spade a spade. > People are not robots you control. Control is not management. > they think their reports are their subjects to lord over. Bossing someone around is not management.
  - ThalesX 5y ago
    >> You don’t manage people [...] You manage problems and projects and enable people to do their jobs well. > This is, like, the definition of managing people. Let's call a spade a spade. That's not like. The definition of managing people. A project is some stakeholders (including the people you 'manage'), some wants, some resources (including the people you 'manage' as well as yourself) and some constraints. People are people. >> People are not robots you control. > Control is not management. What does this even mean? If control is not management, therefore people are not robots you (not) manage, so, are they robots you do manage? I think GP was sort of leaning towards the 'people are not robots' part of that. >> they think their reports are their subjects to lord over. > Bossing someone around is not management. It can be. If you're a shit manager. This 'is not management' thing feels very similar to 'is not Agile'.
- lmilcin 5y ago
  > You don’t manage people. If you do, you’re a bad manager. People are not spherical beings in vacuum. Of course, you have to manage people. My experience is that throwing projects at people and assuming that they are all interchangeable cogs that will be able to complete projects if they fit the project is just asking for problems. Now, managing people does not have to be tantamount to standing there and pointing with your finger what they have to be doing next. "If you do, you're a bad manager." But there are other more subtle ways of managing people and learning to be a manager means learning to be able to influence people to do what you want them to be doing as much as learning what they should be doing.
chiefalchemist 5y ago
> One way to strike a balance is to work with human resources on defining work-life goals and objectives. Pardon me if this sounds nitpicky but let's stop calling it human resources. Those two words establish the wrong precedent and perpetuate the wrong message. If you treat people like resources you're going in the wrong direction.
synergy20 5y ago
is it still 20% of the people doing 80% the work in software projects? if so finding those 20% and rewarding them accordingly. give them a raise, assign them stock options, make them feel appreciated and financially tied with the company. this should be more effective than micro-management. in my book, management is basically trying to use the least money to get the most out of employees, if instead reward people based on their measurable finished items(e.g. work got done on time), most of the management tricks go away on its own, they will manage themselves better than you can ever do.
- quickthrower2 5y ago
  My objection to this is someone's contribution is a factor of culture / role / assignments and person. You could have a great person who's had to do some low-impact work (someone has to fix those bugs!), finds themselves in the 80% and then realises it (they will), and self-selects out of the company. You don't want to lose such people. The trick is to bring out the best talent in everyone in my opinion.
  - synergy20 5y ago
    Those who do testing/bugfixes could be the 20% too. Yes they probably will be paid less then core developers but they're still the 20% to keep and get rewarded. I would say for each job category, reward their top 20% more and do your best to keep them.
    - quickthrower2 5y ago
      You might work for much bigger companies than I have, but there is no 'bug fixing' vs. 'core' job categories. Instead it's like "Susan worked in that area once last year, the expert has left, so Susan can fix it, while the feature work she was on gets postponed a bit".
      - synergy20 5y ago
        not really, doing startup now actually but yes I worked in big companies in the past. the point is to find those gems and reward them and keep them, they deserve it and they're the true core of the company as well.
paulio 5y ago
> Ask developers to propose work-life goals and objectives I think I'd just hand my notice in. If that was ever asked of me. The whole article feels way over the top and honestly suffocating. Most people I work with struggle through the usual set of goals/targets every year and hate every minute of it. People are complex and have a wide variety of skills, treating people like this isn't motivational and you'll find good people moving elsewhere.
- Trasmatta 5y ago
  My anxiety levels literally started rising when I read that line. It's another example of developers being infantalized, instead of treating them as highly trained professionals.

237 points by gk1 5y ago

Lots of free doughnuts.

skeeter2020 5y ago

>> Asking a developer to report to a manager with no software development experience ... This is gonna big a big problem. The article focuses solely on the setup but IME you rarely have the luxury of starting from zero. What would be really helpful is telling me how I step into a role and start moving in the right direction, or what do I do when things go off the rails? Also, how could a manager without dev experience quantify peer review requirements, or validate key metrics and results?

ThalesX 5y ago

I wonder why I've never worked for a company where the managers shared a task board with us. If you plan on answering with a 'because our tasks are too hard to quantify' I would like to remind you that some people on this board implement hard to quantify things every day, so please make an effort to give realistic counter examples.

mythrwy 5y ago

I managed people for a long time (not software developers but think some of this transfers). At times well over 100 people with sub managers in some outfits. I did pretty well at it from a results perspective watching others who came before/after me. Here's some observations: -People are emotional creatures. They will behave irrationally much of the time without realizing it. Everything isn't logical game theory when the rubber meets the road. -People want to feel valued and not in a fake "You folks did a really good job" when everyone knows it isn't true way. They want to feel important and needed. It's something instinctive in the human psyche. You have to give people the space to become heros. Also you need people to feel what they are doing makes a difference to get the best out of them. -Most people will put out given the situation allows them to do so. Some people very simply will not. Don't tolerate those few people and don't let it get started. Nothing threatens a team's morality like those not pulling their weight with no consequences. Also if someone plain isn't happy in their situation (and everyone has bad days and even weeks) it's time for a change. Helping those people make that change when it's needed resolves friction both for them and the organization. -Ambiguity and complexity are mind killers. As a manager your job is to make the path forward simple and make sure the resources are available. People shouldn't have to doubt and guess much to do their jobs. That's your job. Fine grained and very clear tasks are best. -Humility is key. And honesty. Also a leader that wants to be followed is on the front lines with a sword. Not slacking off in comfort and showing up periodically to upbraid or threaten. Not throwing his team members under the bus. The leader is ultimately responsible and lack of results fall on their shoulders. -People have to feel fairly compensated and not taken advantage of to be "happily working". If these are missing in the org don't try to manage it, it's a shitshow revolving door and not somewhere you want to be. On the other hand money doesn't buy everything. People will do amazing things for reasons other then money. -People have an innate sense of fairness dating back to our earliest times. You can be strict in your expectations, and in fact must be to have quality results. But if you have uneven expectations or don't subject yourself to the same standards moral goes out the window in a hurry. Never "pick on" a person. Try your best not to favor people. Don't get cliquish. Employees are not your friends in this context. But do everything in your power to help people working under you. It's easier if you don't go out drinking etc. with your employees. Keep your relationship at a professional level. -A feeling of being a team is very powerful. Create this. But don't create a gang. It's not "us against upper management, other departments, irrational customers etc." The gang instinct is also powerful, and it can work for a bit, but it's a lie and ultimately harmful in the larger picture. Try to avoid negativity. There's a lot more I could write. People are much more complex then say, dogs, but there are general stimuli people respond to and they can be induced in not dissimilar manner. But at the end of the day they also need to eat. It's not about "tricking" people or even "training" people (you train plants, you teach people and "training seminars" is an utterly abhorrent term). It's a ton of work and stress effectively managing people. It made me very tired after some years and I just wanted to write code.

wobbly_bush 5y ago
> It's easier if you don't go out drinking etc. with your employees. Keep your relationship at a professional level. This topic is interesting to discuss, the book The Culture Map goes into detail about how different cultures handle relationship with colleagues differently. Apart from that, agree with you.

d--b 5y ago

Jeez, this article is all wrong, this sounds like cattle hoarding... I've worked with two good non-technical managers in my career. First thing is that they keep their measurements to themselves. You know they're tracking how fast bugs are resolved and these kinds of things, but they don't talk to you about it. Second is that they don't pressure you to finish things with stupid release cycles. Third is that even though they don't know how to program themselves, they should at least be interested in the content of what's being produced and how. Cause programmers aren't all good at the same things, and knowing what to do means that you understand who needs to do what. Fourth is they take the heat if shit's not in time or buggy. Fifth is they take the tasks they can do to make people happier. And Sixth is they can't micromanage cause they're not technical, so the whole premise of the article is moot, and in fact, they should micromanage as much as they're able to.

LAC-Tech 5y ago

My most eye opening leadership experience was last year. I was made tech lead of a small team, and asked to to accomplish something with a hard and somewhat unrealistic deadline. It was a success, but it had nothing to do with me being an incredibly inspirational leader. Or being a brilliant developer - I don't think I actually contributed any code. It honestly wasn't much to do with me at all. I basically just set the stage for them to work effectively: - I booted out all the non-coding people from our standup. The CIO in particular would waffle on, and it was draining everyones will to work (and possibly live). - I ruthlessly pared down requirements. We had some written specs, and whenever there was a question about which way we should go I chose the one that either didn't involve us doing anything, or was easiest. - I handled dealing with the stakeholders myself, and reported back to them the relevant info. The end result was that they were the first dev team to deliver something on time in the history of that company. No one had to work any over time (demo was Friday mid-day, so I got clearance for them to leave early). So yeah, the best project I ever lead, I barely 'lead'. I was a supporting player. I played interference. I made sure everyone left them the hell alone, that they had the information they needed, and told them that if it fucked up it was all my fault so relax (always blame the contractor). And and they pretty much did it all by themselves. Turns out developers can develop if you trust them and get out of their way.

brightball 5y ago
All true, but you did plenty. You got things out of their way. You made the call on trimming requirements when that normally would have resulted in scheduling a meeting to get approval. Bravo for that. Getting decisions made is one of the biggest hindrances to moving forward.
- LAC-Tech 5y ago
  OK sure - I didn't do nothing. But let's be honest - what I did was nowhere near as difficult as actually developing software.
  - faangiq 5y ago
    On the contrary. Dealing with bullshitters is much more difficult than writing code.

rhizome 5y ago

I'm afraid that in a lot of cases, particularly with dollar-chasers in startups, this involves becoming a different person. Some people are just bad managers. It doesn't have to be that way, people can learn, but in any particular instance there can be the wrong specific person for any job that involves underlings at that stage of a company's growth, wherever it is. I'm not just talking about spergy devs getting Peter Principled into supervision, I mean founders/CxOs of any stripe. Extroverts, even! Citizenship and bedside manner can feel like disappearing arts sometimes.

bedobi 5y ago

> Meet sprint and release commitments consistently: Scrum blabla Aahhahha ok nonsense confirmed I've NEVER seen Scrum work, at any cadence, anywhere, ever, even in shops with good developers, BAs and PMs The list of reasons why is endless but usually boils down to vague requirements, (or clear requirements for what turns out to be the wrong thing, which is basically the same problem) and unrealistic expectations from stakeholders. Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. There's also the fact that bundling all changes over a whole week or two into a single giant release is more or less guaranteed to fail since even a small bug or problem means the whole release has to be rolled back. (even though there was nothing wrong with most of it) Contrast this to continuous releases where every small change is released independently all the time, where, if something breaks, you can likewise just roll back that single small change while letting everyone else carry on as they were and release their stuff whenever it's ready. I could go on

kqr 5y ago
> Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?" If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?" If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?" The discussions get much more productive this way. And I get more information about how valuable the different problems are.

Knuth69 5y ago

hizxy 5y ago

I question the value of management everyday.

FourthProtocol 5y ago

Get out of their way. Software developers know how to develop. Your job as manager is to remove any obstacles that keep developers from developing. And so you manage interfering people away from your project. You head off anything that might distract your developers. You remove ceremony, and you take the heat when "management" has issues with your team or anyone in it. You put your team front and centre, and step into the shadows when it's time to harvest the fame. You're like a bouncer at a nightclub door, protecting all who are within.

gyulai 5y ago

This article frames management as being quite an adversarial process, framing it as managers vs software engineering ICs. It seems to say that it's quite natural that as an SE manager you'd have no actual SE experience and that micromanagement is the ideal you'd naturally want to strive for. The problem being addressed is that you can't actually have that, because SEs will quit. So now you have to find a way around that problem. In my opinion: If you subscribe to all these premises, you don't need to read the rest of the article, because you've already lost.

js8 5y ago

I liked what my old boss did, it's quite traditional way of doing things. He gave us a long-term task/project (order of months) to work on, that would challenge us enough, by patiently explaining what has to be done. He gave us complete authority of how we want to do things that have to be done (the longer perspective of the work you have, the better you can get at optimizing yourself doing it). Then he made sure that we are making steady progress (about weekly, but could be shorter), and also made sure that all other external pressures go through him, so we wouldn't be distracted from that one goal too much. I think this is the best system, and I read the top comment and that's pretty similar. The article is not a particularly good advice, nor is "agile self-managing teams". IMHO management is not a rocket science, it's just people's intuitions about how to do it right are often very wrong.

yvrev 5y ago
I find this is the best for teams with competent developers. I have seen it abused however, which I guess is why micromanagement is popular in the first place.
- js8 5y ago
  From what I saw, at least 90% of the people can work like that. They don't need to be particularly competent, unless by competent you mean "show up at work and do something". It really is a very flexible system as far as complexity and hand-holding on the tasks can go. Are you really gonna worry about 10% who are unable to learn to work in such a system? At some point, you will probably have to dismiss them anyway. I think the key point is to give people enough perspective (and stick to it if possible) so it makes sense for them to learn something in a bit of depth, new skill, new module, etc. (Sometimes "code ownership" can be good too - if you know you're gonna continue working on it in the future, you might as well do a better job now.) This is what micromanagement doesn't provide, in fact, it gets you used to the expectation of the opposite - there is no need and motivation to learn and study anything a bit deeper than to just accomplish the next small task. Micromanagement is literally motivating people not to grow, and not to think for themselves.
astura 5y ago

xyzzy21 5y ago

This really depends on the type of programmer. A major cut is "packer" vs. "mapper". Often packers need more micromanagement and linear details of the plan; they can't "see the map" and run with that like a "mapper".

core-utility 5y ago

Nothing I've read in this article sounds more appealing than what I've dealt with in the past. Performance metrics at my recent careers have really become "Write what you did well in the last year aligning to these and we'll give you what we think you earn." It's a flawed system, but it's understood and doesn't get in the way all that much (especially when you start building templates year-after-year). Those who receive the highest performance rating are pretty well known by everyone, as are those who receive the lowest. Everyone else just wants to be left alone and will deal with this little bit of red tape to get by.

commandlinefan 5y ago
What I've always dealt with is "goal setting": at the beginning of the year, you're supposed to write down all the goals you're going to accomplish by the end of the year - usually five or so. The goals you write down are usually based on whatever random priorities are most visible during goal setting time (if you actually try to make up your own goals, your manager just tells you you have to change them before he'll sign off on them), but then priorities change, management demands you work on dozens of other things, so at the end of the year you write down some lame excuse for why you didn't accomplish any of the things nobody cares if you accomplish any more and if your manager likes you he rubber stamps it and if he doesn't like it he uses it as a stick to try to get rid of you.
- naasking 5y ago
  Here's some goal setting: I shall endeavour to document how much monetary value I bring to the company and break it down as a dollar by the minute, then document how long it takes to fill in all of unnecessary the bureaucratic red tape so as to quantify their exact opportunity cost.
- JonChesterfield 5y ago
  Try writing the goals for the year at the end of the year instead. Significantly more accurate.
  - 5y ago

TheGigaChad 5y ago

zwieback 5y ago

Surprisingly perceptive and useful tips, I think peer-review is something that's both underused and hard to get right. We all love to self-manage but SW development can be a bit insular and some feedback from peers, if they are respected, can really help.

deleted 5y ago
[deleted]

rchaves 5y ago

This article provides nothing new to me, my current company has it all and I don’t like Does anyone here actually feel personal goal setting as beneficial anyhow?

Trasmatta 5y ago
I hate goal setting. Goals plain don't work, except for maybe as a way to set your direction.
DerArzt 5y ago
It's beneficial to your manager in that they can tell you exactly what to write on your "personal goals list" and then string you up with those words come review time when they weren't met due to things out of your control and they will feel like the onus is on you for not delivering.
openknot 5y ago
>Does anyone here actually feel personal goal setting as beneficial anyhow? Personal goal setting has helped me a lot, though I haven't developed many personal goals at the request of a supervisor (they're created just for myself). The assumptions that make personal goal setting work are: i) Time and energy is limited, so I can't pursue all my interests at once. ii) If time isn't made for personal goals, they won't happen, as requests from other people (or unfocused activity) will occupy my attention. iii) By keeping goals in mind, it's easier to maintain boundaries on time, by politely declining certain tasks or opportunities to focus on my goals. This has helped with developing skills outside the workplace (which have indirectly helped with my work), as it provides clarity whenever there is uncertainty about how to spend time and energy when there isn't external structure. In a past workplace, I've set personal goals with a non-technical supervisor (e.g. suggestions to add features to a website). This helped with skill development and showed initiative that was appreciated, as the supervisor wouldn't have thought about these potential features (as their primary responsibilities weren't in development).
wpietri 5y ago
I don't. But I have found it useful to think about personal development in a kanban-like sense, with various queues and WIP limits. E.g. for physical/health stuff, I have a limit of 1 must-do change and 1 stretch-goal change. My stretch goal for December was moving back toward intermitting fasting. That went well, so my main goal for January was doing the intermittent fasting for real. That also went well, so my main February goal was about starting to train for an upcoming race. I have a whole backlog of physical/health goals that I could do. Having a WIP limit forces me to decide what's most important when a slot open up. That involves a bunch of thinking about goal-like things, but in a way that makes more sense to me. It also helps me balance desire with capacity; when I tried goal-setting outside of a kanban-like framework, it was easy for me to dream big and then crash when I couldn't hit the goals.

Oras 5y ago

Micromanagement is a behavior related to the obsession with being in control. I don’t think the article will change how they manage their teams. Not even sure if micromanagers identify it as an issue. A better title might be: how to improve your developers' performance.

irateswami 5y ago

Literally the way to "manage" developers is to enable them to do good work, and then get the hell out of their way. The git logs, uptime, and slack messages are all the records you need for evals.

drblast 5y ago
Or do away with performance reviews entirely. In my entire career I've never once seen a review cycle that was a net positive, and more often than not they cause the best performers who normally don't care about such things to become disgruntled and leave. As a manager they create perverse incentives especially if you have a high performing team (which you want to have) that all deserves a promotion but a limited budget. The incentive is to keep that low performer around so you have the budget to promote the others. It's a systematized way for management to shoot itself in the foot. But for whatever reason we think something must be wrong if we're not giving and getting report cards at the end of the year. Waste of time and counter-productive.
beebeepka 5y ago
Does that actually happen, though? Do managers have enough time to go through git commits, chats, etc. Sounds like a full-time job on its own
- sdesol 5y ago
  Full disclosure: I'm trying to find a way to use development insights to help us develop software better, together. I tried a lot and I mean a lot of ways to see if we could use git commits to help us better understand productivity, but I've found commits by themselves lacks a lot of context. Especially since some commits may never be merged. What I've personally found so far, is that using pull requests is a very good way to help us understand development effort. By looking at pull requests, like the following for cockroach: https://oss.gitsense.com/insights/github?t=crc-insights&tb=all&v=cockroachdb%2Fcockroach%3A%3Agithub%3Acockroachdb%2Fcockroach%3A%3A%3A%3A https://oss.gitsense.com/insights/github?t=crc-insights&tb=a... it is much easier to grok what everybody is working on or has worked on. Having studied a lot of open source projects, it is kind of shocking how some developers can move and manage so much. As a side note, if you are wondering what the lightning bolt icon is for, it means another pull request is modifying a similar file. The left arrow means the pull request has a file that is not up to date with the target branch.

drewcoo 5y ago

Manage them with listicles! Everyone loves those. They solve every problem. Have a problem that seems complex and want to make sure you give a nod to everyone who matters but really just make a bunch of words and no cohesive strategy? Listicle it!

commandlinefan 5y ago
Whenever I'm presented with a problem that I don't have enough information to meaningfully estimate, a "helpful" manager suggests "breaking it down into subtasks". I usually end up breaking it down into tasks something like: 1) Figure out what's going on 2) Fix it
- guavaNinja 5y ago
  It's ok to break it down iteratively, so after figuring it out you can get back to the list of subtasks and update them

golf_mike 5y ago

Interesting read, but it feels like a catch 22. Any organisation that is mature enough to practically implement stuff like [non-negotiable KPIs, quantified peer-reviews, mentoring programs, work-life goals, ...] seems like a place that does not need advice against micro-managing. The places that do need that advice are in my experience ill-equipped to practically implement such measures. In order to get an organisation to such a maturity level you need strong leadership that is sensitive to the changes needed and how to get their people to actually make those changes in a constructive and permanent way. So if an organisation needs changes like this, take a hard look at who lead you to the current state and ask yourself if it is worth the battle. Because chances are that without change in leadership (be it approach or replacing people) you will not be able to get the things in place mentioned in this article.

wpietri 5y ago

This is missing one of my biggest tools: establishing the right feedback loops. For example, there was a novel situation where we thought we might be able to do something for the internal team of experts that was handling it. So we paired one of their people up with one of the developers and said, "Take a few weeks and try out things that might help." That short feedback loop between need and solutions let them iterate through a variety of things to see what had the highest ROI. Or at the last company I co-founded, we started out by doing user-testing every Tuesday afternoon. My co-founder and I would try things and see how they worked on real users, iterating from there. Later, as we got more developers and enough users, we gradually built up a sophisticated set of tools for conducting experiments. Developers were closely involved in that work and we had a ship-early, ship-often approach that let people release something, see how it was working, and then adjust. I think of it sort of like game design. If you can structure things so that teams can develop a rewarding emotional connection via an overall purpose and frequent feedback, they'll just do the right thing naturally. Through that lens, the need for a lot of active bossing people around can sometimes be seen as a sign of bad management.

JacobThreeThree 5y ago
>If you can structure things so that teams can develop a rewarding emotional connection via an overall purpose and frequent feedback, they'll just do the right thing naturally. I love the idea of connecting developers with users as a way to motivate. Not everyone's job provides motivation intrinsically, and a big part of the manager's job is to motivate people in a genuine way.
- wpietri 5y ago
  For sure! Most software has a purpose. If we can connect developers with that purpose they can be much more effective. There are a zillion ways I can build a feature. But if I learn about the business context and listen to the actual users, often the right choices become obvious.

sleepingadmin 5y ago

Micromanagement is a negative and is unhealthy. If you are being micromanaged, that's grounds for finding a new job instantly. Absolutely nothing to do with what industry you work in. Performance reviews is another bag. That is bag of issues. My last job, I got my first performance review. I was expecting a good raise. I was a leader of the team, people would come to me constantly looking for help with their issues. Out of a team of ~30 sysadmins, only 2 people(including me) had any networking skills. I was valueable. I was available afterhours regularly, I billed ~50-60 hour weeks. I worked on multiple teams for clients, I had many clients who wanted me exclusively. When a coworker ended up in a disaster, I was often dispatched to help in the situation. I often gave out kudos to my coworkers and thanked them for the good work they did. Positivity in MSP is so important because everything we deal with is negative. Something broke, someone ran a virus, etc. Went into my performance review. I got very poorly rated justifying no raise. So I went into it... why was I so poorly rated? I had over 40 lates to work. Except that wasn't true. I was often one of the first people into the building in the morning. So what gives? Oh, every time I worked a weekend and clocked in at say 10am to respond to an emergency... I was late to work. I had worked 40+ weekend days. So if I worked a saturday and sunday, I was late twice. When actually properly evaluated, I was late once and that was with pre-approval for a doctors appt. That wasn't all, my boss was under the impression that I had no friends there. That I was out of the office too much to build interpersonal relationships with coworkers. That there was 2 people who at the time were anonymous in that they didn't speak highly of me. Turns out... I was being harassed. I had one of my clients provide me a phone recording of my coworker badmouthing me pretty badly.

kenferry 5y ago
It's extremely strange that your boss could be so unaware, and honestly quite a red flag. Did they have 100 reports?
Twisol 5y ago
Did they formally update your performance rating? Did you end up getting the raise you were expecting, or did they give an excuse like "well all the raises have been allocated at this point"? The immediate situation sounds like it sucked enough, but if it had continuing ramifications, I'd be beside myself.

dbodin11 5y ago

[dead]

Waterluvian 5y ago

I’m gonna say something pedantic and perhaps obvious. You don’t manage people. If you do, you’re a bad manager. You manage problems and projects and enable people to do their jobs well. You facilitate conversations and make sure they have what info and tools they need. People are not robots you control. You are not better than them. You aren’t above them. In fact you’re usually far easier to replace than them. Maybe I have a chip on my shoulder but this is core to bad managers: they think their reports are their subjects to lord over.

deleted 5y ago
[deleted]
senko 5y ago
> You don’t manage people [...] You manage problems and projects and enable people to do their jobs well. This is, like, the definition of managing people. Let's call a spade a spade. > People are not robots you control. Control is not management. > they think their reports are their subjects to lord over. Bossing someone around is not management.
- ThalesX 5y ago
  >> You don’t manage people [...] You manage problems and projects and enable people to do their jobs well. > This is, like, the definition of managing people. Let's call a spade a spade. That's not like. The definition of managing people. A project is some stakeholders (including the people you 'manage'), some wants, some resources (including the people you 'manage' as well as yourself) and some constraints. People are people. >> People are not robots you control. > Control is not management. What does this even mean? If control is not management, therefore people are not robots you (not) manage, so, are they robots you do manage? I think GP was sort of leaning towards the 'people are not robots' part of that. >> they think their reports are their subjects to lord over. > Bossing someone around is not management. It can be. If you're a shit manager. This 'is not management' thing feels very similar to 'is not Agile'.
lmilcin 5y ago
> You don’t manage people. If you do, you’re a bad manager. People are not spherical beings in vacuum. Of course, you have to manage people. My experience is that throwing projects at people and assuming that they are all interchangeable cogs that will be able to complete projects if they fit the project is just asking for problems. Now, managing people does not have to be tantamount to standing there and pointing with your finger what they have to be doing next. "If you do, you're a bad manager." But there are other more subtle ways of managing people and learning to be a manager means learning to be able to influence people to do what you want them to be doing as much as learning what they should be doing.

chiefalchemist 5y ago

> One way to strike a balance is to work with human resources on defining work-life goals and objectives. Pardon me if this sounds nitpicky but let's stop calling it human resources. Those two words establish the wrong precedent and perpetuate the wrong message. If you treat people like resources you're going in the wrong direction.

synergy20 5y ago

is it still 20% of the people doing 80% the work in software projects? if so finding those 20% and rewarding them accordingly. give them a raise, assign them stock options, make them feel appreciated and financially tied with the company. this should be more effective than micro-management. in my book, management is basically trying to use the least money to get the most out of employees, if instead reward people based on their measurable finished items(e.g. work got done on time), most of the management tricks go away on its own, they will manage themselves better than you can ever do.

quickthrower2 5y ago
My objection to this is someone's contribution is a factor of culture / role / assignments and person. You could have a great person who's had to do some low-impact work (someone has to fix those bugs!), finds themselves in the 80% and then realises it (they will), and self-selects out of the company. You don't want to lose such people. The trick is to bring out the best talent in everyone in my opinion.
- synergy20 5y ago
  Those who do testing/bugfixes could be the 20% too. Yes they probably will be paid less then core developers but they're still the 20% to keep and get rewarded. I would say for each job category, reward their top 20% more and do your best to keep them.
  - quickthrower2 5y ago
    You might work for much bigger companies than I have, but there is no 'bug fixing' vs. 'core' job categories. Instead it's like "Susan worked in that area once last year, the expert has left, so Susan can fix it, while the feature work she was on gets postponed a bit".
    - synergy20 5y ago
      not really, doing startup now actually but yes I worked in big companies in the past. the point is to find those gems and reward them and keep them, they deserve it and they're the true core of the company as well.

paulio 5y ago

> Ask developers to propose work-life goals and objectives I think I'd just hand my notice in. If that was ever asked of me. The whole article feels way over the top and honestly suffocating. Most people I work with struggle through the usual set of goals/targets every year and hate every minute of it. People are complex and have a wide variety of skills, treating people like this isn't motivational and you'll find good people moving elsewhere.

Trasmatta 5y ago
My anxiety levels literally started rising when I read that line. It's another example of developers being infantalized, instead of treating them as highly trained professionals.