tags:

views:

656

answers:

14

People don't take me seriously at my workplace. Whatever suggestions I give, it is always labeled as a technical solution. What do I have to do?

A: 

Get a new job, one where programmers are respected.

FlySwat
People not listening to one person isn't the same as people not listening to programmers as a group. On the flip side, programmers need to respect other people too, and I find that often lacking, not only in effect but motivation to even try.
brian d foy
+1  A: 

Oops!!! Wrong career!!! Work for something non tech related.

Ok... seriously... perhaps you a re using too much technical words to offer/describe solutions? Try to use a more business related argumentation to push your propossed solutions.

vmarquez
+3  A: 

You should also try to understand the domain and speak a bit along those lines, if that is what others want..

Gulzar
+3  A: 

Frame the reason for your suggestions in terms of "business value" that makes peoples' lives easier.

moffdub
+3  A: 

On a more serious note...

I would suggest start small. For instance, when giving a suggestion for a solution, maybe preparing beforehand would help. Showing that your suggestion works helps in persuading people that you are a valuable person. Then your coworkers will actually respect your answers not just that they are "technical" but they are also "correct".

contagious
+3  A: 

Huh, you got me confused.

Whatever suggestions I give, it is always labeled as a technical solution.

So? Isn't that a good thing? Would you rather have it labelled as a non-technical solution (or worse, marketing solution)? For me, “technical solution” says “here's the description, let's do this thing!” As opposed to “I don't have a clue, so I'm just sprouting nonsense that doesn't adhere to reality.” We're not in a Dilbert cartoon.

By the way, too late. Jon did it. :-p

Konrad Rudolph
I'd most always prefer a solution that requires less work and less technology over one that piles on more technology.
brian d foy
“technical” isn't the same as technology, though.
Konrad Rudolph
I agree with Brian. Sometimes it is best to avoid a technical solution to a problem if the technical solution is in depth and costly and an alternative non-technical solution is not. I have seen tens of thousands spent on development to solve a problem saving mere minutes for a user once per week.
BlackWasp
+2  A: 

You may need to support better your suggestions.

You must not only tell how, but also why, and the impact of the solution.

some times tech people use technology as the objective instead of using it as a tool to support an objective.

Cesar
A: 

You have to better take into account other dimensions of the problem you are addressing.

A way to do that is by studying other architectural aspects of a problem.

Another way is to learn communicate better (a non-technical skill, I confess, but a vital one).

With those two other dimensions (architecture and communication), you will be able to support (as Cesar says very aptly) your proposition, and make it looks like not just a technical fix, but a well thought through solution.

VonC
+20  A: 

Are your solutions always involving technology over other solutions such as design, process, business requirements, behavior modification, education, or the many other dimensions that impact a problem? How do your answers compare to what other people bring up and what they finally do? Start taking notes and see if you can spot the trends in your answers. What's common about your answers and their differences to the discussion?

Do you know much about the business or industry? I've seen plenty of programmers think they know what they are doing, but they've never talked to a customer, been on a sales call, or done any other sorts of work in the industry. They don't know why things are the way they are, what legal restrictions might be in place, what economic concerns people have, who the stakeholders are, the results of past efforts, and so on. How much of your industry is in response to things the business does not control? A lot of that might be stupid, but they influence how other people think and act and how they design and use things.

Although some people may laugh or make fun of the other parts of an organization, understanding why they exist and what their problems are may lead to solutions where you don't need technology. For instance, I've been in situations where the tech people were trying to solve a problem they thought the accounting people had, but the accounting people were trying to work around a problem they thought the programmers had. Put them together and they discover that neither of them really have a problem and there was a much better process that required less work and no additional effort. The manufactured problem of the two groups not talking to each other was the real problem.

Often you'll hear about customer service problems where people keep using the product in the "wrong way". That's usually not a problem of code, how you talk to the database, and so on. Adding more tech to make people do what you think they should isn't going to solve the real problem of people doing things you hadn't planned. The answer might be better marketing (as in, real market research) or responding to real customer needs rather than the manufactured customer needs.

brian d foy
Great answer. Reflects a person with very good experience working in corporate environments. Everything is correct and VERY valuable.
vmarquez
Right. that's what I meant to write in my answer, but didn't :-).
SquareCog
+9  A: 

When talking to people, you always need to speak in a language they understand, about things they care about.

So if you are a lone programmer in the marketing meeting -- don't start talking to them about design patterns (they will start thinking "paisley"). Talk about measuring impact of their ad (or, if you are really elite, you can even throw in the word "the creative" since ad people don't actually say "ad"..).

Yes, perhaps it's them who should learn something about your craft. But if you are known as the guy who can talk to any team, you are made of gold. It's a better position to be in, and worth the effort.

Also.. I don't know much about your situation, so perhaps it is worth considering that they are right, and not all problems require a technical solution. Sometimes instead of building a monitoring system that remotely checks the number of cokes left in the machine and sends an alert to the soda vendor when the supply is close to depleted, you want to just make sure the restocking guy comes over once a week, and be done with it, you know?

SquareCog
+9  A: 

I think you're asking the wrong crowd.

Bill the Lizard
A: 

Ditch the pocket pencil protector.

Paul Croarkin
+2  A: 

Here are some tips to bridge the gap between the business and technology:

  • Discuss interactions from the end users perspective. What do they see? What actions do they do to complete tasks? How is information presented to the end user?
  • Try to avoid mentioning specific technologies e.g. a web page is a web page irrespective of if it's written in JSP, PHP or ASP.NET especially as these terms mean nothing to users
  • Often technology plays a role in a larger end to end process. Try and understand that end to end process and where the technology touch points are.
  • Try and pick up business terminology relevant to the problem domain. Reuse this terminology when describing prospective solutions. Do not be afraid to ask for explanations of terms or concepts with which you are unfamiliar. This all builds confidence between business and technology.
  • Appreciate and empathize with other non-technical constraints e.g. cost, organisation, legacy technologies. use this knowledge to identify improvements where possible

Above all remember that the technical knowledge is critical BUT if you can support that with business facing skills you'll create better solutions. From time to time you'll have to surpress the geek but when you get back to the shop you can discuss the phenomenon of resurrection in the CLR until your heart is content!

+1  A: 

I think it's a balancing act. It is sort of like commuting. Anybody slower than you is a slow poke and anybody faster than you is crazy.

You are most likely the most technical person in your group. You need to watch the jargon when explaining your suggestions. Keeping it simple is the best approach. Be clear in your explanations like you are explaining it over the phone to someone you don't know.

When suggesting some new technology that really deviates from what your group is doing you need to do what I call planting seeds. You can't just suggest it. You need to mention it a few times here and there, so people become familiar with it. Overtime it may seem like the natural progression to move in that direction.

bruceatk