Software Developer Cheat Code: How To Be Respected By Management
The key is to ask questions
If software developers knew the value of their skill, there’d be no need for this article. They’d be free.
But they don’t.
One of the most in-demand professions in the world feels like a drive-through restaurant. Business types make orders, and we software developers fulfill them. When they pull up and order something, not on the menu, we put our heads down and type.
These days, we’re a cog in the wheel. We exist to take orders so they can make sales happen.
It’s disrespectful. But like Pavlov’s dogs, we hear the feature whistle and start coding.
It’s a shame.
We need to have a backbone.
I’ve always felt engineers should have a chip on their shoulders. We need a code of conduct — a shared understanding amongst engineers to buck the system. Right now we don’t believe we deserve a seat at the table. Product people deliver requirements. Overzealous salespeople regurgitate customer needs. Together they decide the product’s fate while they expect us to wait and play fetch.
A backbone means we don’t take orders. Rather than kneeling, we take part in driving business direction because we’re more than hands on the keyboard.
If engineers worldwide pushed back more, we’d bring dignity back to software forever. You’d see fewer YouTube videos documenting the demise of the industry.
Think about lawyers and doctors. People listen to their doctors because they respect them. They seek guidance from their lawyers.
But we’re treated as commodities. Business types use the word hour to define our work. They speak of “engineering lift,” as if we stack bricks for a living. It’s common to talk about swapping(trading) one engineer for another.
Some of these business types don’t come from software. You see them on LinkedIn making motivational videos about technology culture. You hear technical words they stole from someone else come out of their mouths.
It’s time to flip the script because we deserve answers. It’s time to ask questions.
Open-ended questions
An excellent way to gain respect is to ask open-ended questions. High-value questions create an intellectual dialogue. Either you learn, they do, or both. Asking questions like: “What’s the one thing we can’t do without?” prompts thought. It encourages management to think about value.
Creating value is why businesses exist.
Instead of participating in the value discussion, it’s easy to fall in love with process folklore. Baptized in Agile, engineers allow management fairies to create a product backlog for us. We’re happy to let them identify value in our absence.
We stand in the ready position with our hands perched over the keyboard. “Decisions makers” descend from mount-high to spoon-feed us our next task.
This strategy fails.
A better approach is to dig deep into each request. When something doesn’t make sense, start a dialogue—Walk through the detail using basic common sense. If you have an idea, suggest it. Avoid opening your code editor when someone writes a Jira ticket.
We ask nothing, so they don’t tell us anything. A considerable portion of tech debt is our inability to challenge requests. We hold our tongue and pay for it by spending time away from our families.
It doesn’t have to be this way.
Below you’ll find a list of common questions to understand better what management wants. The approach is the same whether they ask you to build something new, fix a bug, or extend a feature.
The following questions embody a way to sort through the cruft. Before you read on, take a look at this formula:
[Demonstrate you understand their concern] + [Ask a group of good questions] + [Solve their problem] === Success.
When management asks for increased scope
Scope creep is the bane of an engineer’s existence. Despite a hundred ways to run agile and too many ways to communicate, scope creep happens. It’s frustrating. We want to slam our keyboards into the ground.
But our approach should be to swallow the lump in your throats and understand the reason for their question. Assume management’s request is valid and work towards a solution. Sometimes requests may be correct, and maybe they’re wrong. But what would a doctor do? A doctor would diagnose(ask questions) then prescribe(provide a solution).
Here are some helpful questions.
I understand this is important to you. Will you walk me through the customer’s pain?
What happens if we don’t do this right now?
Would it be impossible to build this later?
When the “powers that be” question your time commitment
Every question about time is not about hours. When management asks about time, there’s an emotional need. Maybe their boss or the board is pushing hard for a business deliverable. Perhaps something in the market changed, and they must figure out a way to adapt. Or they’re bad managers and don’t understand any other way to manage. Here are a few ways to get to the bottom of the time question.
There must be a good reason for your question. Would you help me better understand what’s at stake?
It seems like there are concerns about deliverables. Can you help me understand your top concerns?
Would it be impossible for you to walk me through what a win looks like?
It’s crucial for us to see management teams as our customers. They have business pressures, but often don’t know how to approach us with respect. Sometimes their excitement turns them into evil overloads who watch the clock.
Ignore questions about hours and minutes, and ask them what the project means.
When management expresses confusion about what you built
Believe it or not, confusion is a good thing. If management is a tad foggy, it’s an excellent time for you to gain greater clarity before you get too far away from the ground truth. Requirements and specifications are guides — an outline of what someone thinks they want. It’s a mistake to take requirements at face value, assuming that management is all-knowing. The best way is to ask thoughtful, insightful questions.
Whether building products or executing on projects, take a consultative approach. We offer the power of software engineering to the companies that employ us.
Try these questions:
It seems like we’re not on the same page. Will you walk me through what the user will see? What are we making happen? Improving? Reducing?
What would make this feature/product/release better?
How would you grade what we have now? How do I get an ‘A’?
When salespeople ask if you can do something, but you’re unsure if you can do it
Salespeople who ask questions show genuine interest. They want to trust us and deepen their relationship with us, but they think we’re aliens. They have no idea how to relate to us. Extroverted tactics elevated them to success, but that makes our skin crawl.
So, we tune them out and keep our distance.
But the best approach is to think of salespeople as future customers for our ideas. One day we may need them to sell our products. Perhaps they know a contact we can leverage later. Their contacts could be our next job or next investor. Relish these conversations.
Thank them for coming to you for a new feature. Tell them you’d like to take a moment to jot down their requests.
Thank you for including me in this discussion. I want to make sure I get you the correct answer. Would it be impossible for me to take notes so that I capture what you want?
A sure way to gain respect and favor is to entertain everyone’s ideas. That’s it.
You don’t need to make promises or pretend you know how to do anything.
It’s also important not to negativity-bomb their idea. This is where you tell them every reason it won’t work. Or you talk about how it failed thousands of times before. And the worst thing you can do is to trumpet how busy you are.
It’s easy to blow off the people who drive business to your current organization while torching future opportunities for yourself.
When management asks you to meet at a particular time, but you can’t make it
So-called product people will demand as much of your time as possible. They connect our time to deliverables—anyone who does this is an amateur.
Management sees software developers as an underclass. We’re the help that jumps when the CEO snaps their fingers. They expect us to stop mid-keystroke and address their concerns now!
My grandma had a saying I think applies. “If you got a jackass, ride it.” The point is, don’t be the jackass.
We don’t have to salute with yes sirs and no sirs. Companies are not plantations.
Our salaries and contracts represent an exchange— our expertise and services for fair compensation. And in this market, we can bounce anytime we want. And we should.
I recall being reported to management back in the day because I didn’t show up to a meeting invite. When I asked why someone would expect me to show up to an invite I didn’t accept, I got crickets.
To not be the jackass everyone rides, here’s how you handle them.
I’m sorry, but I can’t make it at that time. I know this is important to you, and I want to ensure we have enough time to chat. I am available to meet at XX on the YY date.
And, if they say, “what are you doing that you can’t make my meeting?”
You say:
I’m sorry, but I have a pressing item I can’t drop. Would it be possible to meet at these times (X, Y, Z)?
Many developers get in the fetal position and work for anyone and everyone in the organization. All departments make requests, and we kneel.
Own your time. Be the boss of your next task. Don’t ignore management but train them to approach you with respect. You’re not their idea trashcan.
If you don’t respect your time, no one will.
When they tell you they can do it cheaper with offshore engineers
Let them.
When you have a business question, and you can’t get answers
If you want management to squirm in their chairs, ask piercing business questions. Think about what you’d like to know if you were investing your own money.
Investors aren’t the only people who should ask questions. And their dollars mean nothing if we don’t build technology.
When you want answers, do your research. Show up to meetings with more than casual google searches. Ask yourself whether it makes sense.
It’s crucial to form your ideas.
You see, managers expect questions from the board, but they don’t see you coming. Some will be delighted that you show interest. Others will look down their snouts.
But the trick is to ask broad qualitative questions backed by your research. It’s like forcing them to do an open-ended essay.
Here are a few that have worked for me:
How do you think the board feels about where we are?
What do you tell your colleagues about the state of our business?
What’s the worst thing that could happen?
What’s the biggest challenge we face?
What about this project is important to you? What happens to you if we fail?
What are some changes that make us better starting now?
Respect is earned, not given. To ascend to our rightful place at the decision table, we must ask questions. We must not only own lines of code but business processes. Our focus must turn towards business value.
We learn value by asking questions.