I'll say this much: People problems are behind the majority of failures I've seen in my career. A project isn't delivered on time, and no one knew it was going poorly? People problem. A team spends three months building the wrong system, because they didn't work out the details with the right stakeholders? People problem. A critical person is fired, and the processes they manage predictably catch on fire a month later? People problem.
There is a category of problems that, I think, are mainly engineering problems (a few examples below.) You could argue that these, too, are people problems, because the team lacked experience and someone should have hired better engineers. However, given how difficult and unpredictable hiring is, I think it's better to treat questions of engineering design as primarily engineering problems, since that's a much easier problem to address. Some examples:
* An analytics system without tests that generated incorrect results silently.
* A project management system that ran out of memory when usage increased and couldn't be fixed without completely re-architecting it.
* An accounting system that wrote the same value in two places which frequently got out of sync.
"An analytics system without tests that generated incorrect results silently."
I've noticed that test coverage and quality is largely a people (budget) problem. They want the system now. They want that value delivered number going up and the cycle time going down. Tests are some of the first cuts.
i think thats too simple. i'm older, and when i go into shops its not that everyone realizes they need testing and it got cut, its that no one even has any notion that testing is useful or interesting. an entire generation of developers propping up systems without any real systemic validation that they do what they are supposed to.
organizations spend a huge amount of resource keeping 'cicd' propped up, but when you look at whats inside - its a build, and some random unit tests and mocks.
to be fair, testing in an environment where everything is internal and external services laced together with json isn't easy. what i find really odd is just that no one is willing to acknowledge it as a real problem.
That might be true in some places. In my company, they've systemically cut QA positions and testing gets pushed off. We spend about 25% of our time fixing bugs and defects every sprint. They are still pushing us for more speed.
Even so, the difference between some tests and no tests is vast. It's worth keeping CI/CD "propped up" just to detect syntax/compilation errors if nothing else.
(And then those of us who care at least have the option of writing some tests. I'll take the heat for being "slower" if I have to, because a bare minimum of tests provides extremely high value and advocating for baseline CI/CD is a great way to contribute to any organization.)
I've seen tests cut for that reason. But I've more often seen tests get cut or skimped on or slip through the cracks due to internal team dynamics problems.
If QA and engineering staff are organized into separate verticals, rather than being direct teammates that share a manager, then time that could have been spent on testing instead gets spent on bickering over who tests what and how.
If different team members have different opinions on testing strategy, and dig in on their respective positions rather than coming to an understanding, then tests will slip through the gap between them.
If senior team members don't think it's their responsibility to mentor (not browbeat!) less-experienced team members on good testing practice, then the correct tests won't get written.
If the people in charge of architecture don't recognize the outsize influence they have on the cost of designing and implementing tests, then testing can indeed become too expensive.
If people don't recognize that test cases are, first and foremost, a way of communicating and memorializing design specifications, and not just a clever way to run code in isolation, then the cost of maintaining them will go up and the value of maintaining them will go down, until people start to forget that there was ever a baby in all that bathwater in the first place.
Taken to the extreme, this says nothing because humans are ultimately behind every decision. If a cosmic ray caused a bit to flip and trigger an error, you could call it a people problem because humans failed to account for it.
Yeah, this is take is easy for the brain to start down. I blame the word "people". A more accurate term that maps to the examples in the previous post is perhaps something like "inter-team coordination problem".
This type of post is practically a trope at this point: technical blogger who digs deep into tech inevitably has a grand epiphany that it's really all about people, not tech, and that's what we should really be interested in.
Maybe this is the unofficial CTO creed or something.
I face the same problem with about 70%-80% of my clients. And there are 2 reasons:
a) they really do not know how their business runs - maybe some parts but never the whole "machine"
b) they do not know how to properly express their thoughts - it is a combination of art and skill but it can definitely be learned to a certain degree either at school or later by self-education
mid 2020s: outsource development to AI rather than pay your people
I've always been amazed at the kind of money companies will throw at not having to hire a developer. Salesforce is a quarter of a trillion dollar company because they tell management that they won't need to hire any developers and then charge outrageous rates to accomplish simple tasks in the most complicated way possible.
Just not yours, but their designated and certified developers that will stay stuck to Salesforce while your business might come and go. In the first few meetings with SF you'll invariably be presented with a consulting company that will help you deal with the purposedly hot mess that SF integration is.
I love this trend, every time they fail, it costs them a lot of money, and then I make bank after a few years of destruction because they look for a safe bet.
And in the tech industry we actually have it easy. Anyone who thinks it's hard to manage "people problems" with software developers has obviously never managed production workers in a factory or restaurant or something like that.
You just plan for things differently. The workers you mention are commodities, so it's easier to plan for them.
My father needed to design assembly lines that were safe enough for tweaked out workers who may not have slept for days to work on. Those were just his design constraints. True story.
"we can't figure out why this thing restarts so we seamlessly made it restart with no downtime by having a load-balancer/backup that kicks in when it kicks down"
I certainly agree that a lot of problems (including a lot of very difficult problems!) are not amenable to purely technical solutions.
But sometimes you have a difficult, technical bug to fix, and the "people problem" is making sure that someone has the knowledge, context, time, and incentive to fix it. This is not necessarily easy!
... especially if enough people have bought into "everything is a people problem", because then the technical work of fixing the bugs isn't valued or incentivized. Why would it be? It's not solving a people problem.
I think the viewpoint "everything is a people problem" can create a feedback loop that leads to poor incentives - which, ironically, is a people problem.
He wrote the questions back during the bad old days when a lot of shops tried to measure developer productivity in KLOCs.
Understanding the context, something similar today might be "How many story points will this take your team?" and if the answer is anything specific, the project is in trouble . . .
Nevertheless, this observation is too trivial to be useful, with the possible exception of "design things so that some automatic mechanism, independent of humans, is able to detect errors".
There's a tension here which I can't quite put my finger on, but perhaps it is: If everything is a people problem, why do we need engineers at all? And if the business can't be run solely by MBAs and project managers, and we bring on engineers for that last part, is it really just a people problem they're solving?
As a tech manager with twenty years experience, I can assure you, in fact, engineers are people. And they interact with those MBAs, project managers, etc. The really good product/project people understand this as well, and make a point of doing their very best to be effective when interacting with the engineering team. They know how expensive we are, and try to bring our our best.
To the point of this article, the best product people were in fact respected by the tech team, and it made all the difference.
To design stuff. That's what engineers do (on the case of software, designing is also called "building" and "developing").
Engineers do not fix the problems of your organization. At least not while wearing an "engineer" hat.
> MBAs and project managers
Non-technical MBAs and project managers are patently unable to solve a lot of the organizational problems of engineering organizations. But well, usually yes, the MBAs are the ones tasked into solving them. I dunno why you included project managers.
> If everything is a people problem, why do we need engineers at all?
Let's look at it as a bunch of people solving a problem which is too big for any one of them. Those people are different, they contribute different parts of the solutions - engineering, managerial - but they all have to cooperate to solve the problem, at least efficiently. If they don't, or don't do enough, for whatever reason, the solving suffers, possibly up to not happening.
There is a category of problems that, I think, are mainly engineering problems (a few examples below.) You could argue that these, too, are people problems, because the team lacked experience and someone should have hired better engineers. However, given how difficult and unpredictable hiring is, I think it's better to treat questions of engineering design as primarily engineering problems, since that's a much easier problem to address. Some examples:
* An analytics system without tests that generated incorrect results silently.
* A project management system that ran out of memory when usage increased and couldn't be fixed without completely re-architecting it.
* An accounting system that wrote the same value in two places which frequently got out of sync.
reply