The Radiating Programmer
dev.37signals.com
dev.37signals.com
I have found that communication strengths and weaknesses can vary, from person to person, and it's usually a tough sell to come up with "one size fits all" solutions.
One example, is that I had an employee who is probably the best engineer that I've ever met, and I've worked with top-shelf people.
But he is "on the spectrum," so his verbal communication tends to be in monosyllables, and can sometimes be a bit inscrutable.
His emails and specs, on the other hand, were absolute marvels of communication.
I had another engineer on the same team, who wasn't quite as brilliant, but he is an awesome "people person." It was always a good idea for me to make the time to chat. His emails tended to sometimes be abrupt, and the information density wasn't that great.
Put him in front of a whiteboard, however, with an audience, and it was amazing.
As their manager, it was incumbent upon me to deal with each as an individual. They would sometimes have clashes, and I was often the peacemaker.
Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team. There are “superman” engineers, like Linus Torvalds, that can create entire shipping architectures, but those are incredibly rare.
That said, the myth of the “cookie cutter” engineer is just that: a myth. Some cultures do better at it than others. I worked for a Japanese company, and they came very close to it, but at a cost that most folks here, would find prohibitive.
High-performing teams can be difficult to manage. There’s often significant differences in personalities, egos can be high, and everyone has an opinion that is the only “right” one.
Great teams require good management. It’s always fun to dis managers, but good ones are force multipliers, like nothing else.
Yes, but also there are things that teams cannot do, and in fact make them worse.
To use an example from my org, there is a feature which was proposed to accomplish a specific objective. The feature grew in complexity to address much more than was originally planned. A large team was assembled to rapidly deliver as the original objective was important to business needs. The large team enabled the larger version of the feature.
This mostly happened without the knowledge of one of those smart but ostracized engineers. When they became aware of it, they had to step in and force changes to prevent the large feature from leading to serious technical debt and behavior that would not compose with other features well. More changes should have been done to return to a simpler design that would have focused on the original goal but it was too late.
We're supposed to be doing more than just spout jargon to our superiors.
We need to be completely situationally aware of the project, make sure that key stakeholders are always consulted for big decisions, and kept aware of plans, push back on senior managers, if what they ask is unreasonable, etc.
And we need to do it in a highly unobtrusive way, that doesn't interfere with developer productivity.
I have said it before, that I was lucky to have the situation I did, and the more I hear about how most companies run, the more fortunate I feel.
It seems that managing my way, these days, in Silicon Valley, would just get me fired.
It can, but in my experience with employers who push async as primary communication, the noise is MUCH higher than regularly scheduled stand-ups.
With that said, in my experience, many stand-up formats devolve into some version of "the two most talkative people have a conversation for 30 minutes while everyone else listens". I'd probably get more value out of doing a write-up than sitting through a meeting like that.
It really depends on the health of the stand-ups on the team.
In my decades as a SWE, there is one way that worked better than all others: having a competent project manager who individually polls team members with weekly, short(5-10min) 1:1s and then takes care of handling schedule updates, resource assignment and unblocking the dev. This allows devs to focus on what they do best with minimal cognitive load.
It requires hiring PMs though, and established managers will bristle at the thought of giving up responsibilities and power to another person. I'm seeing that within my org now. We're slowly learning all the lessons that big companies learned years ago from 70+ years of project management theory, but we're half-assing it because we refuse to accept that PMs and Gantt charts are about the only way for a large org to deliver efficiently and accurately in a mixed hw/sw, multi-team environment.
I've been in places where this would be a great deterrent for the endless meetings where slightly different groups of people need reassurance about the same things over and over again. Not that they're completely useless, but they're slow, low bandwidth and fatiguing. I wish some of those could have been replaced with a document like this.
I personally have no issue with a daily stand up, but then it’s always been basically the only meeting in my day and 9 times out of 10 people have stuck to a structure and always shared something interesting and useful about their day. If you just say “no blockers” you’re doing it wrong in my opinion.
If writing and sharing works best for a team then do it that way however we, as devs, need to realise we work in service of a broader business so if we don’t do a good job communicating what we do then that business will force something on us.
This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. No non-technical staff from the above list should have a right to challenge estimates. No product owner can belong to the above list. There should be openness when technical decisions made by a team get overriden from people on the above list. Especially when something painful like a terse edict to the effect of "allow x and y from security and audit team full, direct, read-write-execute permission to the backing data store of your micro service in production".
If there is no communication from the top, or there are negative consequences for speaking up, expect people to mentally check out.
not sure how I'd've ever justified suggesting engineering standup without our engineering manager present
In the companies I work at we can create whatever ceremony our team deems nessesary as long as we're meeting our metrics.
The CEO or someone high up the food chain sees a defect and now zomg the sky is falling. It has to be fixed nao, prioritization be damned. That's what I meant by nobody from the above list can be a product owner. The whole point of having sprints is so things can't be added to a sprint mid-sprint. Maybe there are extenuating circumstances but they should a. really be extenuating circumstances and b. should come through the (clearly nominal) product owner.
"Empowered to meet metrics" still doesn't sound like a very enlightened philosophy to me.
(A mix of capital letters and enlarged lower-case letters.)