|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at email@example.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
Married to the Team
March 21, 2019
Marriage (if you're not a drunken celebrity) is usually preceded by an engagement and a period of dating that can last years. This time allows for an important ritual wherein one spends a lot of time trying on the potential spouse for size and fit, for compatibility and friendship. Outs exist at any time during this courtship, outs that are safety valves to defuse what could turn into an over-pressured boiler once the wedding is over.
Yet half of marriages end in divorce, often within a very short period of time.
Most engineers, though, marry their team after only an interview lasting an hour or two. It's more like polygamy than conventional marriage as teams are, well, teams, comprised of many members.
Extant team members are members of an arranged marriage, as many don't meet the "spouse" till the day of the marriage. Then they're expected to work in an almost intimate way, killing each other's ideas when they're bad and accepting a constant stream of intellectual criticism that is not always well-meaning or tactfully given.
CEOs sign pre-nuptial agreements, though sometimes these are, oddly, golden parachutes that enrich them even as they destroy the company.
We spend 40 to 60 hours a week working with these people, which may be far more time than spent with one's real spouse. Though divorce from a team is easier than that from real marriage, at least after a conventional divorce one can take years to re-evaluate, to figure out what went wrong, and to pursue a different tack the next time. A work "marriage" that fails leads to another hurried arrangement - a shotgun wedding, if you will - within days or weeks to avoid financial ruin.
Bankruptcy can follow. Just as it often does with real divorce.
In a romantic courtship certain rules ameliorate failure. Avoid a hasty trip to the altar. Avoid any idea that seems brilliant at the time, when the time is a party and a couple of drinks. Get to know the other, his/her friends, interests, desires and dreams. Find congruence between these and yours. Feel a deep attraction. Recognize that, while there is love at first sight, too often we mix that up with lust at first sight.
A team marriage is always a hasty affair. There's no bachelor/bachelorette party. No toast. The only promises akin to those implied in the I Do contract are legalistic paperwork about withholding taxes and a parking space. After a whirlwind courtship lasting perhaps only a few days the company proposes; and one has a day or two to accept. The honeymoon is a half-day of health insurance and 401-K forms followed by total immersion into all of team's problems.
Anniversary flowers, romantic dinners to nourish the relationship and the occasional present out of the blue are the grease of a real marriage to help overcome inevitable differences and spats. There are virtually no analogous tools in the workplace. Grievances fester, the rumor mill buzzes, and teams either implode or work far less efficiently than they could.
Larry Constantine, one of programming's luminaries, worked half time as a family therapist. I've always thought that a wonderful commentary on the nature of teams. His legendary team-building skills presumably stem, at least in part, from his understanding of the nature of human interaction. Yet in most companies leads are simply engineers who may be clueless about helping developers work efficiently, and with as little friction as possible.
What do you think? Do we bring the skills we use in marriage to the workplace? Should we?
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- A Lack of Forethought - Y2K redux
- How I Write Code - Comments first, code second.
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.