A few years ago when I started SOOMLA, my co-founder and I were debating the subject of commitment among software engineers in our team. To prove his point my co-founder presented a fable that goes as so:
You’ve just been notified of an urgent bug in production. You come up to your team of two well rounded engineers (both equally skilled technically) and explain the situation, implying that they need to stay late until the bug is solved. The reactions that follow are:
Engineer #1 (we’ll call her Alice):
I’ll work on it as much as I can, but at 9pm I have to leave. I’ll continue first thing in the morning.
Engineer #2 (we’ll call him Bob):
I’m on it. I’m not leaving till it’s solved, even if it’ll take me all night to squash that bug.
Both developers get to work on the bug. Eventually both solve the bug at 8PM and go home. Which engineer would you prefer on your team and why?
The short and obvious answer to the fable is that we’d all prefer engineer #2 - Bob. The reasoning is that Bob is more accountable, even in circumstances which aren’t convenient. He’s willing to put in the extra effort, prioritizing the organization in front of his personal life without expecting for anything in return. In many managers’ minds, this behavior epitomizes true commitment.
Why? Because managers eventually want piece of mind. They strive to build self managed teams so that they can focus on mentorship, guidance and innovation rather than micro management. But managers also secretly wish to have highly committed teams that can be relied on when the shit hits the fan, so that they don’t have to “hold the loose wires” themselves every time an emergency comes up. Commonly, in a workplace with live production systems serving customers at scale, this level of commitment comes as the natural expectation from engineers - those who can’t abide aren’t welcome.
Holding the opinion that Bob is the superior engineer for a long time, I’ve recently come to change my mind. Given that bugs occasionally crawl into production and expedited feature requests arise two and fro (a reasonable assumption in startups - subject to debate whether this is healthy or not), developer #1 - Alice - excels in the long term. Here’s why:
While Bob obsessively commits to tackle each crisis, over weeks and months he will gradually lose energy and burn out. Sleepless debugging nights will be followed by ineffective work days. Fatigue will take its toll in bad code and bug creep. The sleepless engineer, self deprived of rest, will procrastinate under the excuse of “I’ve worked all night, I deserve some quiet”.
Bob is constantly showing commitment, but in fact he’s mostly trying exhibit control, hoping to garner praise and perhaps promotion from his managers (not to say that seeking promotion is a bad thing). More senior team members who’ve seen the production bug drill for a while, would view Bob’s frantic behavior as loss of focus, or worse, putting your personal interests in front of the team’s. Some would see this as the negative manifestation of “managing up”.
If we embrace the notion that building a company (or a product for that sake) is a marathon and not a sprint, then I claim that Alice is in fact more committed than Bob in the long run. Furthermore, I would also contend that Bob, who makes an extraordinary effort to shine only in these extreme situations for the sake of his personal interests and career, is likely to leave the company long before Alice does.
I can think of a bunch of reasons (some of which I’ve witnessed often in past workplaces):
- We’re afraid the task at hand is too uncertain.
- We have no idea how much time it’ll take, so we prefer to avoid commitment.
- We don’t want to stay late and miss dinner at home.
- We’re afraid to get reprimanded by our managers.
- We’re just socially incompetent weirdos who can’t deal with criticism.
But here’s the kicker: it’s sometimes better to commit and miss your target rather than not committing at all. I believe this is key to learning and improving. As engineers, we should strive to constantly improve our skills. By committing we challenge ourselves and out teams to work smarter, give more educated effort estimations and eventually help move the organization forward. This advice holds especially true for those who wish to climb up the management path. I have yet to see a VP R&D who doesn’t commit on deliverables, or a VP Sales who doesn’t commit on closing deals. The trick is to pace your commitments so that you don’t undertake more than your plate can hold.
With all due respect to personal responsibility and accountability at work, there’s this nugget that my wife always reminds me that applies here as well - we’re eventually software engineers, not brain surgeons. There are (usually) no lives at stake - it’s only work. In the face of critical business situations we should by no means exhibit commitment in a mature and professional manner. The reward of gaining critical acclaim by your colleagues and supervisors is worth the extra hours, but not if you find yourself doing it every other day. We can go home at the end of the day and continue fresh the next morning from where we left off, the universe will probably still stay intact. Production issues come and go - stay committed, don’t burnout.