My funniest experience as a pleb on the other end of an executive off-site working in product was being handed a detailed roadmap for the following year, which I had no input on and was politely told to shut up when I raised concerns about it. Specifically why wasn't "Big Feature X" that's been a point of emphasis for the past 4 months and that you made a big deal about being a top priority when I was hired missing from the roadmap? Nope, my job was to "deliver" not to ask questions.
Three (3!) weeks later, after adjusting the teams workload to focus on the new roadmap in conjunction with the Head of Engineering and getting approval on the new plan from the CTO, CFO and VP Sales I get called into a meeting with the CTO, CFO, CEO,, COO, VP Sales, and Head of Engineering, aka the group of Big Brained Leaders who came up with the roadmap that I was responsible for delivering but not allowed to comment on. They then began to attack me over "Big Feature X" - why is it not there, when can we deliver it, how it's my job to define the roadmap and it's unacceptable that we don't have "Big Feature X"...
Recently, I've been breaking into upper management and now that I've seen just how messy it is/was this is a completely believable story. Crazy stuff. As I continue in my career will be interested to see if different organizations handle that better at upper management or is it just the proverbial shit show everywhere you go.
My experience is that the higher you go, the less rules and objectivity exists. You get paid more because you have to navigate this. An e.g. Developer just has to work on the backlog, there might be technical challenges but the requirement is obvious.
Once you get to Exec level, do we hire more to produce more work? Close a department because it's losing money now (but might not in the future)? Do we stick with our current market that we have most of or go after a new one that is untapped but less familiar.
All of this with the situation/world/people changing all the time. People can call it a shit show but the truth is that it's hard. It's hard to put relative values on things to help make decisions. Ultimately, it usually takes a step of faith and the ability to execute well to increase your chances of making your decision work. You also need to balance the need to stick with something and make it work with accepting it was a bad idea and canning it.
I suspect in the very large corporations, it probably gets very surreal because 10 levels of management make the execs completely disconnected from reality so they can make it look like they are making decisions without really knowing what is going on (and most of those might never happen because they take too long to fall down the soil pipe!).
Some companies are clearly run better than others, this is mostly apologist nonsense.
What really goes on is that the goals of executives is different from that of people who actually do things, and paradoxically, the ones who actually do things tend to be valued the least.
But that is a failure of middle management. Middle management's main job is to get the ones who actually do things the tools they need. That includes roadmaps that make sense, etc. That also includes showing upper management the value of the opinions of the ones who actually do things. Upper management is not the advocate for opinions, they are the decision makers who base decisions on what they have been fed. Middle managers are the advocates for the opinions of their people.
Ironically, TFA highlights this as a common anti-pattern:
> Don’t stop the deep-dives. Sometimes executives get confused (or are too afraid) to step on toes and so avoid getting into the weeds. It’s seen as a waste of time or somehow not practical to spend the exec team’s time discussion “lower level” things. But where there are critical initiatives (see John’s point about points of leverage) I think you should get into as much detail as you can.
The more execs gloss over details (e.g., technical challenges, requirements), the less valuable (maybe even more dangerous) their plans become.
I've worked at several companies now, sometimes in a management role. In my experience it's always a shitshow filled with people making things up as they go.
One key difference is culture. Some cultures punish candid honesty which leads to reasonable people resorting to politics and blame games.
Not sure how to spot this when you're applying, but good culture seems to be correlated with competent and respected technical people in upper-management and lots of devs/engineers with a long tenure.
My most negative experience has been with business school grads, meaning BComms with MBAs whose experience is in the finance or accounting departments. Seems the culture is about doing what you're told and CYA rather than critical thinking that come from a solid STEM background.
It reached the point where I now believe any BComm who wants a leadership role should first spend 3 months shadowing the cleaning staff. Once that person convinces the staff they're capable of not setting anything on fire, they can be allowed to mop the floors for the next 3 months. So on through the organization until 10-15 years later they're deemed qualified to think independently and understand what taking responsibility means.
Again, could just be select negative experience, but it's what I've noticed
I have had both good and bad experiences with MBAs and other business school grads, but I could say the same about STEM folks. I agree there are major cultural differences (i.e. BS from engineers takes a totally different form from BS from MBAs) but I think the more salient problem is if your management team consists of nothing but a single background.
If a tech company is run by business and finance folks it can become unmoored from engineering realities. But a tech company run by engineers and scientists can become similarly unmoored from business realities. In my experience, companies that promote well-respected members of their key disciplines into senior management roles seem to be the least dysfunctional.
1. This is what happens when there are non-technical folks in the upper-echelons of an organization. The CTO should have highly technical backgrounds and should be able to do the work they’re pushing down to the rest of the engineering staff; however, oftentimes, they cannot and/or never could because their station comes from business acumen, not tech.
2. Now, there’s the other side of that where you have technical leaders who can code but cannot effectively communicate and/or make it known to other leaders why requested roadmap items are not feasible, possible, etc. This is a very common scenario where technical leaders are not great at communicating to other business leaders and making realities known.
The third issue is when a technical leader draws a line in the sand and gets sacked because the rest of the leaders hate having their ‘vision’ quashed. This leads to #1 and #2, above.
> This is what happens when there are non-technical folks in the upper-echelons of an organization
The described behavior can be found in non technical organizations as well. A room full of people will never blame itself, they will always blame someone not in the room (or failing that push someone out of the room and blame them). In group VS out group behavior[0][1].
You could tell the same story around a lemonade stand, "Looks like we are going to be busy next week, should I order more lemons?" "no, we ordered plenty", a week later "Why didn't you order more lemons!".
It's not a technical problem in the slightest, or even a human nature problem, this stuff was wired in when we were early primates.
I used to believe this too, but I've worked in multiple organizations now where there was no shame associated with assessing who or what factors contributed to project failures. The primary desire was to understand them accurately to mitigate those same failures in the future.
Ultimately it comes down to the organization's culture and whether failures are punished or accepted as a necessary side-effect of doing ambitious work.
Another pattern I've seen is that the CTO is technical and can do the work, but all their experiences actually coding for the company is from the early days where releasing half-baked bug filled messes was the standard. As the organization grows, maturity around quality, security, reliability, etc. increase but they still have an internalized notion that the company should be able to ship product "like the old days".
Alternatively, the slight variation where even shipping good clean robust code was easier in the old days because the product was much smaller and didn't have years of accrued product and technical decisions to work around or unpick, all of which were good at the time but don't work a few years later.
The "maturity makes things slower" thing can apply even if the quality of code was always good.
Then there's the 3rd issue, where everything has become a moat and it's just not worth the effort of trying to do a good job anymore.
I've literally seen things that should take an hour be weeks because it ended up involving 10 different teams. And while you may think that's an exaggeration, it's not.
software is often used to assert authority so people CAN'T even attempt to work around these issues. Paradoxically, software can actually make companies less effective.
Agree with everything, but I wouldn't be too strict on the requirement that the CTO be able to do the work - within reason and depending on the org. They definitely have to be able to understand it and have an intelligible conversation.
For example, my current place does hardware and software - CTO comes from the software side so he's not a specialist on the hardware and can't contribute directly to the electrical engineering work. But at least he knows how to ask the right questions, learn when he needs to, and got the right people under him to get the job done. And to your point, he has no formal business education and our CEO is the founder, and an electrical engineer
Yeah I flirted but after that experience I moved on to a couple of other places and started to pay closer attention. Trying to be a competent higher-up is not worth the headaches. I'm happy to find my niche at a place that pays well, delivering just enough to whatever higher up is asking for it so people stay happy with my performance to say "he's a good guy!". Side projects are where I get my personal sense of accomplishment these days
I've had interactions with upper management some times and agree. I had an older boss who explained that part of his job is to politely head off bad decisions before they get too popular. It's not a people skill they usually teach in management/leadership training for obvious reasons. I guess it falls into the whole "managing up" communication.
Yep! I remember as a (very) junior dev being told that I was 'responsible' for product documentation. When I asked what I had to do, I was told "nothing, you're just responsible". And like you I got grief when things weren't as they should have been.
I think they used to call such people "whipping boys"
I did, but like I said I
"was politely told to shut up" and "my job was to "deliver" not to ask questions.
This was raised in one on ones with the Head of Engineering, a weekly group planning with Head and CTO where it wasn't me but the Scrum master putting forward the question, then again as asides with the sales guys. This was a systemic issue with how the company was run and who was selected for leadership
Variations of "stick with the plan" and "we have visibility you don't".
Keep in mind I'm an already experienced Product Manager at this point brought on specifically because I had a proven background in full product lifecycle, revenue growth and communication to higher ups at companies running on the 10-100MM revenue and profits in the 10% range. I got there because I know how to schmooze the C-suite. I appreciate you're trying to turn this into a "work on your communications skills to get ahead"
coaching opportunity but this was not the case. It was my first, and I hope only, experience with yes men being thoughtless yes men.
I asked because you ended the story somewhat early, which was a bit unsatisfying.
Now I suppose you could humor these folks and look a bit foolish all the while collecting big paychecks. Or you could nip it in the bud at risk of souring the relationship. Believe I’d choose differently depending on how old I was at the time.
It’s on my mind because last night I watched “the bodyguard” (final night on Netflix). Main character nips all bullishit in the bud immediately, increases his rate by 1/3 and gains respect at the same time. Have to deliver however.
Yeah, it was tough because the CTO was either a flake or already checked out and the Head of Engineering was a brown nose who would do whatever the last executive told him to do. Totally different reality from the answers I got at the interview.
In this situation, unless you have a spot in the C suite, or a defender, you have to play ball because the decisions happen behind your back.
It was very disheartening because it was clear being a yes man who steals the credit and finding fall guys got you ahead. If that's the culture, there's really not much you can do but play ball or leave. And if you're not "in", playing ball means getting all the blame. I wasn't "in", but luckily since most conversations were over slack or email I always had documented evidence that they couldn't deny. But the people responsible wouldn't be held responsible.
Again I've been at a few places, and I've never experienced anything similar, and I hope I never do.
Another example. Supposedly the CFOs office was providing usage stats in presentations to clients, which I found odd because we only starting collecting this data shortly after I started. One day an underling from the finance department sends me a message saying they need the data for the next presentation happening in a few days... I ask what's needed since no one showed me one of these decks. We don't actually collect a good chunk of the data that are in that deck, and of the ones we do, the data from my pipeline doesn't match at all. Underling freaks out and says we can't present this, it will raise too many questions! (That's literally what she said)
As usual, I get called into a rush meeting where CFO reams me and Ops for having changed how we collect data, and this is squarely on our feet. We're remote at this point so me and Ops person start digging, and it turns out the data they present are effectively numbers the VP Sales pulled out of the air in the early sales days. Based literally on nothing.
At this point ops and I were able to provide enough documentary evidence on the topic that is clear the people responsible for these decks were making it up. Because it's the CFO and VP Sales, nothing happens it's all swept under the rug. They gave two more presentations to other clients with the fake data by the time I left. Apparently the practice stopped after a bigger company bought them out and both were shown the door
Experiences like this one affirm me to send brief emails for documentation.
“Is it true that we are winning clients by presenting usage statistics? Did you know that we recently started collecting that data in an organized fashion? This might save you time when you’re looking for updated figures.”
…or the original problem:
“Thanks for the updated road map. Accordingly, I just made sure that all tickets related to big feature x are marked as obsolete.”
The last executive offsite I went to was with a company that had a severe problem with focus - we were always chasing 10 trends at once and never really accomplishing any of them.
The main output of the offsite is that we came up with a list of around 30 different things that were essential to nail in the next year. The 30th? "Relentless prioritization"
nobody gets praised for shooting down other people's ideas or saying "lets do less". Everybody has their own pet idea that will surely bring in a bunch of money so more and more stuff just gets added to the list
At my last company, this was so common and painful that towards the end of my tenure we started using a “No” roadmap, which was a list of things we would explicitly not do. Shooting down an idea is hard but sometimes people would go around and try to get a team working on it anyway as hidden work.
Added benefit, off site execs have less opportunity to get in the way and mess up things as long as they are occupied with leisure and playing politics.
In my experience, they shouldn't be about work at all. It should be a bonding experience. Better if there is a non-work task to be solved, or to work for, together.
As a technical person, I bond by working with someone and talking about technical stuff during the course of our work. Forced social activity has always alienated me from coworkers because I can't relate with people that want to talk about their personal lives or sports or whatever and I suck at pretending.
I would take a pay cut for a company that promises to not force this shit on me.
I think what works really well for these sorts of offsites is to make leisure activities really flexible and let people self-select. We went to one where you could absolutely go to a bar if you wanted, or go hiking with some other folks, or play boardgames with another, etc.
There was probably a soft expectation that you were doing something to socialize, but it wasn't a dictated activity, and frankly if some people wanted to code something with a group that wasn't 100% part of a regular days work that would have probably been fine too.
I don't go to a bar or do stuff like that. At most maybe we can watch a movie or something but even that isn't an experience I want to share with a coworker. Even working on a cool app with someone is nice but not if they are a coworker unless somehow we genuinley became friends as in the kind that stay friends after they leave that company.
Employees do work in exchange for compensation. We are not servants to jump at the whim of our master managers and do random shit like kayak or shoot guns. You wanna build a team, ask them to work together on a project.
Boundaries are important and my entire life is not shares with employers and colleagues.
I would try saying not engaging in the forced social activity, find a quiet corner with people you like and do what works for you. I used to think I couldn’t get away with it. Years later I appreciated as long as you don’t flaunt it, people are very accommodating.
And you know what? I usually know the names of coworkers' significant others, children, and pets. And what their favorite foods are. And some hobbies and interests. Because those just come up in the course of work even when it's not forced. Especially if meeting with people is through a videoconference window into their homes.
i am also a technical person and work on small teams generally. my take on team weeks/retreats is that they’re unique opportunities to get to know the people you work with more closely and what motivates them.
doing the same work you do 40 weeks of the year, just in person, is a severe wasted opportunity. pair programming remotely over video will accomplish the same thing.
i also want and expect technical conversations to happen during that time. what i’ve found works great is that you do other stuff, hackathons, lightning talks, and yeah, some of the stuff you hate, forced socialization or activities. in my experience this leads to great conversations and ideas over dinner and leaves us all excited to get back home to get back to the “regular” work.
Let me ask you this, why do I have to get to know people? Because I certainly don't want people at work to get to know me and when forced I have to make stuff up basically. We are not a "family", family don't get to fire each other lol. Most of you on HN are programmers, so let me ask why you need to know about a persons life to code with them? In my experience even at work people go out of their way to avoid technical discussions. Many even refuse to do their job unless you become their best friend. I expect mangement to weed bullshitters like that out not encourage it by mandating forced bullshitting basically.
That’s usually a big part of it. Typically people in these positions don’t interact closely, but may be competing for resources or promotions. You want to discourage a culture where people are trying to kill each other.
Getting everyone together helps with that and takes people out of their daily context. For a company that prints money, sending everyone to some luxury resort is worth it. Where I work, we went to a local picnic grove and had barbecue for a day.
Other tax systems may vary, but in the UK if you have an offsite and it's not overwhelmingly for work (think agendas, sessions, meetings, etc. as proof) - the employee gets taxed on the value as if it was income.
There are ways for the employer to meet the additional tax burden, but far easier to just add in a work component and call it an offsite.
Sometimes with spot bonuses though the employer can “gross up”, and I’ve more rarely (but a non-zero number of times) seen that applied to other “taxable benefits”. By grossing up they are essentially just paying you additional compensation sufficient to nullify the taxable impact on the employees wallet.
When I was at Google in the bay area almost a decade ago and, unless my memory is heavily exaggerating, the executives of our org were in an offsite every three weeks for at least a year working on 'strategy'. It became a meme at the time among us lower ranks and I was amazed at the excess. There was no noticeable output from all those offsites and as an org we failed to execute on anything successful. I have had a low opinion of offsites ever since and have wondered if other people thought so as well or it was just me being cynical.
They're good for teaching a McKinsey 3 horizons model and realizing you're stuck on horizon 1 for 5+ years because you never cared to get input from the line who actually does the work and has something to say.
A team off-site is infinitely more valuable at the same cost including more people and less BS consultant frameworks.
What really should happen is after these off-sites, a cross-comparison is made and executives can get reality checks that work aligns or it doesn't. That way there's no surprises when people start leaving or nothing gets done because too much is expected in a just do it fashion.
Executive Off-Sites are good for paying for a luxury all expense paid trip for the executives where they can go ahead and have affairs without their wives being around.
I feel that executive off-sites will be better discussing cultural/operational shifts the company should make in the coming year and perhaps broad themes for success rather than going deep because most people will just doze through it.
So there is lots of grouchiness in this thread. Maybe I'll try and give some comments on how these can be productive.
I'm in a remote working firm that provides IT services. We get together as a leadership team once a quarter to review what was and wasn't completed the previous quarter; review operations metrics, discuss changes in the business environment; and build the plan for the next quarter.
On a yearly basis, we do a bigger strategy session to really think about our marketing position, our offerings, our competitors and so on. The fancy strategy so to speak.
It's good for the group to be in person as the conversations can get difficult at times and it's easier to have them without having to mediate through Zoom. We also use it as a chance to do relationship building and to handle some tactical issues that need a hand.
We don't do go anywhere fancy - we usually rent a conference room offsite as our office doesn't have a lot of conference space.
Implementing these sessions has led to much better execution overall against our plans.
Yes, we're about 100 people in total with a leadership team of sevenish. Adding the regular offsites has actually increased accountability and ferreted out who is effective and who is not; and ended tolerance for those who are not.
It would be interesting to see long-term results of off-sites in which a company's executives and an equal number of long-tenured average-performing and high-performing employees gather to share and learn from each other, with follow-up on-site meetings to experiment and execute afterward.
I have never encountered an off-site like this, but if you have, how did it go?
I think periodic off-sites (or on-sites in the era of remote) are incredibly valuable even without a specific business issue to address.
It's easy to say that strategic thinking and planning should be continuous, but in reality there's always a storm of immediate tactical tasks sucking up your attention. That's true for both software engineers (living in Jira tickets, sprints, and one-to-two quarter projects) and the c-suite.
These sessions can force you to make time, put aside the tactical noise, and think.
That is true! And I get it that calendar years are easier to get your head around (2023 plan rather than specific dates).
By continuous I mean end of year shouldn’t be to special, you could have a rolling plan and amend it every month with offsite when it is felt that brainpower is needed and especially more grassroots input is needed.
I prefer the idea of a solo offsite better. Well, something between an offsite and a holiday. A time to think deeply about your business / market / customers / future, whatever it is.
All hands off sites in "remote" companies are so often a way to make up for the ways the company has failed to implement a stable async remote culture.
"Let's get together every quarter (!) to talk about all the things we can't figure out how to talk about remotely"
I'm a cofounder of a start-up that is all remote but does quarterly get togethers (though attendance isn't required).
I think that the software development team in general is ambivalent about them and happy to just work from home.
But the other areas of the company seem to really enjoy getting together to socialize and interact with their co-workers once in a while. A lot of people want some level of human connection with the thing they spend the majority of their waking hours doing and really hate being isolated and never meeting their team in person. Preferences of course vary by personality, age/living situation, type of work, etc.
So I think it's a little unfair to say that the only reason people have off-sites is because they can't figure out how to effectively work remotely. Different people like different things and need different things to get satisfaction from their job.
Your paragraph about what people "seem to really enjoy" is just a restatement of the grandparent's "make up for the ways the company has failed to implement a stable async remote culture."
People are different and software developers are notoriously asocial if not antisocial.[1]
Their desires shouldn't be extrapolated to the general population, since even the most tech heavy company will at point need to have HR, sales folks, marketing folks, recruiters, program managers, project managers, on site consultants, technical writers, etc, etc, etc.
[1] On average, this is based on anecdata from my personal experience and tons of discussions with folks, reading books, blog posts, etc.
I've been working remote for nearly a decade and find quarterly offsites super helpful. Things like brainstorming about loosely defined problems and just getting to know your colleagues happen at a rapid pace vs remote.
They don't need to be "all-hands" though, the way I've seen it done that I like is 2 offsites with my direct team and potentially 1 more to team up with, 1 offsite with cousin teams, then 1 offsite with a much larger group—maybe the entire company.
In fact this is something I ask about in interviews: I find quarterly to be the ideal balance between being productive at work and not being away from my family too much.
I used to want to meet more (before I had a family) but I learned to make a list of the people I want to talk to and the conversations I want to have ahead of time which really helps me make the most of our short time together.
Tbh, in a remote company, I would call this an "on-site" even if you don't have a home office to go to.
My previous company, we did the fully remote thing pre-pandemic and had a good culture, but I found meeting up once a quarter was really effective.
Reasons why:
1- No one has solved the remote whiteboarding problem. There is nothing quite like a few people sitting around a whiteboard, drawing pictures, looking in the whites of each others eyes to see if they really understand, and debating the tradeoffs. You can simulate this remotely, but its just not nearly as effective in my experience. In general, I found that about once every 3 months we would have a pile of problems and things we are seeing as potential problems on the horizon that we want to brainstorm on how to fix in a way that chat did not facilitate well. In fact, I would send out a list of these items ahead of time so we could deliberate on them and then present ideas. Things like: "We seem to be generating a lot of metrics that cost a lot of money to store and we only use them when debugging thorny problems- how do we try to make these smaller/more useful?"
2- Text communication is great to a point, but sometimes perceived slights can build up, or maybe someone's communication style is just off putting to you, and you start to build up animosity or perceive there to be animosity that just isn't there. Breaking the ice by just talking to the person in person almost always makes that friction go away.
2a- Often you work with someone and may think they are not performing, or not very smart, or an **hole or whatever, and sitting next to them for a day or two makes you empathetic to their situation as you see how many times they are getting pinged by other teams/people. Sometimes sitting next to them makes you realize they really are a problem and you can start focusing on your efforts on routing around that.
3- It lets you get to know people socially. I find that as we move into an ever more surveilled environment, just talking over slack becomes an ever more fraught endeavor. Discussions about the difficulties your kids may be giving you or the fact that you had a little too much fun last weekend are now archived and mineable for more or less forever. It just puts a real damper on making a connection with your team mates. I have a real example of this at the end of this post.
4- Its fun? Getting away roughly once every three months and spending time face to face, in a new city, is generally pretty enjoyable. We would try to do a different region each time so that no one was stuck traveling a far distance all the time- and in the cold winter months, we would try to go to a warmer location, and vice versa. The ability to socialize with coworkers outside of coworkers was always enjoyable for me.
Real example of socializing on work channels gone bad: At a fairly brutal place I worked at during the pandemic, which reluctantly allowed remote work, I was chit chatting with a coworker I was friendly with, and mentioned how I had had to work the previous three weekends, which was really grating on me, and I had pushed back on checking out another change the upcoming weekend because I needed a "Mental health weekend." This got flagged by some system, next thing you know I am getting a call from my boss asking if everything is ok, and he wouldn't admit at the time, but they were actively surveilling our messages and looking for stuff like this amongst other things mostly related to IP theft, insider trading, etc.
People typically think of them as extravagant trips, but not always the case. When we did them we would go to one of the members houses nearby for the day twice/year after the prior 2Qs financials settled. We would deep dive into how the business was doing and make sure big picture strategy was still on point. For us anyway, it was the only time to get us all in a room without interruption for a day.
So you've been to several, I see. Did you successfully subvert the paradigm shift to deliver transformative innovation in a black-box containerized interface?
I think you and nprateem need to circle back and have a quick sidebar to collaborate on strategic initiatives to inspect his/her ability to move the needle in terms of the paradigm shift to ensure the organization can gain leverage from efficiencies across the various stakeholders. Be sure to keep me looped in, but I’ll be OOO this week and won‘t have the bandwidth to discuss until our next touchpoint.
My off-the-cuff answer would be something like "they give people who work for a living a valuable chance to do so without interference while the management are off somewhere else".
Three (3!) weeks later, after adjusting the teams workload to focus on the new roadmap in conjunction with the Head of Engineering and getting approval on the new plan from the CTO, CFO and VP Sales I get called into a meeting with the CTO, CFO, CEO,, COO, VP Sales, and Head of Engineering, aka the group of Big Brained Leaders who came up with the roadmap that I was responsible for delivering but not allowed to comment on. They then began to attack me over "Big Feature X" - why is it not there, when can we deliver it, how it's my job to define the roadmap and it's unacceptable that we don't have "Big Feature X"...