I've previously worked in a project where mostly my Team Lead, Project Manager and the Business Analyst would sit together and discuss the business of our project. They'd attend client meetings and takes notes of requirements. Then it's always them three discussing about the business and making requirement analysis. The other developers and I were never any part of it.

Then all of a sudden, one day, I was surprised that my Team Lead told me and another developer to attend one business analysis meeting. I was mostly sitting silently, listened to what the other guys said and took notes. I never expressed my opinions there. I was feeling like I was not really sure what to do there.

My question is, what is actually the appropriate attitude on my part i.e. developer's part in these type of business analysis meetings? Was my attitude correct in the above mentioned situation? How much participation and contribution is expected from a developer in such meetings?

My team lead later hinted me indirectly that he expects more enthusiasm and participation from me regarding attending business meetings, rather than just stick to coding. How right is he? Should I consider his advice seriously? Does this mean he expects to see me in a Technical Lead or Management position in future, so he wants me to get prepared and accustomed to attending business meetings from now?

  • 6
    IMHO most people would perceive the fact that your attendance and participation are encouraged as a good thing. Software development literature is full of stories of requirements that are unworkable, or are unclear but the developer has to go through their manager to talk to the analysts and/or stakeholders. Being able to participate in the process doesn't guarantee that you'll be "heard" but it's certainly better than the alternative.
    – David
    Commented Nov 20, 2014 at 14:45
  • 6
    You seem to think this is strange or undesirable. A disconnect between coders and users is the fundamental reason for poor software. Commented Nov 20, 2014 at 14:55
  • @TheMathemagician I never said this is strange or undesirable. I just wanted to know about this thing as I was a freshman that time and I didn't know many things about industry behavior and practices. Commented Nov 20, 2014 at 15:41
  • Depends on the company I guess. I work part-time at a small place without much technical leadership as the most senior of only two programmers, so despite not officially being a lead or manager they still seem to immensely value my input at meetings. In fact more often than not they're looking to me to take the lead and tell them how we should be doing things. Commented Dec 11, 2015 at 22:45

6 Answers 6


The reason he expects you to attend the business meetings is

  1. to understand the problem domain;

  2. participate in the requirements analysis ao that you understand what is going to be done;

You are not coding in a vacuum and apparently, your team lead expects his software engineers to function as software engineers and not as code typists who are simply told to code. Which is what we expect from a competent team lead.

Your team lead's requirement is a core duty for software engineers. Sitting around like a potted plant and neither asking questions nor taking notes while others are asking questions and taking notes as to what has to be done - that will mark you as as uninvolved and uninterested in a key part of the software development process and count against you.

With respect to taking your attendance at these meetings as a sign that you are being groomed fo promotion, you are jumping to conclusions and getting ahead of yourself.

  • 2
    I like this answer, but I don't think it's complete. A big part of the participation is not just understanding the need but helping to guide the need relative to the technology. Pointing out that a business requirement as presented may introduce too much user friction, inconclusive results or potentially faulty data. But I agree with you. At the core, the lead wants participation not a ficus. Commented Nov 20, 2014 at 13:44
  • 1
    It's also been my experience that sometimes technology decisions are made in these meetings. I was on a project where, before IT ever got involved, a decision had been made to track partner-supplied resources on a spreadsheet (rather than integrate the provisioning and tracking into our software). So in addition to understanding the business need, you can potentially help guide discussions away from premature optimization ("we may want to do it that way, but I'm not sure I understand this aspect of the problem fully, can we talk about that some more?")
    – David
    Commented Nov 20, 2014 at 14:35
  • @Capt.JackSparrow: I don't really know what his problem with you is, but I can take a guess reading your interactions on other questions. My point stands though. You benefit this site more when you vote based on the quality of the answer rather than your personal bias for/against the answering party. If you want to discuss that personal issue, feel free to make a chat room. Commented Nov 20, 2014 at 15:52
  • 1
    @Capt.JackSparrow: You're looking at it from the wrong perspective. If you truly want help and genuine truth/answers, then those are exactly the people you want commenting on your posts. People who "like" you or are trying to stay on your good side aren't going to give you the unvarnished truth. People who don't care who you are or what you think will give you the most honest opinion, advice, direction available. This is the most valuable information you can have. Don't throw it away for something as pedantic as "irritation". Commented Nov 20, 2014 at 16:01
  • @Capt.JackSparrow: Unless a moderator or the two of you have deleted comments, I've read all of your interactions. There has been no hostility, bigotry or even condescension in any of his answers or remarks. In fact, the only hostility I can find anywhere in any of it is in your remarks. Perhaps you can point me to an exchange that shows differently? Maybe then I would have a better understanding of what you mean. Commented Nov 20, 2014 at 16:16

All technical people should be ready to participate fully in requirements definition. When no technical people are consulted you get requirements that are too vague to be useful in developing code or requirements to do something specific when it won't solve the actual problem they have or all sorts of other things.

What you bring to the table is twofold, your knowledge of how programming in general works, what is and isn't feasible from a purely technical standpoint and your knowledge of how the current system the project is being integrated into works or your knowledge of the system that is being replaced. Both are invaluable in determining requirements. You can keep them from going down a wrong path.

But there are other reasons to be there and to participate as well. IF you have ever played the childhood game of telephone, you know that the message deteriorates the more people it passes through. By being in on the meeting, you know what was actually said and how others in the room interpreted it. This keeps you from getting a poorly passed on message. You also start to see the business reasons why things are being asked for and start to develop an understanding of the business domain and can start to think of how you can solve the actual problems they have rather than what they said in the formal requirement.

If things are unclear to you, then you can get the information from the source not passed through 12 people when you ask a question later while you try to implement. This helps prevent deterioration of the information so that Client A wants problem B solved but by the time the message gets to you it has morphed into problem ZQ. This greatly increases your chances of building what they need instead of what was told to you after passing through many people. If you are developer, you should be fighting to be included in these meetings. Any place where devs are excluded is doing it wrong and will have many more bugs than they need to have You don't want to waste time solving the wrong problem.

Next you have a chance at this stage to influence the direction of the project which is also invaluable. Ask any very experienced dev how often they have been forced to build something stupid because no one could clearly communicate with the ultimate users.

You can stop account managers and BAs and other people from promising what can't be delivered in the timeframe. It is often too late to protest the schedule after it has been agreed on in a meeting like this. You can point out all the things they haven't thought of that this will involve so they understand why the timeline doesn't work.

I have seen a group of people think that a change must be simple because how hard can it be to add a button to a form. It never occurs to these people that the button won't do anything unless someone defines what it will do and then builds the underlying structure and code to make that thing happen.

Having devs in a requirements meeting to explain how difficult some task might be can often prevent you having to work the next 12 weekends in row and 14 hours days for weeks on end to meet a deadline designed around the idea that this was something easy to do.

You also get to ask questions abut the less common paths through the software. For instance, they say they want to institute an approval process and then define how that works. I have never seen a group of non-programmers define what to do in that process if the approval is turned down, yet most competent devs will need to know that has to be defined because every dev knows that when you have an IF branch, you should be handling more than one case.

From a career perspective it is important for you to actively particulate as well. The people in these meetings are often the people who have input into raises and promotions and bonuses. You want them to have a good impression of your professionalism and your technical ability based on the things you bring up. Remember most of these people will never see a line of code and they are part of the process that allocated limited budgets for pay and bonuses. The only thing they will know about you is what they learned in these meetings and any emails you send and anything they hear about you.

If they only thing they heard was you built the part of the project where there was a bug they found painful (but you saw as minor because it took minutes to fix) then they will think you are incompetent if they have no other way to judge. They have no basis for determining how good a dev you are except these meetings and any issue that gets escalated. Don't make the escalations be the only thing they know about you.


The developer's role in these meetings is what you make of it. It can be insight into customer preferences and requirements (if you have them), insight into costs and tradeoffs of proposals, and so on.

If you have opinions, or questions, you can go ahead and voice them; that's why you're there. It may be safer to voice opinions as questions ("this may be obvious, but have we considered..."). If you aren't sure you can get away with that, you can certainly give your team lead feedback after the meeting and ask whether you should have brought it up at the time.

Even if you aren't headed toward technical lead or management any time soon (or ever), it's useful to have some exposure to and understanding of the business planning process. And it's sometimes helpful for them to have someone around who isn't yet infected with group-think and can ask the questions they've been ignoring.


I think for the first meeting or so, it was smart to take notes and remain quiet. You should know how things work. It's better to remain quiet and people think you don't know what is going on, than to open your mouth and prove it.

Taking your boss's feedback into consideration, if you have a comment, recommendation don't hesitate. Definitely ask questions to help your understanding.

Hold a separate meeting with other team members who may or may not attend, so you are all on the same page. You don't want to be contradicting each other in the meeting nor do you want to have to return to the next meeting and withdraw an incorrect recommendation that could have been avoided by consulting your team initially. This is what your team is for.

This is a great opportunity to have a voice in the project and some control over the requirements and expectations. Often some would will suggest a "nice to have" feature and by the time it reaches the development team it turns into "If we don't implement this immediately, everyone is fired." You can be a great service to the team by being involved in these meetings.


Many managers in my country (aka business analyst) think developers should stay coding and never participate to those kind of meeting because talking to the final client is a privilege of the "leaders". Ok I am exaggerating a bit but this is the idea.

However I have experienced that knowing the stakes and expectations from the client directly (and not repeated, deformed by your managers) help us a lot to define our priority in our effort to build quality software for them. Moreover knowing what the client needs from a final user point of view and having even a glimpse of the business practice is crucial to deliver the right technical parts of a projects expected from the client.

Lastly I have always found rewarding to feel involved in the construction of a software solution from the analysis to the definition. Even better when you know the person who will use the piece of software your are working on makes a lot of difference in the end because you end up feeling obliged to deliver the best you can.

I have found on several occasions the client asking questions to the developer attending the meeting. The client knows that developers don't lie when they ask them about the feasibility and the cost of a feature so that in some way if your manager wants to hide the truth they should not invite you ...

  • What is your country? While it seems to be a big deal in your first sentence, you never state which of the couple hundred or so exist in this world it is.
    – JB King
    Commented Dec 11, 2015 at 15:44

As a developer, with possibly considerable intelligence, and possibly considerable experience implementing what is given to you, you probably know better than anyone else what the cost of some decisions will be. For example, if the client says "A would be Ok if we can't get B, but B would be nicer to have", then you might be able to say that the cost of A and B is the same or almost the same, or B would actually be cheaper (making everyone happy), or B would be very difficult and costly to implement (and the customer could get a lot more benefit if the time and money is spent elsewhere).

As a developer, you know everything about workflows, and you can tell which suggested workflows just won't work. You know where a suggested workflow contains an unmentioned step "read the user's mind".

As a developer, you know when you get requirements that you just know are going to change and produce unnecessary work, and you just know which people are going to change their mind.

Of course if some manager thinks he or she knows it all and you are just a stupid coder that shouldn't be listened to, that's their problem (you keep your CV up to date).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .