How Software Engineers can be heard and why it matters
- Are Software Engineers human or alien?
Being a Software Engineer (SE) at heart, I was always curious to explore why there are such a limited number of engineers (coders and testers) that can help shape the roadmap, provide feedback on the complexity of potential solutions, challenge requirements in a constructive way, etc.
Why are there not that many influencers and leaders with a software engineering background out there, whose voices would be heard?
I’ve started asking myself:
Are we, in general, interested in contributing to the success of our organizations? Are we so different from the rest?
Are our values deviating from the values of our business counterparts?
Then I went one step further (with even more drastic questions):
- Maybe there’s something wrong with us? Are we just a bunch of weirdos sitting in the basement?
- Maybe our feedback is not that important, and “others” just know better?
- Do “others” understand what kind of skillset software engineers have? Why is it not being used to the full extent?
“I don’t have all the answers. I’d simply like to encourage awareness and reflection.”
Well, those are simple questions that deserve complex answers. For the first group of questions, the answer may sound like “Yes, but…”, whereas for the second group it’s more like “No, but…”. I believe this “but” is something that is worth demystifying, even though I find it difficult to express sometimes.
What if I were to say that an average SE simply does not believe that the loudest person in the room is necessarily the smartest one, but is too shy to speak up? Maybe because most of us are introverts? Maybe it’s the amount of detail, that often isn’t sufficient enough to start coding, that causes disruption in communication?
It’s common to experience a situation where it is simply not understood how complex it is to build certain functionality, acknowledging an infinite number of unknowns and pushing for timelines, that, by nature, can’t be guaranteed in those cases.
Reflecting a bit more on the topic, you probably won’t disagree that quite often Product Owners (POs) and/or Product Managers (PMs) can’t find a common language with Software Engineers. In return, Software Engineers don’t bother to express themselves in a non-cryptic way. So, why is that happening?
2. “I don’t understand what this coder is saying” or guide to communicating with “others”
We have often heard during meetings: “Oh this sounds like rocket science” or “This is all Tech talk”. As developers, we are often branded as people with our own lingos and non-technical folks can often not make sense of what we say. This leads to a situation where our ideas and thoughts are disregarded.
“It’s a two-way street”
To progress in our careers and have our voices heard in regards to innovation and decision-making we would need to master the art of understanding how to communicate with non-technical folks within the organization. It is cool to have our little tech chat with our fellow developer, but we must know how to translate that to our non-technical teammates.
Here are some tips:
- Simplify the complex
For example,
Before: “This won’t be optimal since the time complexity is O(n2).”
After Simplifying: “This is going to lead to a significant performance issue, which could slow down the system.”
- Teach your non-Tech coworkers some crucial Tech terms
At times even the most effective communicators may not be able to translate all the Tech terms to simple English. After all, you are working for a Tech Company and some terminology would still need to be understood by all.
- Be present on the meeting
This may sound ridiculous to some, but it happens. We get bored easily in meetings, and sometimes resort to coding, compiling, running tests etc. during the course of a meeting.
What happens when we do that?
We are not a part of the decision-making that happens during that meeting. Soon all decisions are made by people who have no idea about how the technology behind all of this works. And once that happens, we may start the blame game of how we were not asked for an opinion.
To avoid this situation, always be present during meetings, and give your best inputs. If you think you have nothing to contribute to the meeting, politely decline or walk out.
- Build Prototypes/Proof of concepts
Building something and showcasing it, will have a far bigger impact than just talking about it. If you run into a situation where it makes sense to spend a few hours and build a prototype to showcase its merits to the team, go ahead and build it.
This will make people really pay attention to your idea and also help them clearly understand it. Since we love coding, we can utilize it to our advantage and build proof of concepts to showcase to our teams.
3. “Why is my Software Engineer so annoyed”?
Let me speak for myself, talking about situations where I personally feel upset and annoyed.
Mainly I can sort them into 3 groups:
· Complexity is not being understood and acknowledged
· Feedback is not taken seriously
· Belief in a “super coder” that does not need to learn, as they already know how to code
I’ll never forget the first time I was asked: “How hard can that be? Why does that take soooo long?”. I guess it’s one of the most-used phrases non-developers use in order to annoy developers.
Why not use a bit of a different approach:
“Could you please give me some insights on how the resource calculation was done? Which sub-tasks would have to be completed?”
If any SE comes to you, it means they are missing something to be successful in their task. Don’t send them over saying: “I don’t know how to code, that’s your job.” — simply because they are struggling to explain the problem in simple terms.
“Wrong questions -> Wrong answers”
For sure ignore using phrases like: “My grandmother (or my son) can do it for 20$”. That’s not valid measurement of software complexity and in the best case you would be suggested to send your requirements to your grandma or son to be implemented.
The next two go in the same bucket: “You’ve just written … lines of code in past … days?” and “You have to work harder — there are bugs!”. Well, those are the big ones. I can assure you that number of lines of code per day is not the right metric to use to judge a SE’s performance. Remember one more thing — there’s no perfect Software without bugs out there, so be collaborative and help to catch those at early stages, rather than complaining.
As non-developers find it hard to communicate their requirements and ideas, they tend to downplay their requirements hoping that the task doesn’t take too long to be executed by the developer.
“I just have this tiny little change request” or “It’s just a minor design change, you don’t need to change the whole system.” Simply give a chance to the SE to judge about complexity of the task.
There’s a lot of miscommunication out there, especially with technologies becoming more widespread (and sometimes more complex), the communication between developers and non-developers has become quite a challenge. If not addressed, you will keep building complex solutions to resolve simple problems.
I would encourage all development team leaders (whatever role they are in) to try to understand their engineers, partner with them, trust them and make space for learning.
4. Leveraging Software Engineer’s full potential
At the level that decisions are being made about a particular product, SEs are often not present. There are several reasons for that:
- Miscommunication
- SEs are rarely recognized by organizations as leaders, hence not promoted to leadership positions
- Even being “invited”, SEs easily get bored with management topics and prefer to focus on coding
We have already talked a lot about miscommunication above. You will see fascinating results, if you cultivate the creation of an environment where SEs and managers (in other roles) meet, try to understand each other, start trusting and working as a team.
In many organizations, that by nature, are not pure IT companies, we face the challenge of recognizing talents with an Engineering background. In such companies, the career path of SEs is rather limited. However, in the world of digital transformations, this issue needs to be tackled and those organizations who take it seriously will win.
There are quite a few options:
- Creating relevant Tech roles (Technical Lead (Lead Developer), Architect, Director of Engineering, Principal Engineer) and don’t force good coders to become bad managers
- Hunt for talents with a broad skillset and do everything it takes to develop them further. Having people like that in leading roles will allow you to move incredibly fast, as they can immediately provide feedback on Tech complexity, consequences of certain decisions and impact on the eco-system
- Keep diversity and inclusion in mind. If coders do not speak a lot, but they are good at what they do, do not “mark” them as weird or not collaborative — they are a valuable asset to the team
- Cultivate learning culture. A healthy culture rallies developers around a common goal, of creating high-quality code, continuously improving and enjoying the process. Culture is not only key to the alignment and effectiveness of the work, but to recruiting and retaining high-level talent.
Creating a good culture for Software Development teams can be achieved by “Providing space for autonomy and mastery”, “Creating a sense of purpose”, “Continuous Training”, “Coaching and mentorship”, “Internal communities of practice”, “Engagement with external communities”
Realizing that average working day of SE consists of multiple very complex tasks, that require special skills, and a lot of thinking, exploration, trial and error, you would probably start appreciating their work much more than you do now.
Don’t hesitate to learn “their” terminology, leverage Software Engineer’s knowledge and skills to do with a product what is right at that moment. Most importantly, trust them and find a way to gain their trust in return - it’s not a simple task.
The views, thoughts, and opinions expressed in the text belong solely to the author, and do not represent the opinion, strategy or goals of the author’s employer, organization, committee or any other group or individual.
