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.
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.
That depends on the political environment, you still had to get the CIO to accept being booted out of the stand-up, the stakeholders to accept you deciding on the requirements and so on. Sometimes it's relatively easy, sometimes it's impossible.
Yep, he had the balls to stand up for the team, and to get away with that the organisation has to be very pragmatic and reasonable, which is not always the case..
Hmm. Maybe I'm just a mediocre maintenance dev but a decent tech lead. I went back to being a dev afterwards, and I was shocked by how much harder I found it.
I'll say one mistake is to have a tech lead that spends most of their time coding. I don't know how you can do everything else effectively if the company still relies on you to deliver code.
I'm facing this right now, but I enjoy coding so much more. It's a hard choice, but I'm leaning towards going back to coding full time. Worse career choice, but better for my sanity, I think.
A possible explanation is that leading a team effectively isn't necessarily more difficult, but rather that it might be less pleasant and/or less financially advantageous than being either an individual contributor or an ineffective team leader.
In my experience, it's way harder to find good managers than it is finding good developers. Maybe I've just seen a bunch of talented devs and outright terrible managers, but that's my data point.
What you're describing is leadership, just not the popular style. To put terms to it, you weren't doing Taylorist command and control, you were doing servant leadership.
In my opinion, yours is the only sane way to lead. With command and control, all you would be doing is creating the illusion of control, providing no actual added value. If your leadership style is adversarial, you're stimulating your employees to see you as a liability.
Totally concur with the other comments here - you were a great leader. The problem with “leadership” as a concept is that many people think it’s an active thing - pushing people to work harder and forcing your opinions into them. But that doesn’t work. Get out of their way and they’ll work out the most efficient way to get there.
Antoine de Saint-Exupéry said, “If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea“
I agree, in principle, but I think not only was he a good leader, he also was lucky to have good team members (which probably also became better team members from the trust and respect that his leadership got them). But a large percentage of people simply don't function when they are trusted and left alone, so it's up to someone to make a leap of faith, and not take the "safer" path of command and control. And when your livelihood is on the line, most people don't want to take any risk.
I don’t really agree with “a large percentage”, but yeah it happens, and identifying these people is part of being a manager, right? Everyone on the team needs to pull together, and we need to ask non performers to leave.
I don’t think there’s any real evidence that “command and control” is actually safer - the world is full of failed software projects - but I agree that it’s perceived to be safer, and the rest follows on from there I guess.
IMHO, the core epiphany in "servant-leader" is not about inverting authority, but about understanding that needs for high performing teams come from the ground up.
On the one hand, it's about solving problems so your team isn't even aware of them (typically, politics and spec stuff).
But on the other hand, it's about listening to your team and working on problems they tell you are problems (e.g. non-coders in stand-ups).
This, I'm starting to think, is one of the most important parts of the job. When people have their heads down in technicalities, every requirement becomes a challenge they gladly accept.
But in practise, you have to match the workload to the workers. That's the only way to ever do things on time.
(Though I am useful when I reject requirements, I do try to teach my team to stop every now and then and consider the actual value of requirements for themselves. I don't want them to depend on me for workload adjustments.)
That has been my experience as well; playing supportive interference, managing stakeholder expectations, and good communication and solidarity with your team makes for a much more productive environment than being a human version of a corporate whip.
As many are saying, what you did is great leadership.
A somewhat "out there" book on servant leadership that I really like is John Heier's "Tao of Leadership". It's an adaptation on the Tao Te Ching towards modern leadership. Here[1] is a part of it as audio.
Reminds me of the advice I read many years ago that said that the single best thing a manager of software developers could do was to take away their telephones to make sure that no one could interrupt them or pester them for extra features.
> I chose the one that either didn't involve us doing anything, or was easiest
In my leadership experience, in the long run this is a recipe for disaster. If every team does this, in the end you get silos and a toxic culture, where it is really hard to steer architecture and product changes. At meetings with team leads all will seem fine, but then there will be some silent, elegant and even somewhat unintentional boycotting and delays, eventually grinding the organization to a halt. After years this leads to major changes in the management chain and then rinse and repeat :)
It's really a fine line, I think. You cannot do everything and you cannot discuss everything. Unfortunately, you also often cannot undo such a decision cheaply later. (One of the big fallacies of agile software development is that making changes has essentially constant cost of effort, whereas in reality changes get more costly over time.) So the only way out is some kind of agency/ownership. Every team should have a basic understanding of the goals of the stakeholders so they can make such decisions in good faith.
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.
It's fine to feel that way, but it's not a particularly effective approach in my opinion and in fact quite the opposite of what I look for in a manager. A good manager manages people; they understand people's strengths, weaknesses, goals, how to motivate and reward people, how to resolve potential conflicts, how to delegate, and how to help people grow. These are all people things. People are not robots which is exactly why they need to be managed. After all you typically do not manage robots, the point of using robots is that they're autonomous.
Problems are not things you really want to manage, maybe in the short run you can try to manage a problem, but ultimately the goal is to solve a problem as opposed to managing it. The goal of a manager is to assemble a team of people who can work together to solve problems.
Your issue is conflating management with superiority, you seem to think that someone who coaches a basketball team feels superior to its players. That couldn't be further from the truth. While Michael Jordan's coach was in his time a competent basketball player, he would never claim to have ever been better than Michael Jordan, and yet both he and Michael Jordan had an excellent working relationship without either of them feeling superior to the other [1].
The issue you have about superiority has nothing to do with solving problems or managing people. You could be a lawyer working entirely independently from developers and feel you are superior to them (or vice-versa). A good manager can cross multiple projects and multiple problems, because a good manager understands people first and foremost and lets competent people work on solving problems, as opposed to trying to manage problems.
> Your issue is conflating management with superiority...
Your issue is not realizing that many managers feel this way. They think that being a manager puts them above the people they are managing, and that their job as a manager is to boss people around (thus the genesis of that term).
Edit: I'll see your Phil Jackson and raise you Bobby Knight.
Bobby Knight led the Hoosiers to three national championships and 11 Big Ten championships. I'm not sure the definition of "bad manager" would fit succeeding at the most important metrics in sports - championship wins.
Isn't this exactly the point GP was making? That managers conflate the team's wins with their own 'succeeding'? It's not the manager that wins the championship, it's the team that is comprised of the manager also. Why is this so hard to grasp for managers? Is it the power? Is it the disconnect from the actual work?
As someone involved in both the technical and business side, but heavily biased towards tech, it's amusing to me just how cliché the management parties after a 'big win' on a 'visible' project are. It's almost unbearable to be around save for the brilliant food.
> That managers conflate the team's wins with their own 'succeeding'?
Is that actually conflated? I manage a few reports and try to succeed by setting them up to succeed but every management position I’ve had, I have had explicit OKRs/goals/metrics/etc stating that the success of the team as it’s own entity was something I was rated on.
If my team managed to succeed without me putting in any effort that was actually ideal as I got a free goal hit.
It's literally in the post from GP I am responding to:
> Bobby Knight led the Hoosiers to three national championships and 11 Big Ten championships. I'm not sure the definition of "bad manager" would fit succeeding at the most important metrics in sports - championship wins.
But even in that, presumably the owners have some compensation for him based on winning championships. I really can’t see how a good manager doesn’t believe that their team winning is a measure of their success
Why would a college team need to preselect players if it's all about the management? Couldn't they just pick random players?
Thinking about this more, I find it hilarious to imagine that you would expect the same results from A and B given the same set of performant managers:
A - team of highly unmotivated, undisciplined players
Do you watch college sports? Or are you just talking about what you imagine to be true? It’s not the same thing as a team of mid 20s+ trained professionals working in the context of a tech org. Indeed, The excellent talent skips college, goes to the pros, where talent matters much more than the org management.
I watch college soccer. There are talented players, talented coaches, shit players and everything in between. There are people who go on to become pretty known and there are people who die out in college soccer. I've never seen a single championship won by a team that doesn't have synergy going on between the players also, and not just a great top management.
Anecdotal:
There's a huge team here, wins most of the high level championship because they have a lot of money and end up buying worldwide players, so their access to the talent pool is broader. They also have the best coaches money can buy.
One year, one of the most famous players we've had decided to start up his own academy and create a new soccer team, with local people. He worked on it for a couple of years and came in and took first spot in the championship. Brilliant games.
They sold players due to their win, for a lot of money, and started the roster again. Next year, and since then, they have yet to achieve such a victory.
I would blame this situation on the synergy of the team and find it hard to imagine your world where the top management gets to decide who wins and who doesn't.
(edited for clarity)
Given that successful coaches are regularly fired for being garbage human beings (including Bobby Knight more than once!) I'm going to disagree that the "most important metric" is championships.
This is exactly the response I was hoping/dreading to get, as it illustrates my point so perfectly. Bobby Knight absolutely believed that he was above his players, and repeatedly physically abused them for perceived disrespect. He was a terrible person at Indiana and at Texas Tech, and no amount of winning answers that.
People glorify managers/coaches who succeed at the organizations goals, be they profits or rings, at the expense of the humans that report to them. These people are terrible managers and should be immortalized as shining examples of what not to do.
Are you arriving at this conclusion from a place of jaded bias or from actual data? Some managers feel that way sure, but your statement implies that its essentially the norm to be expected which is not the case.
Why is this argument so easy to make for politicians that get corrupted by power, but not for managers that might suffer from the exact same human weakness?
> implies that its essentially the norm to be expected which is not the case.
I deliberately chose words which do not draw a conclusion about "the norm" because I, just like you, don't know what that is. There is no such dataset, all anyone can do is assemble anecdotes.
You're correct about bad managers, but not about the idea that you shouldn't manage people. You summed it up:
> People are not robots
Exactly, people are motivated in different ways, have different backgrounds, aptitudes and weaknesses, the list goes on. A good manager takes these aspects into account to help people and teams do their best work. There is no generic template.
> 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.
Most people in an organisation have, very roughly, the same desire to do their jobs well. There are outliers in either direction.
If most people in an organisation are not interested in doing their jobs well, then something about the organisation is incorrectly set up. Humans have intrinsic motivation driven by autonomy, mastery, and purpose. If the masses of people don't want to do their jobs well, the organisation has taken too much autonomy, mastery, and purpose away from their employees.
If most people in the organisation are willing to do a good job, but some outliers misbehave, there are, as another commenter mentioned, standard ways to deal with that. (Mentorship, counceling, retraining, warning, firing.)
But critically, the standard ways to deal with struggling individuals should not be applied if there's a large majority struggling, because then the problem is in the organisation, not the individual.
If you think that your manager could improve...if only he'd read the Evil Overlord list* and really give that some thought, then your "manager" is actually an Evil Overlord (or wanna-be), and you might want to look for a new job. Working for a real manager.
>> 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'.
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.
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.
This mirrors my experience. Setting goals for what you will accomplish when you aren't in charge of what you are tasked with doing is classic responsibility without authority. It mostly feels to me that it's management trying to deligate out performance management to their reports.
This is so true. As a PM, it's very arbitrary to set OKRs, when you don't even have the KPIs in place to evaluate what is meaningful.
On top of that when you have a vision, roadmap, backlog what are you going to say other than, "yessir, I'll do more better" and will definitely help out more on the distractions or "quick-wins" as you like to refer to them.
In a matter of weeks l, it's clear who is moving the needle and think peer review would show this more than management alignment to OKRs.
When I went from contractor to permanent at my last employer the goal-setting really stressed me out as I knew I didn’t want to be held responsible for something that might change.
In the end I just decided to stop thinking about it to avoid the stress and my manager stopped asking. End of the year I filled in suitable goals based on what I had done and explained how well I’d met them.
It worked very well for me and I did the same for every year I was employed there.
Same here. This was at GE, the goal and review structure is elaborate, shifting, and based on a slew of cultural and corporate factors and cult bullshit. A real mess. You better have a cool manager that knows how to deal with it in an optimal way or it is a very very painful waste of time. My manager was brand new and by the book...greatly hastening my exit.
On top of all that it actually did influence your ability to progress (I just told them I had no aspirations of advancement beyond my current position...again, further hastening my exit lol).
I would love to do that but unfortunately every organisation I've been in demands that I set them at the start of the year. Then at the end of the year I can reflect on all the goals that were no longer relevant because plans change and being able change is agile.
You can also use goals as a shield. Since the company agreed it is high priority other work should not interfere with it. Of course if you manager thinks otherwise one can mutually change the list (which ppl only will do if the new thing is reeeaally important).
Why would they be? If my manager wants to constantly change priorities, then it’s THAT much easier for both of us when that same manager wants to know why the five things we agreed to do in January didn’t get done come performance review in November.
Maybe you havent worked for a company which changes your priorities and then doesnt want to pay the performance bonus because the original (written down) goal was not met?
Several of those goals are still subject to the whims of factors outside of your control.
E.g. "lead engineering on a project that has at least one other engineer." What if no project comes about? What if you start such a project and it gets canceled by strategic re-alignment? What if management keeps re-assigning the other engineer out from under you? What if executive leadership decides a larger project is priority #1 and demands 100% of your time? What if your division re-organizes how it assigns work and changes what it means to "lead" a team?
Not attaching goals to specific projects is certainly step number 1, and insulates you from some measure of change. But all of your goals are still subject to varying degrees of being de-valued or re-defined after a year's time.
For sure. The theory of annual goals is you already know the most valuable ways to spend your time for the next year. But that's true only if nothing changes and nobody learns anything important. It's generally just fantasy.
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.
I have this same experience, but goals are editable all the way through evaluations, so there's nothing saying you can't change your goals as you're writing your self-evaluations.
The problem with this kind of article is the dry, abstract, formal presentation, which feels devoid of content. A lot of us don't quite know how to operationalize it, and often the users of such language don't either. It feels like religious doctrine that everyone pays lip service to but doesn't really affect life in any meaningful way.
The manager-bureaucrat many of us are familiar with does not understand or care how to put these ideas to work, and reduces "OKRs" to forms to be filled and boxes to be checked.
We need context, examples, and explanations that show us when these ideas are working and when they aren't. We need them in plainer, more candid and more relatable language. And they need to be relevant to the problems developers and managers actually face. We need the why - why is it helpful to think in terms of OKRs rather than some other more familiar or simpler way?
Bottom line: the secret missing ingredient is often "actually use your brain when doing all these things".
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.
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.
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.
>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.
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.
> 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.
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.
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.
Oof, please no. Simple metrics like LoC, story points and number of commits are lazy ways to evaluate developers. And people will recognize this so the metric becomes the goal. Might as well replace managers with a bot. Good managers should be in touch with the full picture of their reports work and not rely on simple heuristics. That's what makes a really good manager.
> Simple metrics like LoC, story points and number of commits are lazy ways to evaluate developers.
I mean, looking through the git logs means you look at code contributions. If you're a software engineer, that's kind of, ya know, your entire jobs. You can get a lot from looking at someone's contributions, especially in code or documentation or slack responses. Volume doesn't mean shit though, that's the trick.
> Volume doesn't mean shit though, that's the trick.
Based on having studied lots and lots of open source projects, I can say volume has a very strong correlation with experience. The more people contribute, the more likely they have been contributing for a long time. A novice contributing a lot to me, can be a sign they are extremely good or they are trying to game the system or they don't know what they are doing and are constantly fixing previous mistakes.
My git logs don't represent all the code I didn't write. Solving a problem doesn't necessitate me writing the code, or even having code written at all.
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.
I'm a VPE at a small-ish org (30 devs or so, currently), and I regularly skim through commit history and keep an eye on various technical chat (we're fully remote, so there's lots of chat). I don't think I spend more than 15 mins per week looking at git history, but that's very informative -- it is not enough to make robust decisions but it is good enough to spot issues once in a while. (I have written my fair share of code in the past, so that helps.) So it's like going to a book shop, reading two pages from a book and deciding whether I like the style or not.
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:
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.
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.
I guess this works if you have a team of mostly jrs or are working on something truly unique. Most software doesn't have challenging work - it's mostly basic, boring, run-of-the-mill CRUD and/or API integration. Especially when you are working on a mature product. It's been years since I've worked on a project that even had tasks that would take more than a week.
You also absolutely need some constraints- "do this any way you want" can lead to "resume driven development." Too much of that and your code becomes completely unmaintainable. Which I guess is usually fine if you're a startup lighting VC money on fire, but if you are developing software for paying clients then you won't be in business long.
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.
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.
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.
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.
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.
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".
That doesn't really reward workers that take on hard problems and open themselves up to failure. Plus the limitation of this 20/80ism is that it's not explaining why some people are more effective. Maybe they did really well a long time ago and manager afforded them more freedom to set technical direction. Now every way is their way, they are bombarded with negative reviews and requires rewrites, etc. A good manager can see a problem even in their aces. Just because they're high performers, it doesn't mean they aren't a problem.
Real world story time, a company I worked at had the worst employee I've ever met. He was aggressive, openly berated staff, insert a bunch of things that would get you fired and they did those. But the rub was he was one of their most capable developers they had, so he got away with it. You could argue the company was fine, but a trivially deep analysis would dictate that the company lost a boat load of potential talent that quit due to this disruptive influence. I still to this day feel lousy because I never had the guts to personally raise a complaint against them with HR.
This sounds so sensible, yet the only company that ever did this did it with no other option but when they needed to re-hire me away from a sabbatical.
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.
>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).
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.
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?
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:
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.
> 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.
> 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.
>> 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?
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.
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.
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.
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.
> 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.
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.
> 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.
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".
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.
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.
You were working too much and you made everybody else look bad. Also, they didn't have budget for a raise so they gave you a poor review. I worked at a company like that. You see, if they give you a raise then the budget must grow. This is the job of the manager. But as he isn't doing his job, budget is not growing. So bad reviews all around. This is when top manager think they are so smart and come up with these rules, and then middle managers bend the rules.
If people are cognizant of when I start work then I'm scrambling for the door. Everyone always thinks I come in at 7am for some reason. I always have this reputation as an early bird. I start ramping up somewhere between 9-10am. I have had co-workers that guilty-ly admit they don't start up until 8:30 and they notify everyone about the munitia of thier schedule like we work in a restaurant or a factory or some shit.
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.
>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.
Precisely what happened. Incidentally I reported the harassment and I got fired the day after I reported the harassment.
>This seems like a long time ago, but that last sentence is blatantly illegal in my country and I dare say a lot of states.
About 4 years ago. Here in Ontario, doing this is not considered illegal. Your employer is obligated to investigate harassment claims but not required to do anything at all. Including firing you. I know this because I went to 'office of the worker' whose lawyers told me this.
Biggest two lessons of job performance I ever learned.
1) Your future hire-ability is determined by the work you do and the results you achieve. If you aren't an A-hole to work with this helps.
2) Your performance rating within a company is based on perception. If you are perceived as doing good work then you get a good rating. There are no objective internal measures of engineer quality in any company.
>> 1) Your future hire-ability is determined by the work you do and the results you achieve. If you aren't an A-hole to work with this helps.
I agree with these but you've got them backwards. I'll help a positive & kind but marginal performer get better or find a role where they can excel; An a-hole is a cancer on the team regardless of how talented.
>It's also possible management didn't know what all you did. Or, you were running around like a headless chicken-not aligned with the company goals.
I was an outbound tech at an MSP. I was often not in the office, avoiding much of the drama.
I was hired originally because 3 people quit with no notice on the same friday. Between the time I was hired and fired. Many other people quit and they were very ineffective at hiring.
I was 1 of 2 networking capable techs. I was also constantly out for emergency after emergency. None of which I caused.
I actually live wrote a 4 day week at this place on r/sysadmin back in the day. I took the friday off because it was my birthday. In those 4 days I dealt with over 40 tickets, >25 of which were emergencies. At least half of these clients were clients I never worked on previously. On the friday the company phone was constantly ringing, i didnt pick up and even had an account manager come to my house. Of which he shouldn't know where I lived. Except he sat next to someone who did.
Out of ~30 sysadmins, 25 of which didnt last beyond 6 months. Everyone was fired or quit.
Well, with this description you can cheer - their demise as a company is written on the wall. Especially in the current situation of the worker's market.
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.