I'm a software developer in a 30 person company specialized in financial technology. I started to work here early this year. Over time I heard that the company tripled their employees in the last 3 years. The working organisation can be described as "start up mentality" at best. There is a lot of floor project management, you suddenly get tasks on the kitchen an so on. Every developer does what needs to be done next, regardless of strength or weaknesses or experience. But the strangest thing is, every developer works alone on 1 full fledged software development project, complex enough, that no other developer can take over in case of illness. Also a project can only move further if the specific project developer is available. Depending on the years a developer worked in the company, it can happen, that 4 projects needs this one specific developer resource, if the clients make change requests.

I learned agile project management in a big company, and I love it. I learned a lot about project management by myself and got some minor experience in it, so in my year end talk with my boss I proposed to him, that I think we need to start working in teams. He was skeptical. I crunched the numbers in front of him, why working in teams benefits the company and counted the different soft-skill improvements, teamwork in software development gets you on top.

At the end he declined it all with the expression: this all just sounds like putting 2 man on the same job position, which is uneconomical and our small business can't afford that.

I was so perplexed the hear the answer of "2 man on the same job position" on advocating teamwork, that I just silenced.

I like to work here, but I hate how we work while I see how we could be so much better in everything, if we could start to clearly organize the company and work together and not just somehow work next to each other.

How can I convince my boss that teamwork isn't "2 man on the same job position"?

  • What's your capacity in the role place? Are you a manager or one of the developers working on a project solo? Commented Dec 5, 2019 at 9:50
  • "startup mentality" is just a new word for non-organisation. Having to defend knowledge sharing like you do is nowhere near a startup mindset...
    – Laurent S.
    Commented Dec 5, 2019 at 10:06
  • @JayGould im one of the developers.
    – Mintri
    Commented Dec 5, 2019 at 10:54
  • @LaurentS. i just couldn't come up with a better wording :)
    – Mintri
    Commented Dec 5, 2019 at 10:54
  • 1
    Instead of focusing on changing the workplace, focus on what you can learn. Once you feel that you're no longer learning, or your frustration is simply unbearable, leave, and find a more structured company. Problem solved.
    – AndreiROM
    Commented Dec 5, 2019 at 17:21

6 Answers 6


Bring up the Bus Factor

One person working on a bit of software means only one person knows the internal workings of that bit of software. What happens if that person gets hit by a bus? Leaves the company? Is fired effective immediately? Is ill? Is uncontactable during a crisis?

Life happens, and reasons why a single person is no longer able to work on projects, either temporarily or permanently, are both plentiful and common. Having at least a second person on that job is a good insurance policy against modern life's eventualities.

Look at the development of VKD3D, a DirectX12-to-Vulkan compatibility layer. Their project founder and one of their lead programmers, Józef Kucia, who was 30 at the time, had a fatal accident while exploring a snow-cave (Jaskinia Wielka Śnieżna) in the Tatra-mountains (Poland) earlier this year.

If he was their only developer, the entire project would have been screwed; the project is far too complex for someone to simply pick up without any sort of documentation, which if you are the only person working on the job, you simply will not have time to do.

  • 1
    i brought up that point. But my boss believes in our expertise. Well i showed that i can somehow catch up to an 10 years old project with horrible legacy code and almost 0 documentation. we have 2 seniors who are with the company for over 10 years, in total the company is 13 years old. And without my boss being arrogant, he made the point that somehow it always works out the one or the other way, and 13 years of growth and success can't all be wrong.
    – Mintri
    Commented Dec 5, 2019 at 11:01
  • 3
    None of that is going to matter in a crisis. If you need a critical fix and your client needs it to be done right now, you cannot just assign people to a job and wait for them to catch up. You may have been able to eventually catch up with a 10 year old project with crappy code, but could you do that in an emergency scenario? The thing about luck is that it eventually runs out. When it does, you need a plan B Commented Dec 5, 2019 at 11:13
  • 1
    i completely agree with you. i kinda seethe achievements of this company comes from 60 - 70 hours work week of my boss, a hand full of really local and dependable dev's and a lot of luck, nothing serious ever came up. but this hardly can be called success by method. i kinda feel like in a situation where i try to tell a kid. not to touch the fire, bc its hot. As long as there is no accident to react to. He seems like the cold analytic overachiever type of person. And telling clients, that a project needs to freeze some time, because of a accident is cheaper than 2 man on the same job position.
    – Mintri
    Commented Dec 5, 2019 at 13:03
  • 1
    Well, like the kid who wants to touch the fire, he's just going to have to learn the hard way. He will learn one day that actually his cost/return maths is simply not adding up; not only can two developers cover significantly more ground than one, it also means that fewer bugs make it into production because the tester isn't marking their own homework and it's much more likely that you'll have someone able to respond in a crisis. If a big security vulnerability is found in the products, clients won't accept 'freeze time'; they will stop using it and blacklist the company from future contracts. Commented Dec 5, 2019 at 13:25
  • 1
    @520saysReinstateMonica Though I fully agree with your answer, let me correct a detail or two about the bus-factor..
    – iLuvLogix
    Commented Dec 5, 2019 at 15:01

You won´t change the company culture over night!

Let´s face it:

  • you are 1 of 30 employees, most of them are probably used to or even liking the way it´s done now
  • You are not in a position of power (Manager etc.)
  • You are hired to do a different job (Development)
  • You are fairly new to the company

So the weight of your opinion is fairly small. Ask yourself this: If I could not change this part, do I want to continue working here. If no, start looking for another job. If you still like to keep the job, prepare for a long journey.

You can influence the company culture over time and little by little. But you won´t change them over night and you will never get 100% of what you think should be done.

I suggest you take baby steps to improve collaboration. Chat with your colleges an see what they are thinking. Maybe you can introduce coding standards? Weekly standups to at least get an idea what the others are up to? A wiki for known problems ... etc. Small things that do not frighten your boss but improve teamwork a little.

Also, if there are obstacles and difficulties that can be attributed to bad development practices you can report them. Don´t play the blame game though. Always stay neutral, matter-of-fact and suggest actionable improvements. Nobody likes to hear a doomsday prophet ramble on about how bad everything is.

Some day, something will go really wrong - especially if the company keeps growing like that. If that happens, hopefully you will have established yourself a forward-thinking and full of ideas for improvement. Resist the urge to say i-told-you-so! Offer your help!

If you are prepared to put in a lot of extra effort and a lot of patience with little expectation of returns you can actually sometimes move something. I suggest you read up a little on the topic: "leading from below"

  • 1
    never thought about "leading from below" definitely will look it up, thanks. I'm working almost a year in this company now. I didn't notice all this in the beginning, since there was a lot to do day 1, but my developer brain can't stop to try and optimize things. Now it's kinda like a dealbreaker for me to add up on other things not really happy about, but since i rather fix stuff than rebuy i tried my best to fix the situation. But it doomed me, that this will introduce my farewell in this company. thanks for the great answer!
    – Mintri
    Commented Dec 5, 2019 at 14:58
  • 2
    @Mintri I hear you, about the "rather fixing stuff" but unfortunately changing an organization can be quite a daunting task even when welcomed by the management. That´s why there is a whole field called "change management". Excpect a lot of work and frustration and not much thanks for it. If you succeed though it can also be very rewarding and get you ahead in your career. I wish you luck!
    – Daniel
    Commented Dec 5, 2019 at 15:06

Also a project can only move further if the specific project developer is available. Depending on the years a developer worked in the company, it can happen, that 4 projects needs this one specific developer resource, if the clients make change requests.

Find examples where this went wrong and give them to him. Also argue that if a developer leaves, all knowledge of that particular software project leaves in the current setup. Those all cost money and maybe then he will see the advantages.

Edited after comments:
But in the end, if your boss comes with irrational arguments, then you can't convince him with rational ones. It might also be that he has good reasons but can't or simply doesn't want to explain them. In the end it is his decision. So be prepared if the answer stays no.

  • 2
    There may be rational arguments which the boss did not express or the OP did not cite. There is valid reasons to oppose Agile, and reasons why it's overall more effective to have people work on single projects. Of course there are disadvantages as mentioned, but so are disadvantages to any of OP's suggestions. It's a choice either way, and it's the boss'es one to make - which apparently he already made quite a time ago.
    – Battle
    Commented Dec 5, 2019 at 9:58
  • @Battle I agree that there are pros and cons to agile. I did not want to suggest that refusing Agile is irrational in itself. but saying: "2 man on the same job position" does sound like an irrational reason (or fallacy, english is not my primary language) to me.
    – user180146
    Commented Dec 5, 2019 at 10:03
  • 2
    Well, mathematically you can see it this way: 1 person working on one project, 100% efficiency. 2 people working on one project: Each 80% efficiency. 3 people - 65%, etc. It can go down by having to adapt to each other, communication, code work related issues, etc. A challenge is often to minimize that loss by various means like code review in the case of many developers, or just having a proper code/project structure. All of that still has a cost in one way or another. Also, what about one of the two people not being able to work in his field of expertise?
    – Battle
    Commented Dec 5, 2019 at 10:39
  • i brought up that point. But my boss believes in our expertise. Well i showed that i can somehow catch up to an 10 years old project with horrible legacy code and almost 0 documentation. we have 2 seniors who are with the company for over 10 years, in total the company is 13 years old. I see were his position comes from. And without my boss being arrogant, he made the point that somehow it always works out the one or the other way, and 13 years of growth and success can't all be wrong. But just because there was no major accident yet.
    – Mintri
    Commented Dec 5, 2019 at 12:55
  • i don't see this wild growth work, also because we are going to shift our field of operation from service orientated to software product development, but maybe im just seeing things too dark.
    – Mintri
    Commented Dec 5, 2019 at 12:55

“...2 man on the same job position...”

Looks like one (or both of you) are assuming “Agile equals Pair Programming”. You need to clear that up on your next conversation about the topic.

The primary thing that needs to be considered is the fit of your company’s operating model and the Agile implementation that you’re thinking of (XP, Scrum, etc). For example, if your business model involves bidding X project hours/dollars to win a customer project then it’s better to stay away from pair programming because that increase in software quality and knowledge sharing/resiliency, will cause you to bid higher than your competitors that aren’t doing that. That’s going to leave your company in an unpleasant economic position.

If your group however, is working on a product - a thing that you sell over and over - I’ve seen a lot of successful products built using Scrum techniques.

To summarize, to advocate for teamwork, you would need to advocate for an approach (e.g. XP, Scrum) that fits your business model / economic viability. You will have a tough time pitching an approach that ignores the environment that it’s going to operate in.


Any question that starts off with,

How can I convince person X of ...

is hard to answer, because none of us really know what motivates your boss. So, while we can provide ideas for specific arguments you can make, we can't really understand if those arguments will actually help or not. As you've noted, some bosses will reject what appears to you as a sensible argument.

The good news is, you can follow a process to answer this question yourself. The key to convincing someone of something is to understand their perspective. The mistake most people make is that they try to argue for change based on their own perspective. While it can be important to enact change that will help you personally, you will be much more effective if you can frame it from the other person's point of view.

If you want to have the best shot at convincing your boss to make a change, take a step back from your current arguments and do the following:

  • Make sure you understand your company culture. If there is any (official or unofficial) strategy, mission, or other overall framework, make sure you understand it.
  • Observe your boss and reflect on what motivates them. Do they align with the company's goals? Do they have any personal motivators? Things they're interested in, or afraid of?
  • Set your own arguments and your own motivations aside.
  • Make sure you can clearly articulate the problem at hand, and the change you want to make, in a way that will make sense from your boss's perspective. Be able to state the problem in a way that will make sense to them, and tie your solution to their motivators.

If your boss is happy ignoring the "bus factor" then you probably won't win by arguing for change because of single points of failure. However, maybe your boss is motivated by reducing bug tickets, or meeting turnaround times, or throughput of tasks, or some other factor. Maybe there's even a measurable metric they care about! Or, at least, a soft factor that you can tie your change to.

By making the relationship between your change and their goals as clear as possible, you will be more likely to get what you want.


Teamwork is usually not desired by the company itself but it's requested from the outside, namely the customer who buys the products. The interface to the external world is usually located in the marketing department. If the aim is to introduce teamwork for software development this is equal to let the marketing department control the technological decisions.

A good starting point is a customer request which can only be fulfilled if different departments combine their strength. If one developer isn't motivated to work in a team, he can report direct to the customer and explain to him, why the task can be solved by a single person much better.

To introduce team work for a software development project it is important to know, that not longterm engineers have to decide which kind of software is required, but the customer. Talking to the customer, ask for his needs and communicate it back into the company is a management obligation and will result into a collaborative atmosphere.


You must log in to answer this question.

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