Caught in the Space/Build Continuum, Part II
Last week, I wrote about a tool I conjured up to help describe the various positions organizations have their build teams in: Preed’s Build Team Spectrum.
I wanted to talk a bit more about the X-axis. (I’ll leave the Y-axis for another post.)
The biggest source of problems (and it was precisely this that caused Brad1 and I to talk past each other in our discussion) is when expectations—whether they be between a build engineer and her manager, the release team manager and other managers, or the build team and the engineering organization as a whole—differ.
You might imagine this wouldn’t happen, but it happens all the time.
As I explained to Brad: “When someone hired build or QA engineers, the majority of the time2, the description and mandate of the role is not ‘make developers more productive.’ It’s ‘ship/QA’ the product.”
Of course, making developers successful, as Brad initially pointed out, really should be at the core of any engineering support organization. But often, there is release engineering technical debt that the organization must pay off to get to a sustainable place before the focus tends back to developer support. Some of the worst, ugliest, most demoralizing situations I’ve seen in my career have been due to mismatches in these exact expectations.
It’s
For instance, another release engineer used to tell me how he kept getting pestered about why the new release tool hadn’t been finished, but his manager never put together that they were doing the releases manually, and had faced 2-3 months of continued emergency-patch releases.
His manager thought he was on the right side of the X-axis; he was actually spending his days in the center, shipping bits manually. (He was in the red zone to boot, and quit soon thereafter.)
It’s a common story: I’ve experienced situations where developers and their managers become angry when I can’t immediately respond to their support requests: they want me on the left side of the X-axis, because no one ever told them that the build team had been chronically understaffed and the mandate we were given was to keep shipping—that’s a constant—and keep the build farm from keeling over. Developer support was always going to be “the next build engineer we hire”-’s responsibility.
Again, mismatched perceptions.
Making it clear which resources are available on which portions of the spectrum is an incredibly important facet of keeping the build team productive and engaged with the larger engineering organization.
When everyone is honest with each other and on the same page about which resources are available for what types of activities, and those current mandates, positions, and expectations are broadly communicated and time taken for them to be understood, you have will happier engineers and managers, no matter what team they’re on.
_______________
1 My college friend who’s still actually probably not named that
2 Though admittedly, not always