A very good lesson I learned from a previous company (medium size, 1-2K employees) where a C-Level exec was hired in and needed to make some large scale changes in the company with speed:
1. You can't "fake it" at this level. One of the most impressive things IMO about this exec was his ability to know, at a fairly low level, what every department and org in the company was doing, and to diagnose their strengths and weaknesses very quickly. We'd have quarterly day-long meetings where every department would present, and his ability to quickly hone in on critical low-level details was extremely impressive. I think he would have failed if he had just thought that his job was to "brush with broad strokes". (Aside, this did NOT mean he was a micromanager, it just meant that he had a very good understanding of the details across many departments).
2. It's important to put some structures in place where departments are forced to show some accountability for speed. For example, one metric that I actually hated at the time, but later learned to appreciate the purpose, was that individual departments were judged on the number of A/B tests they ran per month. I hated this metric at the time because I felt it was easily "gamed" - departments would run small little A/B tests like button color changes. However, after a while there were a couple of big cultural changes that had taken place: (1) the company built tools and processes that made it easier to deploy and run tests in the first place (better CI/CD pipelines, better analysis tools, etc.) which had the overall effect of letting us ship faster with higher quality, (2) while yes, there was a lot of "gaming" of count of A/B tests run in the beginning, it didn't take that long for teams to actually run out of tests to game, and people actually put in the hard work of thinking about better tests to run, and (3) it changed our culture to become much more data-driven - it wasn't perfect, and "data driven" can be a double-edged sword, but it was an improvement.
Thanks for sharing the second part! I’ve worked places as a DS where we were ramping up A/B tests, and it’s honestly one of the worst experiences a DS can have - everybody is asking why you need such large samples, then when you get null results, everyone wants an explanation for why (“this idea didn’t do what you wanted it to” isn’t an acceptable answer), etc.
You’re entirely right that running a bunch of tests is a really effective way to advocate for better resources to run the tests. While I’ve never worked anywhere that ran out of ideas to game the testing incentives, it’s definitely true that people who initially fall into the trap of gaming the tests come around with some experience and in general the org builds better intuitions and culture around how to use tests.
It may be that an org that _has_ a culture of testing just has them constantly running in the background but they’re minor in terms of time spent running them, but that building a culture of testing initially involves the whole org focusing on it to a seemingly ridiculous extent, as it’s the only way to generate enough momentum to get the infrastructure and institutional knowledge right.
I watched an org limp into better A/B testing as slowly and painfully as possible. They knew why it was important but just weren’t in a hurry to get there.
I can see all of the organizational side effects that would come from a metric like this and the upside far outweighs the downside.
A lot of senior management isn't about specific outcomes, but building muscle memory within an organization that evolves into workflows and processes that level up the company. A favorite quote of mine is "leadership is holding a vision long enough for someone else to realize it for themselves."
This is excellent. I also like to use the phrase (to myself as much as anyone else) “keep repeating things until you hear your words used by others”. It’s not until people are saying things back to you as if they were their own ideas that they have fully internalised what you want.
That particular idiom is just something I’ve worked out myself, rather than coming from a particular book. But if you want a recommendation, then I’d start with this [0]. It’s the book about leading engineers that I always wanted to write. I can’t recommend it highly enough. And for a bit of shameless self-promotion, I also wrote a blog post [1] a while back on good books for engineers to read (from non-fiction to fiction). You might find a few good tips in there.
In a broader sense you can't really take this advice and roll into a CTO role and repeat it. The problems are going to be different everywhere, even though the result might feel the same: Some 'slowness' at these congealed organizations where things aren't moving to the naked eye. That's where the similarities usually stop. You have to talk to the executives to figure out what the perceived issues are, and then talk to your staff (and skip all the way to the implementers) to figure out what their issues are too. Only with a full picture can you figure out what the problems are, and what some potential solutions might be.
* You cannot rely on people to provide face value suggestions or problems because politics is actually a thing.
* You cannot rely on people to provide meaningful action items because incentives are usually misaligned.
* The whole team will probably know about a division or group that needs to be fired and nobody will do it; if you don't then you immediately lose face.
* Companies at this scale usually value predictability over speed. So building reporting structures that values said predictability works wonders.
This comes up every few years and it is important to note that the opposite is true. Most unhappy families have drug abuse or interpersonal abuse at play. Most happy families are happy and fulfilled for a variety of interesting reasons.
I try and look at companies today as beasts trapped in the middle ages, trying to break free. I think that software literacy is a great lens to view the changes coming, but as well as that I think plain old democracy is a great way to view these things.
A company with 30,000 people may as well be seen as a (very small) country - and it may well benefit us from trying to run it in the same democratic manner.
A top down hierarchy is how most companies are run and most especially rewarded. The CTO is set up here to basically tell people how it is going to be and what to do. he can't - so try democracy:-)
Edit: I think the democracy argument matters because of the inherent near-socialopathic approach inherent in the CTOs position - "I as a C-level exec want to find people in the organisation who will work hard to transform it, but will not receive anything like the inherent rewards (I will), but without whom ..."
The solution to Kings and Tyranny is not highly trained Kings with great people skills.
It's interesting that companies are these little island command economies inside the market economy.
Is there a better way to organize them? Would democracy really work? In countries, many consider democracy to be actually worse than an excellent dictatorship/monarchy. But it's a hell of a lot better than the bad ones. And there's no way to prevent a good dictatorship from going bad. Just because the king did a good job, doesn't mean his son will.
Democracy only works as well as the voters are educated and participate. Companies would seem as vulnerable to that as countries are.
Employee owned businesses tend to outperform more traditional top down business models. [1]
The reason we don't see more of them is because employee owned businesses have a hard time existing at the startup phase. That means, you have to transition from a somewhat top down structure to employee ownership. Guess what C levels DON'T generally want to do.
Certainly not to say that democracy would definitely work. You'd probably need a seniority/trustworthiness modifier on votes to really be effective (can't have the Junior devs proposing dumb shit and winning simply because there are more of them).
That being said, a lot of opensource projects are run democratically. That seems to be a good signal for an open source project's longevity.
On the contrary — almost all early-stage startups are part-employee-owned. The meta-analysis of firm performance you're linking to references specifically companies with ESOPs (employee stock option plans); the stock options most early-stage startup employees own are usually higher percentages of the company on an individual basis than public-company ESOPs.
IMO, that's one of the huge advantages early stage startups have over larger companies. Employees are highly incentivized to work together to make the company succeed, rather than climbing internally to higher positions by stepping on their peers.
> almost all early-stage startups are part-employee-owned.
I've never seen seen a startup where more than about 10% of shares was in the hands of non-founder employees and even that was an outlier. Dilution during funding rounds can often reduce this number even further. When talking about employee-owned organisations, we usually talk about companies where > 50% of shares are in the hands of employees. I agree that the study linked does not target that group though.
The biggest problem with employee-owned companies is that there is (by definition) no single person who can push through risky initiatives, so while they are often more stable they also tend to stay medium sized as it becomes harder and harder to develop risky new business units as the company grows.
That's why I said "part-employee-owned" and not "majority employee owned."
(FWIW, at least back in the early 2010s when I started a company, reserving 20% of the company for employees was pretty standard for early-stage startups. It's possible things have changed though, and it's true that dilution will drop that number.)
Is there a specific reason you exclude founders as employees? In the earliest phases of a company they're remarkably similar to "employees" in even like Series B companies... (save for ownership structure)
You say "save for ownership structure" like it isn't the most important thing in this case :)
Because of their majority ownership, the power balance is very much different than with normal employees. It is typically not possible for employees to band together and fire a founder, but it is very possible for founders to fire employees. The risk assumed is also different: founders often put up significant chunks of their personal capital to get off the ground, but I have never heard of a startup employee being asked to put in extra money in order to get hired.
Democracy is easily captured by moneyed interests, unfortunately, which within companies gets called "politics".
I've had much better luck using the techniques of social anarchy. We all generally want the same thing, we are in pretty stable communities, and there is a lot that can be accomplished by facilitators & organizers offering people the opportunity to opt in to certain kinds of improvements. You don't need power-over to bring about change.
Oh I agree - I would suggest that most companies are if not corrupt then corroded. Weirdly I see Elon and SpaceX as an example - NASA found itself unable to escape its own corrosion so intelligently found ways to put its own engineers (I mean who else did SpaceX hire?) in a new organisational form. For ten years that managed to avoid "corrupting" the original vision, probably through sheer force of Elon firing people who weren't drinking the kool aid. Which works fine as long as his is the right kool aid. And something something unions, employees rights, decent conditions.
But anyway - getting out of the wrong organisational form is well hard, and staying out seems ... impossible.
Perhaps the simplest solution is to make a limit to the amount of time a company can exist for. Ten years and then tear it down and return capital to the owners.
It might force rebuilding and recreation into staid forms.
It's unlikely but there we go - I am just amazed as Inlook around that we have a mono-culture of organisational forms globally.
So after ten years, no more Apple? Too bad if you still want to buy an iphone or you want support on the one you bought? Do you think this stuff through?
I think we need to ask what part of the tech-growth S curve does modern civilisation sit? After coal, oil, electricity, chemistry, medicine and silicon, is there another big driver out there? Or are we flattening out and need to find ways to sustainably share control and wealth and opportunity?
Why do you think a tech-growth S curve is the right model for civilization? Companies plateau and then eventually decline as do cultures and countries.
Because everything about the last two hundred years has been explosive tech growth - and the countries who were players in 1800 are basically the same players today (plus the two startups Germany and Japan from 1860s) - they all just held on through steam, turbines, internal combustion and electrical.
What chnaged in those countries and cultures that was not driven by (at minimum) power generation methods?
Plus it may be an observation (I agree with) that companies eventually corrude and decline - but why? what is the mechanism - can we observe it? Chnage it?
Not really though. Portugal, Belgium and the Netherlands were major colonial powers in 1800 and are bit players today compared with how they were back then.
Plus Chinese historians will have you believe they've been the first civilization around for 5k years. (the truth is there has been rise and fall, but each subsequent one claims to be the _real_ dynasty and so continues from the beginning) so is China new or old?
I think the truth is geographical places rise and fall multiple times. They go through cycles both internally (need, growth, comfort, decay) and externally as their characteristics are useful/useless to the greater world around them.
Eg: I doubt China would have established its current power without inexpensive labor, telecommunications, and American debt fueled consumerism. Had China been a middle power in like 1900-1950 then another country might have absorbed the USA's consumer demand
The last paragraph is key. It’s a long term investment. There are companies that are run democratically, they typically grow slowly, but are more stable.
Let employees vote to fire their managers, possibly up to the c-suite (though there may be contention with the board having this control). Keeps management aligned to the employees interests.
I do think this is actually a viable option. Possibly inevitable. And would necessitate actual discussion internally. More so than happens today at even the most "open• companies
Unions are adversarial organizations designed to balance an existing structure that can't be easily removed, but this is about "if you were inventing a new kind of organization that didn't need an adversarial structure, what's the best way to do so?" and you can do much better than management-vs-union there.
Not an expert, but my understanding is that German unions are collaborative with management and not adversarial. Not common, but it would disprove the direct link and make it more of a strong correlation.
Happy to be shown how my understanding of the German system isn’t correct.
You're probably right, but much of HN tends to take a very US (or even very silicon valley centric) view of things. In the US the narrative (and maybe the truth too, idk) has been set up of Company vs Union. I suspect it's been made polarized so that the 2 party system can take advantage of what side they're on.
> The solution to Kings and Tyranny is not highly trained Kings with great people skills.
This is a wonderful quote! Is it yours?
I think you’ve captured the problem perfectly, but I’m not sure democracy is the solution. Democracies don’t seems capable of distributing rewards in any sensible way. I think Plato’s philosopher kings may be the best we can do.
I am dubious. The whole point of having leaders is that they're supposed to talk to each other and coordinate the different needs of the different teams. Which is more important to accomplish by EOY, to adopt k8s or to ship the new feature? There is an objectively correct answer to that, and ideally the leaders should be able to talk to each other and agree on what it is and plan accordingly.
What kind of bottom-up "democratic" process would accomplish that, when the Sales people don't know what k8s is or why it's useful, and the Devs don't talk to customers about what features they most urgently want?
> Which is more important to accomplish by EOY, to adopt k8s or to ship the new feature? There is an objectively correct answer to that
This doesn't really negate your point, but what do you mean by objective?
It seems to me like this would depend on a number of factors, like
- How much time you stand to save in the long run by switching to k8s.
- How much revenue or growth you stand to gain in the short run by adding the new feature.
- How much you prioritize the long run versus the short run.
Of those factors, the first two can only be vaguely estimated; you can gain more information by having sales and development talk to each other, but ultimately someone needs to make a fairly subjective judgement call. And the third factor is even more subjective.
Indeed, I'd argue that ability to handle subjectivity is a strong point of top-down processes. For questions with an objectively correct answer that can be discerned through discussion, there's less need for such a formal and rigid structure; the group of individuals who care most about the specific issue (who may not all line up neatly on the org chart) can meet and hash it out. It's when people can't come to an agreement that it helps to have someone above them to make the decision.
I was using that term kinda loosely, I didn't mean there's nothing subjective in a decision like that. I used objective to mean the POV of the whole company, and subjective to mean the views from within the departments. A salesperson says, "we need this feature because X", and a dev says, "we need k8s because Y", and someone outside those perspectives needs to decide whether X or Y is more urgent. That might happen collaboratively (all the leaders go to an offsite and come away with the same opinion) or combatively (they can't agree and the CEO has to make a tough call), and they might get it right or wrong, but they can't even attempt it if they're looking at things from the subjective view of one dept or the other.
So I was asking OP, how does that happen in a "democracy" company? Presumably the employees vote on it? And if Sales has more people than IT, wouldn't that mean that the company would invest more and more in Sales even when the problems of IT are more urgent?
what if there is a org form (democracy) that is 5x or 10x faster better more flexible than the hierarchical one we are all living in? I mean we all work in modern companies. no one can believe this is the best that can be. But where are the experiments and new forms being tried out. And no, DAOs barely count.
While this is an interesting piece overall, based on the title I'm struggling to find the "action plan" part. The "lesson's learned" section is just statements, not even suggestions.
* Large companies often have divisions and functions with innovation, incubation and technology scouting all operating independently with no common language or tools
* Innovation heroics as the sole source of deployment of new capabilities are a sign of a dysfunctional organization
* Innovation isn’t a single activity (incubators, accelerators, hackathons); it is a strategically organized end-to-end process from idea to deployment
* Somewhere three, four or five levels down the organization are the real centers of innovation – accelerating mission/delivering innovative products/services at high speed
* The CTO’s job is to:
* create a common process, language and tools for innovation make them permanent with a written innovation doctrine and policy
* And don’t ever tell anyone you’re a “short timer”
The only actual suggestion in there is "create a common process, language and tools for innovation make them permanent with a written innovation doctrine and policy" but it doesn't really say how to do this or go into detail about what this might look like.
> but it doesn't really say how to do this or go into detail about what this might look like.
I think that's because for each organization that is likely going to be different. It may be enough to simply push to product that "Hey, we need to also spend time on new innovations, not just day to day feature grinds" and lay out plans to get those greenfield innovations prioritized and deployed.
It may be the case that the innovation is around infrastructure "Hey, we are deploying to Ubuntu 14.04 VMs with an inflexable infrastructure. Perhaps we need to start working towards something more modern and flexable?" That will look very different from just giving PM time for innovation and may stop development from making meaningful innovations.
The point of the article, I think, is to provide a path and light on innovation and not leave it to some dark development corners where innovation is a "don't ask don't tell" sort of scenario.
He’s a Microsoft careerist engineer who rose through the ranks to be in charge of Office through the ambitious “Ribbon UI” redesign, then was appointed to salvage the Windows and Services segment as the Longhorn/Vista debacle was close to shipping. His latest entries describe the sorry state of the Windows org as he came in, and the initial actions and goals he set to rectify the ship.
In hindsight we know that Windows 7 was a success under his leadership and 8 wasn’t, so even though his style is a bit rambling, it makes for good reading to try to understand the decisions that put Windows on its course.
> Anthony had long come to the same conclusion I had, that highly visible corporate incubators do a good job of shaping culture and getting great press, but most often their biggest products were demos that never get deployed to the field.
> As we were finishing my coffee Anthony said, "I'm going to let a few of the execs know I'm not out for turf because I only intend to be here for a few years."
One ought to know, 'tis but a game of poker, mister.
I previously worked at a large enterprise software company. The CTO is smart, but talks expletives all the times and is not approachable beyond their inner circle. The people around the CTO effectively control the access and because of their attitude no one dares to challenge or propose anything newer than whatever exists.
Everyone used to hate the work in private conversations. But the CTO effective chose to stay on their own island, only communicate with people around them. There was never a two-way conversation from real engineers to the CTO.
And ya, hackathons used to happen all the time with a lot of "assertion" about innovation, but nothing ever gets shipped from the hacks. It's just to satisfy the engineers so they feel excited about working on something new and receive a token gift card.
When reading articles like these, I can't tell if they are very low semantic density, or if they are using terms of art that sound like noise but are actually communicating valuable information.
"accelerating mission/delivering innovative products/services at high speed" - what does this actually mean? This sounds like a jumble of positively-connoted words that I would throw together if I was trying to fill space in a powerpoint.
"The CTO’s job is to: create a common process, language and tools for innovation [and] make them permanent with a written innovation doctrine and policy". Is this not just "Draw the rest of the owl"?
"The CEO's job is to: make the company make lots of money."
One rough translation for the first two lines there would be: Look for the orgs that are "getting shit done" and then "figure out how to unblock the people who want to get shit done in the other orgs based on how the currently-productive ones do things, and make that a company-wide policy."
In any large company things will have changed since the org was founded, so some of what used to work won't be efficient any more. So you both have to spot what's working now vs what used to work, and also figure out how to get a sufficient group of "doers" (vs just middle management) that they should buy in even though a lot of people won't be super motivated for the classic Office Space reason: "Now if I work my ass off and Initech ships a few extra units, I don't see another dime; so where's the motivation?" - and you often are going to have to do it without that motivation being just financial.
I have found that higher level management works in sort of.. higher order derivatives of process. they end up having to use bullshit sounding terms like this as a result. the more you get into management, the more meaningful those sentences become, but I totally understand it absolutely sounds like bullshit.
it also definitely becomes a coping mechanism to management-fuck your sentences in order to counteract your crippling imposter syndrome as you ascend
Why isn’t the more common solution to senior management imposter syndrome to capitulate to your ignorance and humbly speak with those at the lower rungs?
Extending programming patterns to how executive management operates: they need a very high level language with support for generics and abstractions to communicate efficiently without getting caught in the details. That is the job of lower level management.
Terms like “innovation” are a placeholder for something that will vary greatly depending on the instance.
As feedback, I find that new executives, even with external credibility won't be able to get the "innovation heroes" to talk to them at first. You have to make time, make space, and follow through.
Don't just have a single all-hands meeting to say "Come to me with your stories of friction", but continually do "skip level meetings" and "meet the team 'lunches'". And then boost that signal personally.
If you want an organization to value the removal of friction and apathy, it requires the most senior executives to actually celebrate the groups that were fighting that fight. Otherwise, these folks would rather remain nameless and wait for this new executive to go away like all the rest have. They're already doing their job, and it's too emotionally taxing to believe that this new executive means what they said.
I’m not getting the problem Anthony is trying to solve. I get that people are trying to keep him at bay, but what is he trying to do that they don’t want him to do? I get that he’s trying to identify pockets of innovation, but what will he do with those pockets?
It sounds like his game plan is to do “cto stuff”. But shouldn’t there be a more precise goal? Like picking some business metric and cause it to move in the right direction? Or define a new metric? Or introduce a fundamental new way for the company to do business? Once you know the specific problem you want to solve in the company, it becomes a lot easier to pick a strategy.
But maybe I’m just misunderstanding what the cto of a 30k person company does.
> the individuals others in the company point to who single-handedly fought the system and got a new product, project or service delivered
There is a toxicity lurking here. We should also be looking for the individuals who brought positive innovations, fought the system, and failed to overcome it. Why failed? Because it's not their fault that the system is broken, we cannot burden innovators with both the fixing of the environment, plus innovation. Else their only innovation may be how to cope with an increasingly terrible organization, and if that org wants survive or evolve it needs the innovators to stay.
a CTO should be a normal role without bonuses. or at least only attached to the time the person has been in that position.
ctos come, fuck the company forever to get a first good year or two then leave everything behind.
The problem is that most CTOs are just trying to move up to CEO so they have to play the game which is shaping the eng and prod orgs to make it looks like he runs a tight ship and speaking the language. Then he just has to wait for the CEO to falter or move on. I have a new CTO right now and it's too early to tell if he is one of those many or if he really wants to build a good engineering org.
1. You can't "fake it" at this level. One of the most impressive things IMO about this exec was his ability to know, at a fairly low level, what every department and org in the company was doing, and to diagnose their strengths and weaknesses very quickly. We'd have quarterly day-long meetings where every department would present, and his ability to quickly hone in on critical low-level details was extremely impressive. I think he would have failed if he had just thought that his job was to "brush with broad strokes". (Aside, this did NOT mean he was a micromanager, it just meant that he had a very good understanding of the details across many departments).
2. It's important to put some structures in place where departments are forced to show some accountability for speed. For example, one metric that I actually hated at the time, but later learned to appreciate the purpose, was that individual departments were judged on the number of A/B tests they ran per month. I hated this metric at the time because I felt it was easily "gamed" - departments would run small little A/B tests like button color changes. However, after a while there were a couple of big cultural changes that had taken place: (1) the company built tools and processes that made it easier to deploy and run tests in the first place (better CI/CD pipelines, better analysis tools, etc.) which had the overall effect of letting us ship faster with higher quality, (2) while yes, there was a lot of "gaming" of count of A/B tests run in the beginning, it didn't take that long for teams to actually run out of tests to game, and people actually put in the hard work of thinking about better tests to run, and (3) it changed our culture to become much more data-driven - it wasn't perfect, and "data driven" can be a double-edged sword, but it was an improvement.