I miss Gerry Weinberg. Used to get lunch with him regularly
He credits a man named Sherbie for the three rules. That man was my grandfather.
The best advice Gerry gave me was when I was in a tough spot in college. “Expectations are fickle things that we work ourselves up over. Reevaluate them regularly, they have expiration dates long before they begin to smell funny.”
Reassessing expectations means, I would say in the vast majority of cases, lowering them, not raising them. I would advise, as always depending on the person and the situation, to make peace with disappointment and to have higher expectations, especially of oneself, not of others, that a reasonable person would have.
My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems rather than push out more features.
Then the same problems start popping up and the manager loses faith in their team. The times they said "no" to infrastructure development and working down technical debt may not even enter their mind.
After the manager declines to invest in engineering quality a few times, they have sent a clear message that quality and reliability are secondary to the desire to get things our the door. Then they blame the staff for their mistake.
>> a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems
Anecdata follows but I’m certain this has been getting better in recent years. It’s more common today for management to be swayed by data - my recollections of the 2000s were interactions more along the lines of
“I’ve been doing this for 20 years son, whatever your little spreadsheet contains, I’ve already accounted for just by feeling the air in the room through my superb gut”. - management at that time had gone from playing with Sinclair spectrums in their bedrooms to leading huge multimillion dollar teams, partly because software development had exploded and someone needed to lead those teams. So several managers I ran across seemed to see their position as a result of their greatness and not really anything at all to do with growth in the industry leading to bigger roles needing filled. This is a long way to say it used to be very hard to penetrate a charismatic self-aggrandising tech leader’s thought bubble.
Today I definitely see it as different. E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management slide decks over the next few weeks.
> E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management slide decks over the next few weeks.
No you will be waved away like always, they don't care. Features features features, nothing else matters.
If your management is waving off the waste of something so immediately convertible into dollars as their (probably) highly-paid engineers' time, then they're idiots.
Usually the hard part is collecting the numbers and defending their validity.
> My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems rather than push out more features.
This is only partly true. It is true that management sometimes faces budget pressure. But the real skill lies in what they do next. They could - easily - come up with a strategy of feature delivery, and communicate it clearly. Ask engineers to pause red tape, be scrappy for the next few quarters, talk to dependent teams to make certain flows easier. Explicitly use their authority to set the rules aligned with leadership.
But this is not what they do. The average management simply pushes indirectly, via 1:1s or individual blaming.
> After the manager declines to invest in engineering quality a few times, they have sent a clear message that quality and reliability are secondary to the desire to get things our the door. Then they blame the staff for their mistake.
I think it helps to speak the same „language“ as the manager. Add price tags to the infrastructure development or technical debt. This may add an important perspective to the discussion for both sides.
As developers you should be doing this anyway to understand why you want to do something. Gut feeling for "it's just better" doesn't get you far - no wonder you can't get anyone else on board.
Similar issues happen for justifying security. But if you've got a price tag, then just do expected utility. What's the odds that you'll need a backup? 1%? 0.1%? Per year? And what's the value of that backup price tag during that time? $10m? 0.1% per year * 10m = 10k per year.
Give the price tag when missing. The argument is we need to fix this in order to insure against this catastrophic event.
Or take the price tag when missing multiply by the probability of needing it over the course of one year. This is a more accurate estimate for the annual cost of not creating the backup.
What is fascinating to me about technical people is the particular subculture that sincerely believes that technology will solve the people problem. I recently got into a long thread argument with someone on HN about this. The person was adamant that people problems can NOW finally be solved by designing technology to be able to handle adversarial and incompetent actors. But the problems that such software tries to solve are tightly defined in scope and cannot deal with actually messed up people or organizational problems. Unless engineers are willing to acknowledge people problems, they will keep banging their heads against the door when the organization isn't doing what it's supposed to do.
But it's far easier to acknowledge the people problem first and see if there is a solution for that, rather than trying to ram technological solutions through a people-shaped hole. And if the people problem can't be solved (i.e., it will often involve a change in culture and leadership style, or else a change in leadership, both of which are difficult), it may be best to give up anyway and wash one's hands of the whole mess. In which case, one just sits there going through the motions to pass the day and collect the pay. If they're motivated, they'll find another job, rather than try to fix the mess, and they'll likely be happier doing that too. This is also why it takes a certain non-technical skillset combined with technical skills to succeed in leadership roles. It's a completely different game to play.
I was watching some interview long ago when the guest hit it square on the head. My guess is that it was Joel Spolsky, but only because no other names come to mind as being plausible.
Essentially the rant goes: So all of these people who were not particularly good at people skills in high school go into a career where they think people skills won't matter as much, and check out for 4 years while their fellow classmates are honing their interpersonal skills in one of the most intense personal growth periods of a young adult's life.
Then they graduate, get out into the world and realize that it is all people problems, and now they're even further behind their peers than when they went into college.
Being friendly, honest, and learning when to keep your mouth shut (biggest mistake when I had engineers chat with customers) is more than enough to keep everyone happy.
Honestly, I think finding a non-software project to volunteer on is a good start. About half of my better acquaintances are landscapers because that's what one of my hobbies attracts.
Also turns out they don't really like tech for tech's sake. Who knew!
Tech is still a pretty good option though. Having poor people skills but good tech skills means being a not-too-senior IC forever, a job with decent pay and hours relative to other career options.
I actually belive that a lot of the world's hard problems have been, in many ways, made worse by this attitude. Fb being so slow and reluctant to acknowledge their pivotal role in polarizing the world for instance.
To be honest this is what I usually see, not what GP describes. I've never worked with anyone who was ignorant of the people problems around them. Interns, maybe.
I would argue that all of the ideology-based advocacy for Bitcoin and other cryptocurrencies is/was advocating to solve a people problem with technology.
It's more along the lines of "most world governments are actively sabotaging their own citizens. This happens for various reasons, from corruption, to dictatorial panic, ... and Bitcoin provides payment while avoiding to deal with them"
Of course that probably is not the concern Swiss banks have on Bitcoin, but it's still what they offer.
> But the problems that such software tries to solve are tightly defined in scope and cannot deal with actually messed up people or organizational problems.
In many cases the solution comes in the form of "go away or I will replace you with a very small shell script."
For example, suppose that you have regulator captured by construction companies who want construction to be labor-intensive because they're the ones who get the money. The problem here is not that we need technology to reduce construction costs, it's that construction costs are being artificially inflated by regulators.
But now you come up with a technology that allows construction to be performed in a factory and the local part is limited to taking the thing off the truck and putting it in the building, which takes ten seconds and can be done by the truck driver. Can this solve the problem?
Maybe. It depends on whether the incumbents have enough political power to have it banned or made prohibitively expensive. If they do then it won't work. But if they don't, the technology solves the people problem, by removing the problematic people from the operation. Or forcing them to improve their own efficiency so they can remain competitive with the new technology.
> your ICs won’t have the full picture. They really may not understand why certain priorities are set the way they are. You’ll need to take that as feedback for improving internal comms rather than “fixing” the perceived problem, and you certainly don’t want to make empty promises.
One time, my manager gave me negative ratings out of nowhere. In his review, he wrote that I rolled a feature a few days late. I chatted with him and explained that the delay was because of production freezes (see dates) and bureaucratic steps (see dates). He didn't want to hear it. I asked what the consequences were of the delay, did it affect a customer? Did it impact revenue? I knew it didn't because I was always checking in but I wanted to hear it from him.
It was clear the priorities were different. I asked what the priorities were. And he couldn't answer.
To the post's point about fixing internal comms, this manager did not WANT to fix internal comms because the internal comms would sound something like, "I just need everyone to finish everything within the quarter - by the exact date - regardless of any company-wide freezes or red tape - because I get scored on it by my boss. I don't want to be at the bottom of the stack rank".
Hard to have clear and precise internal comms when deadlines and deliverables are just a joke with no business value. They'll be found out.
The interesting thing is that actually honestly communicating "I just need everyone to finish everything within the quarter - by the exact date - regardless of any company-wide freezes or red tape - because I get scored on it by my boss" can easily work; that's a clear measurable goal that gives others clear guidelines on the actual priorities and what can be cut if necessary (e.g. quality or features) and what can't (deadlines) and the team can execute that even if the goal is arbitrary, and the alignment of goals is clear - if you miss deadlines to help customers, then you're not surprised that the boss is unsatisfied with your performance and wants to replace you, and if you can manage the deployment process so that the feature "counts as deployed" (even if it's not really ready) at the arbitrary quarter it needs to, then you're a valuable employee for whom they'll find a way to arrange whatever budget is needed to keep you.
It's especially relevant in B2B work - you have to know what the actual personal goals of the decision makers at your customer business are, because your job is to address that; you're not there to bring them in more revenue or satisfy their customers, your actual goal is to help the manager signing your checks to meet his quarterly KPIs/OKRs/whatever, so you'd better know and prioritize the exact things on that list.
> "I just need everyone to finish everything within the quarter - by the exact date - regardless of any company-wide freezes or red tape - because I get scored on it by my boss" can easily work; that's a clear measurable goal that gives others clear guidelines on the actual priorities
This only works if they actually communicate it before projects start. Which they did not. Which is the whole point of the original article - "internal comms" is the issue. Just being honest and timely is sometimes enough but management doesn't think they can do that.
>>> want honest feedback and that they are safe to offer it
The key word is safe. It’s not safe. Or they don’t think it is safe.
The problem is almost always going to be the person asking and saying “it’s safe”. Or their boss. Which just repeats the problem one level up.
And you know the solution?
Weirdly it’s democracy. The idea of enough of us know the secret we can replace the problem. Often we don’t have to do the socially difficult problem of explaining why that politician is a knucklehead, we just don’t vote for them.
I had never seen democracy as a solution to awkward social hierarchy problems !
> During this meeting it is important to only listen. Especially if you’re at a small company and you are regularly involved in the day-to-day operations, you might feel immediately defensive. Sit with that feeling, and process it later. Don’t unload your emotional state on an employee you have power over.
This is why I rarely give frank feedback to anyone except my direct manager, and only then if I've spent enough time working with them to understand what kind of person they are.
I've had enough meetings where I'm welcomed to candidly share my opinions and observations, only to be told my opinions are wrong and my observations are invalid, and that everything is fine, or will be after this new re-org/initiative/project!
Ha. After explaining the problems to leadership, my team and i were laid off and leadership is pursuing a nee and fancy cloud replacement for our jenkins pipelines.
I agree with the article 100% though. Just had insane leadership.
>So the intended audience for this piece is potential clients, leaders of teams (or organizations, or companies) who have a general technology problem and are wondering if they need a consultant with my skill-set to help them fix it. Before you decide that your issue is the need to implement a complex distributed system consensus algorithm, check if that is really what’s at issue.
At least 90% of the time, these leaders already know that it's a people problem. Because it's always a people problem. But presumably this guy has a good reputation which means he knows how to solve people problems. And companies are willing to pay a whole lot more than a few hundred dollars to have him be the one asking "what is fucked up about this place" than a senior manager.
I'm guessing people are a lot more honest with a consultant than they would be with the guy signing their paychecks. Does the IC3 get a raise or bonus for his keen strategic insight? No, best case scenario he keeps his job. Worst case, he doesn't.
>If you have these conversations directly, you can get something from it that no consultant can offer you: credibility. If you can actively listen, the conversation alone can improve morale. People like having their concerns heard. If, better still, you manage to make meaningful changes to address the concerns you’ve heard about, you can inspire true respect.
This goes the other way too. If the manager can't address those concerns, he loses a lot of respect. The consultant has a great excuse for failure here, and even if he didn't, he'll be gone soon enough. So it's less risky to have the consultant do this, and management likes low-risk options.
> Talk to your ICs, and — taking care to make sure they understand that you want honest feedback and that they are safe to offer it — ask them what problems your organization has.
Can you reasonably expect for there to be a true “safe space” in a professional setting? It’s always good to be candid and transparent, but I’d never assume I’m in a complete safe space no matter which organization I am in.
> Can you reasonably expect for there to be a true “safe space” in a professional setting?
My experience has generally been that, even if a leadership level person is being sincere when they say they want honest feedback and it is safe to offer it, the junior level person they are meeting with doesn't believe it. (An economist would call this an example of the "market for lemons" problem.) That is a big reason why outside consultants can break the ice on something like this, as the article describes, where internal conversations can't: the consultant can credibly promise that honest feedback won't adversely affect the speaker (the obvious way to do that is to not attribute anything to any particular person when the consultant reports to leadership), so they have a shot at actually getting the honest feedback that is needed to get to a solution to the problem.
The consultant is being paid by management. S/he is beholden to them. If anything can be traced back to a group or individual, it will be, and it won't be pleasant for anyone who believed the request for honest feedback.
> The consultant is being paid by management. S/he is beholden to them.
Quite the opposite. One of the reasons people go into consulting (and I don't mean working for a consulting company), is precisely because they're not beholden to them. They have much more freedom to set the terms than employees do.
If a company wants them to reveal the individual, they'll be happy to give them the middle finger and let them know their morals are lacking.
The point remains that the messenger may deliver a message that invites retaliation, and even if their plan is to protect their sources, they may fail to do so.
Someone who thinks they will protect you may be as big of a wildcard as someone who demonstrates clearly that they won't, because you haven't given anything really damning to the latter.
I can confirm that. I've had more than one opportunity to tell some C-level manager that asking me who said what was making them part of the problem, not the solution. It is quite an effective way to initiate reflection (whatever you think, most managers are not sociopathic morons, they just have different incentives than you).
The pattern that I have seen in consulting is that management has already heard of that feedback, but don't consider it credible for various political reasons (and they're not generally wrong in many cases), so when the same feedback is confirmed by consultants as a 'disinterested third party' as valid (and the opposite is also often the case), then they finally believe it and it can get implemented.
People with different professional backgrounds speak different "languages". It really matters how you describe a solution to the other party so that they accept it. That's one of the skills that a consultant needs to hone: Speak different "languages".
The article is describing a case where what you describe did not happen--he, the consultant, was able to convey feedback from working level people to management, that the working level people were unable to convey themselves, and management liked the feedback. And the article says other consultants have described similar experiences.
Of course there are companies where consultants do not have this happy outcome--either because management doesn't listen to the feedback even from the consultant, or because the consultant does what you describe and doesn't protect the working level people who confided in them. But the article indicates that this doesn't have to happen, and that was my point: as I said, the consultant has a shot at getting to a solution of the problem.
> the consultant has a shot at getting to a solution of the problem.
Yes, and if the consultant fails, s/he's off to the next gig. The author did not mention any cases where his approach failed.
The author also says "One week later, I will schedule a meeting with executive leadership, and during that meeting, I will read back a very lightly edited version of the transcript of the previous meeting"
Dandy. If one has a recognizable voice - style, usage, etc. - it will be recognized. And dealt with.
I don't think the solutions he's presenting will "scale." He says "[if you need] event-driven distributed systems consensus algorithm implemented using Twisted, I’m absolutely your guy." He's a young guy with a pretty narrow niche and is making some pretty big claims for a large world outside of it.
I used to believe that, but no, at this point in my career I have no confidence that anything I say won't be used against me in the future, or misconstrued in some embarrassing way.
There are bosses who get violently angry and fire people. Nobody will trust that boss with honest feedback... ever.
There are the bosses who are simply dismissive of what their staff is already telling them. In that case, the boss is having this meeting to tell his staff "I ignored and forgot everything you told me previously, but this time will be different. I'm prepared to listen this time." That boss may be able to make good on the strategy in the article.
Often the first contractor to come along ends up telling the boss everything that his own employees have been complaining about for years, and either he can't hear it, or they stopped saying it because it gets them nowhere.
Few people continually remind you of the places where you are disappointing them. They've said it a dozen times, they know it's pointless to say it again. Which complicates things because now what you think they are upset with you about are either entirely not the real reasons, or are just proxies for them. But you already fucked up that channel of communication.
I believed that strongly, to the point that it was borderline immoral to not share.
Then I sold the startup and worked at Google for 6 years.
1 out of 4 managers hit the bar that I figured would be a floor, you could have a constructive conversation with them and they'd help you if something was up.
I don't think anything has hurt me as much emotionally in my career as working at a really great place as my first job, setting my expectations for the next ten years of my career to be anything like that, and then get curb stomped over and over again by mediocrity that thought it was objectivity or responsibility.
Trying to mold people who did not want to be molded resulted in a lot of Pyrrhic victories.
If I hadn't moved to a new town, and if they hadn't also, I would have tracked down some of my old coworkers and asked them very nicely for a job. But we all 'graduated' and flew away.
I just worry that if I stay for years, and then for some reason do have to leave, it'll be harder to find a new job with my first as a dev having been at the same company for many years.
Generally I think long tenure is a positive signal, but you have to be growing. If you are growing and learning, and enjoying it, I recommend you continue to do so. Stop and smell the roses while you're at it.
In theory, skills are what matter, but I don't find that true in practice. Appearance matters more. A long tenure is a good look to most.
I can be pretty cynical about corporate politics but that kind of consultant-IC interview is almost always safe. It’s wildly against the consultant’s interests to cause serious conflict to break out and it’s easy to tone down inflammatory comments. Also, if the IC’s ideas are ones likely to rile up management the consultant is going to drop them. There are also potential upsides; if senior management is decent they will be glad that their employees have good suggestions and a good fraction of consultants will be glad to credit the ICs once management have bought in; ofc some will take all the credit themselves but that’s still a low-downside proposition.
I've had one favorite boss get fired, and at least two leave (forced out/encouraged to go) because they agreed with us but their peers or boss didn't. Agreeing with them is fine until it isn't, and then you're a collaborator.
And then there's agreeing with the VP or CTO, but the people between you don't, and try to suppress your enthusiasm. If you go over their heads it better be to get transferred to another team instead of trying to change things in place, because now you're squeezing them and they will retaliate.
> And then there's agreeing with the VP or CTO, but the people between you don't
heh, been there. Sometimes I feel sorry for those that high up, especially the ones that DO mostly see the problems but are powerless to do much because of all the shit between them and the solution.
The higher up you go the more power you have but the less control you have. That seems paradoxical but consider the old adage 'if you want something done right, do it yourself'. You may have the power to hire and fire but have little control over the day-to-day decisions that matter.
The people in charge have the power and the responsibility to ensure they are doing the right thing, and that their subordinates are too. If your subordinates aren't doing the right thing, or aren't listening to you as the leader, you as the leader need to act.
Responsibility is the ceo's/boards for most places. Not that they will be taking responsibility any time soon. But the subordinate thing still applies, I think.
When your boss hears but the CTO doesn't, sometimes you can get your business partners to tell their boss to tell your boss that they need <solution> from your product, at which point it rolls back downhill to you.
This has always been my problem with "psychological safety". Politics is a unavoidable consequence of large organizations and there can be no "safe spaces" where politics exists.
It's certainly possible to have it on a personal relationship basis - with coworkers or a boss, but broadly? Impossible. If someone wants to take you down, then your "honesty" is going to be used against you.
The problem is that generally for the IC the risk to the physiological, safety, and security isn't worth the reward of what they would gain by opening up to management even if it were genuine.
It often is a people problem, and when it is, it's likely to be at the leadership level.
What stumps me however is how to move past those problems -- when the decision makers at an organization themselves are what's dragging the ship down, how will things ever change?
Blog author doesn't cover it, but my uneducated guess is... the consult ends with a technical recommendation, but the people problem remains unresolved.
I am familiar with a particular small business. They have this loop:
1. Product and Engineering cooperatively develop a project, scope milestones, cut tickets, do agile, eng writes the code and iteratively works with product to incorporate feedback and it's a grand ole time
2. They get about 80% done with implementation (so they're about 90% if the way through the entire project, impl is usually about half the time)
3. The owner takes note of the project and examines more closely. They profess their opinions all over it, sowing madness and scope creep, freaking out the junior ICs and new hires, and further exasperating the seniors and old hands
4. They scramble, cut other scope that isn't in the Eye of Sauron, do some late nights and cut a bunch of corners, write some shit code here and there, then push it over the finish line a little late and a lot of stressed
5. They have a retro in which they excoriate the evils of scope creep and extol the virtues of sync meetings and exec reviews and more process layers and stamps.
6. Owner doesn't participate in any of the additional process because they don't have time, naturally.
7. A project nears about 80% completion, the owner takes notice, and...
It's really a beautiful cycle. At various points, sometimes someone will notice all the layers of scar tissue, uh I mean process, aren't actually helping, so they cut a bunch of them out. Much rejoicing. Then the next project gets about 80% done, and...
Yeah. Whatcha gonna do? It's the only thing about the company that isn't going to change.
>What stumps me however is how to move past those problems -- when the decision makers at an organization themselves are what's dragging the ship down, how will things ever change?
People will start new companies and become leadership there (starting the cycle over).
The majority of managers I have encountered have a superiority complex. Because they are the manager they know better. They have a misguided idea that they were promoted on the basis of some meritocracy instead of being good political operatives or shameless sycophants.
That is why only the advice of very expensive consultants is valued. Many times I have had after work drinks with staff who complain that they have been trying to tell the management what the highly paid consultant did.
> The majority of managers I have encountered have a superiority complex. Because they are the manager they know better. They have a misguided idea that they were promoted on the basis of some meritocracy instead of being good political operatives or shameless sycophants
That is usually true. One fix for that is to play into it. Guide them towards the idea but make them think they came up with it and the praise them for it. I always remember the scene in My Big Fat Greek Wedding where the women get Gus to “decide” and come up with the idea that Toula should go work at the travel agency.
Praising a thirsty horse for drinking, after having to forcibly lead it to the waterhole and show it how to drink just isn't in my wheelhouse. It's beyond a certain very-slightly-autistic line of wrong-ness intrinsic to my very soul. I know this holds me back, but, I ... just ... can't.
I will, however, increasingly simplify the explanation of the concept until the conversation reaches acceptance or frustrated dismissal of the topic altogether. This has had patchy success over the years.
Many years ago, after a number of failed explanations, I demo'd to my boss, the IT Manager, the ability to access work emails from a mobile device and how Managers and Salespeople would love it for their productivity and customer relationships. "Nah, I don't think they'd be interested. That's what their laptops are for".
Surprisingly, that particular horse never died of dehydration. I think that's because the next levels up were also thirsty horses.
> I know this holds me back, but, I ... just ... can't
It is messed up, indeed. Better to find another horse. But some people are stuck with their horse for some reason or another.
> I will, however, increasingly simplify the explanation of the concept until the conversation reaches acceptance or frustrated dismissal of the topic altogether. This has had patchy success over the years.
Yeah, that is a better option.
> Surprisingly, that particular horse never died of dehydration. I think that's because the next levels up were also thirsty horses.
Well put. There are thirsty horses all the way up.
That’s an effectively intractable (and common problem). Even when there is a board involved, a skip-level approach to pointing it out is very likely an end of employment situation.
Machiavelli had advice for this situation, and it wasn’t kind.
You come at the king, you best not miss. If I got to the point of going to the board about my CEO, it’s already a him-or-me situation, and that almost always means it’s me who’ll be leaving.
The CEO currently has the board’s support, at least ostensibly, and I’d be faced with moving them off the status quo; that’s unlikely over a routine leader style topic…
He didn't so far as I can tell. He wrote The Prince for an audience of rulers, both new and established, aiming to preserve or reinforce their power.
But to be charitable bc that is basically a nit, he would have advised a calculated approach to wielding political influence or instilling fear. He was partial to creating alliances with the adversaries, circumventing them, or otherwise coercing them into agreeing with your priorities.
He was the “Its better to be feared not loved, if you can’t do both” guy so GP is right when they say his advice here would not be kind. Its because his methods are not really what you want to use to make a better environment at work. Ironically, I think all the problems Machiavelli was concerned with were “people problems”, but he wasn’t concerned with fixing them, just doing whatever it takes to maintain stability for a given ruler.
> After his death Machiavelli's name came to evoke unscrupulous acts of the sort he advised most famously in his work, The Prince. He claimed that his experience and reading of history showed him that politics have always been played with deception, treachery, and crime. He also notably said that a ruler who is establishing a kingdom or a republic, and is criticized for his deeds, including violence, should be excused when the intention and the result are beneficial to him.
"As a consultant, I’m going to be seen as some random guy wasting their time with a meeting."
Yes, he will and that's because he is. His approach may work with midsize companies where word might not get aound. In large diversified one where his specialty is one of thousands? No. There is an industry of consultants who come in with a similar approach promising to listen and claiming that they have the ear of senior leadership. They have no positive impact whatsoever. By the time their recommendations burble up the chain, management will change, and the cycle will be repeated with the next consultant.
Corporate "Safe spaces" are not real. Any manager is a representative of the company 24/7 and everything is on the record. That's direct from my company lawyer's briefing to new managers.
> Corporate "Safe spaces" are not real. Any manager is a representative of the company 24/7 and everything is on the record
I have had a lot of success with knowing this, saying “Great! Let’s go” and loudly complaining about things that are fucked up to anyone who will listen.
This has opened a lot of doors and gotten me into a lot of meetings that I otherwise wouldn’t have access to. Sometimes it has enabled me to change things for the better. Other times it has helped me understand why things are fucked up and appreciate the constraints at play. Then I can drive the best improvements possible within those constraints so things are at least a little better.
Yes it takes years of building trust and a track record of successes before you can do this. Worth the investment.
> Yes it takes years of building trust and a track record of successes before you can do this. Worth the investment.
I built that record. The first time I gave the candid feedback that a project manager requested in an open meeting, I was off the project the next day.
> That's direct from my company lawyer's briefing to new managers.
Just because your company is fucked up doesn’t mean all of them are. Part of the briefing to new managers at my company is how to take critical feedback.
In some sense this could be construed as a good sign. It suggests that management have been promoted to their position based on technical competence and ability to achieve management objectives. I've seen this situation up close and the problem was that while a consultant might find people problems unfulfilling management did too.
It would be nice if tech managers were experts at managing things, but they seem not to be and due to how the tech industry operates it doesn't favour people who are good at management in management roles [0]. There is a high emphasis on playing politics and being/appearing technically productive. Less focus on capable use of basic management skills like fact finding and resolving people problems.
He posted once to HN (https://news.ycombinator.com/item?id=1825352 - but start here: https://news.ycombinator.com/item?id=1813443)
Edit: There's also
Gerald M. Weinberg has died - https://news.ycombinator.com/item?id=17716098 - Aug 2018 (66 comments)