In the history of inventions, the rivalry between Nikola Tesla and Thomas Edison is one of the most famous. Their competition in the field of electricity is sometimes referred to as the “war of currents.” Live Science describes Tesla as having the ability to “accurately visualize intricate 3D objects” and “really work out his inventions in his imagination.” In contrast, Edison was a “tinkerer,” who arrived at many of his inventions via trial and error. Most accounts, however, conclude that “you can’t really say one is greater, because American society needs some Edisons and it needs some Teslas.”
While reading up on these two individuals, it struck us at Sprout Social that these two working styles can teach us how to build a healthy engineering culture consisting of Edisons and Teslas.
We’ve found many software engineers, regardless of background, fall into one of the two personality profiles. While both have their merits, they also carry differences that, when Edisons and Teslas work together, can lead to conflict in the workplace.
Let’s compare their individual beliefs here:
| “Tesla” programmer beliefs | “Edison” programmer beliefs |
|---|---|
| Up front design is valuable. | Speed to market is valuable. |
| Meetings to achieve consensus and brainstorm problems are valuable. | Meetings to knowledge-share after arriving at a solution are valuable. |
| You should “measure twice, cut once.” | You should get something out and iterate. |
| It’s inefficient to write code without full clarity on the problem you’re solving. | We won’t identify many issues up front, so it’s important to get started to find them |
The differences in personality type come to light especially during times of crisis, such as a difficult project, a buggy release or when technical debt starts to add up. Edisons and Teslas can experience the following frustrations during those situations:
| “Tesla” programmer frustrations | “Edison” programmer frustrations |
|---|---|
| We don’t have adequate up-front design. A lot of issues can be identified early. We should be required to do up front design. | We move too slow and have too much corporate minutiae because we spend our time talking and writing documents instead of actually delivering code. |
| My code should be easy to review because the design for it was already reviewed. | I don’t like when people are resistant to rewrite code, or even discard it entirely. |
| I don’t like reviewing code for which I have not reviewed a design. If the code is already done, it’s too late to adjust and I feel awkward reviewing it. | My code should receive a lot of feedback, and I welcome it. Code for review is simply a suggested change, and it can and should be rewritten multiple times if necessary. |
When nurturing team culture, engineering leaders will need to identify ways to balance and accommodate these two perspectives. Teslas become frustrated when forced into an Edison way of operating, and Edisons become frustrated when forced into a Tesla way of thinking. Even engineering leaders can succumb to their own personal biases, preferring one over the other. This makes it even more challenging to create an environment where Teslas and Edisons can thrive.
At Sprout Social, we’ve identified several ways we try to accommodate both Edisons and Teslas:
- Make design documents optional: Teslas may prefer to create design documents more frequently than Edisons, so consider making design documents optional except in the case of major features that could affect other teams.
- Don’t mandate deliverables: Agile Spikes (investigation stories) do not have mandated deliverables. A Tesla may prefer to deliver a diagram or design document, while an Edison may deliver a prototype or code samples.
- Allow for focus time: Have prescribed time blocks for team syncs and otherwise allow for heads down working time. This creates an opportunity for Teslas to share designs while Edisons can knowledge-share. It also protects Edisons from too many ad-hoc collaboration meetings.
- Encourage radical candor: This applies to both design documents (at Sprout, they live on collaborative Wikis) and code reviews. Teslas may prefer thorough feedback on design docs, while Edisons may prefer thorough feedback in PRs. Regardless, both Edisons and Teslas should be encouraged to practice giving and receiving radically candid feedback.
If you are a software engineer or an engineering manager, we encourage you to develop an awareness of how your team members operate and ensure your processes and culture cater to both for a highest-possible level of productivity. If you over cater to one camp or the other, you’re disadvantaging half of the team.
Are you a Tesla or an Edison?