So often in our business, there are few that understand the whole picture of your problem area. Inviting too much critique results in uninformed objections or redundant suggestions that have already been considered and rejected.
The person who has been charged with a task, should have authority to carry it out as best they see fit. Ok, after folks have a chance to review. But letting somebody gate-keep results in stagnation and no progress.
I think this is the most common problem in the tech world, and it’s source it’s on hiring.
When I hire someone to do a job, I don’t want to tell them how to do it. I want them to figure it out, and ask for help if they need it. For some reason, that’s not how most people work. A lot of them expect you to tell them how, but they will refuse to ask for help until too late.
When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better.
So far my only weapon against this has been to be very selective while hiring.
I understand what you say; you want people to solve problems, not to execute tasks. But, there're some points that I figured out myself during my career that may be useful:
> I want them to figure it out
Can they actually figure it out without someone explaining some oddly specific detail related to the company/domain/country?
If you have some very precise requirement that you absolutely want to be satisfied, are you telling them, or do you expect them to "figure it out" because "it's the only right way to do it"?
If they cannot figure it out, and they cannot REALIZE they should have until too late, will they be punished for their mistakes, or are they allowed to make mistakes while learning by themselves?
I find that many people, especially bosses/managers/CEOs/whoever has/thinks having the power, think that their view is the Only One View; who does things differently is Just Wrong (as you say yourself about your past bosses), but they DO NOT CARE about explaining their wishes to whoever is working with them. Since this is quite a prevalent attitude, people tend to ask details about their jobs. This isn't bad, and most people, once they feel safe and properly valued, just stop, in my own experience.
You're right, but it's not even really an "attitude", and it's not necessarily malicious or even stemming from a power relationship.
It's just a fundamental cognitive blind spot that humans have about assuming that what's obvious to ourselves is obvious to everyone else. Every one of us who's jumped into a question about something they're working on and had the other person say "I don't understand the context" has done this.
The opposite is what makes great teachers, authors, and other communicators great: they recognize what the other person doesn't understand.
You can't just go around recognizing what people don't understand. That's what got Socrates killed. You've gotta make them understand what they don't understand without making them want to kill you. That's what makes a great teacher / leader / etc.
I have found the Socratic Method[0] brings out the best outcomes because it forces everyone to show what they think they know, have their assumptions tested and hear about things they might not have considered or even know about. From my experience, everyone is ultimately able to reach a higher level of understanding for the topic or problem which allows for better decision making. The more diverse the participants' backgrounds the larger the network of knowledge one is able to tap into.
Unfortunately, you are right that there are people who are extremely threatened by the Socratic Method. In Plato's Cave[1], Socrates talks about how some people strive to explore and learn while others have no desire to broaden their knowledge as "they know no better life."
Requirements or the asks need to be clealy documented before someone goes for a solution. The problem usually is they discover more use case while reasearching the solution.
> Every one of us who's jumped into a question about something they're working on and had the other person say "I don't understand the context" has done this.
Sometimes. Not always. I think everybody holds ideas in a spectrum from "absolute truth" to "totally my biased opinion". The problem arises if I hold an opinion as an absolute truth and I ask other people to work for me. I won't bother about telling them absolute truths, won't I?
Doing things differently is not only wrong, its also often perceived as a power-play challenge. For if the captain does not steer the ship, what good for is a captain? So the creative worker, is perceived as a challenge by lots of management, that thinks it has to defeat this with micro management.
I think that some commenters kind of misinterpreted my message. I think that just any of us has wishes and ways "to do it".
If I ask somebody to cook for me, I expect the food to be palatable _to me_. But since I'm Italian, I'm probably picky about food, and I may not like some kind of exotic tastes. That's totally ok.
What is not ok is to say to somebody "cook for me", then classify the food as shit because "I don't like it". I should probably investigate a bit with the other person about my tastes (and the other person should, rightfully, ask questions!). They will still have plenty of opportunities to exercise their creativity, without pushing too many boundaries. Mind you: I think that boundaries should be pushed, but it's unwise to push them too hardly at first.
> For some reason, that’s not how most people work. A lot of them expect you to tell them how, but they will refuse to ask for help until too late.
Because that is not how many bosses or jobs work. It is certainly not how school works. Teachers, parents, and plenty of managers have a very particular idea of what work product they want completed.
With them, your choices as a student/employee are to pester them and check in with them constantly until you have narrowed down exactly what you want or be told to go redo it after you figure out how to do it and get it wrong.
> but they will refuse to ask for help until too late.
That's because you're setting that up, perhaps inadvertently, by expecting them to figure it out and ask for help __if__ they need it. You don't even have to explicitly say that's what you expect, it's likely apparent by your demeanor.
There's something about software workplaces that discourages thinking out loud and exploring ideas. Carelessly asking the wrong question in such a place can instantly and permanently red-flag someone as incompetent. It's like people have taken the weird culture from Stackoverflow and ingrained it in their workplace.
Sure "endless" discussions or bike-shedding can be bad, but it's a much worse problem to have an environment where there's no sense of psychological safety for discussions and asking questions.
The OP article, it appears, is proposing a turgid RFC process for deciding things within one organization. That's fine, I guess, if you're a standards body coming up with rules for literally an entire industry, but it's too much for a single team. Sometimes talking things out is good as long as people can be reasonable with each other.
> There's something about software workplaces that discourages thinking out loud and exploring ideas.
I actually encourage it (or at least try). I just prefer it to be 1 on 1 (not necessarily with me), because we can’t really afford doing all of our work on a whiteboard, at some point we have to deliver. Also, I think this exercises are useful up to 3 people, then conversations quickly become too unfocused.
What I meant is that a lot of people are unable to recognize that they are stuck or very behind the schedule, and fear saying so, even if it’s not their fault.
I get it, I also had bosses who “killed the messenger”, and I’m convinced that this is in some sense a feedback loop. My point is that it’s very hard to break this loop with most people, they seem to either get it immediately or to be incapable of it, no matter how much I try.
The SO culture is actually considerably more sane, because when downvoting, you also automatically decrease your own "status" (score). Whereas in many real settings, you get +100 points if you "downvote", i.e. point out someone made a mistake.
> I has bosses that expected me to do things their way
This is a reason you need to learn to manage up.
I'm pretty clear that I'm oriented around the final objective: I don't want to be told how to do something (though I'm happy to collaborate and listen to suggestions). If someone starts telling me the "how" before the "what" and "why" I interrupt and steer the conversation there first. If you really want to be telling someone only the "how" I'm not the right person to employ, and I'm clear about this early on.
The very few times I've got in trouble with this there's been some hidden objective or constraint I wasn't made aware of, and the discussion I have afterwards is that is not compatible with my way of working. This has always resolved successfully and I've never had this issue with someone more than once.
> The very few times I've got in trouble with this there's been some hidden objective or constraint I wasn't made aware of, and the discussion I have afterwards is that is not compatible with my way of working.
I’ve had this, but working in hardware development, this things are big problems.
I have to admit though, and in those situations the main problem was conveying to the manager (who tends to be an experienced engineer) that they’ve messed up and the specifications they’ve agreed to are physically impossible to construct.
> A lot of them expect you to tell them how, but they will refuse to ask for help until too late.
Software is an industry in which people are criticized frequently for doing things differently than how others would've done them. This results in devs (that are less confident with that type of confrontation) over-asking how a company wants something done, and then feeling anxiety around getting it wrong and needing to ask for help. It might not necessarily be the responsibility of the direct manager to define _how_ things are done from a technical perspective on that team, but it's certainly someone's. "I expect you to know how to write software in our codebase" kind of falls apart, given the infinite options for how problems are approached within a given problemspace.
If you're seeing this type of behavior, your org might have trouble with A.) responding to aggressively with developers building something differently than expected, B.) valuable criticism. Pull requests are exhausting, in my experience, because they oftentimes turn into theoretical debates about the validity of different approaches.
Pull requests are the correct time to offer actionable criticism on submitted work. Pull requests are not a place to complain about an implementation strategy, or to suggest the developer should've done something totally differently. If the submitted solution is so far away from correct that that type of criticism comes up, your workflow has already fallen apart (as a developer was able to build and submit a solution without realizing their work wouldn't pass review).
> When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better.
I think ultimately either is "fine" - things just need to be defined appropriately. If a developer is given the freedom to basically do whatever they want, they need to be told so, and that ideal has to be supported through the entire dev lifecycle. Meaning your team's culture has to have the restraint to not complain about implementation details. In my experience, almost no org is actually comfortable with this method though. In my experience it's best to literally define "how" a team solves the problems it is tasked with.
I support your right to run your business as you see fit, and I know that there is both value and profit in that way, but as someone who has seen both perspectives from both sides of the fence I can tell you this:
That does not scale.
If you hire the exact person you want and they get exactly the results you want, you’ve just installed a black box in to your company. You cannot duplicate them and cannot replace them seamlessly if something happens.
In a real way you are now reliant on that specific person and they only have so many hours in a day (and only so much motivation).
Experience tells me that the “20% time” way is the right balance: Support employees in exploring unknown (and possibly much better) ways, and spend 80% of the time following processes that are known to work. Black boxes can cripple a company if work is 100% at the will of single employees, and so much valuable insight is lost when it swings 100% the other way.
These seem to work, but I don’t have anything close to the number needed for statistical significance:
- At least 2 years experience.
- Having built projects on your own is always good, but I’ve seen that having built “weird” stuff is better.
There’s a lot of typical projects, in hardware development building a power supply or a 3D printer are quite common. I find that uncommon projects (even if unsuccessful) tend to be a better predictor of what I’m looking for.
- Uncommon educational paths: having changed majors, or pursued other stuff later (e.g. people that do physics in college but after 2 years working they switch to coding and join a masters in ML)
In the end you are trying to find people that are independent, emotionally stable, a little non conformist, but ideally don’t have serious communication problems. That is said easier than done though..
>The person who has been charged with a task, should have authority to carry it out as best they see fit.
That requires specifically assigning someone the task and authority. This is the part most orgs fail on because to accept ownership is to take on risk. Organizations tend to focus on mitigating risk, and so it becomes increasingly difficult to actually have a person designated as responsible for the thing.
...and if someone naive enough steps up to take responsibility, they don't provide enough authority/resources to achieve the task. This is how organizations destroy autonomy in their employees.
This can be by design, so your risk takers always fail, and thus you can say you encourage risk takers but always have cause to fire them, resulting in a team of sycophants with a "culture of autonomy".
We’re attempting to undergo a culture and operating model change shifting from gate keeping to focus on outcomes. Please wish us luck.
I work at a company that has a management team that historically thinks they need to prioritize initiatives for the organization. A little over a year ago we had a conversation with the management team and explained we would like them to focus on outcomes instead of telling us specifically what to do. It didn’t go over well, they basically ignored the entire conversation and told us what to do.
We are one year later and now undergoing a shift to focusing the organization on outcomes using OKRs and spotify style agile. People are starting to get it now and we’re having a lot of discussions with the very same leaders on a more individual basis which I think helps.
One thing is for certain, people (and culture) are hard to change.
The person who has been charged with a task, should have authority to carry it out as best they see fit. Ok, after folks have a chance to review. But letting somebody gate-keep results in stagnation and no progress.