How to Save Your Next Engineering Project Before You Start It
/
No, not that bart
How are your interactions at work? Chaotic and conflict-filled? Tediously unproductive? The BART system offers an analytical tool to solve stalled interactions—and clarify all sorts of organizational snafus. (And just to get it out of the way up front, no, we’re not talking trains.)
BART parses some of the arcane organizational dynamics lurking in the workplace. Even a bit of background on Boundaries, Authority, Roles, and Tasks will help you loosen log-jams during team encounters. Knowing what lurks below allows you to cut through the confusion—and decipher what’s really going on within your group’s hive-mind.
Boundary Skirmishes
Let’s first take a look at the idea of boundaries. Bad boundaries are the stuff of pop-culture memes, but the ramifications at work are invariably less amusing. Zachary Gabriel Green and Rene J. Molencamp’s BART theory says work boundaries comprise time, territory, and task. These translate roughly into “when, “ “where,” and “what?”
Time is easy to grasp. “In everyday life we have deadlines, due dates, and departure times and the like to which we must adhere. Failure to attend to these time boundaries carries consequences, depending on the rigidity of the boundary.” A plane or train leaves when it leaves; if you miss that time boundary, you don’t travel. Consequences can range from very minor (annoyance at having to wait for the next one) to catastrophic: you’re fired for missing a presentation you were supposed to deliver. Less dramatic but more ubiquitous: do meetings start and end on time?
Also straightforward is the territory aspect of boundaries (which animals-with-no-boundaries illustrate so nicely on the interwebs). Most political skirmishes include the high-stakes version of territorial boundary disputes; the Middle East is an obvious example. A common work version? Some of your team-members are in Bangalore; some are in Mountain View. How do you coordinate ... sans duplication and inconvenience?
Undefined Task boundaries cause confusion and delays. Does your group claim a particular project, or is it the other group’s? Everyone has been in a work-related “turf war” (whether as instigator, cannon fodder, or hostage). In groups with bad boundaries, territory and task issues combine with frustrating results. For example, does everyone do releases or is there a release engineer? If everyone does releases, whose task is it to ensure the release doesn't break?
Formal and Informal Authority and Roles
Getting “meta” with authority and roles is where big pay-offs are possible. Within the BART system, formal and informal (or explicit and implicit) versions of authority and roles always exist. So, solving organizational conflicts is often a matter of teasing out the tensions between the two levels.
Ever met a program manager or engineer who everyone on the team listens to ... though they’re not the designated lead? If a team doesn’t authorize the designated leader to lead, the leader—and, thus, the team—will be ineffective. Even if the organization has delegated formal authority by, say, bestowing a title, teams often make bottom-up decisions to follow someone whose vision they trust. That’s how informal authority usurps formal authority every time: trust always trumps a title. Despite workers believing that managers have all the power, it’s actually a two-way street, because a rogue team can negate all a manager’s efforts. Cultivating informal leaders—and their influence—is one way to acknowledge workplace realpolitik.
Consider all the different roles that comprise a well-functioning team. Explicit roles are engineer, QA tester, and product or program manager. But informal roles are where organizational dynamics are powerfully at play. What if your program manager (explicit role) doesn't take up the task master role (implicit)? Or what if your tech lead is so busy writing code she isn't directing the team? Class clowns grow into comedians at work, defusing tensions via a sort of court jester loophole. Who’s the social coordinator? Who’s the unofficial “jerk” or “devil’s advocate” (where ideas go to die)? (Maybe you’re the informal leader?)
(People get stuck in unofficial roles, too. Does the “giving” type at your office always end up with grungy clean-up tasks or with serving as morale-booster? How long before that person burns out, if their unofficial role is draining—as well as unacknowledged?)
Tasks
Official tasks are pretty much what you’d expect: write code, test code, launch products, etc. If you’re schooled in organizational dynamics, you’ll see plenty of unofficial tasks, too. Temporary groups, convened for a finite purpose or task, are sometimes subject to a counter-intuitive dynamic: survival!
The team wants to survive as a team, the start-up wants to survive as a start-up. Group-members start thinking (subconsciously), “I’m important because I’m in this group ... so I’d better ensure the group persists.” They become preoccupied with the group’s longevity and health (so their important role as group-member will persist), rather than with whatever putative task they’re supposed to accomplish. When this task takes over, unintended consequences arise ... such as the engineer who polishes the same section of code over and over, instead of moving on. Once you know the concept of unofficial tasks, they’re a lot easier to spot.
Dysfunctional Dynamics: A Case Study
Watching for unofficial roles (vs. going by titles) can help you parse puzzling dynamics.
SCENARIO. Let’s see how this plays out via an IRL example. A senior leader in a large tech company convened a team, thus formally authorizing those selected to participate in the project. The group members were peers (they all reported to this senior leader) as well as experienced managers (they each individually managed their own organizations) but they didn’t understand how to function in a group that needed consensus. They were used to top-down deciding and directing — not collaborating as peers. (Do you see how authority might be an issue here?)
The group’s task was to set next year’s annual goals, meaning they would make decisions on behalf of the senior leader’s overall constituency—which included their own individual orgs. But this group didn’t formally take up the authority they had been given to stay on-task. Some angled for power. Others showed up to meetings but in between those meetings didn’t execute the actions they’d agreed upon.
Step back from group conflict to note unofficial roles .
Disagreements arose at several phases, and unofficial roles evolved quickly. One person became the nay-sayer, shooting down every idea. Another tried to grab the crown: I’ll do everything, just let me have it! The group specifically de-authorized the program manager by not taking up his agendas and talking about him behind his back. Another leader became a rationalizer (unofficial role) for the status quo, defending existing decisions and thwarting any evolving visions. The senior leader himself hovered electronically, fretting that the group wasn’t taking more initiative—while group members jockeyed for his approval, rather than getting on with their task.
SOLUTION. Once you activate your “double-vision”—the ability to view both levels of role simultaneously— you can diagnose problems early. An immediate scope question should have been, Let’s define the group’s real task. Yes, we need to develop and disseminate the division’s new annual goals. But where were the task’s exact boundaries? Did that mean “just” creating the goals? (Strategy.) Did it include how to get there? (Tactics.) Should they assign specific tasks and responsibilities—back within their own organizations? (Implementation/Management.)
Once the group said “this—and only this—is our task” things fell into place. One person finally said, “I’m going to be the leader!” Everyone agreed (thus authorizing him informally.) And the group quashed the person who kept saying, “But to accomplish this, we first have to decide A, B, and C.” (No, the group’s task was solely the goals.) They also needed someone to say “we’re going off-task” and herd them back toward productivity: another unofficial but vital role.
Cat-herder is one of the most important unofficial roles on a team.
A BART Checklist—Refactor or Better API?
When you see a group unable to accomplish what it has set out to do (i.e., get results!), or people on a team being scapegoated or even being pushed out, step back for a moment. Do you need to refactor? Or do you need to better define the API for the team? Use BART to analyze what’s going on below the surface at work—the unexamined scenarios that control more of our work-life than we recognize.
Here’s a quick checklist to help you begin to analyze problematic dynamics.
Boundaries
Does the team have a deadline it is trying to meet? How does the team respect meeting boundaries?
Are there boundaries that get in the way?
Is the task truly clear? (Can each team-member define its boundaries?)
Authority
Who are the named / official leaders on the team?
Has the team authorized the leadership of tech lead, program manager, or manager? Is there an unofficial leader that people seem to be following?
Is there a discrepancy between the official and unofficial leader?
Roles
What are the official roles on the team?
What unofficial roles do you notice? (Class clown, slacker, nay-sayer, pollyanna, social coordinator ... )
How do unofficial roles interrupt productivity?
Task
What is the explicit task of the group?
What are some implicit tasks? (i.e. in prior EQ article, can you spot the team who had an implicit task of protect its bad leader?)
Are team-members more concerned with staying on-task ... or perpetuating the group itself (survival)?
After you’ve done the analysis, what’s next? How can you point issues out?
More on this later (in another post), but a quick model for giving feedback is “SBI.”
Situation — What did you observe? (stick to the facts)
Behavior — What was the behavior you saw?
Impact — What was the impact? (on you)
For example, I want to talk to the Tech Lead about being late to our team meetings. I say, “At our last meeting, you showed up 15 minutes late, and the impact was that the team and I weren’t able to really get started without you.” This touches on time boundaries and that the team doesn’t feel authorized to work without the tech lead ((1a and b, respectively, in the above checklist). This can be a lead-in to tell the TL about his impact and also a way to kick off a discussion about how to fix problems.
If you start using BART or SBI to analyze your workplace dynamics, let us know how it goes. Capriole Consulting collects real-life anecdotes to use in our coaching of technical leaders.
