Iyfjky

Question

I've been working as a "Software Engineer" at a large, well-known tech company in the Valley for over a year and a half now. Previous to this, I've worked at another company straight out of college for over two and a half a years, so I have roughly four years of experience in total.

My team is composed of all senior software engineers (each about 9-12+ years experience). A lot of times during meetings (where we go into deep technical discussions about design), I remain very quiet, but I try my best to listen in and understand their thinking when approaching design problems.

The most senior guy on our team (with whom I get along very well with) personally tells me I need to participate more or it won't look good on my behalf. I tell him I understand and it's been a recurring "problem" over the course of several meetings.

My own perceptions are these:

Often times, when my team gets into technical debates, I feel that they discuss topics that are "advanced" or things that require you to have knowledge of the topic in the first place. I often try to keep up with these discussions by instantaneously researching (via Google) while they debate.

I get nervous to ask "stupid" questions when they are in heated debates and often feel that my input might not be valid because I'm not at their "level".

The conversations often move so quickly that I'm doing my best to keep up mentally.

I want to be a strong contributor to the team, but I often feel (perhaps my own negativity/cynicsm/whatever you want to call it) that I'm really considered junior relative to these guys. And I don't want to be in a position where these guys don't take me seriously on technical design decisions. Ultimately, I want to be more assertive, taken more seriously, and want to get to their "level".

What are your suggestions?
Thanks.

@user1220: also known as the "fake it until you make it" plan of fitting in. — Nov 6 '14 at 18:41
If done properly it works wonderfully. They may even not notice that they are the same words, but they will sure like them. With the added benefit that it may get expanded and increase the understanding by the junior guy, or if nothing else it's pretty good rubber ducking discussion. — Nov 6 '14 at 18:45
Too bad it's put on hold. I find this a very interesting questions. Depending on the project / team, I do struggle with this myself. — Nov 7 '14 at 17:28

Telastyn 33.9k977120 · Accepted Answer · 2014-10-29 18:29:41Z

I often try to keep up with these discussions by instantaneously researching (via Google) while they debate.

In general, this strikes me as your biggest problem. This is bad for two reasons:

People can't really multitask. That time you're spending googling stuff is time that you're not spending following the discussion.

The others see you not paying attention/contributing. This will only add to any perception that you're not participating.

So (politely) interrupt people when you have questions. "Hey, sorry, what is XYZ? I've not run into that.". This provides you quite a few benefits:

The conversation slows down so you can keep up (and the debaters can think, as well as see that others can't keep up - keeping things from getting too heated where it becomes awkward to interrupt).

You learn what they mean by XYZ in this context, which doesn't always line up with google.

You're seen as being involved in the meeting.

The more senior people feel good that people want to learn from them.

There is only one rule: don't ask the same thing twice.

Senior folks know that junior folks don't know as much, and are (usually) happy to answer questions. It (usually) makes them feel smart/important/powerful. And for software engineers, there's very often a compulsion to answer questions, educate people, and/or show off how smart they are. Take advantage of that.

What senior folks generally won't tolerate is wasting time (having to repeat themselves). If you don't get it, then follow up with clarifying questions - make sure you understand, because you won't really have the opportunity to ask again without harming your relationships. It can be okay to say "okay, can I stop by later to understand better?" if you don't want to derail the meeting, but the key is to speak up. Software engineers generally don't begrudge people who are ignorant - they begrudge people who remain ignorant.

It most likely depends on the culture, but I have often encountered situations where senior devs dislike it when you ask anything that they consider easy, even though it may not be easy for the junior/middle dev. This is especially noticeable when a team is 1 senior for each 10 juniors/middles (could be a management issue though, with too much pressure on the seniors). — Oct 30 '14 at 9:01
+1, I definitely think the Googling could be key here. I have to say, if you whipped out your phone while I was describing an architectural idea in a meeting, I wouldn't think you were Googling key terms to keep up. I would think that you had completely tuned out and were dicking around on Facebook. And I would definitely say that you should either participate more in the meetings or not bother coming. — Oct 30 '14 at 22:22

HLGEM 133k25226489 · Answer 2 · 2014-10-29 18:52:31Z

Sitting quietly in a technical discussion is a sure way to get marked as junior or incompetent or not caring about the end result in the minds of the others in the meeting. With 4 years of expereince, you are an intermediate dev not a junior one and starting to speak up and participate in design and technical debates is part of that. So you need to fix this immediately.

First you can ask questions about what was said. Don't worry about looking foolish, you actually look worse by being too quiet. You can says things like, "That seems like an important point, but I am not sure I understand completely what you are saying." Or you can say, "How does that relate to..." and bring up some earlier point. Or just ask the question outright, do not Google in a meeting unless you want to bring up a source that you will present to refute what is being said becasue you think it is wrong.

Next you can be the person who gets the discussion back on track when it is not progressing. You don't need a copmlete understanding of what everyone is saying technically to do this. Just say something along the lines of:
"We seem to be stuck here between what Harry is saying and what Jane is saying. Maybe we should try to list out the pros and cons of each side." Then get up on your feet and go over to a whiteboard and start listing out the pros and cons you have heard for each one and asking others to provide them once you write down a few. And if you hear a proor con that you don't understand, say something like, "Can you explain a little more why that is a pro?"

Sometimes the problem to resolve isn't so much technical as it is business related. So sometimes you need to get the conversations focused on what problem are we trying to solve and how important are the relative factors in making that choice. So while Gary might be right that XYZ will do a better job of solving the problme, Steve's solution might be more feasible in the time you have available and will only be 5% less effective. Now the deciding factors commonly are things like:

Price (for off the shelf stuff)
Developmment time
Effectiveness of the solution at solving the problem
Interoperability with existing code/hardware
Deadlines or Time to Market
Maintainibility
Acceptability to the business (they aren't going to buy a new Oracle database when they have SQL Server even if the Oracle solution is better)
Risk of failure

If you set the priorities of these types of items and can get management agreement as to what they are, then evaluating the different technical possibilities is much easier. This is a step best taken before you start to argue technical details though. So try it first when you have a meeting before people get to making technical proposals. As a hint, what management will set as the highest prioriy is very often not what the devs arguing the technical issues would see as the highest priority and most technical disagreements come down to each party placing a higher priority on something different. That is why it is helpful to set up the priorities of various decision factors as part of the intial discussion of what the problem you are going to solve is. This also helps if you have some people who would like to make business decisions based on what new thing they would like to learn insted of the business needs. Focusing on the real business priorities will help people make better choices.

In my workplace, you need to work for about 5-6 years for intermediate developer title, and 10 years before you will get a Senior prefix, unless you come from another workplace with such a title/experience. — Oct 30 '14 at 9:06
@JuhaUntinen, but titles are meaningless for anything except salary. I know of places that promote people to senior with 1-2 years experience but that doesn't make them actually senior. At 4 years he is no longer a trainee and needs to start thinking in different terms than a trainee thinks is the point I am trying to make. — Oct 30 '14 at 14:03

Tyanna 1,679710 · Answer 3 · 2014-10-29 18:16:46Z

My suggestion is: speak up.

When you start Googling on the spot, stop. Speak up. Say "Sorry, I don't understand that term..." or "This might seem like an obvious question, but..."

By researching when they are talking, it looks like you've checkout, when the opposite is true. Also, there might be domain knowledge from the company/team that you need to know that you're not going to find out via Google.

Don't worry about looking stupid. Asking questions so you understand doesn't make you stupid. If you feel you're asking a lot of questions and are holding up discussions, then write down stuff you don't get and after the meeting ask someone for more information.

I know it can be intimidating, but the more practice you get at speaking up, the better you'll be at it. Right now, it seems like you're still in 'learning the code/product' mode. Ask questions so you understand. As you understand more, you can pipe up more and add value to the conversations at hand.

score 0 · Answer 4 · 2014-10-30 02:25:07Z

You are paying attention during these discussions and I take it that you learn a lot by listening - that's good because there are plenty of people out there who simply don't listen, can't listen and don't know how to listen. So at least, you've got this fundamental right.

You do plenty of digging i.e. research on your own and that's great - you're showing the right kind of initiative.

Having said that, you're probably are going to have to approach your manager, tell him about your gigantic efforts and simply eat some humble pie and own up to him that you are just not quite ready and confident enough to fully participate in the discussions yet. Emphasize to your manager that it's not that you are not good - you're plenty good and pretty good, it's that the others are so damn good :) Tell your manager that you are learning an incredible amount of time and that it's only a matter of time and timing when you'll become a full, active participant.

Think of your coming of age as a professional as a process of maturation. Process the right grapes at the right time and you get wine. Process the grapes too early and all you get is grape juice :) And if you process your grapes too late, all you get is sour grapes :) You do the due diligence and you do it every chance you get, but you can't rush it, and you can't drag it - your mind is not a cram box, and there is a difference between learning and digesting and plain old gavage :)

At least initially, ask some questions since you don't have answers. Especially, learn to ask the kind of questions whose answers, if given immediately by the members of your team, will save you a bunch of time and effort. Yes, you can find on your team the answers on your own and no one should doubt it but the point of asking is to help yourself on your feet and up to speed as quickly as can be reasonably achieved.

NotMe 20.9k55695 · Answer 5 · 2014-11-06 18:25:03Z

Sounds like you actually are "junior relative to these guys." If you don't understand enough to really follow the technical debates without googling them mid discussion then I'm failing to understand how you could possibly think you have valid input for design decisions at all. You simply aren't at that level yet. That's like asking a toddler to create a racetrack when they are just trying to remember left-right-left-right...

The key thing you need to work on is gaining experience and learning your trade; not having your voice heard.

Once you have the knowledge and experience necessary then you'll be able to contribute to these types of conversations. When you are able to talk intelligently people will naturally listen. If you have some good ideas, they'll be acted on.

Now, as to the Sr. guy telling you to get more involved: start studying. Hopefully you are at least aware of the names of the technologies you are dealing with. Spend your nights and weekends really getting to know them.

Also, see if you can take that Sr. person out to lunch/dinner/whatever. Sounds like (s)he is already trying to give you a few pointers. Take it to the next level by having them go into detail about what you guys do. Cover the current designs, pitfalls and war stories. Most Sr people I know are more than happy to impart hard won knowledge to an enthusiastic new guy willing to soak it up. Just make sure you actually pay attention.

Telastyn 33.9k977120 · Accepted Answer · 2014-10-29 18:29:41Z

I often try to keep up with these discussions by instantaneously researching (via Google) while they debate.

In general, this strikes me as your biggest problem. This is bad for two reasons:

People can't really multitask. That time you're spending googling stuff is time that you're not spending following the discussion.

The others see you not paying attention/contributing. This will only add to any perception that you're not participating.

So (politely) interrupt people when you have questions. "Hey, sorry, what is XYZ? I've not run into that.". This provides you quite a few benefits:

The conversation slows down so you can keep up (and the debaters can think, as well as see that others can't keep up - keeping things from getting too heated where it becomes awkward to interrupt).

You learn what they mean by XYZ in this context, which doesn't always line up with google.

You're seen as being involved in the meeting.

The more senior people feel good that people want to learn from them.

There is only one rule: don't ask the same thing twice.

Senior folks know that junior folks don't know as much, and are (usually) happy to answer questions. It (usually) makes them feel smart/important/powerful. And for software engineers, there's very often a compulsion to answer questions, educate people, and/or show off how smart they are. Take advantage of that.

What senior folks generally won't tolerate is wasting time (having to repeat themselves). If you don't get it, then follow up with clarifying questions - make sure you understand, because you won't really have the opportunity to ask again without harming your relationships. It can be okay to say "okay, can I stop by later to understand better?" if you don't want to derail the meeting, but the key is to speak up. Software engineers generally don't begrudge people who are ignorant - they begrudge people who remain ignorant.

It most likely depends on the culture, but I have often encountered situations where senior devs dislike it when you ask anything that they consider easy, even though it may not be easy for the junior/middle dev. This is especially noticeable when a team is 1 senior for each 10 juniors/middles (could be a management issue though, with too much pressure on the seniors). — Oct 30 '14 at 9:01
+1, I definitely think the Googling could be key here. I have to say, if you whipped out your phone while I was describing an architectural idea in a meeting, I wouldn't think you were Googling key terms to keep up. I would think that you had completely tuned out and were dicking around on Facebook. And I would definitely say that you should either participate more in the meetings or not bother coming. — Oct 30 '14 at 22:22

HLGEM 133k25226489 · Answer 7 · 2014-10-29 18:52:31Z

Sitting quietly in a technical discussion is a sure way to get marked as junior or incompetent or not caring about the end result in the minds of the others in the meeting. With 4 years of expereince, you are an intermediate dev not a junior one and starting to speak up and participate in design and technical debates is part of that. So you need to fix this immediately.

First you can ask questions about what was said. Don't worry about looking foolish, you actually look worse by being too quiet. You can says things like, "That seems like an important point, but I am not sure I understand completely what you are saying." Or you can say, "How does that relate to..." and bring up some earlier point. Or just ask the question outright, do not Google in a meeting unless you want to bring up a source that you will present to refute what is being said becasue you think it is wrong.

Next you can be the person who gets the discussion back on track when it is not progressing. You don't need a copmlete understanding of what everyone is saying technically to do this. Just say something along the lines of:
"We seem to be stuck here between what Harry is saying and what Jane is saying. Maybe we should try to list out the pros and cons of each side." Then get up on your feet and go over to a whiteboard and start listing out the pros and cons you have heard for each one and asking others to provide them once you write down a few. And if you hear a proor con that you don't understand, say something like, "Can you explain a little more why that is a pro?"

Sometimes the problem to resolve isn't so much technical as it is business related. So sometimes you need to get the conversations focused on what problem are we trying to solve and how important are the relative factors in making that choice. So while Gary might be right that XYZ will do a better job of solving the problme, Steve's solution might be more feasible in the time you have available and will only be 5% less effective. Now the deciding factors commonly are things like:

Price (for off the shelf stuff)
Developmment time
Effectiveness of the solution at solving the problem
Interoperability with existing code/hardware
Deadlines or Time to Market
Maintainibility
Acceptability to the business (they aren't going to buy a new Oracle database when they have SQL Server even if the Oracle solution is better)
Risk of failure

If you set the priorities of these types of items and can get management agreement as to what they are, then evaluating the different technical possibilities is much easier. This is a step best taken before you start to argue technical details though. So try it first when you have a meeting before people get to making technical proposals. As a hint, what management will set as the highest prioriy is very often not what the devs arguing the technical issues would see as the highest priority and most technical disagreements come down to each party placing a higher priority on something different. That is why it is helpful to set up the priorities of various decision factors as part of the intial discussion of what the problem you are going to solve is. This also helps if you have some people who would like to make business decisions based on what new thing they would like to learn insted of the business needs. Focusing on the real business priorities will help people make better choices.

In my workplace, you need to work for about 5-6 years for intermediate developer title, and 10 years before you will get a Senior prefix, unless you come from another workplace with such a title/experience. — Oct 30 '14 at 9:06
@JuhaUntinen, but titles are meaningless for anything except salary. I know of places that promote people to senior with 1-2 years experience but that doesn't make them actually senior. At 4 years he is no longer a trainee and needs to start thinking in different terms than a trainee thinks is the point I am trying to make. — Oct 30 '14 at 14:03

Tyanna 1,679710 · Answer 8 · 2014-10-29 18:16:46Z

My suggestion is: speak up.

When you start Googling on the spot, stop. Speak up. Say "Sorry, I don't understand that term..." or "This might seem like an obvious question, but..."

By researching when they are talking, it looks like you've checkout, when the opposite is true. Also, there might be domain knowledge from the company/team that you need to know that you're not going to find out via Google.

Don't worry about looking stupid. Asking questions so you understand doesn't make you stupid. If you feel you're asking a lot of questions and are holding up discussions, then write down stuff you don't get and after the meeting ask someone for more information.

I know it can be intimidating, but the more practice you get at speaking up, the better you'll be at it. Right now, it seems like you're still in 'learning the code/product' mode. Ask questions so you understand. As you understand more, you can pipe up more and add value to the conversations at hand.

score 0 · Answer 9 · 2014-10-30 02:25:07Z

You are paying attention during these discussions and I take it that you learn a lot by listening - that's good because there are plenty of people out there who simply don't listen, can't listen and don't know how to listen. So at least, you've got this fundamental right.

You do plenty of digging i.e. research on your own and that's great - you're showing the right kind of initiative.

Having said that, you're probably are going to have to approach your manager, tell him about your gigantic efforts and simply eat some humble pie and own up to him that you are just not quite ready and confident enough to fully participate in the discussions yet. Emphasize to your manager that it's not that you are not good - you're plenty good and pretty good, it's that the others are so damn good :) Tell your manager that you are learning an incredible amount of time and that it's only a matter of time and timing when you'll become a full, active participant.

Think of your coming of age as a professional as a process of maturation. Process the right grapes at the right time and you get wine. Process the grapes too early and all you get is grape juice :) And if you process your grapes too late, all you get is sour grapes :) You do the due diligence and you do it every chance you get, but you can't rush it, and you can't drag it - your mind is not a cram box, and there is a difference between learning and digesting and plain old gavage :)

At least initially, ask some questions since you don't have answers. Especially, learn to ask the kind of questions whose answers, if given immediately by the members of your team, will save you a bunch of time and effort. Yes, you can find on your team the answers on your own and no one should doubt it but the point of asking is to help yourself on your feet and up to speed as quickly as can be reasonably achieved.

NotMe 20.9k55695 · Answer 10 · 2014-11-06 18:25:03Z

Sounds like you actually are "junior relative to these guys." If you don't understand enough to really follow the technical debates without googling them mid discussion then I'm failing to understand how you could possibly think you have valid input for design decisions at all. You simply aren't at that level yet. That's like asking a toddler to create a racetrack when they are just trying to remember left-right-left-right...

The key thing you need to work on is gaining experience and learning your trade; not having your voice heard.

Once you have the knowledge and experience necessary then you'll be able to contribute to these types of conversations. When you are able to talk intelligently people will naturally listen. If you have some good ideas, they'll be acted on.

Now, as to the Sr. guy telling you to get more involved: start studying. Hopefully you are at least aware of the names of the technologies you are dealing with. Spend your nights and weekends really getting to know them.

Also, see if you can take that Sr. person out to lunch/dinner/whatever. Sounds like (s)he is already trying to give you a few pointers. Take it to the next level by having them go into detail about what you guys do. Cover the current designs, pitfalls and war stories. Most Sr people I know are more than happy to impart hard won knowledge to an enthusiastic new guy willing to soak it up. Just make sure you actually pay attention.

Search This Blog

Iyfjky

How to be more assertive within a senior team [closed]

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

5 Answers
5

5 Answers
5

5 Answers
5

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How to be more assertive within a senior team [closed]

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

closed as primarily opinion-based by Jim G., gnat, Michael Grubey, Garrison Neely, NotMe Nov 6 '14 at 18:41

5 Answers 5

5 Answers 5

5 Answers 5

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

5 Answers
5

5 Answers
5

5 Answers
5

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor