The question seems to have an obvious answer for most you but stay with me for a while...

In the world of agile Scrum which is nowadays the top used software development methodology either as-is or in the hybrid model, the roles inside the realization team are not clearly defined.

I am a software developer the 3-4th year and I have encountered only with companies (working, interviews, heard-of) where software developers are heavily involved in various things aside of the programming - completing feasibility studies, analyzing business requirements, drawing forgetting the diagrams, writing technical specifications, discussing architecture, involving into DevOps (yet another field of study I believe) and finally... programming.

These actions require a strong understanding and knowledge of the business and most of its rules. ...right, a good documentation memory truly helps! On the other hand, the industry and the market require the developers to educate themselves and learn the newest technologies, standards, language features, architecture and communication patterns, protocols and experiment with such things. But... how are we supposed to become expects in everything? (Consider DevOps as another field of study of a large set of skills.)

I believe that being a software-developer means primarily writing the code according to the given specifications. I feel the more the software developer is involved in such things, the less quality and maintainable code are able to write and the less the overall knowledge of architecture is... and of course, these would heavily impact the product.

Don't get me wrong, although I love programming which is the reason I became a software developer, I understand the importance and brief knowledge of the business requirements and rules and I am interested in why and what I do. Without it, there would be nothing to develop. However, I believe the involvement should be just basic, otherwise, it would not only harm ourselves but also the product, since most of the knowledge would be kept with the software-developers and they would become both irreplaceable in the team and also their programming skills decrease rapidly.

Here are my favorite lines from Code Ahead (pages 181-182):

"So, you are saying that all developers should be stupid code monkeys, who don't care about the business at all, only about the code?" Masha asks.

"You just offended us both," Dennis laughs. "Coding by itself is as much fun as your business, For me, to be honest, it's much more fun".

"Really?" Masha seems surprised.

"Yes!" he exclaims. "I would be absolutely happy if you keep me out of your business concepts and ideas and just tell me what needs to be implemented".

"You guys don't want to know why we need what we ask you to implement?" she is really surprised.

"Absolutely not," I smile. "Do you want to know how we implement those features, what frameworks we use, what database optimization techniques, what programming languages, and all that?"

"No, leave me out of that," now she smiles.

The reason I ask is as a middle-level developer who aims to become a senior sometimes... I involved in business concepts first as much as I could, and I became a valuable member of the team but I felt no career improvement or whatsoever. On the other hand, I isolated from the business concepts at some time and level and it helped me to grow technically really fast and I succeed in a lot of interviews fairly easily. However, I felt like absent at meetings while discussing business stuff, and I often questioned my worthiness for the team in this case - I overexaggerate a lot, but you get the idea.

How should I approach in the case I am very technically inclined in a team among software developers knowledgeable of business (I struggle a bit to understand) for years decades to feel more comfortable and self-confident?

The strikethroughts are intentional.

  • 2
    Interesting thing you ask Nikolas! However, I feel 2 things: first, this seems more related to scrum practices and software development than to how to navigate the workplace (perhaps you can rephrase this to be a great question on Software Engineering SE), and second, the three questions you include in bold I believe can be answered by "depends on the company and it's culture"... do you think you can edit your post to address these points?
    – DarkCygnus
    Commented Jan 23, 2020 at 23:54
  • @DarkCygnus: Thanks for the comment. I admit my question is rather emotional and I tried to lean against the agile concepts that are trendy nowadays to give the readers idea what my question based at. I consider rephrasing the question to “how should I approach in “agile”-alike company when I am technically incined?” and ask the similar question on Software Engineering SE aiming question to the methodologies. What do you suggest? :) Commented Jan 24, 2020 at 0:03
  • I added an answer nonetheless, as I think your post is answerable. You could perhaps consider posting this in Software Engineering SE also in case you want a more technical or software-oriented point of view on the subject (here you can get the workplace and professional POV). Just be careful not to post it exactly as it is here, as cross-posting is discouraged in the Network
    – DarkCygnus
    Commented Jan 24, 2020 at 0:07
  • 1
    "It would not only harm ourselves but also the product, since most of the knowledge would be kept with the software-developers and they would become both irreplaceable in the team and also their programming skills decrease rapidly." How? Can this information not be documented and transferred to others? Why would having business knowledge cause your programming skills to decrease? Commented Jan 24, 2020 at 1:49
  • 3
    This question is rambling and loaded. It is essentially an argument that programmers should have no interest in the business of whatever company they work for, and phrases this as a question about how to be more confident about this attitude. Consider that your attitude is wrong, and that if you have no interest in the business side of things, perhaps you should get a job in which this is not required. Commented Jan 24, 2020 at 10:43

5 Answers 5


This really depends on your value proposition as a contributor to the organisation.

Do you only view yourself as a programmer/coder who can build a given requirement/solution. Or rather the broader value of an engineer who can use his/her strong problem solving skill set to help the organisation solve business problems using technology.

The narrowly focused role of a coder is easily replaceable with a multitude of cheap remote workers that can work in a detached and isolated way to the rest of the organisation. While the cross-functional engineer who brings much more value to the organisation will be much more valuable and potentially will contribute to not only problem solving, but business growth.

Whichever you decide you are. Just keep in mind that it defines your perceived value and henceforth your compensation and future career growth.

  • Good answer! I would like not that isolation and I usually involve as much as I can although I am really not good at it. Also... shouldn't the business growth be assured by problem-solving through the clearly defined business requirements and a definition of done on top of a stable architecture and strict CI/CD pipelines? Commented Jan 24, 2020 at 15:42
  • Business growth can happen for many reasons. Least of them would be stable architecture or defined requirements. Think what would be the result if you took an interest in optimising UX of a certain process/form and made it easier for the users? Yes, that may result in business growth. And many other ways when you combine your technical skills with business knowledge and think independently of how you can improve the overall process
    – Bishoy
    Commented Jan 24, 2020 at 20:04

This is a very interesting question. If you work for a place that does the more classic waterfall with big, up-front design, business analysis, requirements specifications etc. then business knowledge is less useful as your work is largely all prescribed. A working knowledge of the business allows you to perhaps better understand ambiguity and possibly find flaws in the solution but unlikely to allow influence.

Agile offers the opportunity to use a different skill set. A knowledge of the business allows you to better understand the overall goal. In turn this allows you to contribute and anticipate the future direction of the product/system as a whole. You can make your own suggestions as to how things should behave and perhaps even suggest useful product features. That may or may not be interesting or important to you.

Advice: Know yourself. If you prefer technical only, find somewhere that offers it - probably larger organsiations. If you want the latter, more holistic blend, go smaller.

From your post I sense you'd be more comfortable with the former. Personally I am the latter.

  • Good answer! Personally, I'd hate to have a job where my ideas aren't valued and I'm told to shut up and code but it's good to know there are people out there who might prefer this. Commented Jan 24, 2020 at 1:52
  • Commenting as it doesn't add too much directly, but Agile tends to act like the only other methodology is Waterfall. It's really not true, and Agile doesn't stand up as well to other methodologies, which is probably why they focus on the strawman of Waterfall. Of course the other methodologies are not always better than Agile in some aspect, nor are they worse than Agile in some other aspect; but, if your comparison is "against Waterfall" it almost sounds like Agile has culturally won. tatvasoft.com/blog/…
    – Edwin Buck
    Commented Jan 24, 2020 at 3:51
  • @EdwinBuck I totally agree. My point was intended to highlight a) that there is a spectrum from "do what is asked and you can only contribute if you are a member of the Big-Cheese-Product-Development-Steering-Committee" and "everyone can contribute if you know enough about what we're trying to do - hell don't even ask". b) Find your place on the spectrum and go somewhere that does that. It's actually more likely to be driven by a blend of cultural and process than pure process. Commented Jan 24, 2020 at 5:10
  • To the advice: At the interview, you are usually not capable to get an idea about all the responsibilities of the offered role. How should I proceed in the case all the developers in a company involve a lot on the business side of things and I know it's rather my weak part? I'd love to try and learn, but I know my strong/weak side and things I am useful/strugging. Commented Jan 24, 2020 at 15:48
  • @LoztInSpace Thanks for the confirmation. I know someone who's team uses 100% waterfall (gasp!) Not me, but their team doesn't kill kittens and their members don't jump to their deaths off buildings. You see, they do fixed-bid contract programming, paid on delivery date. The kind of work the government typically subcontracts. You build to spec, even if the spec is wrong; because, otherwise you go to court to argue you should get paid for delivering what wasn't requested. Yes, it's not the mainstream (and probably not the best approach), but other methodologies just don't work as well.
    – Edwin Buck
    Commented Jan 25, 2020 at 15:57

A person working in any creative knowledge profession -- developer, doctor, product designer, architect, planner -- is most effective when she/he asks the question why? If you don't know why you do what you do, how can you create the best possible result?

If you know why your software product must do certain things, and who it will serve by doing those things, your product will be better, and your job will stay interesting to you for decades.

Methodologies and tech stacks come and go. Good businesses outlast them. Your career will outlast them too.

The more you know about the challenges faced by the businesses you serve, the better you can serve them.


Software development doesn't happen in a vacuum. Developers are paid to write software because there is a business need that must be met.

All of the technical skills in the world aren't worth much if you can't use them to deliver on what the business really needs. How can you do that if you don't have at least some knowledge of the purpose of the software? Specifications and design documents often miss or leave out the finer details that need to be implemented and you will need to understand the business to make the right decisions when implementing those pieces.

In my 30+ year career as a developer in numerous industries, I have yet to find a job I didn't do better after I learned more about what the business was about.


Already included in a comment what I think, but two things I can say to these questions:

What is the point of view of Scrum agile culture on this issue? What is the healthy balance?

As your very same question says, this depends on the culture. And the culture depends on each company.

Some may have their developers get more involved in business stuff, and some other may not (just like you have witnessed so far).

The healthy balance will depend on each company/culture pair, but surely knowing at least some business stuff is better than a developer with no knowledge of that at all...

How should I approach?

Being realistic, unless you are in a managerial position or have some saying in how the culture/practices are, you can't change anything here.

The best you can do in a situation like that is try to adapt your best to the current culture, and also try to seek companies/jobs that match with your style and culture (or reach a senior/managerial position so you can have a say on the culture/practices of the company ;).

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