Jessica has always been brilliant, even to the absent-minded professor type of behavior. When we dated in high school, she'd get so involved in a deep conversation I'd sometimes have to grab her hand at a curb so she wouldn't walk out in traffic. Our conversations were often in English, French, and Spanish as we were the only two students in school taking all three. I imagine those were easier for her than for me. She got a perfect score on her ACT. She at one point wanted to be a nuclear physicist and I have no doubt she'd have had an impact at University of Chicago. She ended up, to the benefit of the software industry, changing her focus.
Alternatively, decrease the need for coordination altogether. Instead of enforcing stronger department boundaries, build cross-functional project teams.
Departments are responsible for creating and curating reusable knowledge, project teams are responsible for providing value. The former does not need coordination, the latter needs way too much of it to go through formal boundaries.
In product development work, hand-off between people (i.e. different people dealing with implementation, feedback, responsibility and knowledge for the same goal) is one of the biggest wastes. Every time you pass information between people you lose a huge chunk of information and context that would help provide better value for the end user. At best 30 % of the information makes it through a hand-off, more realistically something like 10 %.
Hand-off results in the right knowledge not being available when needed. It leads to delays and low-value trade-offs. Also finger-pointing, endless series of status updates and reports, responsibility shirking, etc.
Popular management techniques (Taylorism, Critical Chain-type thinking) lead to excessive hand-off, either because it assumes everything is perfect (Taylorism) or because it focuses on activities rather than interactions and thinks global optimum is reached through the right local optimums (both Taylorism and Critical Chain).
"Anyone who doesn't do this will be fired" Really?? What kind of submissive pussies work in a place that? You talk to me like that you'll be collecting your teeth from the floor - I don't care if your name is jeff or any other self-aggrandising asshole.
I think we sorted this out for small-to-medium orgs.
We basically have 1 github issue bucket for the whole organization, and the repo its in also contains all of the code we care about, as well as all of the tooling and relevant documentation.
We don't lose track of anything anymore. Everything is done on the basis of some issue#. 1 global sequence. Labels are key. If you want to find some phrase across all code, issues, prs, etc, you just have to type it in the search box. This feature has probably saved me weeks of time by now.
We are adding a separate (non-GH) bucket that is more about the customer-product interactions, but it will ultimately answer to the current one if any product (code) change is desired, or if a bug is spotted.
The hard part is that leaders will hear this as advocating for organisational silos. Many, especially Americans, associate organizational silos with the violent deaths of 3000 Americans 20 years ago.
There were organizational silos in the intelligence agencies. The planning of the attacks became clear once the data was gathered in one place. Still, that was only done in retrospect and many things become clearer in retrospect.
Out of the aftermath of finger-pointing and brainstorming how to improve communication we could have had an additional small agency responsible for tracking, collecting, and making sense of threats across agencies. What we got instead was a major reorganization of the US federal government, the formation of the Department of Homeland Security which oversees far too many investigative and law enforcement personnel under one office, and the PATRIOT Act.
Contracts (APIs, interfaces) imply both parties understand what is being exchanged. The process of developing a contract helps each party figure that out and express it concretely.
Downstream, on one side of contract, as you develop and test, you may find that you understand the problem differently. Then the contract becomes a constraint. This organizational model then requires that parties revisit contracts if needs on one side or the other change. That still looks like coordination.
Perhaps the win is just less frequent, more focused coordination. We still need a common picture of "what", just now as expressed through contracts. I like the peer bob1029 post on consistent labels, in that way. The other decoupling to consider would be "when" - how can we work in parallel with minimal synchronization and blocking?
> how can we work in parallel with minimal synchronization and blocking?
This is something I'm very interested in at the moment. Trying to read up on how good development organisations do it, but I'm partly coming up short.
I know a Ward-style lean approach of web-based concurrent engineering involves these things:
- Brainstorming up multiple potential ways to break the system into subsystems, and exploring those in parallel.
- Negotiating over interfaces. "If I give you that endpoint, how will you use it to improve the product?"
- Specifying ahead of time which subsystems are inflexible and which are flexible. If an inflexible subsystem has an interface demand, the flexible subsystems have to comply. They, of course, are prepared for this and have explored several variants of their interface.
- Exploring several implementations exposing the same interface.
The main thing I don't get is that this is presented by Ward as a cheaper way to do development, because the subsystems are -- when all is said and done -- virtually guaranteed to integrate cleanly, and by exploring many options in parallel at all levels the risk of failure to deliver on schedule is virtually zero.
But... that parallel development of alternatives sounds really, really expensive. Like more expensive than blowing the schedule by a fair amount. I understand not all the work is wasted -- there's useful learning that happens in exploring an alternative even if it doesn't end up being used. But still!
Reinertsen argues for a more fiduciary view where the number of parallel alternatives to be developed must be balanced against the economically defensible level of risk reduction, but it gets somewhat abstract for me at that point. Can you really apply that logic at all levels in the organisation? Does it get easier with experience?
Anybody who enjoys this should check out the book “Team Topologies”. There’s a lot of depth in this whole team interaction patterns which the book brings to life.
As a software developer, this has been obvious to me for a long time. It's interesting how hard it's been to sell in organizations, though.
By way of analogy, consider which programs scale better and which scale worse. The best scaling programs are termed "embarrassingly parallel". The communication is constrained to the start and end of the work, issuing the data to be worked on and receiving the result of that work.
Programs that scale poorly often have too many interaction/synchronization points. Some of these are unavoidable, but minimizing them is literally what you do if you've worked on concurrent, parallel, or distributed systems. And the ones which scale the worst have constraints which force sequential execution of every step.
Business processes are not fundamentally different from any other process. There's nothing magical about it being done by people instead of computers or machines. If you have a large number of synchronization points then you have a cap (which may still be very high) on your ability to scale. Remove those points, to a reasonable level since some work fundamentally requires more than others, and you can smooth out a lot of work issues.
And vice versa. A lot of concurrency and distribution problems have been thoroughly examined by the project management people, but not in computational terms that computer scientists would immediately recognize.
Operations Research is another rich field that computer scientists often seem to neglect, perhaps out of ignorance of its existence or a belief that it's "just" about managing factories or something.
The first time I worked on a real distributed programming system I "grokked" the issues much faster than my peers because of my math degree (dual major) background that had included a couple OR and math modeling courses where I'd already seen the same thing (but presented in different terms). I'm hardly an expert in it, but by having been exposed I knew the right questions to ask to find out more information and how to analyze systems to find bottlenecks.
> Help them coordinate less - more explicitly, less often.
This would hurt during the exploring phase of development by eliminating frequent small iterative increments towards the ideal architecture/implementation.
In large organizations, the go-to tool for managing complex cross-team dependency graphs is SAFe. Even if your team doesn't want it, even if your boss doesn't want it, someone in the org will push for it so you all must adopt it. The vision of everyone working together in harmony contributing pieces of some grand plan is just too enticing for MBA types to pass up.
22 comments
[ 3.1 ms ] story [ 63.5 ms ] threadDepartments are responsible for creating and curating reusable knowledge, project teams are responsible for providing value. The former does not need coordination, the latter needs way too much of it to go through formal boundaries.
In product development work, hand-off between people (i.e. different people dealing with implementation, feedback, responsibility and knowledge for the same goal) is one of the biggest wastes. Every time you pass information between people you lose a huge chunk of information and context that would help provide better value for the end user. At best 30 % of the information makes it through a hand-off, more realistically something like 10 %.
Hand-off results in the right knowledge not being available when needed. It leads to delays and low-value trade-offs. Also finger-pointing, endless series of status updates and reports, responsibility shirking, etc.
Popular management techniques (Taylorism, Critical Chain-type thinking) lead to excessive hand-off, either because it assumes everything is perfect (Taylorism) or because it focuses on activities rather than interactions and thinks global optimum is reached through the right local optimums (both Taylorism and Critical Chain).
We basically have 1 github issue bucket for the whole organization, and the repo its in also contains all of the code we care about, as well as all of the tooling and relevant documentation.
We don't lose track of anything anymore. Everything is done on the basis of some issue#. 1 global sequence. Labels are key. If you want to find some phrase across all code, issues, prs, etc, you just have to type it in the search box. This feature has probably saved me weeks of time by now.
We are adding a separate (non-GH) bucket that is more about the customer-product interactions, but it will ultimately answer to the current one if any product (code) change is desired, or if a bug is spotted.
Out of the aftermath of finger-pointing and brainstorming how to improve communication we could have had an additional small agency responsible for tracking, collecting, and making sense of threats across agencies. What we got instead was a major reorganization of the US federal government, the formation of the Department of Homeland Security which oversees far too many investigative and law enforcement personnel under one office, and the PATRIOT Act.
Downstream, on one side of contract, as you develop and test, you may find that you understand the problem differently. Then the contract becomes a constraint. This organizational model then requires that parties revisit contracts if needs on one side or the other change. That still looks like coordination.
Perhaps the win is just less frequent, more focused coordination. We still need a common picture of "what", just now as expressed through contracts. I like the peer bob1029 post on consistent labels, in that way. The other decoupling to consider would be "when" - how can we work in parallel with minimal synchronization and blocking?
This is something I'm very interested in at the moment. Trying to read up on how good development organisations do it, but I'm partly coming up short.
I know a Ward-style lean approach of web-based concurrent engineering involves these things:
- Brainstorming up multiple potential ways to break the system into subsystems, and exploring those in parallel.
- Negotiating over interfaces. "If I give you that endpoint, how will you use it to improve the product?"
- Specifying ahead of time which subsystems are inflexible and which are flexible. If an inflexible subsystem has an interface demand, the flexible subsystems have to comply. They, of course, are prepared for this and have explored several variants of their interface.
- Exploring several implementations exposing the same interface.
The main thing I don't get is that this is presented by Ward as a cheaper way to do development, because the subsystems are -- when all is said and done -- virtually guaranteed to integrate cleanly, and by exploring many options in parallel at all levels the risk of failure to deliver on schedule is virtually zero.
But... that parallel development of alternatives sounds really, really expensive. Like more expensive than blowing the schedule by a fair amount. I understand not all the work is wasted -- there's useful learning that happens in exploring an alternative even if it doesn't end up being used. But still!
Reinertsen argues for a more fiduciary view where the number of parallel alternatives to be developed must be balanced against the economically defensible level of risk reduction, but it gets somewhat abstract for me at that point. Can you really apply that logic at all levels in the organisation? Does it get easier with experience?
By way of analogy, consider which programs scale better and which scale worse. The best scaling programs are termed "embarrassingly parallel". The communication is constrained to the start and end of the work, issuing the data to be worked on and receiving the result of that work.
Programs that scale poorly often have too many interaction/synchronization points. Some of these are unavoidable, but minimizing them is literally what you do if you've worked on concurrent, parallel, or distributed systems. And the ones which scale the worst have constraints which force sequential execution of every step.
Business processes are not fundamentally different from any other process. There's nothing magical about it being done by people instead of computers or machines. If you have a large number of synchronization points then you have a cap (which may still be very high) on your ability to scale. Remove those points, to a reasonable level since some work fundamentally requires more than others, and you can smooth out a lot of work issues.
I think you're correct. There is a lot of what project management people can learn from computer science.
Operations Research is another rich field that computer scientists often seem to neglect, perhaps out of ignorance of its existence or a belief that it's "just" about managing factories or something.
The first time I worked on a real distributed programming system I "grokked" the issues much faster than my peers because of my math degree (dual major) background that had included a couple OR and math modeling courses where I'd already seen the same thing (but presented in different terms). I'm hardly an expert in it, but by having been exposed I knew the right questions to ask to find out more information and how to analyze systems to find bottlenecks.
This would hurt during the exploring phase of development by eliminating frequent small iterative increments towards the ideal architecture/implementation.