In my career as a software engineer and tech leader, I have sat in a lot of meetings. One meeting in particular many years ago still rings in my head after all these years. It was called “Planning” — simply “Planning” — and there was no agenda. Imagine me sitting in a conference room while product managers and key stakeholders file into the room. It wasn’t long before I realized I was the only “tech person” in that room. They start a discussion of project details walking through key deliverables and timelines. It became clear that there was already a lot of discussion — and decisions — that had happened on this topic before that meeting. In fact, someone even mentioned CEO support and huge business impact, etc., etc. And there I was hurriedly catching up with two eyes on the project documentation and two ears listening to what was going on. It was then that I found out my role in the room — I was being asked about feasibility.
I remember leaving that meeting wishing that I had been involved earlier. If I had, I would have been able to steer the conversation towards something workable. I could have shooed away unworkable ideas. I could have better understood and better engaged with what the company was endeavoring to achieve. I could have even suggested better ideas.
It was then that I realized there is an unspoken divide in companies. There are the people steering the ship, the visionaries, the ideas people. They tend to be non-technical and are business- or creative-oriented. Let’s call them the thinkers. On the other side, there are the people that are making the ship go, the makers, the implementations people. They tend to be technical and are engineering-oriented. Let’s call them the doers. (Not to imply that thinkers don’t do anything or that the doers don’t think.)
The misunderstandings between these two groups ends up fueling a kind of class system. The doers are often accused of not understanding the business problem and creating solutions to problems nobody has. They are accused of being too slow or cumbersome to work with. They are frustrated by being in discussions too late limiting their context and impact in the end. The thinkers are often accused of not being crisp in their requests nor having every question answered. They are accused of being too fast or mindful of constraints. They are frustrated by being accountable for meeting business objectives without feeling the same accountability from the teams on which they depend. This inevitably leads to low trust and dysfunction in the organization.
To address these misalignments head on, companies tend to add in layers of tech leadership, project management, product management, process management, business analysis, consultants, and even agile coaching. Without openness and transparency however, these lead to an invisible wall and the class system becoming further entrenched.
A new approach is necessary to overcome these hurdles. Real innovation happens when people from diverse backgrounds and different perspectives come together. It is those different perspectives that are the key to solving a problem. We need to tear down walls and start building bridges. We need to start speaking the same language and seeing all participants on an equal footing. We need to understand that we all have something to learn and something to teach. We need to become thinker-doers.
What does it mean to be a thinker-doer?
Thinkers need to appreciate the act of doing. Technology is a craft, but it is not witchcraft. There needs to be a willingness to understand and be involved enough to guide the conversation. I don’t advocate for everyone to start learning to code. That would be thinkers becoming doers. I advocate for everyone to understand what it is like to be in the room. Many teams nowadays follow an agile methodology. Terms like backlogs, time-boxing, sprints, velocity, inspecting and adapting, minimum viable product (MVP), technical debt, continuous integration/continuous deployment (CI/CD), proof of concept (PoC), discovery vs. delivery should be clear. Most importantly, bring the doers into the discussion of your ideas from the very beginning.
Doers need to get out of their comfort zone and be willing to be a bigger part of the conversation. Doers should be willing to talk to thinkers — even the most junior engineer on a team should be able to ask a question of the most important stakeholder. They should not simply implement what they are told but ask questions. Build to what the customer would experience rather than the exact letter of the request. Endeavor to understand the spend time evangelizing your impact on it. Give thinkers more transparency into how things are made and occasionally let them in the room.
Let us be thinker-doers. Let us tear down walls and treat each other as equal partners in these endeavors. Let us all engage in an appreciative dialogue that enables mutual collaboration. Because when we do, our abilities increase exponentially.
