> Effective teams need trust. That’s not to say that frameworks for decision making or metrics tracking are not useful, they are critical — but replacing trust with process is called bureaucracy.
A thousand times this. Highly effective teams have super high levels of trust and mutual accountability.
The moment you lose trust, you now have to replace trust with some other type of mechanism. This leads to process/bureaucracy.
Trivial example for those that don’t “get it”: think about why do we need code reviews? If we knew people would write perfect code every time, they would never be needed. However, we hold them because we know that even in our own “best code” we may miss something/forget some detail.
However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code.
But that was a digression, my main point is that hight trust means high speed, low trust causes slow speeds. The more you can build up trust and eliminate/prevent process, the better your organization will be.
For anyone that wants more details on this, I highly recommend the book “The speed of trust” by Stephen Covey.
Ok but serious question...what do you do with highly ineffective teams that you inherit, and/or are contractors, and/or are the only engineers available, and/or are only motivated by a paycheck, and/or would rather be working on their five side projects, etc..... in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate.
Yet your job is to somehow produce high quality software. This is the not uncommon outside elite startups in my experience.
Assuming this is a serious question: You/Your group needs some serious help.
What you do about it depends on your role/level of influence in your organization. Regardless of your level, I highly recommend reading Speed of Trust (like I recommended above). However, two example roles:
If you are the CEO/key leader, there is no excuse for creating/fostering this mess. You have to address the culture you have fostered heads on. Your complaint: “But it will cost too much!”. If that is your mentality, you are missing the point. Don’t look at absolute costs, look at value, that is what good CEOs do. If you can realize $2 for $1 cost, or $5 for $2 of cost, which should you choose?
The $2 for $1 is what you realize by creating/fostering a low trust environment. When you hire folks, find the best people you can, and then enable them. If you aren’t getting good people, it is either because a) they think your environment is toxic or b) you aren’t offering “enough” to compensate them. Note: compensation is NOT just dollars. It could be flexibility, it could be the ability to work on their side projects, it can be ability to learn new skills, or can be shared vision. Take your pick. In general, after some number of x $$$, money becomes secondary. Foster a culture of trust, mutual respect, and you will get dividends.
If you are at the “lower” on the totem pole, the answer is more simple. Ask yourself: can this org be saved? If you brought this up to leadership, would they work to change the culture? If not, then it is time to pack your bags/look for a better org. If they will listen, You have to decide if you WANT to save the org. If so, you have a long road ahead, but if you can pull it off, you will gain lots of experience and will rapidly increase your marketability.
Edit:
In case it wasn’t made clear, let me make this final point for the ceo/leader: Spend the money/create the perks that allow you to attract the people you can trust, then once you get them, TRUST them. Yes, verify, but if you don’t do this, you are doomed to fail. Also, either find a way to trust the people you have, or get rid of them. It is a disservice to both you and them to keep around people you can’t trust.
One big caveat: make sure you are someone THEY can trust too.
Yes very serious question, and very real (multiple orgs). And most times the team manager has zero control over hiring or firing. Nor any access to C level decision makers, who are buffered by layers of HR.
The orgs I have seen this in are 100% safe - highly profitable, and often funded by government or at least heavily subsidized.
So, if I understand your assessment...managers who see this reality should simply leave, instead of using skill and tools to deliver value in a difficult setting? That seems overly pessimistic to me.
I think this is a great call out. This is infact the very moment that skill and professionalism in team management is called to the front. A really good manager can do something about this; but it's a gradual process and a hard one.
Fundamentally you need to change the culture of the team. The first step is to establish a team - in the situation you are describing there is no real team - just a bunch of people waiting for a cheque every month, a new job or being told that this job no longer exists. You need to figure out if there is a core purpose that some or ideally most of the people in the team will sign up to (with you - if you aren't "in" then they can't be), which will deliver for your stakeholders. Then you have to orientate the team to deliver this, some of them won't come along, some of them can't. You will have to do a lot of coaching with some of the ones that would like to.
The big question : what is the core purpose that your team will adopt and which will change how they work and what they will do?
In my book if you don't have authority, including to hire and fire and affect compensation decisions, then you aren't a manager. In that situation you're half glorified babysitter and half scapegoat. And I agree this is how most organizations are designed, and why they're so anemic. I very much like flat hierarchies and consensus decision-making, but at the end of the day someone is in charge or they aren't. If they aren't, their capacity to effect cultural change is severely diminished.
I think the bottom line is this: Where do you want to spend your time?
Yes, you can use process and tools to make a low trust team “work”. This is in fact how most government works.
This isn’t horrible per say, it is just very ineffective. You will spend 2-3X the amount of time/money to produce the same result as a highly effective team. The multiple gets better with good process and tools, the multiplier gets worse if you have bad processes on top of having low trust.
If you want to change things, and don’t have support/the ear of leadership above you, then the alternative is to do what you can that is in your control. This is where great leadership shines (and leadership is much different than management, more on that another time).
A great leader doesn’t need formal lines of authority. They gain influence indirectly by “casting a vision” and enrolling others to pursue it. If you can do that, you can (over time) shift a culture. It is just very slow, and not straightforward to do.
The one bright spot is that in general, the more something is resistant to change, the more readily it will adopt/embrace it once changed. If you can shift the culture, they will never want to go back to how it was before.
But once again, you need to decide you WANT to do this, and in particular do it for this particular org. For most folks, that isn’t what they want to do, therefore they have to either learn to live with an ineffective organization, or move on.
Not OP, but I agree with both your assessments of the situation. I agree with you that most companies work this way. I'd even go a step further and would say that most companies are highly dysfunctional. But I also agree with OP that the only thing you can do in situations like this is to leave. Unfortunately changing the company from the inside is extremely difficult and in most cases a futile effort.
What follows for me is that one should be very careful in how they choose their employer. Unfortunately, I've found it often quite hard to judge this before starting to work there. Would love if someone could give their insight in how to figure this ought before even applying.
> In case it wasn’t made clear, let me make this final point for the ceo/leader: Spend the money/create the perks that allow you to attract the people you can trust, then once you get them, TRUST them. Yes, verify, but if you don’t do this, you are doomed to fail. Also, either find a way to trust the people you have, or get rid of them. It is a disservice to both you and them to keep around people you can’t trust.
Life Principles by Ray Dalio has this exact same advice.
TL;DR if a person doesn't have the technical background to judge someones skills, which in a lot of cases they don't otherwise they wouldn't be hiring you, it's very hard for a person to know whether someone is good at what he does or just full of shit.
What you're saying is a lot of ideologically great stuff but that's a bit disconnected from how the real world of high growth tech works.
The reality is that people can talk about vision and passion all they want but the US is a place where everything is a sales transaction. In a place where everything is a business transaction whoever can sell their work best wins and whoever can make an impression on perceived impact always wins over the people that think their impact will eventually be recognized. In fact listening to advice like that is what gave me a quick severance package despite being one of the most impactful engineers in the company at the time.
In one place I improved their entire performance by 38% and saved them a couple millions on licensing fees. The 38% was claimed by my manager the very same day i got my severance package even though I had to make a gif to convince them of the impact and defied them by fixing this issue, which was deemed a failed project at the time.
Most managers in the SV late startups are early employees that kept getting promoted and at some point were sent to Berkeley for a weekend management certificate. Very few of them stop and think about the things that they do, how they would want to be treated themselves and what they can do to improve transparency of performance.
I was recently responsible for the hire of someone I initially intended as my replacement as an CTO for hire/architect. I got blinded by the resume and the vetting procedure/recruiter and his ability to smooth talk about things he knows nothing about. It didn't take me long to realize he was useless, but the problem was that the guy spending the money actually believed it for 6 months and poured money into it. He massively regretted it. I basically had to let him ruin a bunch of stuff, waiting in the background to clean up after him.
Bottom line is he was a better politician that he was an engineer. And for most people it doesn't matter.
The tough ones are people who aren't clearly bad enough to just let go, but lack enough in the skill department that trust is lower than it could be and slows things down.
i think you're getting the trust causality somewhat backwards. people don't simply fall into trustworthy or untrustworthy buckets, but rather it's mostly context dependent (with rare exception; e.g. sociopaths). a trusting environment can reveal the latent trust inherent in the team members.
and trust takes time to build, so it's often not something you can just hire for (unless maybe you hire a whole team at once).
teams also require a blend of skills blanketing the problem domain, diversity of thought and background, necessary resources, clear goals, and the autonomy to make decisions toward those goals.
Oh right, spend the infinite piles of money we just have lying around. If we had that money, we would have already spent it to hire better people in the first place and wouldn't be in this position.
I was actually hoping for this response. This is something that I fundamentally feel like many startups/companies miss:
You should not be pursing any activity that is not inherently profitable given your cost structure.
Let me say this a different way, if you can expect $10 of revenue, the absolute most you can spend is $10-your minimum profit margin (for normal businesses... for VC backed, it is more about “value/market share creation for eventual earnings).
If you can not do the above, while ensuring the value, you are in the wrong business.
Business 101 dictates you spend less than you earn. The question is can you really do it given your cost structure. I would go even further that if you cant afford to pay what the market dictates to achieve a specific business outcome, you should not be pursuing that business outcome in the first place.
Parent already made clear that there are other options besides raw money:
> Note: compensation is NOT just dollars.
One really simple option that I think a lot of programmers would love, and that doesn't cost any money directly, is just giving them on-the-clock time to do some hacking on whatever they want, instead of keeping their noses permanently affixed to the feature grindstone.
> Ok but serious question...what do you do with highly ineffective teams that you inherit ,and/or are contractors, and/or are the only engineers available, and/or are only motivated by a paycheck, and/or would rather be working on their five side projects, etc
I don't know if this is the best approach, but I actually kind of like these teams, and like working with/leading them, because usually the description is not true. And careful rebuilding of trust can usually (but not always) demonstrate that.
Very few people are truly as ineffective as they might seem, and people are more impacted by situations they are in, or the process/role/authority they have, then anyone will care to admit.
> in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate
Ok, sure. I agree, and have seen this happen too. But why? Very few people intentionally want to make mistakes. Very few people intentionally refuse to cooperate for no reason. Most people are not inherently bad.
Are they making mistakes because they don't know something? Are they making mistakes because they are used to working in a different way, or prefer a different way? (If so, why?) Are they making mistakes because they feel some sort of pressure (like a time crunch, budget crunch, some 'three strikes' hanging over their employment status, etc). Is "only motivated by a paycheck" even a bad thing? (People can still do good work, despite only being motivated by payment. That's how most other industries work already). Are they refusing to cooperate because they have an unresolved grievance (where they demoted, or docked pay? Are they working on something that is slow/bad, because they couldn't get buy-in to do it the proper way the first time?)
People can be kind of cloudy, we're not robots, and there's not necessarily one single right way to go about rebuilding trust and creating functionality out of teams. And yes, occasionally there really are some folks who need to specifically be dealt with. But I really bristle when whole groups of people get written off with labels like the above, because it feels fundamentally untrue for most people most of the time.
These are all the types of things that a good manager is supposed to be solving. A good manager can make a "highly ineffective team" effective, even if they might never have been before.
I am not confounding good work with good people. I very often see great people deliver poor work. I rarely see bad people. I can be a great person and want to succeed at something I am I’ll equipped to do professionally, or for whatever reason am not fully engaged in.
Personally, yes, I feel working for a paycheck only is a sure sign of a bad fit/attitude. Maybe I have an unrealistic view, but I think people should work for more than that, or else find a more rewarding and engaging profession...life is too short to punch the clock (ymmv).
While very few intentionally make mistakes, I find it takes extraordinary effort to maintain the discipline to intentionally not make mistakes. A mistake is not always an erroneous action, it can be the omission of careful attentive proactive action.
My thesis (and practical experience) is that you can deliver good software with ineffective teams, contrary to the myth of 10x rock star hire-only-the-best mantras. But my question is how others use tools and techniques to reliably do this vs. gut feel and trial and error. I know it can be done, just as I know you can hire 10x coders and still fail a project.
Edit/postscript: you can also have (and often do) great people who as individuals can be highly effective, but fail to communicate or collaborate as a team. This is probably more common in larger orgs or in my specific cases, teams that span multiple orgs. You often have to manage great people who are poor communicators via nudges without direct hiring/firing or performance review leverage...aka “dotted lines”.
If you are offering your employees a paycheck, that is all they will work for. If you give them your companies assets, capital, and control over the org structure, then that is what they will work for. If you're offering them the opportunity to work on interesting problems, then maybe guarantee it in an employment contract. There is no reason to blame anyone for working to acquire the only things you're actually offering.
This is not universally true in my experience. People who take pride in their work will often go the extra mile, without being asked. I don’t “blame”, I just correlate.
Maybe this is the answer: if someone needs a guarantee then they are probably a bad fit for a highly effective team. Highly effective people look for opportunities instead of guarantees perhaps.
If I knew, I would be writing articles, not asking questions...
The guarantee is not a need, it is an opportunity that your potential effective employees are looking for. If you deny them that opportunity, they will look elsewhere and be highly effective for someone else.
If I only took work that I enjoyed, life would be a lot shorter. Uninteresting but better-compensated work allows for free time outside of work to do things I enjoy, and the theoretical possibility of saving enough for an eventual sabbatical or early retirement.
In my experience this is not true. I know lots of grunt work that gets done in both paid and open source projects that no one likes, by volunteers with nothing extra to gain. Those mundane tasks are necessary for the larger good, and folks can see past their short term motivations.
Those that respond and raise their hands to do the icky work everyone else tries to avoid seem highly correlated with leadership skills and better communication skills.
Are you really suggesting that people motivated by a paycheck are ineffective and can't be trusted? For that matter, that contractors can't be trusted? Or people who would rather be doing other things?
THIS is basically what I feel is the reason why most german software companies are lacking success in international competition...
Disclaimer: I'm german, have software engineering degree and hate german conservative company structures not adapting to the 21st century...
German society (compared to some others) seems to do much more enforcement of industry-wide and society-wide standardization (e.g. of measurement systems, part compatibility, common procedures, ...), with an expectation that everyone should “follow the rules”.
This has the advantage of increasing interoperability and compatibility and making many things more predictable and easier to assess/audit, at the expense of sometimes fixing poor choices and forcing them into contexts where they should be discarded.
* * *
As one example, most of the design features of computer keyboards sold worldwide from the 1980s–1990s were forced to conform to a (not especially well considered, in my opinion) German standard, which was adopted by IBM and then copied by everyone else, and later became the basis of an ISO standard.
Beige or gray color with matte surface texture and dark labels (no colors allowed), cylindrical keytops with primary symbols in one corner to make room for standard German labels, low keyboard height (which did not fit many of the keyswitches from the 1970s), a shape precisely accommodating the standard German key layout, ...
At some point companies started ignoring this standard (e.g. producing black keyboards), and I don’t think there was ever enforcement. But we are still stuck with many of those design choices now, a dramatic difference from the extreme diversity of designs from the 1960s and 1970s.
Arguably many of the keyboards of the 1970s were better than almost anything produced at mass scale since.
It's basically procedural rigidity. Everything is formalized and has to work in a specific way. This may be an asset sometimes when reproducibility or accountability are key. But the crippling lack of flexibility is a serious downside many other times.
Usually comments about Germany are more positive. What is going on with progressive HN?
Won't a German boss think you are incompetent for working six nines?
For reference ukigumo says, "In countries like Germany or Holland, if you consistently stay over-time in the office you might be surprised to find that you will be called upon justifying your behavior since the local belief is that you are either incompetent..." https://news.ycombinator.com/item?id=9456190
- The psycology of giving a reasonble account of yourself when being judged.
- Assurances that standards are being followed.
Trust is all fine and well, but what happens when one of you're colleagues is having a bad time at home? What happens when their wife is held hostage until they insert some code? What happens when a laptop is hacked?
A cursory glance might just be enough, but you also might want to internalise just why we do these things. Often people won't mind if you set expectations and write the reasons for doing things down.
Also keep in mind all the big breaches that have happened lately. I wouldn't be suprised if they were high trust environments, still got hacked though.
Agree 100%. I work at a big slow place (Google) which has many processes that evolved from a lack of trust. But my local team has pretty high trust levels.
I try to explicitly say things like "I don't think we need that process here, I trust you" to speed things up and it often works. But some people don't want trust, they want the safety of the process.
> However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code.
The difference is that you can't review your own code, for the same reason that writers work with editors: The reviewer is leveraging their unfamiliarity with the code along with their familiarity with the code's intent and the codebase, as a critical tool.
If it was feasible to get someone else familiar enough with the project that they could review it, I would do that, but at that point, I wouldn't be working on my own.
I agree with your premise, but not with your digression. I still read the code reviews of my team’s experts closely because:
1) I might learn something. If they are experts in the domain, they almost certainly know things I don’t.
2) Even experts have blind spots and make mistakes.
If I trust my teammate I default to “accept to unblock” and leave some questions in comments.
If my concerns are valid, they can fix it before landing. I also trust them to request a fresh review if that leads to major changes.
If I misunderstood, they can educate me in their reply and land it without further delay.
How can organizations deal with the problem of too much trust, e.g. freeloaders (lazy workers who get little done) or even those who actually abuse trust (e.g. spend too much money on their own needs, or undermine coworkers, or take credit for their work, or lying about their skills during hiring process, or secretly work for competitors, or otherwise damage the company)?
Ideal is "trust but verify" which sounds good but (1) it's hard to verify (except in annoying and ineffective ways like "face time"), and (2) signaling you don't trust your employees can make people more likely to abuse your trust ("the company thinks we're spending money on ourselves anyways, might as well spend it, we're already guilty"). I think trust issues are one big factor in why nepotism (and other "hiring by connection") remains so popular.
It's a general rule: Systems of elements that can trust each other are more efficient than systems of elements that cannot.
(Corollary: By the time you have written laws it's already too late.)
This ties in to why I think ubiquitous surveillance systems will actually work, provided they're self-reflexive to prevent their own abuse. Secrecy is becoming exponentially more expensive. Economics and technology ensure that the surveillance systems only get better and more pervasive. So the cost/benefit ratio of "cooperation vs. defection" will be skewed towards being a "good citizen", eh? What if the Total Information Awareness systems are their own cure?
My opinion is that in the absence of a process framework, the advantage lies with people who try to build trust rather than doing the right or optimal thing. It also makes people a less fungible resource.
they have innate understanding that being observed working is more valuable than the results of their work.
I've seen coders who knew this by heart forget this less than 5 years after entering management and become champions of forcing everybody into the office for 8:30 stand-ups and time tracking systems that enforce minute by minute "project accountability".
I don't know exactly how this happens, all I know is its like a damn force of nature. The only thing I've ever seen kill morale and tank projects faster is random periodic layoffs.
I know exactly how it happens. Engineering projects take a long time. 90% of the effort lives in the basement where nobody can see it; getting data from some other system, optimizing queries, spinning up the servers... nothing at all user-facing. So to the untrained eye, 90% of the time, programmers are doing nothing. And that 90% can be weeks, months, even years.
I don't think any of this is unique to software engineering, either. You don't just one day decide to build a bridge and show up at the bank of the river with a cement mixer tomorrow. To someone that wants to drive over the river, it looks like no progress is being made on the project. Hence, lots of meetings (delaying the project further) to make sure everyone is working hard enough. (Because there is always "that one guy" who actually isn't doing anything. And it looks the same as someone who is working hard to an outsider.)
As for why we spend money hiring people that don't actually do anything, tracking the progress of other people's work... I think it's just loss aversion in action. If you spend 10% of the day working on timesheets and pay an additional employee to check up on them... you know where your money's going. But if someone just shows up to work and does nothing, then they're stealing from you and must be punished! It is human nature.
I don't know what we did in the past that's different from today. Somehow we got to the moon. But now companies are so bloated that even doing nothing seems like it requires 30,000 employees. I don't have much hope for the future generation of megaprojects. And, you know, we're not really doing them anymore. I wonder what changed. Or maybe looking back at the all the achievements of the entire human race at once makes it difficult to put the present day into perspective.
Well for one, this whole "agile" concept of changing things midstream can't be helping. No one says once a bridge is 20% built. Hmm... You know what, more height to avoid noise and smog problems in fact seems to be a better focus than high vehicular weight. Let's start making those adjustments and expect to stick to our time, cost, and quality estimates.
Outside of a few niche areas, calling what's going on in software "engineering" seems laughable to me, and I never refer to myself with that term.
I feel like other engineering disciplines would function closer to the software world if it was easier to iterate. It is very difficult to nearly impossible to change the design of a bridge once construction has started.
If it was super easy, we'd very likely change things once they were in use. Perhaps we didn't account for pedestrians using the bridge and they're walking across it all the time or tractor trailers are having trouble making a right off the bridge. Software is inherently "soft". It's malleable. When done well, it can create better fit to purpose solutions than almost any other discipline. I agree that most "software engineering" is more like plumbing, but I do feel like "real" engineering disciplines would likely follow a similar paradigm if they had the same luxury to rework things.
Well, look at tooling... and in the bridge analogy; material selection.
Look at the bay bridge, we built it using steel from china which, after it was already being used to construct the span was later found to be inferior.
So in SW dev -- you might choose a tool for a massive project only to find its the wrong/not best tool you could have selected based on the budget at the time the project started.
This can also be said of the team. Employee A was the right eemployee at the start of the project, but they later prove to not be the best resource, but youre already X% down the project timeline... what do? Esp at what cost.
I'm not arguing that that other forms of engineering are completely inflexible or that software doesn't have some constraints. I'm just saying that in general it is far, far easier to change lines of code than it is physical objects. That's why when there is a hardware issue that can be addressed in software, they send you a patch not a new CPU.
Or a surveying team missed some problems early on - and a bridge fell of its supports.
One Job I had (at a top 5 consulting engineer) was to reverse engineer the code from an onsite survey computer and build a GUI to analyse the data allow one of our Senior Engineers to look at what happened.
No, like all management fads, it just needed time to percolate. Now that software is so big, people who grew up in the agile domain have been promoted through the stacks to general engineering managers and have taken Agile with them. This means that folks in the hardware domain are now having to explain that you can't just keep iterating on ASIC's because it is really freakin expensive to make iterations.
It's the exact same trajectory that happened with Lean Six Sigma. It starts out as a good idea in a specific area. People start making money on managerial self help selling based on the idea. Market saturates. Product is pushed into other areas to keep growth. Engineering management idea becomes cult-like. New method comes onto scene and starts to displace the old.
Yes, but that isn't my point. The OP was griping about the difficulty business people have in seeing where the effort happens in software to produce something customer facing, and the dysfunction that happens from that inability to see it. He then wonders in a coda how big infrastructure projects ever succeeded with that kind of disconnect. I'm saying that a big factor at play is that agile subjugated the tech to the business in a way that large nuts and bolts engineering projects simply aren't allowed to do: requirements - down a fine level of detail - have to be provided up front. Once engineers in those domains have their requirements, they are really free to use their expertise as engineers. I don't mean to imply I'm a proponent of "waterfall", but it bugs me that agile evangelists think they've found The One True Way to do software, and don't acknowledge what I think are serious impediments to calling the act of writing software "engineering".
I see your gripe, and customers being promised demo's after every sprint is a bit over the top in many cases. Especially large projects.
But to assume no real engineering goes on discounts the fact that aside from stories there are "detailed" requirements, modeling, and designing that still occurs. If your team is skipping this, that's a problem.
A manager must be able to answer the question "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.
If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.
Time tracking can be a surveilling tool, but it can also be a tool to improve things - someone could find out that a team is running over capacity, and consequently assign more resources to the task at hand or redefine the task.
And, well, for morning standups: when done right they are a valuable tool for efficient communication, and probably better than having people chasing each other for hours on end. IMHO an organisation should agree on a communication strategy that is the most efficient and helpful for it. It is not a religious belief that a standup meeting must be done first thing in the morning, I think that tends to conflict w/the teams personal schedules the least.
>A manager must be able to answer the question "Are we on time? Do we need additional resources?" This happens to help a project, not to delay it.
If we know anything in IT, it's Brook's law: "Adding manpower to a late software project makes it later".
So if the manager asks that for a late project, they are probably incompetent.
>If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.
For a small (a few days) project, 20% accuracy doesn't make any difference. For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects, especially the kind with changing requirements, new issues discovered en route, etc (which is most of them).
>If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.
If the manager is not part of the team / actively involved (and thus he is inside the "black box") then any numbers they get is bogus, time tracking or not. Software is a qualitative process, not a quantitative. "5 hours spent on X" mean nothing at all without knowing what was done for X.
Brooks' law is not actually a law of physics though.
There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc.
It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.
You seem to have a rather negative view of managers.
In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.
Brooks law applies to a late project. However if the project isn't late yet - recognizing it will be and adding the right people now can make a difference in preventing it from becoming late. This is hard: first you need to add the architectures and senior engineers (both are badly needed on some other project that will be late without them) spending a few years getting the right frameworks in place, only then can a bunch of new teams join - you take a hit while they learn the new architecture and framework, but a few months latter they are all getting their part done in near isolation. (note isolation - this implies you have figured out the modules correctly to avoid communication problems - a hard problem in itself)
> So if the manager asks that for a late project, they are probably incompetent.
Not necessarily. I've seen/heard engineers who take great glee in pointing this out, but they don't understand the real dynamic. The managers have probably read the mythical man month too.
If as a manager you report a problem to your boss, you're likely to get "help", even if you already have a plan. Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic.
Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.
>The managers have probably read the mythical man month too.
Some sure, but not the one's violating all of its conclusions...
>Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic. Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.
Well, this doesn't contradict what I wrote above though. Just finds for a more polite way to handle the situation and not let the extra "help" make a mess of things! But it's not like I suggested telling anyone directly they're an idiot!
"Adding manpower to a late software project makes it later" is not hat I even want to argue about. Discovering that a project might run late, and then doing the right thing about that is.. but how is one doing "the right thing" if developers don't want to communicate estimates vs. reality?
"For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects.." (exactly, I made that point as well) "..especially the kind with changing requirements, new issues discovered en route, etc (which is most of them)." If you are working in an environment where shipping something at some random point in the future is fine, well, good for you. The rest of us doesn't work in that world, which means that if you start a large project, lets say over the scale of 1 year, you cannot not talk about progress during that year. This is the point that I want to make.
In that sense: "5 hours spent on X" means, dishonesty aside, that 5 hours have been spent. This has some meaning, namely:
- a) if the estimate has been 1 hour, and this doesn't cancel out over time there is a systemic problem which puts the entire estimate to question. So someone should do something about that, and, whatever that something is - adding new or different resources, changing the goal, changing the timeline, whatever), it is usually not something that developers could do. (Not that I think 5 hours is a useful estimate size for any feature; 1 week, on the other hand, for a set of features would probably be useful)
- and b) if you figure out that team members are frequently spending more than 8 hours per day for whatever features (adjust 8 hours to whatever the team agrees upon) then the team is overloaded, the workload is not sustainable, and, again someone should do something about that...
Really, it shouldn't come as a surprise that - opposite to developers' lore - managers really do add value, especially when they are good managers.
What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)
That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.
The point of Brook's law isn't that extra people won't aid conclusion but that the overhead isn't free and unless the date is grossly overambitious (like 10% done) adding more people will add more tasks in "creating infastructure".
Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse.
To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate.
Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.
That's the pithy aphorism. Brook's actual claim is a lot more nuanced.
The output of n programmers working on a single task is O(n), but each one of those programmers must coordinate with O(n^2) colleagues. As more people are added, the coordination costs begin to to take over, and the project slips further and further behind. Thus, going from 2 to 4 programmers might be a great idea, while 20 to 40 or 200 to 400 may doom the project.
If a hierarchy settles into a strong tree structure, it approaches O(n) connections people have to handle - one bidirectional connection between each person and their immediate superior.
To put it a different way, a hierarchy has potential to scale without limit, or to put it differently again, the larger a system of people, the more they will be forced by necessity into a strict tree structure for the majority of 1:1 communications.
Except the people you need to interact with are very rarely the same people.
It's much more advantageous to form cliques. Small highly connected groups that work on the same thing, possibly with some lose connections to other cliques. That's the model that most closely resembles towns, cities, and even tribes.
Yes, but software project hardly ever tree-ize so neatly.
Talking to your team boss is good for high level guidance, but wont do anything when what you really need is the details on the workings of X a colleague knows.
>What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)
Where did you got this idea from what I wrote (in fact, from my direct quote of Brooks' law)?
>That's an insane idea (it does lead to the conclusion that the optimal team is zero sized)
That adding people to a late project makes it later doesn't "lead to the conclusion" that "optimal team size is zero".
That's what's actually insane (one common form of insanity is following a logic to extremes without caring for nuance and limits).
Just that more people is more overhead (e.g. managerial and communication and agreement overhead), more people later equals more time to bring them up to speed and hand-hold them until they're ready plus the added overhead (related with more people) even when they're ready.
Brook's law doesn't say you should never put more people on a late project. It does say that you should not realistically expect the project to finish at (or sooner) than the initial estimate because of you adding more people.
In other words, for a late project with X persons working and M estimated months to completion. The real completion with X persons might be MR months, and with more persons X' it could get to MP. Adding extra programmers won't (per Brook's law and based on typical observations) ever help it reach M.
Sometimes adding more persons will make things worse, where MP > MR, other times they can help finish faster than the "actual" (not the initially estimated) finish date, so that MP < MR.
So it might still be advisable to add extra people -- it just wont (per Brooks law) get you to finish in M, and in some cases might even get you further from MR.
I've always interpreted this "law" to mean just throwing resources at a problem without understanding the root cause will make things worse.
Like the idea of throwing good money after bad, if the problem isn't rooted in lack of resources (e.g., if the problem is actually rooted in bad communication, bad training, bad requirements, etc.) it's not going to help.
It's more that there is an amount of people that will minimize costs, any more or less than that and costs will increase, and another amount of people that will minimize time, again, any more or less and time increases; also, adding people in the middle of a project imposes a nearly proportional loss on time and costs.
He didn't even get deeply into differences between people in that chapter. It's just very basic stuff that is on project management 101 since forever. Yet he had to write it down, and most people still don't seem to understand it.
You bring good points to the table. I’ve seen time tracking used extensively, but never to (intentionally)gut morale, more for metrics, ie project x took 10,000 man hours, and project y is sorta like that if you squint a bit and tilt your head to the left, so it should probably take us 11000 hours. It’s helps large organizations project staffing needs and keep everybody gainfully employed. Managers don’t like laying off people and usually do want everyone to be productive.
I'm not convinced that managers want everyone to be productive, because so many managers act to undermine and disincentivise their subordinates. When the drag is unintentional, I think many managers would rather not think about how to compensate for it. And sometimes it's intentional.
I think the biggest risk introduced by time tracking is well illustrated by a sibling comment:
> My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow.
It produces a misalignment of incentives: If you do a great job one week getting visible things out the door, then you're punished for the rest of your time in that job, rather than rewarded for doing great. So you know in advance, it's better to deliver slower all the time.
I think a lot of people have in the back of their mind an instinctive trepidation for detailed time reporting, because of fears it will invite that sort of paradoxical push, preventing them from doing the best work they know they could be doing. "To speed you up we need you to attend more meetings."
I've also witnessed a different kind of time-tracking problem. Someone logs into a reporting system that, say, they worked 200 hours on a project so far, since the last 3 month report.
Some people don't take the person's word for it. I've seen bosses, peers, coworkers say "I don't believe you, no way that took 200 hours! You've done maybe 10 hours at best. I could do it in a weekend, if only I had the free time. Anyone competent could! If only I had the time to organise someone to replace you. You're lucky to work here, your job should be given to someone else who doesn't lie about what they've been doing. (etc.)"
What's really happening is the person has put in 250 hours (350 if you count that unpaid overtime they did on their holiday and weekends), but reduced it to 200 in the report because they know what their boss/peer/coworker is likely to say.
If freelancing, they only bill for 200 hours, feeling like in a just world they would bill 350, but it's not a just world, and if their client is unhappy, maybe their work doesn't deserve full rate.
Often, boss/peer/coworker is quite incompetent, and wouldn't be able to implement the thing in 200 hours, let alone 10 - their lack of ability or familiarity with the job is what's making them estimate such a low figure. And no surprise to anyone, they can't find a replacement who will do the same thing in less time - although they sometimes find replacements who say they will, and then don't. The cycle continues, rinse and repeat.
So unlucky time-reporting worker is forced to do things to "prove" they are telling the truth about the time they've put in at least, while feeling a heavy dose of imposter syndrome.
Things like ass-on-seat, make sure screen is visible to others at work (to prove not using social media), timing of repo commits designed around reputation rather than problem solving, participate in social chats/IMs just the right amount (too much = slacker, too little = slacker), same with meetings.
And weirdly, it works. Because visibility matters a lot more than results.
If the above sounds a bit like I might be talking about myself... not really. I've had those sorts of accusations a few times, but it's outweighed by the rather pleasant discovery that I've worked for people who are surprised that the hours I bill for (I often freelance) are lower than they expected.
However, the few times it's happened, I took from that the importance of not doing it to other people, even if I'm unhappy with their work. Because it's so undermining at a rather fundemantal level.
The First Transcontinental Railroad, 1868 mi in length, was built between 1863 and 1869. Six years - completing a route from the Atlantic to the Pacific.
California High-Speed Rail, 520 mi in length, began construction in 2015, cost 90x as much per mile, even after accounting for inflation, and.... was indefinitely postponed in 2019. For a rail line in a single state.
Admittedly, with much higher speed, and much more humane construction. But nonetheless, even with a much higher per-mile price they still couldn't deliver it? I can see how someone someone might get the impression we aren't able to successfully deliver large projects any more.
Seriously, though-- whether true or not, there's undoubtedly an impression of extensive graft throughout the U.S. construction industry. Perhaps there are just so many people involved in such work that the inevitable few bad actors stand out more (a dishonest one is more likely to have stories told about them than one who simply does proper work for a fair price), but there is almost a tradition about it. If you talk to almost anyone directly involved in the industry - at least where I've been - they seem to act like these 'shady' types are a noticeable and constant presence.
We also live in an era where the government (federal, state, whatever) is seemingly viewed by many as less a benevolent force to be co-opted, and increasingly as a necessary evil to be thwarted and disempowered. Sure, the time period you mention is right around the heart of the civil war, with all the anti- and pro-establsihment sentiment that came along with it, but these feelings were rather new at the time. Most people were still farmers who valued "getting shit done" more highly than divorced-from-reality ideological barriers. The country was still needing to be connected and filled up.
I'm of course aware of the basis of these documents as an American. However, a lot of the core ideas behind the US' founding were that it was possible to form "a more perfect union". I.e. one where government was done 'right', I.e. democracy. There were certainly anarchists at the time too, but the form of anti-government sentiment we have now seems to be almost pathological; memetic rather than considered.
Wasn't a lot of the "payment" to the railtoads for the transcontinental railroad giving away land to the railroads to later sell to people (who'd take their trains out there to claim it)? You'd need to factor that in to the payment as well.
I should try to find some hard data, but it always feels like construction costs outpace inflation. I don't know if if it's regulation, labour costs, or what.
Transit advocates have done a lot of work figuring out why costs are so high. Turns out they don't have to be: Barcelona has significantly lower costs than anyone else doing similar scope projects. However Barcelona is in Spain where they speak Spanish so it is hard to learn from them.
I've seen many analysis of the situation pointing to all kinds of different "reasons". Many of those reasons have been rebutted by someone else. I cannot figure out who is right or what factors cause things, but the bottom line is some places transit costs a lot more than others after you factor in cost of labor and land which seem like the only things that should be different.
It is complex. I haven't been there is years, but in general Barcelona everybody speaks Spanish and is learning Catalan. It might be 50/50 now, but Spanish is likely to be the language they speak better. As you leave the city Catalan is more common.
Either way though, they don't speak the same language as the people who want to know what they are doing different.
It isn't just the USA: India has mass transit construction cost problems and could learn - if only they shared a language. Not to mention France (France is better at controlling costs than the US, but still not cheap)
In the US Spanish speakers tend to be poor and thus not in position to do anything about costs if they did look into it.
I'm sure Indians who wanted to go over to Barcelona to learn about the transit system would have difficulty finding a common language, or paying for a couple of translators.
I wouldn't expect the people in their transit department are hired for their English ability. Since Spanish and Catalan are important languages there I would expect that I need to learn at least one of them to learn from there. Of course if Spain wanted to teach the world how they do it English would make more sense as it is the dominate trade language today - but I can't think of any reason why Spain would care to teach others. It thus is on the rest of the world to learn Spanish to learn from them.
We might be able to learn from the Chinese or Russians. I'm not sure what their cost structures are like. Learning best practices from high cost areas won't help you control costs, which rules out all English speaking countries.
This goes back to my original point about visibility of engineering work. Clearly, one of the biggest problems that California high speed rail has to solve is buying land for the track. But nobody sees a few land purchases as "building high speed rail". Until there is a concrete pylon with some train tracks on top, people think nothing is being done. But of course, without that pre-work, nothing can be done.
Yep. And it's a hard, hard problem. Buying land or right-of-way in high-value, dense urban environments is considerably more expensive then buying it in unused wilderness. And dealing with each municipality's politics along the way is far more difficult and expensive than dealing with unincorporated, unpopulated land.
I live in Minneapolis, and remember when the 35W bridge fell. Republicans tried to prevent adding lanes for future light rail to the new bridge (particularly then-governor Coleman, who was eyeing a presidential run), and our mayor basically held the bridge hostage - he told the state and federal governments that if there weren't provisions for future light rail, that the city wouldn't be issuing the necessary construction permits for the new bridge. (A call I fully supported, btw.)
Now factor in the cost paid by laborers and their families in the form of low wages and hgh risk of detah and dismemberment, and see how cheap FTR was.
You can always get something cheap if someone else pays
Compare feeding and clothing the world now to 200 years ago. We get much more done at a much lower consumer price tag.
And of course CHSR is far more complicated -- travelling through dense, developed urban areas at much higher speeds.
Is it really any surprise that after the easier projects are all done, the remaining projects are harder?
Isn't that mostly OSHA? We are still doing megaprojects, but we've traded schedules for safety, which means we can do fewer of them.
I think that's the correct tradeoff, but it would be nice if we didn't lie to ourselves (and our constituents) about the precision of our estimates. I can't recall a megaproject completed this century which was less than 3 years late.
To be honest I still can't understand how those big megaprojects got out of the ground with people coordinating by face to face meetings, circulating memos and phone calls
Maybe that's part of the secret, communication was more expensive so you wasted less time with noise
But how do you put a switch on the panel of the 747, make the wire go all the way to the tail of the aircraft and make it do what you need it to do?
You have a lot of formal processes, a lot of time/effort/money goes into coordination. Having been involved, not with megaprojects but with fairly large design projects (offshore drilling rigs, computer systems) mostly pre- modern communication systems, there were plenty of phone calls, memos, and meetings.
Revolutionary Road was released at the tail end of 1962 and has some stuff to say about office work. If it's accurate (I suspect it's pretty close) then it was largely about passing papers around trying to avoid having to actually do anything with them, without it looking like you're trying to avoid doing anything.
Very similar to modern corporate email, sending crap around forever and bringing in more "eyes" trying to avoid making a decision or—god forbid—actually personally doing real work that produces an actual good.
[EDIT] tail end of 1961, actually, got that wrong.
My point was more that the people are also highly distracted by people around them who are also constantly distracted and thus buzzing, usually because of social media. The only solution is to go away, but then you're not seen in a good light.
I don't know if you are correct in a 'global productivity sense'. I do know that it's quite common for me to get more 'real work' done on the train on the 30 minute journey to work than in the rest of the day.
Peter Thiel asked himself the same question. If you subtract screens and style, how do know you‘re not living in 1973?
I think Yuval Harari was onto something when he said that what guides the vision of a society and thus science spending is ideology, religion and politics.
See medieval churches, the Manhattan Project, the moon landing. I could put a name on it, but better to leave politics out of HN.
As someone who kind of remembers 73 in England, the coffee is way better now. Also we had some epic strikes and power cuts back then and a splendid 73% market crash. After decades of relative economic decline we decided to join EEC, the predecessor to the EU after which things recovered economically from the 'sick man or Europe' to the fastest growing economy in Europe until we recently voted to go back to the good old days.
Only joining the EEC had little, if anything, to do with the recovery and change of coffee.
You remember a country still suffering from WWII and loss of world leader role (and colonies), in a much poorer global period. For starters, the '70s had a global recession and oil crisis, and many countries were affected, not just England. Have a look at pictures of New York of the same period -- it looks like a third world country [1].
In the 80s and 90s, countries that didn't join the EEC, as well as countries that joined EU much later, had the same economic uplift.
(And of course several countries that did join the ECC/EU had economic decline and crashes, e.g. the P.I.I.G.S).
Yeah there were many factors. The UK used to be quite socialist in the 1945-1975 period which was OK for the NHS but many other things like British Leyland didn't work so well.
I would glance at my local grocery store, shopping malls, cars, empty cemeteries, and inflight wifi.
First off, most manufactured things are incredibly cheaper now, due to real, complex behind-the-scenes advances.
We have a global supply chain that largely removes the constraints on geoghraphic locality for foods and manufactured goods.
That's paired with an almost-always-online wireless mobile internet, (that works up to 7 miles up in the sky!) that is absolutely amazing and darn inexpensive.
Our cars are much better at not killing us.
Many more diseases are treatalbe, and injuries curable.
Finally, why subtract screens? Modern screens are great.
> But if someone just shows up to work and does nothing, then they're stealing from you and must be punished! It is human nature.
I do realize that far too many people put their faith in the healing power of judgement.
But that is partly because, as a component of that cognative circuit, is that most people have some sort of innate desire to see things as "fair". Certainly not to be the victim! (That's bigger, actually, by far).
People who work with people know who the slackers or the non-producers are. I try to separate those, because some high-output producers can appear to be slackers because they think for 8 days before they type that one magical line of code that saves the project. (It's hard to tell when you are in the trenches day-to-day which may be which).
In any case! (I almost got lost in my parenthetical there), Workers know which co-workers are getting paid to not produce, and know that this wage, applied to a producer would lower their own work load 10% (or whatever), and besides: it's NOT fair! He get's paid $100K/year to not work! And I work my ass off for the same wage! It's enough to make me stop working myself. That will certainly show "them".
At the end of the day, if we do not purge the slacker, morale-rot sets in on the rest of the team, and that's just "bad". Even without the needing to be punitive in our heart, those people must be culled for the continued positive morale of the herd.
Or, so, I thought once. Now - I'm not so sure. But it seemed reasonable at the time!
The programmers for the Apollo software (which is what we're discussing), were at their peak, around 350 [1]. And most of those roles were secondary and only needed because of the primitive tooling and utmost reliability requirements that modern software doesn't suffer from...
Apollo software is pretty simple, relatively speaking. It was a hard, but small problem compared to what we expect from modern tech like a car or airplane. Modern software is far more reliable than Apollo. The difference is that 99.9% correct-uptime is terrible for modern vehicle software, but was great for Apollo.
I respectfully disagree. Manager's job here would be to:
- work with devs to make sure whatever gets into the work pipeline is well understood
- everybody agrees on the planned work scope
- prevent anyone from adding "just this tiny thing" into planned scope|
- visualise all of this tough, tough dev work, especially the ad-hoc work (putting out fires, for example)
- keeping both management and devs accountable
- and more!
Also I disagree with the bridge metaphor; while true, you can't use the bridge when it's 50% done, you should ideally be able to to use 5% of the planned feature. If you can't, then maybe it was planned out badly and shouldn't go into planning in the first place?
If there's a person that's "working hard" in a team and a person that's "hardly working", then the team has a big issue and should do everything to fix that.
However, This takes a lots of guts on part of (both!) the manager and developers and always has an emotional toll.
This is exactly the problem free market capitalism attempts to solve. To put it oversimply, you have a choice:
* "command&control model" the risk is born by the client, paying cost+15% for everything where they oversee all the work. Low trust, lots of bureaucratic overhead, but if the are competent enough, they can get the project done.
* "free market" model: risk the is born by the vendor -- payment upon successful delivery -- very high profit margin if the project suceeds, but $0 pay if the project fails or is even just second best.
One trick is, even in the "free market" model, you have nested command&control inside vendors, with the same problems that the original client had. You can go "free market" all the way down, but you are still stuck with all the human risks -- people can cheat, be accidentally incompetent, or lose everything just for being second best at project A when they could have been the best at project B.
> Somehow we got to the moon.
The moon isn't hard to reach, it's just not worth the price. If you allocate another $250B like last time, and it will get done -- either publicly command&control NASA, or by paying SpaceX.
We spend collectively about $100B/yr on the Internet, and it's super complex and huge and works amazingly well (works well technically -- how people you hate choose to use it is a human social problem)
Problem with programming - a solution always looks easier when it is already done. Even when a programmer solves a problem, he/she looks at the problem and the solution and thinks: "I have no idea why it took me whole day, it should've taken maybe an hour.". Also, sometimes it's dangerous to leave a programmer alone with the problem - you don't know what they are doing until it's too late.
That is why even the best soloists should try pair/mob programming from time to time. And it is essential to increase visibility in the teams where people work solo/distributed teams. It's okay to shout out in a public chat, group email, etc. of what you're doing, what approach you're going to try, things that unclear to you, what's left, how you'd like to improve it, etc. Don't be afraid to look stupid. It's better than trying to come up with excuses later. Post diagrams drawn on the napkin. Ask your teammates what would they think if you add a library, or remove one. Delayed feature for unknown and speculative reasons never looks good, delayed feature backed-up with your publicly shared notes is always better. Better for you, better for the team.
The best teams operate that way and if a manager cannot create a culture of complete transparency, they'd loose the ability to trust their peers.
Because managers also have managers. If the managers at the highest level think developing software is pretty similar to packing widgets in a factory, they understand and want to see the Frederick Windsor Taylor school of management in the engineering department.
For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.
But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.
> I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.
I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?
I have personally also tracked time on my personal projects. While not sure if it does bring much value, it is not a huge investment time-wise.
I think that's not the point OP is trying to make. There's nothing wrong with tracking time for yourself, or clocking in and out of work. Time however is a really really bad measure of productivity. If somebody constantly stays late at work because they never finish stuff on time, in our current culture they often get promoted for being hard workers. While some might do the same job in 2h that they do in a month.
So what the super productive guy learns after a while is that they just need to "work overtime" and delay presenting results to get ahead. If this attitude starts pervading your team the productivity might start tanking too.
> Time however is a really really bad measure of productivity.
Situationally. With programming there are loads of different tasks. For some tasks I think time can be quite a good metric. Still, metrics matter and I think having lousy metrics is better than not having metrics at all. Of course you have to realize what purpose the metric has in certain situation.
> I think having lousy metrics is better than not having metrics at all.
I fundamentally disagree. Metrics don't live in their own world. They affect the world around them and incentivize certain actions. Bad metrics can produce bad incentives. There are certainly many cases where simply not knowing something is better than knowing something that's only partially right. However, that requires a level of humility and acceptance of one's limitations that can be hard to defend to others looking for straight answers to all questions.
Well, very situational question. My question here is mostly, what are the bad incentives caused when people time track their days for example in with 1 hour or 0,5 hour granularity with software development tasks? I have been doing that kind of tracking both professionally and in personal projects, and I don't see the harm caused.
Fair enough. I mean I guess I wouldn't go so far as to claim that time-tracking is an obviously bad metric. However, I would definitely claim it can be poorly utilized. This metric is just a tool. Employed effectively it can increase performance. Employed ineffectively it can increase...time.
But generally I think my main point stands. We need to be humble enough to sometimes accept lack of control (i.e. not using certain metrics/processes) rather than deluding ourselves by through certain metrics that really aren't very good.
The problem is not the tracking. It is your boss coming over after 3 days asking why this 1 day task is suddenly taking 3 times as long, and how much longer do you think it will take?
Never mind that the task spec changed 5 times in those 3 days.
This 100%. "What gets measured gets managed" is a 70 year old quote by Peter Drucker and it is no less true today. It reminds me of a great anecdote by Mark Graham Brown about "chicken efficiency", which is a great term to describe these situations. https://corporater.com/en/the-chicken-kpi-be-careful-of-what...
If you're a doctor deciding whether to recommend a risky surgical procedure, you certainly don't want to jump the gun when reliable information hasn't yet come in. It surely will do in due course, if you're patient.
But if you're a manager giving out raises to your team, taking no action (i.e. giving no raises) might seem a worse choice than using the unreliable data - and there's no expectation reliable data will arrive if you wait.
Tracking time spent on various tasks can be useful (if not required, eg. for claiming R&D grants). But I feel like tracking time in office/time at desk is a different beast.
Happy employees, at a certain level of knowledge work, have a degree of autonomy.
Unhappy employees who could otherwise be happy employees are a waste of potential and money.
Having a clock on/clock off and a 9-5 butts-in-seats management style and incentive structure reduces perceived autonomy.
>I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?
I don't agree with using it as a slur, but I do think it's an awful way to work in a creative field. Some of my most productive work happens as a direct result of my taking breaks - a walk here, a cup of tea there. All the while I'm thinking about the problem at hand. Time tracking discourages this of lateral approach in favor of brute forcing your way to the answer.
Would you do time tracking for someone writing a script for a movie? Or for a painter? Writing code not only requires skill, it's a creative process. You not only need to think about what you write, but also need to stop and relax. When your mind is tired, you're going to write shitty code. It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow. Worst case scenario, everyone writes bad code, unnecessarily increasing complexity, making the code prone to failures and requiring more rewrites, more developers and more time to understand it.
I don't follow how that is related to time tracking.
I have used time tracking for personal projects and also professionally and I genuinely think that it can add value to my workflow, in a way that I can analyze how much I spend on certain tasks etc.
I would guess also painters and script writers track quite often track their time. I think some level of time tracking is good for almost any level of work. For example, if your goal is to produce paintings and sell them for living, you probably want to know how long does it take for you to produce something so you can see if you are approaching sustainability. Similarly if you write movie or tv scripts it is probably relevant whether it takes 2 months to write the script or 2 years. Some work is just structurally different so different approaches to time tracking make sense.
You're talking about two completely different levels of granularity. It's fine to discuss "what did we accomplish this month" and try to quantify it. It's not fine to ask a script writer why they didn't write any lines between 8:30 and 9:00 this morning.
Personally the software development tasks I have been doing are quite often separable in tasks that take several hours. Sometimes there are tasks that take days without clear separation.
I think asking whether it is discuss "whether you did line this amount of lines within X hours" is more like management and workplace culture than software development issue. It seems that people here are fed up with their managers and funnel that bad feeling against time tracking. In my opinion time tracking is valuable tool and should be used in principle almost everywhere. Bad managers of course make any type of work a pain.
I always found a strong disconnect between what the business side thinks is meaningful and what an engineer and his technical manager finds meaningful. Typically the detailed granularity just isn't there and the data is really noisy as well.
More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.
Heh, presuming management knows what a hard feature looks like.
Or understands the reason why it is hard. They sometimes conflate a patch, a hairy patch or writing correct code from start.
Bonus points if said manager does not understand that writing tests makes one go faster rather than plugging the code and trying to run scenarios manually...
One of the things I now always do is tell my boss both how much work work somethings going to be and how 'hard' something is going to be. Features/changes that are hard have very unreliable estimates. A lot of that has to do with how difficult it is to reason about and debug the feature. And how much other stuff needs to be changed.
When I know ahead of time exactly what the code I’m about to write will look like, I takes this as a warning sign and check in with myself.
Why do I know exactly what this code is going to be? Is it because I’m doing something repetitive? I’m a software developer. My job is to make the computer do the repetitive parts, not get paid for spending four hours doing something we’ve done ten times before.
Mastery isn’t doing more, it’s about being more effective. You develop intuition. And the way your intuitive brain surfaces warnings is as discomfort. If you cultivatea sensitivity to this discomfort it means you are adverse to powering through. On some level you “have to” address this issue instead of tolerating it. You have to scratch.
Now you’re not doing rote work. How long will it take? Who knows. But it’s less time than doing this thing eight more times this year. And it’s not just time. It’s energy and face. A repeated process that can introduce human errors makes you look like a clown to your customers, and your boss’s boss.
I also sometimes track time, so I know how long takes particular task. Good developers do this and can quickly estimate project’a complexity by breaking it into known length tasks. I saw this in a highly specialized consulting company. My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. This time tracking thing can become very ugly in micromanagement environment.
Known exactly, maybe. But when I was a consultant we had a pretty good idea of how long it took to do a good job on a project.
We'd add in some padding because you don't know if something will need a bit more research or if the lead is going to come down with the flu or whatever. You write deadlines that are under the client's control, rather than yours, into the contract.
So you don't know exactly. But if you have a decent handle on the scope of work and aren't trying to solve wide-open problems, you can usually get pretty close.
Certainly, a lot of people don't have this level of experience in a domain. When I do similar work internally at a company now, people are often surprised that I can come up with time estimates (and meet them) pretty easily.
You know how long your budgeted for it. Which is fine up to a point, but when things go over budget then corners get cut. And that costs in time further down the road.
I suppose you can always spend more time but the type of work I did didn't create downstream dependencies. There was no maintenance. (It was reports, competitive analysis, and the like.) Although I can't ever recall a situation where we were like:"It's not good. But it's good enough. Ship it."
That’s the kind of work that can be automated. You’re arguing with people who are doing new feature development almost exclusively. These are apples and oranges.
And frankly if you get too smug about it in a work environment you’re going to antagonize someone into scripting your job out of existence. So I wouldn’t pull on this thread too hard if I were you.
> It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow.
I'm on the fence regarding this statement. If you are accumulating increasing amounts of fatigue by being there and writing bad code, then yes, go home, rest, and recover. But, optimal is the enemy of good. Write some shit code in your own branch, learn from the mistakes you made, so that the code you write tomorrow might be "the good code".
I realised years ago that getting paid per hour is anathema to my enjoyment of work. I'd much rather charge per project (even if that charge is based on an estimated number of hours) then spend whatever time it takes to complete the project than work at an hourly rate and find myself staring at the clock.
Opposite for me! In my experience, being payed a fixed sum for a project requires a very detailed spec up front and still may lead to bickering about whether any issue is a bug or a feature request. Being paid by hour makes it possible to continuously adjust the project without either party getting screwed.
Typically employed developers get paid per time (i.e. hourly or monthly salary). Contractors may be either per hour or a fixed sum to deliver to an agreed-upon specification.
With scriptwriting (and often art in general) you first develop the "product" and then try to find a buyer. This is IMHO not a feasible model for individual software developers.
> Would you do time tracking for someone writing a script for a movie? Or for a painter
If change the flattering comparisons then why not? Instead of someone writing a script for a movie, imagine it is someone writing sales copy. Instead of a "painter" presumably working on some masterpiece, imagine instead it is someone in one of those Chinese factories churning out still life 3265.
Most programming tasks are well understood - most programmers in big corporations are working on CRUD apps. The correct comparison is not to some highly creative process but to some semi-creative process. Sure the details might be different but in the main it can be well understood how long it takes to add crud screen 26.
It's up to you to choose a more creative engineering job that almost requires you to be a painter (or a screenwriter). Sometimes it's the jobs that are product-level slash engineering, sometimes it's purely engineering ones that require a lot of innovation. If you are a creative type and if you want to make your life more interesting, you will be attracted to these jobs.
It's easier going the other direction: what is time tracking good for ?
Tailorism was good for simple, repetitive and immutable tasks, where the only planned improvement would be the worker. If the task was to be revised, it would be top down from an 'analyst' that designs a new task and test it on workers.
What changed this perception ? Toyota like factories, and the idea that tasks should progressively evolve, workers can change their environment in non top-down ways. The metrics was not how much time it took to do a single task, but how much the whole pipeline was efficient.
It's just an example, but I think time tracking should be a relic of the past, as an idea that was too simplistic and too seductive to micro-managers to be really valuable.
From a throughput management perspective for more office-like work:
It's easy for one person to increase in time-tracked productivity in ways that decrease the aggregate productivity of the group they are in.
Sometimes, the person is happy with their own work and unhappy with everyone else's, and they have a blind spot because it's so hard to understand how improving their own productivity can slow down other people so much to be net negative.
But I've seen it, I think it's real. I think it's sometimes a very strong effect, which can make or break a business.
Just like manufacturing pipelines, people affect each other's work in non-linear ways that clog up the system.
As with pipelines, performance improvement lies in working with those non-linear dynamics well enough to reconfigure the system, so each person can excel at their best.
Because making software is like oneoff or small batch production as opposed to a traditional production line.
Engineering practices vary wildly depending on what type of engineering you are doing.
That's one of the problems they had when developing BS5750 and ISO9000 , "where do you hang the defect ticket" was one of the areas where they had problems - that was what the head of the BSI software quality project told me back when he was auditing a project I worked on ack in the 80's.
It increases anxiety and stress, which probably decreases productivity to a much greater degree than whatever benefits you'd get from time tracking.
I suspect the number one factor to a successful project is a happy, healthy team. I'm pretty sure there's a section in Peopleware that backs that up. I'd be really careful with any approaches that risk losing that dynamic (or preventing it from forming).
It is easier to track people being at their desks than diving into the git repository and looking at what got done.
Also, for a programmer who did not code for 5 years because they got into management, it is a huge source of anxiety and forces them to contemplate the obsolescence of their skills. Having to ask a junior dev how to compile the project you are supposed to overwatch can be felt as humiliating.
When I had a team to manage, I tried to keep involved enough so that I could do the whole build process. Most of my work was complaining about broken master branch and regressions, praising the correct person when a feature gets implemented, shout with the higher management to stop adding irrelevant features every time they meet a client and have a weekly discussion on how things are going on.
We had one lay off during that period, on my recommendation. I was worried about the team morale, but got told we should have fired that person earlier.
Why would you feel humiliated for not knowing which button to press to build, on the current bullpoop, if you hadn't yet needed to use that particular bullpoop?
It's possible that a junior dev who showed you the button might then joke to other junior devs about you not knowing. But a smarter junior dev, wise beyond their years, will realize it's just bullpoop trivia, one of thousands of bullpoops one has to pick up and later discard in favor of a fresher bullpoop, and be happy to help.
In any case, you, as an experienced person, should know it's just a different flavor of bullpoop, and not the most valuable thing anyone knows.
Your decision to stay in the loop, with the bullpoop that your team is currently enjoying, sounds like it might come in handy. But I wouldn't want anyone to ever feel humiliated over bullpoop.
I totally agree, but many people feel that way, especially if they got into a higher position because they are supposedly more knowledgeable.
A build process is one thing, knowing C++17 or rust is another. Knowing if refactoring all these templates structures was really worth 2 weeks is something that is hard to ask to a junior dev.
Good point. On something like the refactoring question, sometimes that kind of question can be bounced off a senior developer, maybe as a bit of a mentoring role for them (official or unofficial)?
Being humiliated (humbled) is probably a good thing because status and responsibility often cause people to become callous, self-serving, and out of touch.
I've seen that, and the opposite as well, where you have a huge team of people constantly working and yet mysteriously nothing gets done and managers aren't sure what people are doing on a day to day basis.
If you create a system to measure butt-time in a seat coding, you're going to get lots and lots of butts in seats coding. This may not necessarily result in a product.
"The best example of the danger of focusing on a single measure came when I first started my own consulting practice in California. My second client was in the fast food business and had a chain of fried chicken restaurants that was growing in both the U.S. and internationally.
....
Roy went on: “The one metric that is really important to management is Chicken Efficiency. At the end of every day, I have to calculate my Chicken Efficiency score...this is the measure that all the managers talk about all the time.”
Looking at Roy’s chart it looked like he was achieving 99-100% Chicken Efficiency every day that month that must be good. However, I still didn’t know what the measure entailed. Roy explained: “Chicken Efficiency is basically a scrap measure. You take how much chicken you cook and divided it the number of pieces of chicken sold. If you sell all the chicken you get 100% chicken efficiency, which is the goal – no waste or scrap.“
When I asked Roy how he achieved near perfect Chicken Efficiency every day he answered: “I’m gonna let you in on a secret, but don’t put my name in the report saying you heard this from me. My secret is I stop cooking chicken around 7:30 and only cook to order after that. That way none of the chicken sits under the lights for too long, everyone gets hot and fresh chicken, and I don’t throw any of it away – 100% chicken efficiency.“
I asked, don’t you get people coming in here all evening until the restaurant closes? Roy replied: “Oh yeah we get tons of kids coming in here after baseball or soccer practices or games, families, and lots of people. I tell them I’m going to make their chicken to order and it will take 15-20 minutes.”
I asked, do most of them wait? Roy answered: “Heck no, they file right out the door and head off someplace else, but management doesn’t measure that. They do want to make sure I don’t throw any chicken away every day, however. My buddie Leon taught me this trick – he got promoted to run three restaurants by not cooking any chicken“. I went on to visit other restaurants and every one of them talked about the importance of Chicken Efficiency.
As I developer who accidentally climbed the ladder into management (and eventually bailed) I can say that from my own experience it is by sheer force of pressure from non-technical management above oneself.
I fought the management culture hard for a few years, eventually realising that I needed to either become one of them, or quit.
Did you quit being a manager or the company? (Honest question). From my observations, it is rare to work for someone as a manager and not succumb to upper management pressure.
I quit being a manager but kinda sideways stepped into a different senior (non management) role in the same company/department. I was quite lucky because I didn't really want to leave the company at the time. I just didn't want to be on the trajectory I was on.
It was kinda awkward initially, mostly for the people I had hired and been manager of who I was now colleagues with, but not for long. Hands down it was one of the best life decisions I've ever made. I feel as though the experience I gained helps me to perform my current role even better than I would otherwise be able to as I have an appreciation of the politics above me that I'd not have had I not been up there and back down again the way I have.
I am glad you could make this transition in the same company.
I've recently had to step down from a senior non-management role (tech lead) that my company forced into management tasks into it, specially things that no one else wanted to do. It didn't work and I ended up leaving the company. It was
hurtful because I left believing I had a lot to contribute and was motivated too.
I'm sorry your situation didn't work out as you'd have liked it to. It sounds a lot like the journey I took to be honest. I drifted from "Senior Developer" to "Lead Developer" into "Development Manager" as the company grew. Before I knew it I'd not written a line of code in over a year and all I did was attend lengthy meetings. I'd also have been very disappointed if I'd had to leave the company. I still had a lot to contribute to the business and the product we were working on, just not as a manager.
"It is easier to justify project delays to upper management when everyone in the team comes in on time, otherwise it becomes my liability as a manager". One good friend of mine, who I respected as engineer, after becoming engineer manager in a small company (less than 10 engs).
I've seen this as well, in my experience much of it comes from other orgs that see the engineering team come in late, or walk around the office tossing a ball into the air.
They start putting pressure on engineering managers to make sure their team is "working". Their team clearly needs more discipline and those 'slackers' need to be cut.
What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort.
> What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort.
Maybe this is an unpopular opinion, but that wouldn't mean that the engineer shouldn't implement in a couple days and then work on something else. HN loves the trope of the super smart engineer who is smarter than _everyone_ and can look like they're doing nothing.
You don't have to be a "super smart engineer" for that situation to occur. It's completely normal for software features to shrink (or grow) by that much time in my experience.
Their leaders keep pressuring them and saying, "I don't see your team working!!! What are they doing? Why are they not in at 8am? I want to see some BUTTS IN THE SEATS!" After they get 1 or 2 bad reviews, they realize that one way to get a raise as a manager is to have the team look super busy.
No matter how much your team delivers, if they make it lose easy, folks think it's easy!
If they are running around, sweating, stomping out fires, looking seriously stressed, then my gosh they must be working really hard. :-(
I quit a prior gig because of this. A job I was working on for a few years brought in new management and they started nanomanaging every code commit. After 3 years of building trust, I felt the contract had been broken and quit with nothing else lined up but faith in my abilities. Turned out well.
I can understand requiring the team to be present/online during a certain chunk of the day, so that meetings can be had and people are around if others need help or need to coordinate, but, time tracking for FTEs!? I can only see the most unemployable of Engineers putting up with that shit.
Quite why people think morning stand-ups make sense - as most people are going to have long commutes it makes much more sense to do stand ups at the end of the day.
Actually this is how RAD /DSDM stand-ups are supposed to be done -at the end of the day so everyone knows what they are working on tomorrow.
I think that technology disruption is one of the roots of this. I'm talking about minor disruptions like a new GUI library or an improved query algorithm. Diffusion of these is somewhat uneven, and this results, occasionally, in senior management seeing projects that were impossible or very hard in the past suddenly delivering. This makes them believe that other similar projects should also deliver in that way and that if they aren't then something is wrong - leading to a desire to find out what's going on in minute detail.
Well, managers typically have their own managers and will be under pressure to demonstrate how they are "managing" - I think a lot of these things are done to "manage up" from one level of management to another.
"Seeing Like a State" discusses legibility vs illegibility, and how centralization incentivizes legibility. E.g. like how units of measurement were standardized in order to mitigate tax evasion.
Managing people without means that you have to keep track of your employees’ mindsets individually and communicate to each one accordingly which is exhausting.
Personally I don't really see why following some quite common work schedule like 8:30 - 16:30 and having daily stand-up meetings destroy morale. Of course depends on the details, but my life has always been quite nice following standard work styles. Time tracking is a chore that not many like, but still it takes in my experience only 15 minutes or so from the daily time and IMO produces pretty good value.
The issue that many developers have with time tracking is that it requires you to either translate your work into management speak in order to appease the management, or write what you're actually doing and have tons and tons of small blocks in your time tracker that make you look like you're being unproductive and trying to obscure something. Both options add unnecessary mental overhead and interrupt any possibility of having a "flow state".
Writing code and working on software is not a linear process, so writing "worked on feature X" for your entire morning may be accurate, but it's not fine grained enough for what the managers want to see and it doesn't really serve any purpose at that point when you already have daily stand-ups and sprint meetings every week.
This likely isn't the case at all companies and with all managers, but I suspect many have the same experience I've described.
1. The manager is responsible for team's output/metrics.
2. Metrics are driven by improvements to the product.
3. Software functionality is hard to estimate (not a widget factory as other comments mention).
4. Manager gets anxious as it will be judged by an outcome not entirely within control.
5. Knowing everyone is putting their best effort increases confidence that team will reach goals by which the manager will be measured.
The manager evaluates team members on longer intervals depending on past performance. This allows the manager to course-correct before the team is evaluated. The seniority/past-performance of a team member determines how much the manager trusts them to spend the team's resources (time; man-hours) to accomplish the team's goals.
The brute force approach to make sure people aren't slacking is watching them work/check-in/report on progress. You can quickly tell if someone isn't putting an effort after a couple of standups/reviews with less-than-expected output or 'yet another excuse'.
The best one I received: "It is easy to like likable people. It is much harder to like people who have flaws. It does not mean you should not do it."
I saw a lot of tech people with the same bias as me: instead of dealing with people who think a bit different or act a bit different, we prefer to isolate and stay in our own world. Dealing with different people is hard but can be really rewarding. The lazy approach of sticking with your own crowd is comfortable but not necessarily the best approach.
And I double down on her "thinking is work too". I think internet makes us very addicted to have a constant flow of information pouring into our brain. We dont want it to stop. Disconnecting and staying with your thoughts is something that used to happen naturally, now it takes some efforts to do it. Yet we absolutely need it
Your first point is why I’m quite skeptical of the narrative around “brilliant assholes”. Are they really an asshole, or do they just not communicate in the manner you’d prefer?
> Your first point is why I’m quite skeptical of the narrative around “brilliant assholes”. Are they really an asshole, or do they just not communicate in the manner you’d prefer?
As someone who generally enjoys working with the "brilliant asshole," there are two types to look for.
The first is a brilliant engineer who is an asshole in matters unrelated to the task at-hand. I've seen coworkers physically assaulted by this type.
The second is a brilliant engineer who takes no shit when it comes to the task at-hand, which I think is a bit more of the Torvaldian asshole. If you have someone trying to slip in a below-threshold quality solution into place, this person will not let it slide. One of my favorite engineers had a little comic strip tacked to his cube, the punchline was something along the lines of "You're right, let's do it the stupidest fucking way possible because it is easier for you personally."
Regarding the second, I tend to see their frustrations come out when interacting with the "politician," the kind of person who puts on a polite veneer but uses it as a shield. This is the kind of person who will tell you they aren't doing something because they don't feel like it, but when management gets involved starts acting surprised at the accusation while playing into the "brilliant asshole's" known-quantity.
If you see someone at work getting frustrated with another, don't just buy into the "he's an asshole" narrative. Do a little investigative legwork.
Often times I get frustrated with the second type you describe because they seem to assume that I have deliberately (or otherwise) chosen to do something suboptimal out of laziness or neglect when often it is simply from not being a subject matter expert myself.
There is a lot to be said for not taking any shit when it comes to getting things right in a project. However, I think that the most brilliant engineer is the one who helps people who make mistakes or are not as smart/experienced as they. Implying the only reason someone would not do "The Right Thing" is because they're bad is a sort of self fulfilling prophecy.
That’s definitely problematic behavior you’re describing, there is a big difference between starting from a place of reason and moving to stern due to repeated behavior and starting with stern. The latter is the “good asshole.”
This is an interesting question. I tend to think the narrative is actually true (obviously we’re talking about a very large and vague grouping here - results will vary.)
I’ve definitely run into “brilliant assholes” and yes, they are actually assholes — highly sensitive to perceived insults to their intelligence, violently protective of their fiefdom, etc etc. Culture cancer and I’ve never regretted being rid of them.
BUT - I think it’s worth considering a variation based on the OP’s first point - maybe it’s not the “brilliant asshole” who we should pay more attention to, but instead the brilliant quiet introvert who maybe doesn’t join in on every chat or share his/her opinion so readily, or the brilliant person-who-doesn’t-fit-whatever-subtle-bias-we-might-have that might look, sound, or be older/younger than we might expect.
Those are the people we should be paying more attention to, not the assholes.
I was working somewhere once when we hired this guy. He was brilliant but so intense, he always seemed worked up and emotive. I thought he didn't like me and that he was kind of an asshole.
Years later, when I had become a bit more worldly, I remembered him one day and had a sudden realization: He wasn't an asshole at all! He was just French!
(No disrespect meant to any French persons! The joke is on me and my own naivete, eh? Vive la France!)
For most situations, the distinction is irrelevant. The question that should be answered is: Can this brilliant person do the work him/herself, or will (s)he need the cooperation of others? If the latter, then interpersonal dynamics should be significant factor in evaluating performance.
If most of the team has trouble working with someone, then that someone is a problem. It doesn't matter if he really is an asshole or just communicates differently. If people leave teams because of that someone, then harm is being done to the team.
It's why I don't believe in concepts like 10x developers/engineers. As a manager, if I cannot replace 10 people with this one developer, he/she is not a 10x developer. Almost all teams need to do different types of work - including communicating with customers, writing docs, paperwork, etc. When you factor all those in, no one is a 10x engineer. They're just really, really good at one or two of the skills the team needs.
I have seen engineers making themselves look brilliant by intentionally taking down achievement of others. By successfully blaming own mistakes on others, by saying people they have to do things their way and then blaming them for doing what they have been told. Also by successfully claiming their subjective preferences are objective standards (in front of non technical manager).
By undermining competitors - equally smart skilled people who are not assholes.
By doing completely inconsistent unpredictable code review (forcing you to redo it each time differently in the same situation) and then saying that delays are due to shitty code.
Like, there are brilliant non-assholes. Plenty of them. But in some companies being asshole makes you look better.
The thing is, that in order to have cult around you, you have to consciously build that cult. And brilliant assholes is the person that consciously worked on building that following.
I think the “brilliant asshole” narrative just fits better with the west coast’s (generalizing here) need to armchair psychoanalyze everything. Even in the rare cases where it is right, amateur talk therapy is often low- or counter-productive to solving the problem at hand.
Everyone is bad at giving constructive criticism to some extent, just like everyone is bad at receiving it to some extent. Clickbait that muckrakes LKML does not absolve anyone of the responsibility of finding a way to be productive with someone they don’t like.
Excellent writing, I really enjoyed the content of the post and the way it’s written.
This phrase particularly stood out to me:
> We are stronger by considering the opposite first.
That’s something I’m not very good at, but work hard to do. In many situations I have a tendency to assume I’m right, and that as soon as my interlocutor understands my argument, they will see I’m right. “I’m a rational person and I believe X, so if you don’t believe X you must be irrational.” So I spend lots of time clarifying my argument, and it gets nowhere.
By genuinely spending a larger proportion of my time thinking about others’ points of view, I arrive at better solutions.
Good old syllogism in defense of ego. (Post hoc ergo propter hoc and reduction fallacy kinda, but really just jumping to conclusions.) "Rationalist" meets hypocrisy.
> When I find myself itching to interrupt someone with my thoughts about a topic I try to ask myself “what am I being asked to be an expert in here?” Often I realize that in my enthusiasm to show my casual knowledge I’m about to correct someone that who has devoted a considerable amount of time and effort into developing their expertise in the topic. I never regret keeping my mouth shut and letting them speak.
>When I was in a traditional office environment I used to tell my people: If it’s 2pm and you’ve finished your work for the day and you have no meetings, just go home
I've often had this thought - what is the ultimate cost of giving someone a random friday off, not counted against any sort of vacation policy? "Hey, you've been working really hard and the team is better off for the work you've done, take a three or four day weekend". Would that really harm the bottom line? I mean, in a metrics driven environment, if we hit our metrics, then why not spend some time gearing up for the next thing by recharging?
> But trust also degrades naturally over time. Italian researchers Cristiano Castelfranchi and Rino Falcone have a model of trust in which it’s observability not success that is the key factor. Under their theory an entity that is silently successful can end up seen as less trustworthy than an entity that visibly fails.
I would believe it.
From what I know, trust is a fickle, and irrational attribute. It places disproportionate value on first hand sensory input, and it isn't nearly a commutative as would seem reasonable.
The most trusted client relationships I had in tech consulting where those that had gone through a major foul up (usually a software issue on our side) that was honestly and diligently corrected. Accountability is a big factor in the equation of trust. Finger pointing has the opposite effect.
> Places where no one is sure who owns what, or who is responsible for what are unlikely to have proper monitoring and much more likely to be two or three upgrades behind. The seams are where things get lost, sometimes for years. So if your mandate is security or availability the seams are your best bet of finding a big pay off.
So true. Sometimes there's a person behind the scenes keeping it all working with bailing wire and elbow grease, but that person is also a huge point of failure.
Sometimes the opposite of one person keeping it all together behind the scenes is "diffuse responsibility", where many people are theoretically responsible, and in practice _nobody_ keeps on top of things because they leave it to others, or even finger-point that "someone else" should have done something.
Diffuse is different from distributed.
In distributed responsibility, there is redundancy. Multiple people ensure things operate. This is good.
In diffuse responsibilty, people cancel each other out, so it's worse than having one person.
An office version of the bystander effect, if you will.
This is particularly bad in volunteer organisations, where wishes and reality do not mix well.
Single point of failure is in important thing.
So I've seen people try to convert a SPOF system, where one or two people are keeping the business and systems running, to a diffused responsibility system.
With the result that one or two people still keep the business running... out of exasperated necessity.
But with more complaining by others, because that's not supposed to happen.
If it were complaining by others that more people aren't taking up meaningful responsibility and doing the work, that makes sense to me. But it's usually complaining by others about the people doing the work. And since they are volunteers, that's a shitty position to be in.
Complaints include that they aren't "letting" others do it. Which couldn't be further from the truth.
People keep being asked to help, and keep being individually not very available. Or, worse, available in not really useful way (impractical hours for example, or sessions too short), or on balance unhelpful.
Those few being meaningfully responsible are, however, not "letting" others access critical databases such as personal data, and safety critical systems, without building up a trust reservoir and track record first, and in some cases formalised relationships. And that seems to make would-be volunteers rather grumbly, in a public way.
At least in volunteer organisations, the bottom line is most people avoid work if they think they can rationalise why it shouldn't need to be done, will gut requirements and constraints, if they don't personally like them, and will avoid taking initiatives on things they think are stalled, if they can get away with portraying it as someone else's fault.
In short, they are contradictory, wanting thing to happen, but rarely taking actions that lead to it.
That doesn't match what actually needs to be done, so it falls on the same few shoulders again and again, and usually at crunch times, as those shoulders are criticised if they take action too early.
Then we end up with "hidden single point of failure", which may be worse than the visible kind.
I suspect that the main good purpose of the impostor syndrome concept is to tell it to another person, when they need to hear it.
When an article gives a personal account of someone feeling impostor syndrome, one possibility is that they are trying to tell it to readers who might need to hear it, or who might tell it to someone else who needs to hear it.
What's potentially a bad effect of the impostor syndrome concept is when it causes very rational and needed self-doubt to be dismissed. So, instead of thinking, "I need to figure out how to be better at this," one might think, "Ha ha, my impostor syndrome must be flaring up again. Which means I'm even better than the evidence suggests."
(BTW, management-ish articles usually seem to be about self-promotion, one way or another, and I think it's just accepted as something a savvy person does. I try to pick out useful things, but don't assume (as I might with some other genre) that the writer believes what they are saying, nor that they think what they are saying is actually important -- even though both might be true, despite the conventions of the genre, as they might be true with this particular article.)
I get where you’re coming from. It has begun to annoy me that we’re always supposed to show massive sympathy for it and perform “omg, me too, you’re so valid!” responses to someone saying they have it. If you don’t feel confident in your skills maybe you should... do something about it instead of putting it down to some syndrome that implies you’re actually already great and you just need to believe in yourself?
I don't think that's entirely fair to say. I've experienced it to some extent before and never told anyone about it. I've grown up with humbleness being taught to me as a very valuable virtue and it sometimes ends up impacting me negatively. For example, I struggle with selling my accomplishments on self-assessments. So much so that my manager has had to work with me on a plan that better makes my accomplishments visible.
When I get recognized and promoted, sure, I'm very grateful about it but it can occasionally give me anxiety of what those below me in their career ladder think about me. I have ways of dealing with anxiety but telling them I have imposter syndrome is not remotely one of them.
My collection is at http://github.com/globalcitizen/taoup .. though not exclusively non-engineers, I find it genuinely useful to recalibrate if stuck for fresh perspective.
> If it’s 2pm and you’ve finished your work for the day and you have no meetings, just go home.
It never makes sense to me when people say this. As a Software Engineer, there's always work that can be done. How many people actually have a list of "work for the day"?
I generally pick a goal for the day, and then work hard towards it. If I've done it right, I don't have the energy to start another big rock mid day. Best I can do is think about what tomorrow's big rock is going to be, and get myself set up to hit the ground running. That feeling of never-ending work (and thus, work until your brain is toast) is anathema to being maximally productive. It just makes me take longer on each day's big rock so I'm not burning myself out in the long term anyway.
More precisely: There's no especially valuable work to be done at that moment, so go relax and save your effort for the valuable work that will be there later.
> Another thing he used to say a lot was “when you punch someone you need to pull your arm back, before you launch it forward. If you don’t your hit will be weak.”
A variation is "never replace/remove something if you can't explain what good it does". The classic example is the big code rewrite, where years of bugfixes and nuances get lost in the 'clean' reimplementation.
"I never regret keeping my mouth shut and letting them speak."
love it. even though i like to annoy people with my dumb comments, this is sound advice for sure. :)
Asking the "dumb" questions is actually often a good thing.
For one, you learn faster. Secondly, there's a chance someone else was thinking the same question and was too afraid of looking "dumb" to ask it. Just make sure you don't occupy all of their time with questions, especially in a public forum, thereby wasting other peoples' time.
The quote was actually talking more towards speaking up in an attempt to impress the expert with the little bit of knowledge you have in the subject. It's patronizing and they often see right through your front. It is much more effective to let the expert do their thing and for you to learn than trying to impress them with your little bit of subject matter knowledge.
> “People like us make our money in the seams of things”
Who said it: a Senior Official at the National Security Agency (NSA)
I find this sentiment to be terrifying when it comes from the government, let alone the NSA.
Government employees should be worried about nothing except than the efficient and legal discharge of their legal obligations/goals. I hope the wider context of the conversation makes this more innocent than it initially sounds.
I liked this article and it was nice to think through some of these things in these contexts.
That said, if I was speaking at a big government meeting (where the sign on the door often indicates a classification that is above what you can say on Medium) and found myself quoted in a blog post later I would be pissed.
In future, I would recommend the author take all the names of the organizations out or get permission from the person. The quote would have been just as powerful without the agency name drops in a security context.
In this case I was talking about name dropping agencies and how they operate. Example: "A Senior NSA Official" in what was likely a classified meeting with DHS officials and state department, and calling out how they were speaking with each other.
I'm not saying making it public is bad for the public overall, but I'm not sure that was the intent (based on the focus and purpose of the article) and generally those kinds of discussions are covered by NDAs and aren't for public record.
Her #1: "Security and reliability are more likely to go wrong in the seams between components".
Cannot confirm for security. Too naive thinking. Security mostly goes wrong in the very core, not at the seams.
One of her next is also a big red flag
> A big part of what I do as an engineering manager is stopping truly brilliant people from executing on plans that begin with the words “I can just do this myself in a weekend.”
It completely denies the impossibility of doing great work in a team. Someone has do it somewhen. She'll loose the brilliant guy who offered to do it properly, and she'll come up with the typical business solution. Unscalable and unmaintainable.
I stopped reading then. Way too self-congratulating engineer bashing.
Is the world not full of great work people have done as teams?
If I look around my lounge room right now, literally everything my eyes can see was put together by, not just a team, but a company (literally a team of teams), and much of it is actually very good and has already lasted for many years without fault.
I challenge you to name one person who has built a thing on their own without anyone else’s help.
What's the definition of a good project in your mind? I believe you, and the person you are replying to, are coming at this from two different frames of mind.
Is the quality of the final product all that matters? Is how the people working on the project felt during it a factor?
I'm, for instance, quite happy with the keyboard I am using at the moment. I doubt, very much, that it is the result of the work of a lone individual or a pair. Is your point that the original design might have been drawn by a lone individual, and you view the rest of the work performed by other people as mere augments to that person's vision?
I also did a lot of other projects. Like building engines or houses or planning cities or doing a movie.
Only in software you have the luxury to do it alone or in a pair. In architecture it sometimes works, in movies rarely (but such things do exist, like Shane Carruth), in engineering very rarely. In architecture or movies we call that phenomenon, many cooks don't make good meals. Or planning by committee. Never give up your project to a committee. Eg. Guido or Larry made a huge mistake.
Compared to those other fields and comparing the results you see excellency mostly with projects made by the fewest amount of people.
In SW its trivial to see. All projects managed by a big team are barely successful and more look like managed towards destruction. All managed still by a good founder do look great. Genetic arguments rarely count here.
Clearly NASA's Apollo programme would have been more of a success with only one or two people executing it. Or the Large Hadron Collider. Or the Linux Kernel (and no, that's very much not the work of one person). Or anything else of any real scale or import.
you didn't read the part where, taking an offer without inspecting the offer could be dangerous. They gave the (real?) example of inspecting the offer and discovering it was much more complicated than previously thought.
I've seen countless times brilliant people actually delivering amazing things “I can just do this myself in a weekend.” Now I've also seen countless times avg. people who consider themselves brilliant screwing things up. So it might be the author is just bad at hiring people ?
A thousand times this. Highly effective teams have super high levels of trust and mutual accountability.
The moment you lose trust, you now have to replace trust with some other type of mechanism. This leads to process/bureaucracy.
Trivial example for those that don’t “get it”: think about why do we need code reviews? If we knew people would write perfect code every time, they would never be needed. However, we hold them because we know that even in our own “best code” we may miss something/forget some detail.
However, think about your own process, at least for me, depending on a feature/the engineer, my code review might be cursory rather than super line by line. The difference? How much I trust that engineers ability in that specific type of code.
But that was a digression, my main point is that hight trust means high speed, low trust causes slow speeds. The more you can build up trust and eliminate/prevent process, the better your organization will be.
For anyone that wants more details on this, I highly recommend the book “The speed of trust” by Stephen Covey.