As soon as you start dealing with large customers, these things become inevitable. People can’t start doing whatever they like because it becomes riskier to do it. What might be good for that one customer may not be good for the big customers you actually need to keep to make a profitable business. Big customers always want to know about the roadmap.
That depends on what kind of large customers you're doing business with.
If a customer is large enough, and their pockets deep enough, you can absolutely justify building what is good only for that customer, and shipping it only to that customer. Keep that branch separate from the general-purpose product you're selling to the pleebs.
I've seen several companies think this is a good idea but in practice it's a really bad idea to do this because you get captured by the customer and effectively become an arm of them without the benefits. And you end up dedicating so much time to them that other customers won't be happy and if that big customer ever cancels or leaves (which is often a board cost cutting decision rather than a user decision), then you end up absolutely screwed.
Great points. I agree with everything but I'm not sure about the conclusion that work will be fun for everyone. I don't think there will be work for everyone. The author implies that but saying that with AI startups can do more with fewer people, which I agree. The author also recommends to hire less. Yes, there will be more companies but the question is how the average person will be able to compete. If companies don't need many people they will become more selective.
In such a world progress is made faster and companies are solving more meta-problems. That is why people hand crafting html for their local businesses is no longer a thing and that kind of work is almost non technical now.
The article mentions Rippling as still having that 'spark', but they've been pretty awful the past few months. Between layoffs and data loss, it's looked pretty dire when I've talked to them.
The book Loonshots by Safi Bahcall describes this phenomena quite well. There's a "phase transition" of incentives at around 150 people that can be fatal to many organizations.
The secret sauce is how a startup goes past this headcount. Ideally many software companies quite honestly don't need more than 150 people!
See Miller’s “Barbarians to Bureaucrats” for a description of the full corporate lifecycle. Barbarian -> builder -> explorer -> administrator -> bureaucrat -> aristocrat.
Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person.
Total company size. The book argues, if I recall correctly, that over that size, there are too many moving parts within the organization to be focused on anything but preservation of the organization at large, rather than the product or service the organization offers. It's been a while since I read the book but it was quite a good read - highly recommended.
"And as tools (especially AI) get better, the number of users a small team can support increases. Founders of the future may not need to worry so much about these scaling pains, and work may become fun for everyone"
Except fewer of your users will have jobs because the AI multiplier means smaller teams. So your addressable matter will shrink. So another race to the bottom?
Awareness barely helps, it's the tragedy of the commons. I can't think of a solution other than regulation. But then if some countries regulate and others don't, you're right back at the tragedy of the commons at the international level.
Reminds me of the Mass Effect games, where AI is essentially outlawed (because they revolted against the humans of course, but I can picture less scifi-ish reasons in the real world). I'm sure they're still allowed to use pathfinding algorithms and such, so they probably defined a level of net negative (to society) AI and just regulated that. Starships for example are manually piloted (surely with intelligent support systems and basic auto pilots) IIRC.
Fair, not the best example of regulation countering the tragedy of the commons, because it's just made up. Unfortunately, any real world examples I can think of (nature preservation, gun control, ...) are seemingly controversial.
Isn't the tragedy of the commons how developing technology consumes our attention spans?
Human attention span is a finite resource (we can only do so much in one life), and tech startups can consume a lot of that for relatively little payoff. Building a successful startup is like solving the bitcoin hash on your first few cycles. The barrier for entry is low, but you can hit it big (and consume a lot of cheap, finite* power too).
The payoff is worth the risk since our communication technology is nascent and underexplored. We have an abundance of time right now because of what tech has done for us, but the cultural and environmental costs of growing tech are not well understood.
Use of attention span is difficult to measure right now, but that could change in the coming decades. That said, parent comment seems to use "tragedy of the commons" as a stand in for "human nature."
Except more of your users will have jobs because the AI multiplier means new opportunities to provide cheaper services available to more businesses, new companies that weren't economical before will be founded, entire new markets and whole new professions will be created. So your addressable market will exponentially grow. So another bull run?
AI has been around for the last 300 years of recorded history of technological progress? Or is every piece of technology guaranteed to make life easier? Did the slap chop markedly improve people's lives?
I understand theirs optimism (and pessimism), but optimism in and of itself doesn't make something true.
I'm currently consulting for a logistics/wholesale company that uses AI to massively cut down on product catalog management and vendor/customer support costs. Their services are now affordable to much more vendors. It's been a month or so in production and they have already onboarded many new SMB vendors who previously didn't have the means to pay for their services - and thus couldn't sell nor ship through my client. The cost of onboarding a vendor has decreased 100x thanks to using AI instead of doing it manually and it's not limited by headcount and personal schedules.
The products of these new vendors are now available to many big customers in a major city (a single one where we are doing a pilot), and the vendors are reporting they are already getting 2 times the volume of orders they used to get. They didn't even have the means to deliver that much product before - now they are able to do it because their logistics are handled for them by my client (economy-of-scale advantages) instead of them DIYing it, and they use the freed time to do more of their main business.
The customers are super happy because now they're getting fresh food produce from local farmers just days after it's been actually produced, which increases the quality of their products (food in restaurants/catering, usually) and they are already getting significantly more positive reviews thanks to that, which brings them even more new business of higher value. And funnily enough, the products they are getting are cheaper than what they got before, even though the quality is incomparable.
AI is a huge win for everybody involved:
- My client is no longer forced to deal only with the biggest vendors.
- The employees who used to do sales/onboarding, vendor/customer support and product catalog management are still doing it, only now they're handling 10 times more products from 3 times more vendors, and focus on special and more interesting cases instead of doing grunt work.
- The vendors have gained more customers than they ever dreamed of, make more money per unit and have much cheaper logistics that they don't need to think about nor spend their time on (we're talking about guys who used to hop in a truck themselves to deliver their stuff).
- The customers are getting much better quality for lower price per unit. There's also much more product categories they can choose from now.
- It's more environmentally friendly and supports the local economy.
It almost feels like the "efficiencies of scale" you get from large organisations (e.g. specialised people for recruitment, people matters, quality assurance, user research etc.) are not really efficiencies. Perhaps it's better to grow the organisation by repeatedly cloning the smallest effective team you ever had, rather than creating a more "efficient" organisational structure. How those "mini-companies" communicate with each other efficiently -- another matter.
Yes. Maybe one can design some sort of internally budgeted token based economy between these internal teams (distinct from mere gamification). But based on past experiences, I worry that that will lead to unanticipated perverse incentives.
The challenge is cloning teams is impossible. Teams are a collection of individuals. It’s like saying the way to win the World Cup is to simply clone the best team.
I think the best way to scale is to build processes that reinforce the traits you want in a team, and hire managers who understand teams are collections of unique individuals, as is the manager. The manager should be free to manage their people in a way that optimizes delivery and reduces churn. Between teams there should be a very high bar for quality of communication and delivery. The culture of the organization should be built around respect for each person hired and a relentless focus on ensuring individuals end up in teams that they are effective in and are therefore maximally effective as teams.
I think it's about more than just efficiencies of scale. You kinda play by different rules at a certain scale (not just based on employee count, also based on revenue), and suddenly you're subject to a lot more regulatory scrutiny. Plus, as a company becomes more valuable and attracts shareholders and managers with lower appetite for risk, a lot of money needs to be poured into risk management and avoidance. At a previous company, a competitor was blatantly breaking the law to solve user needs we couldn't solve without breaking it as well. Somehow they got away with it, presumably because they were tiny and (to my knowledge) unprofitable.
Now, if it wasn't for all that, there's still the problem that, from personal experience, most employees don't invest as much energy as a founder would - which is perfectly understandable. As the founder to employee ratio gets smaller, you find yourself hiring three people to do a job you could do yourself, just to make sure it gets done reliably and timely. In a smaller startup, early hires are more similar to founders because they're close to them and stand to gain a lot if the company succeeds and grows. For employee #213, they sell 40 hours of work per week and their fixed salary is all they really stand to get out of it.
So while I like the romantic idea of having a large company comprised of multiple independent startups, I haven't seen that work and I can barely picture it work :( One can get somewhat close to this with the right organisational structure (e.g. sacrificing efficiencies of scale for team autonomy where feasible), but it's not even close to the same thing.
You're correct. It doesn't work. A lot of ails are necessarily inherent in scaling up. Once you get to 80ish, you just necessarily have to change your setup
I met them back in 2014 when they were making insane amounts of money from Clash of Clans and their DS who was building LTV models for the game was doing it as a part of his job.
In lots of other (worse) companies they had huge teams delivering a lot less.
I agree and this is a practical method that I've seen work well in several companies I've worked for. However I think there's a bigger problem that contributes to the loss of "spark" that the author strangely didn't address at all.
The fruits of labor grow ever higher. By which I mean: In the early days of a startup the problem space is ripe and plentiful, the impact you can have is outsized, and the pool of people with which to share it is the smallest it will ever be.
As a company grows, all three of these factors are subject to strain. The problem space becomes sparser, outsized impacts are recognised further up the ever-growing hierarchy, and the pool of people with which you're sharing your impact becomes larger and recognition becomes shorter lived and more diffuse.
There is also a dynamic aspect to that: the original team who started the startup has battle scars, they used to take risk, but now they have a natural incentive to be more conservative, preserve the way things were done.
Adding people/roles can be beneficial when it frees other people from onerous or distracting work. When it increases onerous or distracting work for everyone else, that's a problem. To a large extent, the art of managing growth is finding ways to liberate everyone instead of handcuffing them.
How this can be made even worse is when you have a startup company that in principle operates like a large company because it wasn't founded on equal terms by all employees as a group, but started by one or a handful of people that fund and hire everyone else.
There is no skin in the game as there's no stock options nor revenue share (founders want to keep it all for themselves ofc) and you can be fired on a dime without any due process, software proprietary and closed source of course, so you can't use it for your own stuff either.
Only the PM spends hours on the phone talking to users and then gives you a direct task to work on. The task is always max priority and comes in randomly so you must drop whatever you were doing before to immediately implement it, usually getting the next one before the previous one is even done, making sure that critical tasks inevitably get forgotten and end up at the bottom of the backlog, leading to catastrophic software cohesiveness.
Working on something you want? Haha, right. Do what you're paid to do, no exceptions. Coworkers of course all remote or hybrid so there's no meaningful cooperation and endless Jira review meetings to tell everyone what to do. Daily progress reports of course, gotta make sure people aren't slacking.
Companies that grow naturally form a kind of immune system that fights all kinds of change. That's just the way it is.
I guess the lesson to be learned is to be very careful when scaling up your organization. Past a certain point change becomes very difficult. I.e. only grow headcount above 100 when you're certain about product market fit.
> Most startups needlessly accelerate their corporatization by copying the processes of larger companies, usually by poaching managers from large companies who bring their playbooks with them.
And no one ever stops to think "is that company doing that thing because it's effective, or is it something that they are getting away with because they are big."
Or that big companies are just solving big problems which are different from yours. There nothing i hate more than just rote copying solutions from bigger orgs
I think that’s probably still reductive — in some environments (like a couple years ago), it was very hard for companies, especially startups, to lure in talent.
Perhaps, though, if you only hire when you need, you can be more competitive with pay.
> But no incentive is as good as a fat chunk of equity + the power to influence its value.
Meanwhile your sales team colleagues get their incentives paid out right away, in the very next quarter, and instead of equity lottery tickets it’s just cash.
I’d like to see engineering get some of the types of cash incentives that sales teams get. Perhaps the only reason they don’t is because it’s too hard to come up with metrics to base commission on. Instead, they rely on equity awards even though the value of the company is often quite detached from the quality of the software.
The fun of a startup is nice but it’s probably not worth it if you’re getting below-market compensation, crappy healthcare, long hours, and the IOU of an equity stake that’s probably crafted by financiers to screw over regular employees.
It's not too hard to come up with bonus structure for engineers. Managers have bonuses for team targets at tech companies. The mistake is that those bonuses don't trickle down to the team. That's how it works in the oil field. There are bonuses for on time or early well completion. And everybody, even the newest roughneck, gets a cut of the bonus.
I disagree - as someone who has started up small companies and worked in megacorps, including FAANG and major banks, it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there - and are given the work they excel at and the work they don’t the manager ensures someone who does helps them. Then the manager has to make sure the mission of the team is crystal clear in its value to the mission of the enterprise and the enterprises mission on earth. Finally the manager has to relentlessly break down barriers to production and impact.
The arguments articulated are entirely false: ex. N^2 communications. This is reductionist and absurd. No team depends on every team in the org. Their domain is often fairly small and their adjacent teams extremely finite. The exception are “core teams” (which have been my specialty). However a well functioning core team doesn’t have n^2 communication overhead - they act as a concentrator and teams come to them - which is N. N can be large, in which case effective triage is crucial, but so is automation and self service, coherent platforms that are self documented, and some folks on the team that really really enjoy teaching.
I’ve burned out though on building these teams. It’s absurdly hard work on management. But management is supposed to be absurdly hard work. My next gig is as a distinguished engineer at a late stage startup - back to the roots for a while.
I’d would disagree - I had the exact experience that the autor described. But you are right on this point
> it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there
I still think it’s related to size and bad incentives. I heard stories of people at FAANG that said that department X is like a startup but Y is soul sucking boredom
Yes, thats correct. However the existence of X department at all refutes the authors premise and conclusion - and if X exists, it’s entirely possibly for Y to become better.
Specifically this is entirely false due to the existence of X:
> Is this preventable? I think not.
I> f you look closely, all these problems fundamentally come from:
> Decreased skin in the game, which reduces team alignment
> N^2 communication, which creates need for managers and specialization, which reduces individual agency and breadth of learning
> Reduced risk tolerance, which slows everything down
> #1 and #2 are inevitable results of having more employees. #3 is an inevitable result of having more users, partially due to government regulation.
I think a large company enables Y departments to exist without the company imploding immediately. Survivorship bias ensures most startups that last longer than a short amount of time to appear like X, when I know there are plenty of dysfunctional startups (a friend tells me Ghost is a great example). But due to the economics of a startup they evaporate quickly. In a large company Y departments can limp along for a long time or indefinitely because Y’s function needs to exist and the company can afford for it to suck ass to work there without it going out of business. However invariably X departments in large corporations are where the magic happens, where people want to work, and what moves the large enterprise forward.
I’d also note that not everyone wants to work in a startup environment or are able to. Many engineers got into it for a good paycheck and don’t have much interest in anything particularly dynamic or engaging. They’re perfectly happy committing once a month and sitting in meetings. That’s not me, but I can also see when you build an army, you can’t build it out of special forces only.
So, instead of saying X can’t exist, when it clearly does, I think it’s more useful to say you should be careful where you work in a large company and seek out actively the X departments by learning what Y departments look like and how to spot an X department.
Absolutely. The most exciting work I’ve done that has literally changed our world was done at systemically important multinational megacorps, where we created environments of unfettered innovation and an assembled teams of amazing individuals working as a coherent team. I had some really great leaders early in my career that showed it’s not only possible it’s the only way to enjoy any role at any company no matter the size. While you can’t clone their method to work in any environment, you can adapt their method to any environment with enough energy applied. The essential secrets are the ones I outlined. As an IC though it’s all about finding those leaders among the functionaries.
Likewise, most of the startups I worked at were exciting by not intoxicating. They were relatively banal in their goals (change the world through prestige makeup e-commerce or something), their technology modern but not innovative, and the teams tight but not always coherent like a well oiled machine.
big companies have resources that give you reach (channels, marketing, human talent, legal, international presence, longer term investments) that you can never get with a smaller company.
being able to apply them effectively can really be really frustrating though. and there is always the danger that your two year development arc will be demolished by 'shifts in overall strategy' or 'belt tightening' or a reorg.
> I had some really great leaders early in my career that showed it’s not only possible it’s the only way to enjoy any role at any company no matter the size.
I'm not persuaded anyone is in a position to know that there's only one way for people to enjoy work, and to know what that one way is.
That’s the secret. Most management is about the one way people work. The right way is to realize everyone is an individual and everyone has a different way of working, and what they enjoy about work. This forms a complex optimization problem for the manager, whose job, IMO, is to figure out the puzzle of how to maximize everyone’s individual value in the team. The way you do that is match their style of work and strengths with the teams needs and find other team mates to backfill their weaknesses. Then giving people the space to do things the way they prefer it while keeping a strong common collaboration medium within the team.
Return to office is a current example. My strategy here is that people know how they work best and that’s up to them. We have ways of getting together and collaborating, asynchronously and synchronously, and don’t enforce a mandatory hybrid approach. I encourage the team to intentionally meet up in person regularly, and the team self organizes synchronous in person time on a regular basis. I set up a drop in zoom room that’s always signed in on a conference room and people drop in for adhoc stuff all the time. Some people stay signed in all day on the conference room. I make sure ticketing systems, chats, and other mediums are well used. I regularly talk to people about their well being to be sure folks remote are OK, as sometimes fully remote can mean fully depressed.
Compare this to a “standard” managers approach. “We will be in the office three days a week, with a mandatory day on Wednesday. This is necessary because people work best in person but we want to give people flexibility because we know employees value that. Failure to comply will result in performance review impact. Our company’s culture is built on in person interactions. We do this for the children.”
Typical management is about treating people as butts in seat filling a role with a define set of measurable performance metrics - aka conforming cogs in a machine. that is the method that assumes there is one way for people to enjoy work, and knowing what that one way is.
My way is acknowledging I don’t know any one way that’s best, and specifically, there is no one way for people to enjoy work. It’s my job as a manger to figure out what each and every person on my teams way is, and to do my damnedest to create that environment for each individual. I work hard to hire managers that will also do this, and I meet randomly with people at all levels of my org to be sure they’re being treated like this by the people on my direct team.
The down side for me is I stick out like a sore thumb in the great cog machine of other managers. They don’t understand what I’m doing, it bothers them, and they feel like I’m getting some sort of preferential treatment. And maybe I am, because my organizations are almost always considerably more effective and successful than the rest of the org, so we get enormous latitude. But shielding my people from the game of thrones is exhausting - more exhausting than the rest of my job.
All this said, I’m not the only one who does this. I have encountered a lot of leaders that do this. They’re the ones people want to work for. That’s why I paid attention to what my early leaders were doing and emulated it - the one way is there is no one way ;-)
That was a pleasant read, thank you for the comment. I've felt something similar about management, but not quite clear enough to put in to words.
Maybe I'm late in my comment but, I have two questions if you do not mind.
If you have a manager that is not quite like that, but probably somewhere in their mind would agree to that stance, how could one push that person to that direction? I have my manager (and a friend) in mind, gives good autonomy and let everyone work in the way they feel is optimal. But it also most often lead to aimless or fuzzy goal setting, a lot of ambiguity. My guess is that the thing lacking is the inquisitive nature; like you mentioned you do, he does not check in on people how they feel, what's blocking them, what's suboptimal for them. He simply check in for an update on progress and set meeting to update what he's up to.
Is there any good material or pointer that could make someone manage more like that?
I also informally manage one person due language barrier and the question also applies to me.
> I’d also note that not everyone wants to work in a startup environment or are able to. Many engineers got into it for a good paycheck and don’t have much interest in anything particularly dynamic or engaging.
This is an excellent point. In my experience a majority of people value stability and predictability in their lives. They would rather have someone tell them what to do within well-structured bounds than contend with the ambiguity inherent in an early stage startup, or with solving massive product/business/technical problems with too many stakeholders to fit in a room.
I think the challenge is the people with the intrinsic motivation and stomach for the ambiguity can struggle to grow in large corporate environments that are full of good soldiers who stay in their lane. It's not uncommon for entry level ICs to come in with 3 or 4 layers of management between them and VP level, and then become pawns in middle management games, or stuck reporting to Peter-principle cases who teach them all the wrong lessons.
This is why I was really glad to have worked in startups when I was young, to really get exposed to all the moving parts and fundamentals of an operating business. It's just much easier to learn when the big picture is more legible, you have the latitude to iterate faster, make more mistakes, and see first-hand how things scale (or don't!) from the ground up. These days I see too many ivy league grad ex-FAANG who have all kinds of ideas of best practices with no understanding of why things are done that way at the tech giants, and extremely limited ability to reason from first principles about what makes sense in a different context.
I am the most senior engineering IC by position and years of experience at my current company in a 100+ person engineering group. The only problems I deal with are non technical and organisational in nature, despite on paper being expected to code 30 percent of the time.
Sound advice - currently going down the path of try to make the role better. It will however be a long journey, so need to work out whether I am sufficiently committed to the path. Also need to work out what the ejection criteria are, regardless of my commitment or not.
That coordinating is a quadratic mess, because no task requires bidirectional communicating with everyone else.
I also disagree with all the other points they make about large companies. Not that there exists teams in large companies that suffer these issues, but that there exists no teams in large companies that don’t have these issues. I further extended it to say startups also aren’t without issue, and many are totally screwed up. They just don’t last very long.
Let's set aside value judgements. After all, I don't know that small startups are optimal any more than you know that they aren't. Hopefully, what we can agree on is that small startups are different from large companies, even those with teams. Given that, someone who LIKES their small startup for whatever reason may feel it's lost its lustre when it evolves into a large company. For those people, this article offers an explanation for why that might be.
Or, it gives a guide for the problems to avoid and figure out strategies to solve for to avoid that path. But, yes, if the article were written that way, I would have agreed with it more. But it wasn’t :-)
But it doesn’t exist. For any task the number of contact points is almost always fairly small. Just because the possible N might be large most are occluded by lack of relevance to any specific task.
I would note that the author categorically says it’s not possible for a startup like environment to exist in a large company. That’s what I disagree with.
How have you developed a sense for organizational friction? What observations of culture can I use to make an educated guess about how easy it is to do my work?
I agree with your point that a large org does not guarantee what the author claims. The author claims that the organizational friction can be measured by productivity, but you recognize culture as the better diagnostic criterion. The big O metaphor does not extend well to the argument, as you point out.
I'm looking for hard hitting interview questions so I don't waste my time on "soul sucking" positions.
That’s the trick isn’t it? As “the boss” I’ve been able to self create my culture around me so it’s been easier. I have landed in management teams that were so oppressive I couldn’t even then. I’ve watched my peer leaders for signs. It’s very hard in an interview to know where you’re landing.
A few things I’ve noticed that might help:
* ask people in the team what they do and how they work, and how the team helps them work best. If they answer “oh I’m a programmer 2” and have wishy washy answers on the rest, that’s a bad sign. They’re being managed by a “by the book” manager. If they describe some complex role that isn’t out of the HR leveling guide, and a unique way of working that’s accommodated by the team, that’s a good sign. If you hear everyone in the team describing a role that’s unique and tailored to them, then that’s a great sign.
* this is controversial but I think any org that slavishly follows modern day agile / scrum can not be dynamic. Nothing more to say other than back in the 90’s Bay Area hanging with thought works and those folks, agile was something very different than today.
* the manager themselves should be very open to questions with thoughtful answers that aren’t rote. They should likewise spend more time understanding you than usual. They should be assessing your fit in their team - do you fill a gap? Do your weaknesses complement others strengths? Are you looking to turn the crank or are you looking to innovate?
Also, be aware of yourself. Not everyone does well in a dynamic environment. It’s more chaotic and less structured. If you like clearly defined and regimented work, go for the clearly defined and regimented team.
Organizations are structured as trees as a strategy to combat N^2 complexity. You talk up, or down. The tradeoff is of course N^2 relationships still exist in reality , so you duplicate effort, and sometimes collide, but it's a good tradeoff.
I think it’s more like an adhoc graph that’s more dependent on the task than the organization. Tree based management is only useful for reporting and dictates. The actual work is more like “I need to get X done, I need to work with I,j,k to do it.” Often the real issue is NOT that it’s N^2 interactions, but the space for identifying who I,j,k actually are is quadratic and there’s no index. This is often the immense value of “lore masters” in a team - they have an unnatural ability to know who to talk to about what. If you don’t have one in your team, get one.
I agree here. The opening statement of the article is simplistic and inaccurate. Sure, most big corp jobs might be rather dull, but you can lit that spark in the right circumstances.
> Is this preventable? I think not. If you look closely, all these problems fundamentally come from…
It is preventable.
I built an ISP in mid-90s, a digital agency in late 90s, another digital agency and a streaming CDN (world's first VDN) in 00s, as well as worked as chief architect for cloud at world's largest hedge fund and CTO of world's second largest bank. I'm currently an entrepreneur again, co-founding and building a hedge fund from scratch.
My experiences across these, particularly at the digital agencies (where I got to help hundreds of clients go through growth) and the mega bank (where I got to see how things working when small can also work somewhere global), tell me all the goodness from the initial list can be built into the operating model, with a couple caveats.
These are hard[^1]:
1. No domain versus technology divide. If you hear "The business wants..." or "I need I.T. to..." it's not going to work. At a fintech, for instance, all teams should have both fin and tech on the team, owning their outcomes.
2. No command and control managerialism better suited for piecework than building. No project managers. No scrum-masters. Importantly, and apparently pure heresy: no projects.[^2]
Instead of projects, think, what should we do better?
Instead of controlling for budgets and delivery dates, control for focus (like priorities but mostly about saying "no" to things instead of "yes" to everything with stack ranking) and outcome value (e.g. RoI or RoE instead of hitting dates). Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects.
Hitting dates well becomes easy and fun/rewarding when you scope using focus instead of pre-defining all (probably imperfect) requirements and you ensure teams are equipped with people (will, skill), and resources (tools, space) to own outcomes. (If people are called resources, run away.)
It is preventable, and I'm happy to talk live with anyone building a work management tool that is interested in our approach.
[^2]: You can do time-boxed work with an outcome. That could look a lot like a project. But the word “project” tends to bring with it a pile of practices that all kill the intrinsic motivation for building things you're proud of.
It's interesting even companies as smart as Linear (the Jira alternative, check out their Linear method pages for a lot of better than usual thinking) don't want to even listen why they should (and could just by allowing renaming a few terms in their tool) support a non-project-centric view of building your company and enjoying doing it.
What pile of practices are you trying to avoid? When I see time boxed work with an outcome, that’s the very definition of a project to me. There’s nothing else. I had a weekend project building a desk. It’s timeboxed to the weekend. There’s an outcome. What am I missing?
On the contrary, "time box" means the time is fixed, the work achieved is variable.
Projects: the project comes in "on time and under budget" or is "late", but the work is fixed.
Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups.
You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes!
I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar.
Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work.
A project tries to fix both work and date, which doesn't work and is rarely on time.
A time box fixes the date, not the work. Iterative delivery always hits the date and generally works.
---
Using your weekend desk example:
You could want a wood inlay desk.
For the "job to be done", the desk has to support you doing work.
In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend.
If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk.
The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk.
If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid.
Certainly, doing the inlay after assembly will require more effort.
So then ask yourself, was the deadline real, or was the inlay requirement real?
If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real.
---
What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements.
But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements.
Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead!
You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient.
If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.
I understand what you're saying. I just don't understand what makes it a project vs. not. Fixed-scope projects, fixed-time projects, projects that are fixed in time and you have to fight the stakeholders on in scope... these are all projects with different features.
It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
For the layperson definition of project, of course you're right.
The problem is the professional definition of project, which comes with project management practices and preconceptions.
Those are generally harmful, because they try to manage or control both time and resources needed to deliver unknowns in advance of an inherently discovery-based process that results in (re-)scoping as you learn:
> It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
I posit it's not just "prefer", it's reality. That all "projects" are in fact "fixed time, variable scope" in hindsight. In other words, "it takes as long as it takes" to uncover and ship a minimum viable scope for the "job to be done".
As an entrepreneur, it's preferable to create a workplace that acknowledges that reality up front, and designs the "way of working" for it.
As an engineer, it's preferable, as you note, to join one.
---
Some more musings:
The OP's post says work stops being fun. A key reason why is all the unfortunate beliefs, management overhead, and recrimination for practices trying to override reality and failing.
Small startups don't care. The cost of 5 people being wrong seems irrelevant compared to charging at the problem and getting it done, or finding out it doesn't work so you can pivot. How many "Show HN" are after a pivot? How many "Launch HN" for that matter?
Enterprises care. The cost of 500, or 5000, building the "wrong thing" seems unacceptable (even if less cost per person!), so big companies keep piling on layers of risk management that delay getting in touch with reality.
One reason they do this is the value of the outcome isn't clear. Perhaps it's political, perhaps it's make-work to keep someone's department full sized, perhaps it's a failure of imagination. So they develop scar tissue about shipping multi-year boondoggles that deliver no value. The problem was, it wasn't valuable in the first place, and if they'd just tried it out in the small and iterated, they'd have learned with fewer man-hours than all the planning.
For a great take on this, see Tom DeMarco (author of Peopleware) rethinking his entire stance on projects after 50 years(!) trying to tell people how to project-manage better:
He even throws in the towel on estimation with the now famous phrase, "All projects that finish late have this one thing in common: they started late."
He effectively accepts reality: the needful is the needful, the value is the value, so if it's valuable you'll do what you have to do, just start already and get it done.
What I've found is, a big enterprise can understand this. The CEO can hold his business leaders accountable to telling the value that an effort should generate, the CFO can "venture capital" an appropriately sized investment in a fixed capacity team, and the team can focus to deliver value -- or offer a pivot -- before they run out of funding and can't raise another round.
If they're shipping well, and getting market traction, the business leader looks good, the CEO is happy, and the CFO can continue to invest. One neat thing with this is the remarkable "budget" predictability that comes with investing in teams instead of in projects. Control your capacity and focus, you'll always hit your expense nu...
> Instead of controlling for budgets and delivery dates, control for focus and outcome value. Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects.
Maybe if you sell to end users. If you have clients with SLAs, requirements etc and legal penalties for missing them, not working to delivery dates isn't going to work. Even in teams with projects, ensuring deadlines are met is still tricky.
Wow - I’ve been thinking very closely to what you describe here, but never completely pieced it together until I read “No projects”. You’re completely right. I find that often process is used as an excuse to ignore outcome ownership - even if things didn’t work out, well at least we can say we did things by the book. No one is at fault, and no one needs to learn from it.
The article even reaches the conclusion that granting more ownership to employees might be a solution. What an idea! You could make a new mode of production out of this.
Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof):
1. Too-technical leaders:
As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup phase sometimes move into these when they are not the leadership type, causing engineering team to devolve into a visionless, directionless zoo.
2. Non-technical leaders:
Inverse to the above - as startup scales, in desperation, new leadership roles are filled with non-technical individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous).
3. Problem engineers:
Small number of leaders lack a spine, conducting shallow interviews and let in "problem engineers" who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around.
From experience, it only takes around ~5-10% of a team being this type for it to have a large negative impact, as they tend to derail progress, dodge responsibility, reputation farm, push rubbish, all that nonsense. It harms morale, and the skies turn grey in the office...
4. Micromanagement:
Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration.
EDIT: I'de love to hear how these foot-guns have been avoided. From experience it seems really challenging, as if like magic; as if cultivating and maintaining a good engineering team and culture therein is like balancing a pencil on it's nib...
From experience I can say that these problems can occur just as well in bootstrapped companies when they reach a certain size. It's a problem with the number of employees regardless of how fast the company gets there IMO.
As a corollary of these people problems, I would add:
1. Not correcting problem hires fast enough.
First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out.
The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He was wholly incapable of doing the job but they kept him in the job for 2 years to “give him a chance to grow into it.” Everyone below VP level openly talked about how the VP of Product was incompetent and how to work around him.
The company’s product initiatives ultimately failed to even get started and they had to pivot to entirely services based work. Do not stay at a startup that insists on keeping unqualified people in leadership positions long after everyone in the company has given up on them.
2. Firing the wrong people
The same startup was forced to downsize, largely because their product plans failed to even become defined enough to start under the incompetent VP of Product.
It was the perfect opportunity to fire the VP of Product and his sprawling empire of people who did very little, but they avoided that due to his connections to a C-level executive. Instead, they started cutting engineers. They focused on cutting engineers with the highest compensation out of a misguided effort to cut as few people as possible.
In the process, they lost their key engineers who were holding things together. They sent a message to everyone that incompetence is tolerated if you know the right people. And they lost even more core engineers who quit in the months after those layoffs.
Everyone makes hiring mistakes. It’s how you respond to those hiring mistakes that will seal the fate of the company.
Terrible advice (from a broadly terrible book, I hasten to add). The reason that this is terrible advice: if you "fire quickly", it is because something is either grievously wrong (a mishire) or you are firing based on limited evidence. If the former, you have a hiring problem, not a firing problem; if the latter, you will generate a fear-based culture. Now, if you're running a prison, a fear-based culture may be exactly what you're after -- but fear is anathema to innovation, and if your endeavor requires any creativity whatsoever, you should be seeking to build mutual trust, not foster institutional fear.
Not only that but you run into the very expensive reason why literally every large company has a lengthy documented process for firing (outside of layoffs of course, lol):
Honestly, european common approach of "trial period" is better for this.
Details vary, but for example in Poland you can (simplified case):
1. Hire for fixed-length term of a year
2. First 3 months of that are "trial period" - you have minimal paperwork for firing during that time, effectively no chance of lawsuit (if someone brings a lawsuit that gets far enough for any paperwork to reach you, you have much worse things to take care of internally)
3. After the fixed-length period, if you're happy with the employee and want him to continue you switch to "permanent" contract. If not, the term lapses and that's it.
The problem (I’m not in Poland but I’m in Berlin, which also has strict rules about firing long term employees) is that senior talent has a lot of choice of where to go to so why should they bother with a place that would only give them a 1-year contract at first?
I honestly think the book is so bad that it's not worth a lengthy critique, but in short:
1. Dalio doesn't understand what a "principle" is -- but I can understand that "Aphorisms, Cliches and Hunches" is a less arresting title, if much more accurate. (See [0] for a fuller review on this.)
2. Dalio's version of Bridgewater doesn't line up with the experience of others -- which I have heard from so many people as to completely undermine whatever he might say.
Now, in the book's defense: I didn't get through it and perhaps it got suddenly palatable or interesting. However: I also couldn't get through it -- it was just that bad.
I agree that his descriptions are less "principles" and more like "heuristics". The overall message of the book, as the referenced reviewer points out, is "do what's sensible." As someone so young, what is sensible to me is not obvious, so I find value in this.
What, in your opinion, defines what is sensible in business and leads to your frustration with Dalio's message? Can you give personal anecdotes?
In Germany it is very hard to fire people but there is a six month period in the beginning, where one can be fired without reason. Is it possible to gauge a new employee during that timeframe?
I would say you can generally (from my experience >95% of the time) identify a bad hire in roughly a month, mostly in two weeks and then give yourself / them additional two to be very sure.
We just hired for a management position a couple of month ago and I could tell from the very first meeting that it was a bad hire. I made sure with my team that I’m not totally wrong and then communicated my doubts to the C-Level. It took some time because they wanted to give them a real chance but just before the probation ended there was an evaluation meeting and the feedback was, without exception, negative. Took two days and they were gone.
Of course there will be hires that can uphold their charade for six month but I would say that’s an exception.
If you can tell from the first meeting, why was this person even hired in the first place? The only time i experienced something like that was when the CEO hired someone without asking anyone else to vet them.
You answered it yourself, no? The people who could vet them were not involved. And the reason doesn’t have to be malicious, it’s just that not everybody can be involved with every interview.
Some people are just good at interviews or talking themselves up.
Back in university, most of the students in my Chemistry course had A-Bs (grades were published publicly). The final for the course though was set up by some national body (in the US), and all but a few in the class got no higher than a D. Why? Because the national test was reflective of what students actually learned. The typical university multiple-choice test just self-selected good test takers. I myself got in the habit of only attending certain classes once a month because I knew how to game the tests and still walk away with an A-B average (e.g. have a good idea of what will be tested, know the material well enough that you can eliminate 50% of the false answers, and then make an educated guess on the rest.)
The same is true in hiring. It can be easily gamed if you don't have a great interview process (most companies don't). Even worse, part of that is by necessity. Each candidate has a different set of experiences, but the interview is made to be as routine and consistent as possible to weed out any potential biases (e.g. candidate given purposefully hard question or colored feedback because interviewer didn't like them). To truly vet a candidate, you would need situational questions and feedback, like they quickly glossed over some part of the question, so I'm going to go off-script and drill down into this area. Big companies especially run far away from that due to risk of discrimination lawsuits.
It's very old school and discounts how many problems can actually be corrected faster and less expensively than by firing ASAP.
The reason "fire quickly" may be appealing advice to some is that solving problems takes effort without a clear guarantee of return, and leaders usually end up trying easy solutions that diffuse blame or create the illusion that something has changed. Then they wonder why productivity is not up or why employee sentiment is middleing.
A mishire situation is what usually this advice is about. Maybe if you hire only people you previously worked with you can bring the mishire rate way down but for majority that rate will probably be very high is what I commonly hear.
About your point 2, can you summarize what you heard about Bridgewater Associates from people who were there? I also stopped reading the book, probably further in than you did, and I felt uneasy about Dalio's description because it seemed internally inconsistent given rudimentary knowledge about working environments and their psychology. He felt like a good boss because people wanted to work at Bridgewater ($$$) and nobody criticized him much - but probably, people had reason to do so but just didn't dare to.
I also wonder what their actual competitive advantage was. My guess is Dalio himself had a good way to think about economic questions, and that they used not-too-simplified computer modeling before most others.
Yep, this very much resonates with my experiences.
At the end of the day, startups are run by people, who generally prefer to work with their friends, avoid conflict, etc. There's no great mystery. The mystery is when things work well.
Big +1 on too technical leaders. Seen this a couple times with brilliant engineers who, once they became in charge of 50 different teams, appeared to try to just do the same work they did in one team but "scaled". Put every team in a spreadsheet and try to automate management through uniform metrics instead of focusing on managing and growing his direct reports.
And another time, seen a less technical leader step in, see engineers around me roll their eyes a couple of times at the lady (with maybe a smidge of male chauvinism blended in), but then see her actually fire bad hires, hire star players, and get everyone to align their priorities so they could be productive. Leadership is a very different job from the kind of technical excellence that too often gets rewarded by promotions (vs raises or bonuses).
Another +1, I left a startup over exactly this, all the managers, directors, and VP of engineering were IC engineers maybe 2 years prior. It was a shame, because I really enjoyed my role at that company in general, but ended up opting to leave after getting a really terrible leader.
I've seen this in science as well. Analysts get promoted to managers and managing is a completely different skill set that involves social skills, communication, empathy- all people skills that they didn't need to be a good analyst. They were promoted because they were good at being an analyst- meticulous, quiet, just do their job and don't interact with others. Unfortunately almost none of this carries over to being a good manager. I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well.
My last industry job saw the company implode from this cycle as everyone got pissed off and left the company. My old ex co-worker sent me a letter from the CEO last week saying layoffs were starting because revenues were down and they keep losing clients...
That's true. It's also the case that, if you polled people here, you'd find no shortage of people with zero respect for managers without technical backgrounds.
> I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well.
Having been there too, I feel like this is another recipe for disaster. Technical management needs to be able to make calls on escalations — that's in fact one of their main jobs — and when they don't have the depth of knowledge to make the call on merit, they make it on rash impulse, or favoritism, or (perhaps worst of all) don't make the call and let issues fester.
Academic science is pretty much designed this way.
You get a faculty job based on your brilliant work as an IC (i.e., first author papers) but running a research group is a totally different skill set—-and often one people get very little training for.
It's interesting that you have experienced both sides of the leadership problem space. Honestly a bit glad to hear that others share my experiences and that I'm not just unlucky or something.
Also, oh my do I ever have an extremely similar experience of an IC-type engineer going into a leadership position and trying to "engineer" it: put all teams, sprints, tech visions, growth frameworks, etc. in huge spreadsheets. I look back in jest now, lessons to be learned!
I think your question about avoiding these mechanisms isn't the right one; the real question is, how does one succeed despite these inevitable problems?
In other words, I don't think you avoid these, I think you understand they're coming and accept the trade off, making sure it's worth the issues you invite when you do have to promote those engineers/non-technical people, for example.
Don’t forget: Hiring remote contractors to “speed up” things. Dev will slow to 50% and meetings will double as you attempt unsuccessfully to teach them how to code.
Anytime a leader sees new hires or contractors as a "speed boost" is when it all goes to the dump. The sooner we get past this idea, and start viewing new hires/contractors as "speed bumps" the better. Bringing anyone new into the fold should always be a slow process!
Depends on the scope of the change and the objectives of the company. This is more true in larger organizations than startups, but not all technical problems you’re working on are directly linked to your value prop. I’ve seen good results in many cases where some systems are handed off to be managed by contractors so the FTE devs can focus their attention on improving the product which actually makes them money.
What I haven’t seen work is (which is what I think you’re describing more specifically) bringing on new hires or contractors to a project in flight in an attempt to deliver it more quickly. That’s where we get into Mythical Man Month territory.
After 25 years in the full range of IC and management positions, I'm convinced there's no substitute for expertise, maturity and judgement. I could come up with some rules of thumb (eg. ICs need the maximum amount of agency they are capable of handling), but every rule has its exception. Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it.
I've seen how small dynamics resulting from individual personalities and nuances of org structure have led to massive dysfunction and productivity loss, even though everyone was well intentioned and doing their job to the best of their ability. I could list out hundreds of behavioral "flaws" that individuals exhibit, but there's no way to fix them all directly, good engineering can't be done by top-down edict and central planning. Instead, you need a critical mass of people, including engineers on the ground, with a good end-to-end understanding of the product and business so that micro-decisions can be suitably informed by the big picture, and the right concerns can be escalated for leadership attention. You need to be able to weigh the cost of product, design, legal, financial, support, security, and operations across both short and long-term to make the right decisions. This is only possible with a high degree of mutual trust and safety for experts to voice their opinion and find the right tradeoffs. It's very easy for egos and personality conflicts to come in the way, hence the need for maturity in leadership. Balancing a pencil on its nib is not a bad analogy.
"Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it." - so true.
The surprising/unfortunate thing is that dysfunctional unproductive organizations can survive and even thrive. There isn't an obvious cause and effect and the time it takes until effects are seen can be measured in years or decades.
That's a great taxonomy of foot-guns! As to how they can be avoided, I can only describe some of what has worked for us so far, with the caveats that we are still small (~60 employees); that none of this is formulaic or perfect; and that there are many reasons why what we have done might not work for others -- or may not work for us as we get larger! That said, here is some of what has broadly worked for us:
1. Writing-intensive hiring process
This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process.
2. Transparent compensation
Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities.
3. Uniform compensation
One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks.
4. Very, very careful hiring
We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful!
Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix!
Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow.
As for compensation, those certainly are controversial. I believe in honesty, but your extent of it is quite...towards one end of the spectrum? Certainly interesting.
Ha -- "towards one end of the spectrum" is a fair (if not generous!) way to describe much of our approach, on many things. ;) And it has been interesting -- with surprising ramifications in many areas. As a concrete example: when people are assessing a hire to be a true peer with respect to compensation -- being paid neither more nor less -- the level of expectation is really high, and the reviews are thoughtful, thorough, and candid. This is but one of several examples; at some point, a blog entry on our experience is probably called for...
Here's an idea I've seen work: stop assuming people over 35 aren't a good fit for a start up. People who've been in leadership for a while but have the chops and in their day did on the ground work, and who can - given enough time and guidance - understand the minutest detail of a new tech stack or financial maneuver, command the respect of the super stars doing the day to day for their contribution of far seeing leadership.
Preface: I'm not saying that this norm is necessarily right, rather just explaining the mechanism that I believe is at play here.
Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?
When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on.
Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better.
> Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?
There seems to be a strong culture in American companies, and especially in startups, of rewarding heroic efforts. But if I see people putting in heroic efforts to get things done I tend to look for ways to not need those efforts in the future.
Good experienced engineers can help ensure that you don’t keep having to go that extra mile to get the job done in the first place.
Most things are not written in stone. You can probably change even if it's not comfortable to do so. Maybe a different role or organization would be a better fit. But typically just getting your part done and moving on isn't the best fit for a lot of jobs and, even if you work for yourself, you probably even have more interactions with clients at that point.
Well, nobody has the intention of being a problem engineer. That said, from your comment I haven't really understood why you're considered (or are considering yourself) to be a problem engineer?
From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems:
1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it."
2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example).
3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid.
4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.
I would like to change many things I feel could be solved in better ways.
Unfortunately Im not a rockstar engineer and stuff takes me more time. I care a lot about maintainability, so writing docs or good explanations to design decisions simply take time.
As you can guess we often dont have that time in the industry thus most things look like they look.
My biggest issue right now is communicating those findings.
Curse of things seeming too obvious, trivial or simply requiring more time.
I'm an Engineering Manager, i wouldn't consider taking time to do any of the things you listed be what I would consider to be the definition of a "problem engineer".
To me, a problem engineer is someone who blocks the discussion, or that any solution needs to fit the specs of what the problem engineer wants, even before anyone has outlined what the issues are. Basically someone everyone walks on eggshells around. Anyone who breaks collaboration, team work, and especially anyone who ignores good engineering practices just because that makes that specific person happy... Is a problem.. for all the engineers.
You take a little extra time, that's fine. You're taking that time to do good documentation, or writing higher quality code.. you're an engineer, that's what I expect. Higher quality code and better documentation helps boost velocity in so many ways. You're doing yourself, and everyone around you a good service.
One thing I'll add - or maybe it expands on too technical of a leader - is when a brilliant outside hire is brought in to fill the arch/principal/whatever role.
Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt"
I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance.
Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing.
Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.
It sounds like the VP Eng was actually a great leader if he could take feedback like that in stride and admit when he was wrong. Bad leaders would have dug in their heels and sidelined the person with abrasive feedback (you).
Absolutely. My point is that it doesn't always go that way. He had his faults, but he could take string feedback. If I recall, he said something to the effect of "not many people speak to me like that. I forget how helpful it is to be challenged"
Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.
Sometimes it goes the other way around. New people hired from bigger company, advocating for solutions that are known to work if painful to start, opposed by "old guard" who finds nothing bad in their hundreds of SSH windows with root logins into machines and where the "technical debt" is actually reaching the point where it will result in losing important clients through a legal statute impacting said technical debt
Re: 3. "Problem engineers" are a similar problem to those users in a forum who don't actively break the rules but destroy the community.
And for 4, the opposite is even worse, aka "no management". So when you develop something but it turns out the outcome was not needed or in a different way.
Problem engineers are not necessarily all new hires. It could also be people who were there initially but fail to transition into a role more suitable for a growing company.
A classical example, which I've seen before, is a cowboy coder who can be a useful asset in the very early stages, but who later demonstrates a total lack of teamwork ability.
Such people are even worse than bad new hires because they have a certain clout with management who is therefore more willing to turn a blind eye.
This sounds like the opposite of what the author had in mind. The cowboy coder is the one with spark, and the need to "transition into a role more suitable for a growing company" is the problem.
Companies change, and if you can't adapt then the problem is you. Being able to work together with your peers and not alienate them is not too much of an ask.
What is to be done if you find yourself in the first situation (too-technical leader)? I found myself there before a few times...reporting to someone who was no doubt a brilliant IC but has no concept of things like communicating vision or even basic project management. Would be curious to understand if anyone has been able to "fix" this from the IC side.
I find it hard to imagine that it's possible to, in all likelihood, improve a too-technical leader problem from the individual team member position. There's only two ways through which that I can conceive it being solved:
1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc.
2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.
I'll throw in greed as another factor. Being ambitious is fine, but being greedy will wreck a startup in no time flat. Or in the case of my previous employers, in about 13 months ...
I've always assumed that greed, particularly when it's egregious and endemic, would more rapidly unwind a start-up. My OC was more focusing on those mechanisms that tend to be at play at start-ups that cause them to gradually decline/implode.
However, I totally agree with your point. Also, sorry that happened to you!
I recall a teamwork study that found few if any superstar team players can really make any given team better, but they did discover that one bad apple can easily kill a team’s productivity, happiness and etc.
I once worked for a company that was really great about “no finger pointing” and lots of trust of employees to do the right thing.
We acquired a small troubled company along the way, they were a mess with finger pointing and empty accusations. Within a year they had infected our entire department:(
Elaborating a tiny bit on #2: It is a dangerous situation when non-technical leadership comes up with very specific technical opinions - based on hearsay & evangelists on their Twitter/Instagram.
"I saw X on his Reel telling changing everything in our frontend to purely Coffescript will be more durable" is a kind of advice which does not bode well generally
Ok, so a simple solution is to compose your larger company of a bunch of startups that remain to operate as such, no matter what the larger company does. So anything that runs on top of these startups acts as a customer of these startups.
I went through this cycle a few times. My favorite, and last successful startup was acquired by a gigantic international corporation four years in (2007), and I stuck around for another two years.
After the product shipped, the need to support customers and sales definitely slowed things down. Our fantastic VP of Engineering became CTO, and hired a middle management moron as VP, and that was the end of the good times. The new VP then hired "team players" instead of good engineers, rewarded loyalty over competence, and hilarity ensued. And then we were acquired.
My fun startup-like time was reduced to ONE WEEK per year -- the week between Christmas and New Year. The rest of the year, all the layers of management were present and doing what they do. But that one week of the year, nobody was around, so I found myself much freer to do what I thought was important. And that wasn't just self indulgence, (I mean, it was, but not only), and having an alpha version of a shiny new thing forced the organization to go along.
> Our fantastic VP of Engineering became CTO, and hired a middle management moron as VP
Hardest lesson I learned when I got promoted to upper leadership positions: Hiring middle management is incredibly hard. The number of absolute sharks in the candidate pool is wild. People will show up, sense that you’re new, and tell you everything you want to hear about how they’ll solve all of your problems. They’ll claim they’ve done exactly what you need at every prior company they’ve worked for. They’ll flatter you and tell you they’ve been waiting for an opportunity to work or someone like you.
Imagine the schmooze-iest IC candidate you’ve ever interviewed, but 5 times better and harder to see through. These people have charisma you wouldn’t believe (when you’re new) but they don’t really care to do the hard work. They just want to worm their way into the company and then extract. They’ll extract compensation for themselves, extract headcount to hire their friends and build an empire, extract compensation for their friends (who will return the favor at a future company), extract lucrative contracts for their contracting buddies (where they might even be in on the take). Years can pass before people realize they haven’t really done much despite producing a flurry of activity. They may have even driven away the good employees who got tired of their BS or were pushed out for identifying their incompetence.
I was unlucky-lucky to watch this play out under a fast rising CEO at a lesser known unicorn. The number of sharks who showed up and charmed him after he became successful was unbelievable. The same thing plays out with less experienced middle managers who get thrust into high-budget positions at smaller companies.
A highly successful hedge fund with a highly successful group got one of these senior managers and they managed to spends hundreds of millions on crazy ideas (not my money syndrome) while the people who actually built the machine originally were sidelined.
1) Don’t hire mediocre people. We knew this new VP was terrible. But the guy being promoted was impatient and wanted someone to take over.
2) Upper management and the board must not forget the reason why the company exists, and put profit ahead of the mission. Otherwise you end up with 1980s GM, or the Boeing 800 Max. Read this speech by Dave Packard, a founder of HP. https://sriramk.com/memos/packard.pdf. A very clear, concise summary of how to run a company, and how to think about your job. And anyone who has experienced corporate America can immediately see that nearly no companies are run this way.
I liked parts of this and disagreed with other parts.
Perhaps the part I agreed with the most is "don't hire too fast". It's difficult for me to think of a startup (or, honestly, any company) that failed or experienced pains from hiring too slow, but I can think of tons of problems (often from personal experience) from hiring too fast.
One piece I couldn't help roll my eyes at is the "don't use Jira" bit - like the sun rising in the East, bashing on Jira is the favorite past time of engineers. Depending on your type of startup, Jira may be a great tool for the job. E.g. if your company has lots of different workflows it needs to support, it can be very easy to waste a ton of time due to "dropped balls" if things aren't tracked well and issue ownership isn't explicitly clear. Of course, it's easy to waste a ton of time over-complicating Jira with a million unnecessary issue states, but IMO Jira has made it much easier for small teams to use it and be productive quickly (i.e. team-based projects). I'm also not saying Jira is the best tool to start with (my last startup stated with Trello and it worked well), but once you get into production and have a lot of operational issues to manage and prioritize alongside new feature development, you're likely going to need some Jira-like tool to keep everyone aligned and informed.
There is an incredible important step missing: find a viable business model. Getting ideas and building them is "relatively" easy (just look at the vast open source ecosystem) for engineers but integrating/pairing/merging them with a business models that generates revenue within a limited time period is hard.
New ideas getting shot down for fear of cannibalizing existing revenue.
The product that was the breakthrough is likely (somewhat) wonderful and loved (or at least used) by many and generates the bulk of your revenue. However we all know that solution that has gotten you this far has problems and there are many ideas to be able to go to the next level.
But any idea that is seen to take away from the focus of that main revenue generator will be fought unless there is VERY strong leadership. Anything "new" will impact marketing budgets, Sales incentives and revenue goals, threaten those who are working on the "legacy" project, not to mention external forces who are only interested in the bottom line revenue and EBITDA numbers for the next quarter, not the next 1, 3 and 5 years.
I've had this happen at 2 startups I've been through. Both had successful exits, but could've been more and build a much better future path for themselves.
The value of this recommendation cannot be overstated. Put another way: only hire when there is no other way to solve a problem, and even then do so carefully. Be willing to elongate timelines substantially as a result of this practice; the medium- and long-term costs of over hiring are much worse than the cost of later launches.
Unfortunately, the funding environment and growth expectations for startups often incentivize the opposite behavior.
Coming from Canada (and Quebec especially) it's curious to see a recognition of this emerge in SV. Quebec has a problem that historically small enterprise funding came from sources that require commitment to hiring plans (i.e. in two years hire fifty people or you get nothing), which leads to absolute madness, and a unsurprising lack of successful exits.
I had seriously underestimated how bad the hiring situation for startups in SV had become though, and a lot of people are using them as a bench to either recover from FAANG burnout or to put on a resume while training for interviews. With that dynamic a hiring manager is going to end up leaning towards being too optimistic because you can't risk not noticing the few that can build your company. You just need to be aggressive about removing those that aren't working out.
Precisely. Can also apply to tax credits. Luckily since the tax credit war race to the bottom ran out of steam this nonsense has been far less prominent, but for a long time many of the game studios in Montreal were dependent on this sort of thing.
I regarded many of these subsidies as killing the business dead before it had even started, but missed that if you can keep it going for two years at least the managers escape with some decent money.
286 comments
[ 2.9 ms ] story [ 273 ms ] threadIf a customer is large enough, and their pockets deep enough, you can absolutely justify building what is good only for that customer, and shipping it only to that customer. Keep that branch separate from the general-purpose product you're selling to the pleebs.
The secret sauce is how a startup goes past this headcount. Ideally many software companies quite honestly don't need more than 150 people!
Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person.
https://en.wikipedia.org/wiki/Dunbar%27s_number
The world scaled past this millenia ago. You can scale your company past it too.
Except fewer of your users will have jobs because the AI multiplier means smaller teams. So your addressable matter will shrink. So another race to the bottom?
I'm sure we'll work it out right..
Reminds me of the Mass Effect games, where AI is essentially outlawed (because they revolted against the humans of course, but I can picture less scifi-ish reasons in the real world). I'm sure they're still allowed to use pathfinding algorithms and such, so they probably defined a level of net negative (to society) AI and just regulated that. Starships for example are manually piloted (surely with intelligent support systems and basic auto pilots) IIRC.
Or let me raise a The Culture argument, where computers/AI is hyper-advanced, AIs are friends, and no regulation whatsoever is needed.
I mean real, observable things, not theories.
Human attention span is a finite resource (we can only do so much in one life), and tech startups can consume a lot of that for relatively little payoff. Building a successful startup is like solving the bitcoin hash on your first few cycles. The barrier for entry is low, but you can hit it big (and consume a lot of cheap, finite* power too).
The payoff is worth the risk since our communication technology is nascent and underexplored. We have an abundance of time right now because of what tech has done for us, but the cultural and environmental costs of growing tech are not well understood.
Use of attention span is difficult to measure right now, but that could change in the coming decades. That said, parent comment seems to use "tragedy of the commons" as a stand in for "human nature."
Except more of your users will have jobs because the AI multiplier means new opportunities to provide cheaper services available to more businesses, new companies that weren't economical before will be founded, entire new markets and whole new professions will be created. So your addressable market will exponentially grow. So another bull run?
I'm sure we will work it out right.
I understand theirs optimism (and pessimism), but optimism in and of itself doesn't make something true.
The products of these new vendors are now available to many big customers in a major city (a single one where we are doing a pilot), and the vendors are reporting they are already getting 2 times the volume of orders they used to get. They didn't even have the means to deliver that much product before - now they are able to do it because their logistics are handled for them by my client (economy-of-scale advantages) instead of them DIYing it, and they use the freed time to do more of their main business.
The customers are super happy because now they're getting fresh food produce from local farmers just days after it's been actually produced, which increases the quality of their products (food in restaurants/catering, usually) and they are already getting significantly more positive reviews thanks to that, which brings them even more new business of higher value. And funnily enough, the products they are getting are cheaper than what they got before, even though the quality is incomparable.
AI is a huge win for everybody involved:
- My client is no longer forced to deal only with the biggest vendors.
- The employees who used to do sales/onboarding, vendor/customer support and product catalog management are still doing it, only now they're handling 10 times more products from 3 times more vendors, and focus on special and more interesting cases instead of doing grunt work.
- The vendors have gained more customers than they ever dreamed of, make more money per unit and have much cheaper logistics that they don't need to think about nor spend their time on (we're talking about guys who used to hop in a truck themselves to deliver their stuff).
- The customers are getting much better quality for lower price per unit. There's also much more product categories they can choose from now.
- It's more environmentally friendly and supports the local economy.
Idk why people don’t like the question, I’m actually looking for a developed model/ paradigm around this concept. No sense reinventing the wheel.
I think the best way to scale is to build processes that reinforce the traits you want in a team, and hire managers who understand teams are collections of unique individuals, as is the manager. The manager should be free to manage their people in a way that optimizes delivery and reduces churn. Between teams there should be a very high bar for quality of communication and delivery. The culture of the organization should be built around respect for each person hired and a relentless focus on ensuring individuals end up in teams that they are effective in and are therefore maximally effective as teams.
The startup that does that should absolutely be called "Boys from Brazil".
Now, if it wasn't for all that, there's still the problem that, from personal experience, most employees don't invest as much energy as a founder would - which is perfectly understandable. As the founder to employee ratio gets smaller, you find yourself hiring three people to do a job you could do yourself, just to make sure it gets done reliably and timely. In a smaller startup, early hires are more similar to founders because they're close to them and stand to gain a lot if the company succeeds and grows. For employee #213, they sell 40 hours of work per week and their fixed salary is all they really stand to get out of it.
So while I like the romantic idea of having a large company comprised of multiple independent startups, I haven't seen that work and I can barely picture it work :( One can get somewhat close to this with the right organisational structure (e.g. sacrificing efficiencies of scale for team autonomy where feasible), but it's not even close to the same thing.
It also eventually became a monolithic org.
Same with Valve and flat org structures.
Once something scales enough it becomes the blob, like everything else.
In lots of other (worse) companies they had huge teams delivering a lot less.
The fruits of labor grow ever higher. By which I mean: In the early days of a startup the problem space is ripe and plentiful, the impact you can have is outsized, and the pool of people with which to share it is the smallest it will ever be.
As a company grows, all three of these factors are subject to strain. The problem space becomes sparser, outsized impacts are recognised further up the ever-growing hierarchy, and the pool of people with which you're sharing your impact becomes larger and recognition becomes shorter lived and more diffuse.
Rands has a great article on that topic well worth reading: https://randsinrepose.com/archives/stables-and-volatiles/
It matches my experience with startups experiencing challenges as they grow.
There is no skin in the game as there's no stock options nor revenue share (founders want to keep it all for themselves ofc) and you can be fired on a dime without any due process, software proprietary and closed source of course, so you can't use it for your own stuff either.
Only the PM spends hours on the phone talking to users and then gives you a direct task to work on. The task is always max priority and comes in randomly so you must drop whatever you were doing before to immediately implement it, usually getting the next one before the previous one is even done, making sure that critical tasks inevitably get forgotten and end up at the bottom of the backlog, leading to catastrophic software cohesiveness.
Working on something you want? Haha, right. Do what you're paid to do, no exceptions. Coworkers of course all remote or hybrid so there's no meaningful cooperation and endless Jira review meetings to tell everyone what to do. Daily progress reports of course, gotta make sure people aren't slacking.
The result is 100% turnover.
Problem solved? Just be sure to leave a note online for potential hires to avoid the company.
I guess the lesson to be learned is to be very careful when scaling up your organization. Past a certain point change becomes very difficult. I.e. only grow headcount above 100 when you're certain about product market fit.
This is painfully on point.
Perhaps, though, if you only hire when you need, you can be more competitive with pay.
Meanwhile your sales team colleagues get their incentives paid out right away, in the very next quarter, and instead of equity lottery tickets it’s just cash.
I’d like to see engineering get some of the types of cash incentives that sales teams get. Perhaps the only reason they don’t is because it’s too hard to come up with metrics to base commission on. Instead, they rely on equity awards even though the value of the company is often quite detached from the quality of the software.
The fun of a startup is nice but it’s probably not worth it if you’re getting below-market compensation, crappy healthcare, long hours, and the IOU of an equity stake that’s probably crafted by financiers to screw over regular employees.
The arguments articulated are entirely false: ex. N^2 communications. This is reductionist and absurd. No team depends on every team in the org. Their domain is often fairly small and their adjacent teams extremely finite. The exception are “core teams” (which have been my specialty). However a well functioning core team doesn’t have n^2 communication overhead - they act as a concentrator and teams come to them - which is N. N can be large, in which case effective triage is crucial, but so is automation and self service, coherent platforms that are self documented, and some folks on the team that really really enjoy teaching.
I’ve burned out though on building these teams. It’s absurdly hard work on management. But management is supposed to be absurdly hard work. My next gig is as a distinguished engineer at a late stage startup - back to the roots for a while.
I’d would disagree - I had the exact experience that the autor described. But you are right on this point
> it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there
I still think it’s related to size and bad incentives. I heard stories of people at FAANG that said that department X is like a startup but Y is soul sucking boredom
Specifically this is entirely false due to the existence of X:
> Is this preventable? I think not.
I> f you look closely, all these problems fundamentally come from:
> Decreased skin in the game, which reduces team alignment
> N^2 communication, which creates need for managers and specialization, which reduces individual agency and breadth of learning
> Reduced risk tolerance, which slows everything down
> #1 and #2 are inevitable results of having more employees. #3 is an inevitable result of having more users, partially due to government regulation.
I think a large company enables Y departments to exist without the company imploding immediately. Survivorship bias ensures most startups that last longer than a short amount of time to appear like X, when I know there are plenty of dysfunctional startups (a friend tells me Ghost is a great example). But due to the economics of a startup they evaporate quickly. In a large company Y departments can limp along for a long time or indefinitely because Y’s function needs to exist and the company can afford for it to suck ass to work there without it going out of business. However invariably X departments in large corporations are where the magic happens, where people want to work, and what moves the large enterprise forward.
I’d also note that not everyone wants to work in a startup environment or are able to. Many engineers got into it for a good paycheck and don’t have much interest in anything particularly dynamic or engaging. They’re perfectly happy committing once a month and sitting in meetings. That’s not me, but I can also see when you build an army, you can’t build it out of special forces only.
So, instead of saying X can’t exist, when it clearly does, I think it’s more useful to say you should be careful where you work in a large company and seek out actively the X departments by learning what Y departments look like and how to spot an X department.
Likewise, most of the startups I worked at were exciting by not intoxicating. They were relatively banal in their goals (change the world through prestige makeup e-commerce or something), their technology modern but not innovative, and the teams tight but not always coherent like a well oiled machine.
being able to apply them effectively can really be really frustrating though. and there is always the danger that your two year development arc will be demolished by 'shifts in overall strategy' or 'belt tightening' or a reorg.
I'm not persuaded anyone is in a position to know that there's only one way for people to enjoy work, and to know what that one way is.
Return to office is a current example. My strategy here is that people know how they work best and that’s up to them. We have ways of getting together and collaborating, asynchronously and synchronously, and don’t enforce a mandatory hybrid approach. I encourage the team to intentionally meet up in person regularly, and the team self organizes synchronous in person time on a regular basis. I set up a drop in zoom room that’s always signed in on a conference room and people drop in for adhoc stuff all the time. Some people stay signed in all day on the conference room. I make sure ticketing systems, chats, and other mediums are well used. I regularly talk to people about their well being to be sure folks remote are OK, as sometimes fully remote can mean fully depressed.
Compare this to a “standard” managers approach. “We will be in the office three days a week, with a mandatory day on Wednesday. This is necessary because people work best in person but we want to give people flexibility because we know employees value that. Failure to comply will result in performance review impact. Our company’s culture is built on in person interactions. We do this for the children.”
Typical management is about treating people as butts in seat filling a role with a define set of measurable performance metrics - aka conforming cogs in a machine. that is the method that assumes there is one way for people to enjoy work, and knowing what that one way is.
My way is acknowledging I don’t know any one way that’s best, and specifically, there is no one way for people to enjoy work. It’s my job as a manger to figure out what each and every person on my teams way is, and to do my damnedest to create that environment for each individual. I work hard to hire managers that will also do this, and I meet randomly with people at all levels of my org to be sure they’re being treated like this by the people on my direct team.
The down side for me is I stick out like a sore thumb in the great cog machine of other managers. They don’t understand what I’m doing, it bothers them, and they feel like I’m getting some sort of preferential treatment. And maybe I am, because my organizations are almost always considerably more effective and successful than the rest of the org, so we get enormous latitude. But shielding my people from the game of thrones is exhausting - more exhausting than the rest of my job.
All this said, I’m not the only one who does this. I have encountered a lot of leaders that do this. They’re the ones people want to work for. That’s why I paid attention to what my early leaders were doing and emulated it - the one way is there is no one way ;-)
How about people who don't want to work for a "manager"? Where should we go?
Maybe I'm late in my comment but, I have two questions if you do not mind.
If you have a manager that is not quite like that, but probably somewhere in their mind would agree to that stance, how could one push that person to that direction? I have my manager (and a friend) in mind, gives good autonomy and let everyone work in the way they feel is optimal. But it also most often lead to aimless or fuzzy goal setting, a lot of ambiguity. My guess is that the thing lacking is the inquisitive nature; like you mentioned you do, he does not check in on people how they feel, what's blocking them, what's suboptimal for them. He simply check in for an update on progress and set meeting to update what he's up to.
Is there any good material or pointer that could make someone manage more like that?
I also informally manage one person due language barrier and the question also applies to me.
This is an excellent point. In my experience a majority of people value stability and predictability in their lives. They would rather have someone tell them what to do within well-structured bounds than contend with the ambiguity inherent in an early stage startup, or with solving massive product/business/technical problems with too many stakeholders to fit in a room.
I think the challenge is the people with the intrinsic motivation and stomach for the ambiguity can struggle to grow in large corporate environments that are full of good soldiers who stay in their lane. It's not uncommon for entry level ICs to come in with 3 or 4 layers of management between them and VP level, and then become pawns in middle management games, or stuck reporting to Peter-principle cases who teach them all the wrong lessons.
This is why I was really glad to have worked in startups when I was young, to really get exposed to all the moving parts and fundamentals of an operating business. It's just much easier to learn when the big picture is more legible, you have the latitude to iterate faster, make more mistakes, and see first-hand how things scale (or don't!) from the ground up. These days I see too many ivy league grad ex-FAANG who have all kinds of ideas of best practices with no understanding of why things are done that way at the tech giants, and extremely limited ability to reason from first principles about what makes sense in a different context.
From the article:
"You can’t just work on whatever you want; coordinating would be an O(N^2) communication mess."
Evidently, you're agreeing with the article. So which part is false then?
I also disagree with all the other points they make about large companies. Not that there exists teams in large companies that suffer these issues, but that there exists no teams in large companies that don’t have these issues. I further extended it to say startups also aren’t without issue, and many are totally screwed up. They just don’t last very long.
I think you’re being unnecessarily harsh and reductionist of the article’s arguments. I’ve experienced exactly this failure mode in startups.
The counter-example you described is an example of properly managing the N^2 complexity, not an example of it not existing.
I would note that the author categorically says it’s not possible for a startup like environment to exist in a large company. That’s what I disagree with.
I agree with your point that a large org does not guarantee what the author claims. The author claims that the organizational friction can be measured by productivity, but you recognize culture as the better diagnostic criterion. The big O metaphor does not extend well to the argument, as you point out.
I'm looking for hard hitting interview questions so I don't waste my time on "soul sucking" positions.
A few things I’ve noticed that might help:
* ask people in the team what they do and how they work, and how the team helps them work best. If they answer “oh I’m a programmer 2” and have wishy washy answers on the rest, that’s a bad sign. They’re being managed by a “by the book” manager. If they describe some complex role that isn’t out of the HR leveling guide, and a unique way of working that’s accommodated by the team, that’s a good sign. If you hear everyone in the team describing a role that’s unique and tailored to them, then that’s a great sign.
* this is controversial but I think any org that slavishly follows modern day agile / scrum can not be dynamic. Nothing more to say other than back in the 90’s Bay Area hanging with thought works and those folks, agile was something very different than today.
* the manager themselves should be very open to questions with thoughtful answers that aren’t rote. They should likewise spend more time understanding you than usual. They should be assessing your fit in their team - do you fill a gap? Do your weaknesses complement others strengths? Are you looking to turn the crank or are you looking to innovate?
Also, be aware of yourself. Not everyone does well in a dynamic environment. It’s more chaotic and less structured. If you like clearly defined and regimented work, go for the clearly defined and regimented team.
It is preventable.
I built an ISP in mid-90s, a digital agency in late 90s, another digital agency and a streaming CDN (world's first VDN) in 00s, as well as worked as chief architect for cloud at world's largest hedge fund and CTO of world's second largest bank. I'm currently an entrepreneur again, co-founding and building a hedge fund from scratch.
My experiences across these, particularly at the digital agencies (where I got to help hundreds of clients go through growth) and the mega bank (where I got to see how things working when small can also work somewhere global), tell me all the goodness from the initial list can be built into the operating model, with a couple caveats.
These are hard[^1]:
1. No domain versus technology divide. If you hear "The business wants..." or "I need I.T. to..." it's not going to work. At a fintech, for instance, all teams should have both fin and tech on the team, owning their outcomes.
2. No command and control managerialism better suited for piecework than building. No project managers. No scrum-masters. Importantly, and apparently pure heresy: no projects.[^2]
Instead of projects, think, what should we do better?
Instead of controlling for budgets and delivery dates, control for focus (like priorities but mostly about saying "no" to things instead of "yes" to everything with stack ranking) and outcome value (e.g. RoI or RoE instead of hitting dates). Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects.
Hitting dates well becomes easy and fun/rewarding when you scope using focus instead of pre-defining all (probably imperfect) requirements and you ensure teams are equipped with people (will, skill), and resources (tools, space) to own outcomes. (If people are called resources, run away.)
It is preventable, and I'm happy to talk live with anyone building a work management tool that is interested in our approach.
---
[^1]: see wicked problems: https://en.m.wikipedia.org/wiki/Wicked_problem
[^2]: You can do time-boxed work with an outcome. That could look a lot like a project. But the word “project” tends to bring with it a pile of practices that all kill the intrinsic motivation for building things you're proud of.
It's interesting even companies as smart as Linear (the Jira alternative, check out their Linear method pages for a lot of better than usual thinking) don't want to even listen why they should (and could just by allowing renaming a few terms in their tool) support a non-project-centric view of building your company and enjoying doing it.
Projects: the project comes in "on time and under budget" or is "late", but the work is fixed.
Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups.
You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes!
I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar.
Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work.
A project tries to fix both work and date, which doesn't work and is rarely on time.
A time box fixes the date, not the work. Iterative delivery always hits the date and generally works.
---
Using your weekend desk example:
You could want a wood inlay desk.
For the "job to be done", the desk has to support you doing work.
In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend.
If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk.
The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk.
If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid.
Certainly, doing the inlay after assembly will require more effort.
So then ask yourself, was the deadline real, or was the inlay requirement real?
If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real.
---
What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements.
But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements.
Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead!
You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient.
If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.
It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
The problem is the professional definition of project, which comes with project management practices and preconceptions.
Those are generally harmful, because they try to manage or control both time and resources needed to deliver unknowns in advance of an inherently discovery-based process that results in (re-)scoping as you learn:
https://en.wikipedia.org/wiki/Project_management_triangle
> It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
I posit it's not just "prefer", it's reality. That all "projects" are in fact "fixed time, variable scope" in hindsight. In other words, "it takes as long as it takes" to uncover and ship a minimum viable scope for the "job to be done".
As an entrepreneur, it's preferable to create a workplace that acknowledges that reality up front, and designs the "way of working" for it.
As an engineer, it's preferable, as you note, to join one.
---
Some more musings:
The OP's post says work stops being fun. A key reason why is all the unfortunate beliefs, management overhead, and recrimination for practices trying to override reality and failing.
Small startups don't care. The cost of 5 people being wrong seems irrelevant compared to charging at the problem and getting it done, or finding out it doesn't work so you can pivot. How many "Show HN" are after a pivot? How many "Launch HN" for that matter?
Enterprises care. The cost of 500, or 5000, building the "wrong thing" seems unacceptable (even if less cost per person!), so big companies keep piling on layers of risk management that delay getting in touch with reality.
One reason they do this is the value of the outcome isn't clear. Perhaps it's political, perhaps it's make-work to keep someone's department full sized, perhaps it's a failure of imagination. So they develop scar tissue about shipping multi-year boondoggles that deliver no value. The problem was, it wasn't valuable in the first place, and if they'd just tried it out in the small and iterated, they'd have learned with fewer man-hours than all the planning.
For a great take on this, see Tom DeMarco (author of Peopleware) rethinking his entire stance on projects after 50 years(!) trying to tell people how to project-manage better:
https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...
He even throws in the towel on estimation with the now famous phrase, "All projects that finish late have this one thing in common: they started late."
He effectively accepts reality: the needful is the needful, the value is the value, so if it's valuable you'll do what you have to do, just start already and get it done.
What I've found is, a big enterprise can understand this. The CEO can hold his business leaders accountable to telling the value that an effort should generate, the CFO can "venture capital" an appropriately sized investment in a fixed capacity team, and the team can focus to deliver value -- or offer a pivot -- before they run out of funding and can't raise another round.
If they're shipping well, and getting market traction, the business leader looks good, the CEO is happy, and the CFO can continue to invest. One neat thing with this is the remarkable "budget" predictability that comes with investing in teams instead of in projects. Control your capacity and focus, you'll always hit your expense nu...
Maybe if you sell to end users. If you have clients with SLAs, requirements etc and legal penalties for missing them, not working to delivery dates isn't going to work. Even in teams with projects, ensuring deadlines are met is still tricky.
https://news.ycombinator.com/item?id=37100090
Telling me "it isn't going to work" is why I call this approach "heresy".
By contrast, I've observed across every size firm from 1 to 150,000, it does.
Jira is a fine tool in and of itself, just don’t turn it into a religion.
Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof):
1. Too-technical leaders:
As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup phase sometimes move into these when they are not the leadership type, causing engineering team to devolve into a visionless, directionless zoo.
2. Non-technical leaders:
Inverse to the above - as startup scales, in desperation, new leadership roles are filled with non-technical individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous).
3. Problem engineers:
Small number of leaders lack a spine, conducting shallow interviews and let in "problem engineers" who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around.
From experience, it only takes around ~5-10% of a team being this type for it to have a large negative impact, as they tend to derail progress, dodge responsibility, reputation farm, push rubbish, all that nonsense. It harms morale, and the skies turn grey in the office...
4. Micromanagement:
Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration.
EDIT: I'de love to hear how these foot-guns have been avoided. From experience it seems really challenging, as if like magic; as if cultivating and maintaining a good engineering team and culture therein is like balancing a pencil on it's nib...
It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.
There are still things you can do, e.g. don't pick the offers in a round with the most $$$ - instead pick the 1 that will help you the most.
Set the right expectations. Most of the time it's not the VC money that's the problem but the founders being consumed by suddenly being "rich".
1. Not correcting problem hires fast enough.
First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out.
The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He was wholly incapable of doing the job but they kept him in the job for 2 years to “give him a chance to grow into it.” Everyone below VP level openly talked about how the VP of Product was incompetent and how to work around him.
The company’s product initiatives ultimately failed to even get started and they had to pivot to entirely services based work. Do not stay at a startup that insists on keeping unqualified people in leadership positions long after everyone in the company has given up on them.
2. Firing the wrong people
The same startup was forced to downsize, largely because their product plans failed to even become defined enough to start under the incompetent VP of Product.
It was the perfect opportunity to fire the VP of Product and his sprawling empire of people who did very little, but they avoided that due to his connections to a C-level executive. Instead, they started cutting engineers. They focused on cutting engineers with the highest compensation out of a misguided effort to cut as few people as possible.
In the process, they lost their key engineers who were holding things together. They sent a message to everyone that incompetence is tolerated if you know the right people. And they lost even more core engineers who quit in the months after those layoffs.
Everyone makes hiring mistakes. It’s how you respond to those hiring mistakes that will seal the fate of the company.
The specific advice he offers is "hire slowly, fire quickly."
Lawsuits
Details vary, but for example in Poland you can (simplified case):
1. Hire for fixed-length term of a year 2. First 3 months of that are "trial period" - you have minimal paperwork for firing during that time, effectively no chance of lawsuit (if someone brings a lawsuit that gets far enough for any paperwork to reach you, you have much worse things to take care of internally) 3. After the fixed-length period, if you're happy with the employee and want him to continue you switch to "permanent" contract. If not, the term lapses and that's it.
1. Dalio doesn't understand what a "principle" is -- but I can understand that "Aphorisms, Cliches and Hunches" is a less arresting title, if much more accurate. (See [0] for a fuller review on this.)
2. Dalio's version of Bridgewater doesn't line up with the experience of others -- which I have heard from so many people as to completely undermine whatever he might say.
Now, in the book's defense: I didn't get through it and perhaps it got suddenly palatable or interesting. However: I also couldn't get through it -- it was just that bad.
[0] https://www.goodreads.com/review/show/2233988523
What, in your opinion, defines what is sensible in business and leads to your frustration with Dalio's message? Can you give personal anecdotes?
[0] https://www.youtube.com/watch?v=9QMGAtxUlAc
[1] https://vimeo.com/230142234
[2] https://www.youtube.com/watch?v=VzdVSMRu16g
We just hired for a management position a couple of month ago and I could tell from the very first meeting that it was a bad hire. I made sure with my team that I’m not totally wrong and then communicated my doubts to the C-Level. It took some time because they wanted to give them a real chance but just before the probation ended there was an evaluation meeting and the feedback was, without exception, negative. Took two days and they were gone.
Of course there will be hires that can uphold their charade for six month but I would say that’s an exception.
Back in university, most of the students in my Chemistry course had A-Bs (grades were published publicly). The final for the course though was set up by some national body (in the US), and all but a few in the class got no higher than a D. Why? Because the national test was reflective of what students actually learned. The typical university multiple-choice test just self-selected good test takers. I myself got in the habit of only attending certain classes once a month because I knew how to game the tests and still walk away with an A-B average (e.g. have a good idea of what will be tested, know the material well enough that you can eliminate 50% of the false answers, and then make an educated guess on the rest.)
The same is true in hiring. It can be easily gamed if you don't have a great interview process (most companies don't). Even worse, part of that is by necessity. Each candidate has a different set of experiences, but the interview is made to be as routine and consistent as possible to weed out any potential biases (e.g. candidate given purposefully hard question or colored feedback because interviewer didn't like them). To truly vet a candidate, you would need situational questions and feedback, like they quickly glossed over some part of the question, so I'm going to go off-script and drill down into this area. Big companies especially run far away from that due to risk of discrimination lawsuits.
The reason "fire quickly" may be appealing advice to some is that solving problems takes effort without a clear guarantee of return, and leaders usually end up trying easy solutions that diffuse blame or create the illusion that something has changed. Then they wonder why productivity is not up or why employee sentiment is middleing.
I also wonder what their actual competitive advantage was. My guess is Dalio himself had a good way to think about economic questions, and that they used not-too-simplified computer modeling before most others.
At the end of the day, startups are run by people, who generally prefer to work with their friends, avoid conflict, etc. There's no great mystery. The mystery is when things work well.
And another time, seen a less technical leader step in, see engineers around me roll their eyes a couple of times at the lady (with maybe a smidge of male chauvinism blended in), but then see her actually fire bad hires, hire star players, and get everyone to align their priorities so they could be productive. Leadership is a very different job from the kind of technical excellence that too often gets rewarded by promotions (vs raises or bonuses).
My last industry job saw the company implode from this cycle as everyone got pissed off and left the company. My old ex co-worker sent me a letter from the CEO last week saying layoffs were starting because revenues were down and they keep losing clients...
Having been there too, I feel like this is another recipe for disaster. Technical management needs to be able to make calls on escalations — that's in fact one of their main jobs — and when they don't have the depth of knowledge to make the call on merit, they make it on rash impulse, or favoritism, or (perhaps worst of all) don't make the call and let issues fester.
Academic science is pretty much designed this way.
You get a faculty job based on your brilliant work as an IC (i.e., first author papers) but running a research group is a totally different skill set—-and often one people get very little training for.
Also, oh my do I ever have an extremely similar experience of an IC-type engineer going into a leadership position and trying to "engineer" it: put all teams, sprints, tech visions, growth frameworks, etc. in huge spreadsheets. I look back in jest now, lessons to be learned!
In other words, I don't think you avoid these, I think you understand they're coming and accept the trade off, making sure it's worth the issues you invite when you do have to promote those engineers/non-technical people, for example.
If a key engineer leaves, you lose a _lot_ more than 2-300k.
In opportunity cost, you lose tens of millions, possibly.
What I haven’t seen work is (which is what I think you’re describing more specifically) bringing on new hires or contractors to a project in flight in an attempt to deliver it more quickly. That’s where we get into Mythical Man Month territory.
I've seen how small dynamics resulting from individual personalities and nuances of org structure have led to massive dysfunction and productivity loss, even though everyone was well intentioned and doing their job to the best of their ability. I could list out hundreds of behavioral "flaws" that individuals exhibit, but there's no way to fix them all directly, good engineering can't be done by top-down edict and central planning. Instead, you need a critical mass of people, including engineers on the ground, with a good end-to-end understanding of the product and business so that micro-decisions can be suitably informed by the big picture, and the right concerns can be escalated for leadership attention. You need to be able to weigh the cost of product, design, legal, financial, support, security, and operations across both short and long-term to make the right decisions. This is only possible with a high degree of mutual trust and safety for experts to voice their opinion and find the right tradeoffs. It's very easy for egos and personality conflicts to come in the way, hence the need for maturity in leadership. Balancing a pencil on its nib is not a bad analogy.
The surprising/unfortunate thing is that dysfunctional unproductive organizations can survive and even thrive. There isn't an obvious cause and effect and the time it takes until effects are seen can be measured in years or decades.
1. Writing-intensive hiring process
This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process.
2. Transparent compensation
Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities.
3. Uniform compensation
One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks.
4. Very, very careful hiring
We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful!
[0] https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgD...
[1] https://oxide.computer/blog/compensation-as-a-reflection-of-...
Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix!
Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow.
As for compensation, those certainly are controversial. I believe in honesty, but your extent of it is quite...towards one end of the spectrum? Certainly interesting.
Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?
When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on.
Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better.
It's a complex world!
There seems to be a strong culture in American companies, and especially in startups, of rewarding heroic efforts. But if I see people putting in heroic efforts to get things done I tend to look for ways to not need those efforts in the future.
Good experienced engineers can help ensure that you don’t keep having to go that extra mile to get the job done in the first place.
Im a bit anxious and introverted and thus like to get my part done and focus on other things.
This always results in rest of the team losing will to go far and beyond.
I dont know what to do about it, beside aknowledging it exists.
Do you say that ppl like me should simply quit and go working at sewege?
I dont think I like that idea. So what can I do if thats just how I am ? I cant seem to change how others see ppl like me.
Most things are not written in stone. You can probably change even if it's not comfortable to do so. Maybe a different role or organization would be a better fit. But typically just getting your part done and moving on isn't the best fit for a lot of jobs and, even if you work for yourself, you probably even have more interactions with clients at that point.
If it's unexplainable, or the majority doesn't accept it, move on: change your ways or accept they are going to see you as such.
1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it."
2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example).
3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid.
4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.
Unfortunately Im not a rockstar engineer and stuff takes me more time. I care a lot about maintainability, so writing docs or good explanations to design decisions simply take time.
As you can guess we often dont have that time in the industry thus most things look like they look.
My biggest issue right now is communicating those findings.
Curse of things seeming too obvious, trivial or simply requiring more time.
To me, a problem engineer is someone who blocks the discussion, or that any solution needs to fit the specs of what the problem engineer wants, even before anyone has outlined what the issues are. Basically someone everyone walks on eggshells around. Anyone who breaks collaboration, team work, and especially anyone who ignores good engineering practices just because that makes that specific person happy... Is a problem.. for all the engineers.
You take a little extra time, that's fine. You're taking that time to do good documentation, or writing higher quality code.. you're an engineer, that's what I expect. Higher quality code and better documentation helps boost velocity in so many ways. You're doing yourself, and everyone around you a good service.
Don't beat yourself up.
> This always results in rest of the team losing will to go far and beyond.
The logic chain here is not very clear, I'm wondering if you actually understand what's going on.
Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt"
I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance.
Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing.
Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.
Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.
And for 4, the opposite is even worse, aka "no management". So when you develop something but it turns out the outcome was not needed or in a different way.
A classical example, which I've seen before, is a cowboy coder who can be a useful asset in the very early stages, but who later demonstrates a total lack of teamwork ability.
Such people are even worse than bad new hires because they have a certain clout with management who is therefore more willing to turn a blind eye.
Scapegoat mechanism.
1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc.
2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.
However, I totally agree with your point. Also, sorry that happened to you!
I recall a teamwork study that found few if any superstar team players can really make any given team better, but they did discover that one bad apple can easily kill a team’s productivity, happiness and etc.
I once worked for a company that was really great about “no finger pointing” and lots of trust of employees to do the right thing.
We acquired a small troubled company along the way, they were a mess with finger pointing and empty accusations. Within a year they had infected our entire department:(
"I saw X on his Reel telling changing everything in our frontend to purely Coffescript will be more durable" is a kind of advice which does not bode well generally
After the product shipped, the need to support customers and sales definitely slowed things down. Our fantastic VP of Engineering became CTO, and hired a middle management moron as VP, and that was the end of the good times. The new VP then hired "team players" instead of good engineers, rewarded loyalty over competence, and hilarity ensued. And then we were acquired.
My fun startup-like time was reduced to ONE WEEK per year -- the week between Christmas and New Year. The rest of the year, all the layers of management were present and doing what they do. But that one week of the year, nobody was around, so I found myself much freer to do what I thought was important. And that wasn't just self indulgence, (I mean, it was, but not only), and having an alpha version of a shiny new thing forced the organization to go along.
Hardest lesson I learned when I got promoted to upper leadership positions: Hiring middle management is incredibly hard. The number of absolute sharks in the candidate pool is wild. People will show up, sense that you’re new, and tell you everything you want to hear about how they’ll solve all of your problems. They’ll claim they’ve done exactly what you need at every prior company they’ve worked for. They’ll flatter you and tell you they’ve been waiting for an opportunity to work or someone like you.
Imagine the schmooze-iest IC candidate you’ve ever interviewed, but 5 times better and harder to see through. These people have charisma you wouldn’t believe (when you’re new) but they don’t really care to do the hard work. They just want to worm their way into the company and then extract. They’ll extract compensation for themselves, extract headcount to hire their friends and build an empire, extract compensation for their friends (who will return the favor at a future company), extract lucrative contracts for their contracting buddies (where they might even be in on the take). Years can pass before people realize they haven’t really done much despite producing a flurry of activity. They may have even driven away the good employees who got tired of their BS or were pushed out for identifying their incompetence.
I was unlucky-lucky to watch this play out under a fast rising CEO at a lesser known unicorn. The number of sharks who showed up and charmed him after he became successful was unbelievable. The same thing plays out with less experienced middle managers who get thrust into high-budget positions at smaller companies.
Thanks for the spot-on description. You are right, the more money involved, the sleazier it gets. It reminds me of the book: https://www.goodreads.com/book/show/18905630-hedgehogging
A highly successful hedge fund with a highly successful group got one of these senior managers and they managed to spends hundreds of millions on crazy ideas (not my money syndrome) while the people who actually built the machine originally were sidelined.
1) Don’t hire mediocre people. We knew this new VP was terrible. But the guy being promoted was impatient and wanted someone to take over.
2) Upper management and the board must not forget the reason why the company exists, and put profit ahead of the mission. Otherwise you end up with 1980s GM, or the Boeing 800 Max. Read this speech by Dave Packard, a founder of HP. https://sriramk.com/memos/packard.pdf. A very clear, concise summary of how to run a company, and how to think about your job. And anyone who has experienced corporate America can immediately see that nearly no companies are run this way.
https://en.wikipedia.org/wiki/Downfall:_The_Case_Against_Boe...
Perhaps the part I agreed with the most is "don't hire too fast". It's difficult for me to think of a startup (or, honestly, any company) that failed or experienced pains from hiring too slow, but I can think of tons of problems (often from personal experience) from hiring too fast.
One piece I couldn't help roll my eyes at is the "don't use Jira" bit - like the sun rising in the East, bashing on Jira is the favorite past time of engineers. Depending on your type of startup, Jira may be a great tool for the job. E.g. if your company has lots of different workflows it needs to support, it can be very easy to waste a ton of time due to "dropped balls" if things aren't tracked well and issue ownership isn't explicitly clear. Of course, it's easy to waste a ton of time over-complicating Jira with a million unnecessary issue states, but IMO Jira has made it much easier for small teams to use it and be productive quickly (i.e. team-based projects). I'm also not saying Jira is the best tool to start with (my last startup stated with Trello and it worked well), but once you get into production and have a lot of operational issues to manage and prioritize alongside new feature development, you're likely going to need some Jira-like tool to keep everyone aligned and informed.
The product that was the breakthrough is likely (somewhat) wonderful and loved (or at least used) by many and generates the bulk of your revenue. However we all know that solution that has gotten you this far has problems and there are many ideas to be able to go to the next level.
But any idea that is seen to take away from the focus of that main revenue generator will be fought unless there is VERY strong leadership. Anything "new" will impact marketing budgets, Sales incentives and revenue goals, threaten those who are working on the "legacy" project, not to mention external forces who are only interested in the bottom line revenue and EBITDA numbers for the next quarter, not the next 1, 3 and 5 years.
I've had this happen at 2 startups I've been through. Both had successful exits, but could've been more and build a much better future path for themselves.
Now trying to avoid this in my current home.
What if Apple had stopped the iPhone for fear of it cannibalizing* the iPod line of products revenue? * https://www.imd.org/research-knowledge/economics/articles/ap...
The value of this recommendation cannot be overstated. Put another way: only hire when there is no other way to solve a problem, and even then do so carefully. Be willing to elongate timelines substantially as a result of this practice; the medium- and long-term costs of over hiring are much worse than the cost of later launches.
Unfortunately, the funding environment and growth expectations for startups often incentivize the opposite behavior.
I had seriously underestimated how bad the hiring situation for startups in SV had become though, and a lot of people are using them as a bench to either recover from FAANG burnout or to put on a resume while training for interviews. With that dynamic a hiring manager is going to end up leaning towards being too optimistic because you can't risk not noticing the few that can build your company. You just need to be aggressive about removing those that aren't working out.
Are these local/provincial development funds that need to show job growth?
Any case where "we need to hire someone in the worst way" seems to deliver exactly that.
I regarded many of these subsidies as killing the business dead before it had even started, but missed that if you can keep it going for two years at least the managers escape with some decent money.