69

I’ve been working in an IT company for 7 years (and I have a 14+ total work experience). About 2 years ago I was promoted to the solution architect's office. In my company a solution architect is a very senior role that requires both strong experience and solid competencies: at least 10 years work experience in IT, at least 2 years work experience in the company, competencies of skilled senior developer, senior team leader, knowledge in system administration, project management, strong abilities in functional analysis and documentation, good in relation with customers, etc.

My job can be described in this way: a manager arrives with a request from a customer for a new project. We meet the customer, we collect requirements, we write the technical section of the offer that the manager presents to the customer. If the customer accepts the offer, we prepare a detailed document (or a series of documents) to describe every single technical aspect that developers should know to implement the solution for the customer (the document contains language(s) to be used, framework(s), software required and the architecture, both logical and physical, how to interact with customer/third party services, roadmaps, milestones, a complete functional analysis for the technical aspects, etc. - documents length and depth depend on expected elapsed for the project: a 4 years project could have 1500+ documentation pages, a 2 week projects no more than 15-20 pages). When these documents are completed we send them to the managers and they present these to the development team(s) involved, during the project kick off meeting. According to the expected elapsed of the project, the development team has a period during which can ask for clarifications/explanations for the documents. After this our job is completed and we move on to the next project.

We do not have direct (in person) or indirect (mail/phone/chat) contacts with developers (we are even in a different office than them): all interactions are through managers.

During last year HR and some managers informed us of a relative high number of complaints from junior and middle level developers about our way of work: in particular they say that we “impose from above our solutions” and they “are mere performers/monkeys typing on the keyboard”. No complaints from senior developers (and when I was a senior developer I really appreciated the fact that we only need to build the project software architecture and then start the fun part: write code).

We were asked to think of suggestions to better present our work and improve their perception of us. I have really few ideas: what do you suggest?

3
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – user44108
    Jul 31, 2019 at 6:25
  • 28
    It might be a good idea to include why you think you're adding value; what are the benefits you're trying to sell to the developers?
    – Luaan
    Jul 31, 2019 at 7:39
  • 4
    As an architect you are probably supposed to do a stakeholder analysis and the stakeholders concerns need to be considered. The developers are stakeholders. Your process makes this part of your job practically impossible.
    – qznc
    Aug 18, 2019 at 12:28

12 Answers 12

237

During last year HR and some managers informed us of a relative high number of complaints from junior and middle level developer about our way of work: in particular they say that we “impose from above our solutions” and they “are mere performers/monkeys typing on the keyboard”.

Well, that's hardly surprising given that that is exactly what you have described your role to be. If the documents contain what you said they contain and it's binding, you have basically split your software engineers into "solution architects" and "typing monkeys", one group making all the decisions and one group basically typing them out and compiling them.

Apparently, that is how your company wants it to work. I don't think there is much you can personally do about that criticism, assuming that you understood your role right.

Your company needs to be prepared that the people they hired to be typing monkeys will not wait to become a mid-level typing monkey and a senior typing monkey before they are allowed to ascend to solution architect and actually do some software development. They will go to a company that allows them to do their full job. Quite frankly, I don't see how you would hire for that position inhouse either. How would a typing monkey ever get the experience and skillset you quoted as required to become a solution architect? Certainly not by typing other people's code.

So yes, they have a point. But assuming that you did not define your job yourself, that's not a beef with you, but with the organization. But just do an experiment in your head: what would happen if you did not force the choice of language and framework on the developers? Would it still work? If so, why do it? If not, why not? I think those are questions only you can answer, but they might help a lot in understanding the complaints.

16
  • 78
    @AFalluj This isn't your fault, but I've rarely heard somebody in a dead-end job say that they prefer having no career path because it lets them do their job "without pressure". I wouldn't be surprised if this disconnect is where many of your juniors have an issue - they expected to be a software developer with career growth, but as it turns out, your company wanted people who type well and who don't aspire to making decisions. (Again, problem with the company's hiring/what they tell people - not your problem personally).
    – user81330
    Jul 30, 2019 at 12:22
  • 131
    If 90% of architects are outside hires then either you hire people who are not very good, or you stop them from growing into a position where they are the architect, or you ignore the talent that you have. No wonder they are complaining. And if they are any good, they will be leaving.
    – gnasher729
    Jul 30, 2019 at 14:21
  • 27
    @gnasher729 I concur. 1st thing I thought after reading there is no complaints from seniors was the survivor bias. The company makes people wait 10 years before being brought on decision making deck. Most of them are probably capable sooner. OP stance confirms it, they were happy not to have the responsibility most people aren't. Anyone fit for the role probably burnt out. I wonder how much experience the outside hires have. If less than 10 years it would be even worse, though more obvious. This is company culture and development process issue.
    – luk32
    Jul 30, 2019 at 15:46
  • 29
    I agree with the others. The reason why no senior developers are complaining is because the only senior devs you have left are ones who are willing to put up with the current (terrible) culture.
    – 17 of 26
    Jul 30, 2019 at 17:49
  • 36
    @AFalluj But that's the survivor bias luk was talking about - there are always people who do not want more responsibilities, people who prefer a stable job to a fulfilling one, rote work to challenge. There's nothing wrong with that. You just have to keep in mind that these are the people you're selecting for with your company culture. That's a business decision, it's fine as long as it actually serves the business goals. Just don't be surprised that you're not going to retain juniors who want more, and that you get complaints from hires who expected something else. Check your hiring process.
    – Luaan
    Jul 31, 2019 at 7:45
88

We do not have direct (in person) or indirect (mail/phone/chat) contacts with developers (we are even in a different office than them): all interactions are through managers.

That's the root of your problem right there, IMHO.

You're not going to convince developers who are complaining about being left out of the loop in all key decisions, that this is the way things should be. They don't even know you and somehow they're supposed to trust your judgement implicitly?

Why not make yourselves available, find ways to interact with them and explain yourselves and your decisions? It won't cost you much, and it will increase trust and motivation amongst those who are responsible for implementing your work with a high level of quality.

Project managers can still pretend that the boxes on their gantt charts have crisp lines. There's nothing to lose if you simply increase the level of interaction with the developers.

6
  • 22
    @AFalluj, OK, you said that it's not in the company culture to visit with other teams. Does that mean you cannot do it? What will happen? The fact that your management is relaying the discontent of the developers means that they want you do do something to address it. So you won't do any harm by at least opening a dialog with the implementation staff.
    – teego1967
    Jul 30, 2019 at 12:05
  • 62
    @AFalluj If I were trying to make up the most toxic description of how a software company works as an example of a toxic workplace I wouldn't even approach what you're describing as I'd think its too ridiculous to believe its real. Your company is FUBAR. At this point there's no fixing it, there's only escaping it to sanity. Jul 30, 2019 at 19:03
  • 12
    I don't think talking with the developers is going to change the company situation. After all, their code monkey opinion is worthless and the godly architects will move on to the next project anyway. Voicing your opinion doesn't feel good when noone is listening. Jul 31, 2019 at 6:42
  • 6
    @pytago, that may be the case. However, if the OP wants to change the situation it will involve communicating more with the developers. It's a first step, and it gives him a way to at least address the prime concerns.
    – teego1967
    Jul 31, 2019 at 10:33
  • 6
    @pytago Talking with the developers makes you stop thinking their opinion is worthless and the architects are godly, that's the point.
    – user253751
    Jul 31, 2019 at 23:04
51
  1. No direct or indirect contact between architects and developers - this has to change, there is no way around it. If there's not even email contact, there's not going to be any trust between the two teams.
  2. Solution architects need to also be (senior) developers, and all developers need to be involved in the architecture, to the limit of their level of knowledge (obviously, juniors less than seniors, but still at least somewhat).

There's again no way around that.

If the architects do not do any coding themselves, their solutions/architecture will over time become more and more divorced from reality. Heck, even if their architecture is perfect, if there is no contact there will still be doubts and resentment; and sooner or later the architecture will stop being perfect.

If the developers don't do any architecture, they won't know how their work fits into the grand scheme of things, and also their growth will be stunted.

From these points it's clear that the company policy has to change if you want the problem to be solved.

The question is if you can persuade those who make decisions to change the policy. This is often very hard, sometimes impossible.

You'll know, better than anyone here, if it's possible in the company where you work.

5
  • 18
    As an example, for the OP: if you use JavaScript front-end frameworks in your systems, and you've not done actual JS front-end development for two years, you are far out of touch with the current state of the art. It would be no surprise if developers get annoyed when you tell them to use old technology that's harder to use and less efficient. To use technology most effectively, the people doing the actual development must be the ones choosing it.
    – cjs
    Jul 31, 2019 at 3:19
  • 6
    @CurtJ.Sampson This is only partially true. It ignores the cost of switching technologies and the associated risks. Most of serious software requires stable technologies and platforms, which only change incrementally on everyday basis. It wouldn't make sense to write in COBOL now, but it also certainly doesn't make company-wise sense to write every next project in the newest version of yet another JS framework.
    – Gnudiff
    Jul 31, 2019 at 6:37
  • 5
    @gnudiff I was not as clear as I could have been, but I am not ignoring the cost of switching technologies. I am saying that a) those actually writing and maintaining the code have much better information about the cost-benefit tradeoffs of new tech, and b) tech in some areas changes fast enough that even if your most recent coding experience in the area is "only" two years old, you are not in a good position to be planning for the future. In general, managers who no longer code refusing to use newer technologies than those they used to use is a serious problem in the industry.
    – cjs
    Jul 31, 2019 at 6:50
  • @CurtJ.Sampson oh, I agree with (a). I just disagree with (b) when it applies to everyday work. The fact that there are new fads, 99% of which will die out or be replaced in 2 years with yet new fads, is an unfortunate situation in rather a small and narrow subset of programming, mostly, but not exclusively, as far as I can see, related to front-end web development.
    – Gnudiff
    Jul 31, 2019 at 8:24
  • 1
    @Gnudiff I agree with not going with new fads, but not everything are just new fads and if you are not up to date on things how can you give any feedback? Also it seems that once they become architects they don't code anymore, so it could well be way beyond 2 years of disconnection. Also It could be the other way around, the architects telling devs to use things they have no knowledge of training on.
    – Dzyann
    Jul 31, 2019 at 18:41
40

I think the environment you describe is somewhat old-fashioned and is not aging well. Much of the reason that software engineering gets a bad rap is because the incentives are not aligned in a way that promotes good design, implementation, and maintenance practices, leading to low-quality software. Divorcing developers from solution ownership is exactly the kind of thing which promotes complacency, malaise, and bit rot. Writing code is not, in fact the "fun part" of being a software engineer. Solving problems is the fun part, and writing the code should be mostly mechanical, except for the most junior developers who are still learning the finer points of their programming language.

I dare say that Google, Amazon, Facebook, Apple, and Netflix (the FAANG club) are based on the West Coast of the USA because this region strongly tends towards a more modern approach to software engineering, which is to drive ownership of solutions as far down the org chart as possible. Amazon, in particular, is famous for its "two-pizza teams". It might seem that it's a statement on team size, but it is not. The 2PT literally owns all the code it writes, and rarely has more than one or two senior developers. Architects do not dictate the design of new projects in detail. Rather, they coordinate design across teams, collaborating with engineers to come up with solutions created iteratively, rather than dictated in a more traditional waterfall-style approach. Or, they work on framework projects to be consumed by other teams at the teams' discretion. Junior engineers learn how to design software very quickly, because they are expected to do so, at various scales, from day 1. Which is also why they get pager duty and woken up at 3 AM if there's an outage: they own the design, they own the code, they own the bugs, they own the fix. The feedback loop is tight, and the results are indisputable.

For software which is hosted by the client rather than the provider, this feedback loop does not need to be so tight. Low-stakes software allows much greater freedom in the process to do less-efficient things. But creating solutions at the top and pushing them down the entire org chart is causing push-back for a very simple reason: it's a bad process. Your junior engineers are new and inexperienced, yes. But they also have the benefit of hindsight, of learning from instructors and an environment that has a wealth of experience that simply didn't exist when you were their age. You would do well to take their feedback to heart and push your company to adopt more modern engineering practices, starting with a more collaborative design process.

This will require quite a bit of humility from you, especially if you find out that your juniors are much smarter than you give them credit for. But an easy way to start is to just invite some of them to design brainstorming meetings. Invite them from all levels of developers. Present them the requirements you gathered, and ask: "How should we solve this?" Let them freewheel a bit, challenge them with insightful questions to show flaws in their proposed solutions, and see if you can't get them to craft the same design you would have on your own...or better yet, a superior design. Farm out parts of the specification to them, acting as the editor and reviewer, but also let them review each other.

The entire process should be very educational, and any half-competent management chain would see that you are improving the skill set of the entire team on a level that simply didn't occur before. On the other hand, by removing them from the loop, the entire middle management chain will also fight you tooth and nail, because you are eroding their clout and value add. They are the "people who take things from this desk and walk down the hall and put them on that desk." Taking away this perceived value-add will be politically threatening to them, whether it adds value to the company or not.

So, this process is political suicide if you don't already have the political capital to fend off all challengers. But if you can convince your boss that it's a good idea, and ask them to support you while you demonstrate the superior results, then it should be feasible to pull off anyway. If your boss is also politically weak, then it could simply get you run out of the company or relegated to "truck maintenance", as an old boss of mine used to call it. Just giving you fair warning that tipping the apple cart like this is not without dangers, no matter how beneficial it may be to your company's bottom line.

[EDIT]

I feel that I ended on an overly pessimistic note, so allow me to add a strategy for making this succeed, no matter how much political capital you have amassed at your company. The key, of course, is to make allies of the people who most benefit, and to include the ones who are most threatened. So explain to the more junior engineers (including the seniors who are right below you) that this experiment is a politically risky move, and that they need to voice their support for it in meetings with their managers. If you must, hold design meetings first, without consulting any other managers, so as to leverage the element of surprise. Better to ask forgiveness than permission. If you run the meetings well, it will energize the coder base and make them excited about change. This will incentivize them to go to bat for you.

You should also scout out the managers that are more forward-thinking and who might make natural allies in this process. Invite them to the design meetings too, and make it clear that it's a round table with no hierarchy, and everyone is an equally valued contributor. Ideally, the managers themselves have more engineering experience (and if they don't, because they are pure people managers selected for non-technical skills, that is a whole other ball of wax to contend with, and outside the scope of this question) and can also add valuable insights and guidance, demonstrating their technical chops and helping to firm up their technical authority.

When other architects or interested parties come to you and ask what you're doing and why you are doing it, just calmly and politely explain that you think you will get better fidelity on the results if the engineers who build the system participate in its design. It will also allow you to be more concise with the design docs and specs, saving everyone time and money and allowing you to tighten up some deadlines. And if you hold a few successful meetings, you can challenge them to go talk to the engineers themselves, get their perspective, and ask if there is any change in morale. Ideally, the results will speak for themselves, and loudly.

If you succeed in making this first step, then you can introduce modern Agile practices as mentioned in other answers, and hopefully, your management org will eventually wise up and maybe bring in a coach to help the company get up to speed on more modern practices. It doesn't matter if you follow Scrum or Kanban, Kaizen or some other system. You just need to design small, start building early, and iterate heavily. It sounds like your junior engineers will push the ball very, very hard on their own if you manage to just get it rolling. Good luck!

1
  • 8
    It's more than "somewhat" old-fashioned. The problems with top-down development were understood in the 1970s. Jul 31, 2019 at 17:29
40

I've been in this exact position and it sucks. Not yours, mind you; the dev team's.

I was Lead Developer for a near-shore dev team. We maintained a rather old but absolutely critical system which several nations' international postal service depended upon.
As a member of UPU, our customer incurred in six-figure fines if the system had excessive delays -- something that was happening more as of lately, due to the surge in international traffic (thanks Amazon and Alibaba). So our Architect Team in our central office was tasked with designing a solution.

The Architects Team did what was expected of them:

  • The had meetings with the customer to collect the requirements.
  • They picked the technologies that seemed more fit for the task.
  • They designed a solution, built a PoC, gave an estimation of total effort required and expected milestones, and got the manager's approval.
  • They wrote documentation for us (requirements, technical design) and a stub for the project itself. They also hosted remote training sessions to introduce us to the new technology.

And then they moved on.

The project was a complete disaster. Reasons:

  • The architects didn't ask for input from the dev team which had been maintaining the old system for years, nor inspected the system themselves. They designed a new one from scratch, based solely on our customer's requirements, to avoid "contamination" by the "faulty" old system.
    • Result 1: requirements missing about 40% of the actual functionality, and being too vague or shallow, e.g. "System must handle XYZ-type packages."
    • Result 2: the technology wasn't actually that fit to the complexity of the task at hand.
  • The architects didn't take into account the skills of the dev team nor the cost of learning a whole new framework.
    • Result: productivity cut by half because no one knew the technology and the teaching sessions were based on a HelloWorld-level example.
  • The architects didn't take into account whether their chosen technologies would integrate well with our customer's current stack and way of doing things.
    • Result: alternative solutions had to be improvised on an already tight (read: deadlines missed by months) schedule.

But worst of all: when the dev team complained about the above, the response from the architects was along the lines of "the design is fine, you're just failing to implement it" and "we're architects, we just design the solution, we're already working on something else, stop bothering us".

So what could have been done to avoid this?

  • Do not architect your solution in isolation. Talk to the dev team to get input about the current skills, tech stack, environment constraints, etc.
  • Do not rely solely on customer requirements. Talk to the dev team to learn about in-place processes the customer may have forgotten about, actual inputs and outputs of the system, complex relationships that the customer might not have explained in full, etc. Avoid your requirements being a "How to draw an owl" guide.
  • Do not be so quick to "move on". Talk to the dev team to ID any initial design flaws, and be there to help solve design-related problems that may arise during development.

TL;DR Talk to the dev team.

16

This post highlights some severe problems:

You highlight your own experience and not so subtly downplay "junior and middle level developers"' complaints. This may not be your intent, but that is how it comes off. This attitude of "I know best because I have worked in this field for longer than everyone else involved" is unhealthy and blocks learning both ways. I can't count the number of times a colleague 5+ years my junior has taught me something new or convinced me to change an approach.

The planning process you mention mirrors the waterfall model of development - gather requirements, plan, implement, verify and maintain, all in one neat continuous stream. But there is overwhelming evidence that this method of working is extremely inefficient for software development.

Have you looked into Agile processes? Bear in mind there is much more to them than daily standups, and unless you have any actual Agile experts inhouse (and even if you do) I would urge you to get someone from outside to hold courses for anybody who wants to participate. This should give you a good idea of how much more organic, self-organizing and collaborative successful software development projects are nowadays.

Just as an example, it frequently comes up that implementing a requirement exactly as written (and this goes more than doubly if it was written years ago) costs many times more than a similar implementation given the developers' knowledge of how the system actually works. What usually happens in this situation is the developer(s) will follow a rough escalation:

  1. The alternative implementation is obviously superior in every aspect and they simply implement it that way. Code review should catch any major glitches here anyway, and besides there is trust between everybody that we are all working towards the same goal (happy customers, not software developed to a spec).
  2. The trade-offs are highly technical (for example, more hardware resource use or requires a refactoring), so the issue is discussed with other developers before settling on a reasonable solution (often different from the two original ones).
  3. The trade-offs are functional but very minor (showing the presence of something rather than the number of somethings, for example) or an acceptance criterion is ambiguous, so an analyst/architect is usually involved to discuss whether the alternative solution is acceptable.
  4. The alternative solution differs significantly from the acceptance criteria but may be vastly simpler to implement or improves on the original requirements without extra cost. This is where the client should get involved to verify that this would indeed be an improvement.

If you care about the employees, the company or the software, I would urge you to take a long hard look at your processes. Involve everybody who wants to be. Facilitate so you don't end up bikeshedding. Find the biggest pain points and work towards solutions. Repeat forever.

(If it matters to you, I'm a senior working on a project which is successful by every metric — the client representative calls it "world class" software and my colleagues and I are highly motivated.)

Re. the comments below: contracts don't appear out of thin air, they are negotiated between parties. If by developing and agreeing to contracts which are clearly antithetical to modern software development processes it is your responsibility to make this clear to the customers and to push for a reasonable process.

6
  • 4
    I suspect the reason the company is still using Waterfall is that it gives them a contract and an agreed price. The hardest part of Agile is the contract negotiation. Jul 31, 2019 at 8:37
  • 1
    @RobinBennett I confirm: roadmap and milestones are written in the contracts (for some customers, like PA, this is required by the customers themselves). Also price is fixed in the contract. If the customer changes his mind or wants to add new feature, a new contract must be signed, with new roadmap, new milestones and new price
    – A Falluj
    Jul 31, 2019 at 11:34
  • 1
    @AFalluj Does the contract specify which technologies and design the program will use, or does it just say that the program will solve the problem?
    – user253751
    Jul 31, 2019 at 23:29
  • 2
    @AFalluj There's a body of writing about how to integrate agile methodologies with the requirements of public procurement processes. But even if the contracting methodology can't be changed, even if you're stuck in agilefall, that doesn't mean your internal processes can't incorporate agile methods of working like collaborative teams with shared ownership, iterative development, frequent user feedback, or creating potentially shippable product on an ongoing basis. It's a win even if you can only improve part of your process. Aug 1, 2019 at 6:36
  • "Just as an example, it frequently comes up that implementing a requirement exactly as written (and this goes more than doubly if it was written years ago) costs many times more than a similar implementation given the developers' knowledge of how the system actually works." A bit of a quibble here: A design is not a requirement. A requirement says "The product can do X" without any regard to how X is accomplished. Figuring out how to accomplish X is the design and should be the job of the engineer(s). Putting design in requirements documents is a major error, regardless of development model.
    – reirab
    Aug 1, 2019 at 22:04
13

Assuming the things have to stay the way they are, you will always receive complaints from junior level developers because they can't understand the complexity and the value of the functional engineering until they have faced it (or the lack of it). It may also be tedious to read documentation, and their hostility a reaction to that. But there are also many problems with how your company is organized:

We do not have direct (in person) or indirect (mail/phone/chat) contacts with developers (we are even in a different office than them): all interactions are through managers.

This is a problem, both because they would need your input, may have constructive feedback as well, and because they are less likely to feel empathy for you as a person

According to the expected elapsed of the project, the development team has a period during which can ask for clarifications/explanations for the documents. After this our job is completed and we move on to the next project.

Well, this is precisely everything agile software development stood against. Whether or not you like agile software development, it is efficient and popular among developers. There are some downsides to organizing work the way your company did, in particular the ability to embrace perimeter change and project unknowns. If your company face a lot of these, then it's quite understandable your static documentation is being heavily criticized, as it is prone to become of no use.

5
  • As you already found out, we do not work in anything even similar to agile. Roadmaps and project milestones our written in the contracts between my company and the customers. If some changes occur or are requested by the customer, we start the process again, updating documentations, roadmaps, milestones, etc
    – A Falluj
    Jul 30, 2019 at 7:26
  • 3
    @AFalluj Well yes and I think you will then face regular complaints, some part of which are legitimate and some part which is just rant
    – Diane M
    Jul 30, 2019 at 7:27
  • 13
    In that case the question is "I design steam engines and our engineers are talking about this 'electricity' thing. How do I design a steam engine that competes with these new machines" and that is a valid question (steam is still in use in some specific use cases) but missing a vital point.
    – Borgh
    Jul 30, 2019 at 8:01
  • @AFalluj Have you heard any stories of what happens when architects (for buildings) don't listen to builders? Here's one for example. Another. This is why architects should listen to builders and update their plans accordingly.
    – user253751
    Jul 31, 2019 at 23:28
  • @immibis Also, architects should listen to engineers when making their designs. Otherwise, this happens. And when that same architect still doesn't learn his lesson, then this happens.
    – reirab
    Aug 1, 2019 at 21:59
12

As the other answers specified, top down architecture is bad for a number of reasons, mainly:

  • It's less productive than several other methodologies.
  • The architects do not learn because they don't face the consequences of their decisions.
  • The developers don't learn because they don't get to make decisions.
  • The developers have a boring job and everyone who wants to learn more skills to further their career will leave as soon as they can.

I'm writing this answer because I want to highlight that none of this means there shouldn't be architects, or an overarching design. The opposite extreme of "anyone can implement any feature whichever way they like" also has significant downsides especially once the code base grows beyond 100'000 lines.

Various processes already deal with this problem, and this is what these processes have in common:

  • Everyone designs.
  • Architects* guide and often review design.
  • Architects* highlight problems that fit in neither of the teams' domains.
  • Architects* still do occasional programming work, often while joining a normal dev team temporarily.
  • Communication between teams is encouraged and facilitated.
  • And architectural vision is shared, and continuously updated.

*Some of the processes use a different word than Architect

8

My impression is that because you are following the prescribed business model, the only suitable response from you is to question if the business model is working, and satisfies not just the immediate business needs, but needs into the future. And the business needs do include employee satisfaction at all levels.

Giving patronising lip-service to those complaining by giving them a false impression of inclusion is not likely to be effective. No amount of team bonding events, or friendly chats is going to cover up the business structure in place.

The simple fact of the matter is that no matter which way you sell it, there is a two tier structure to development, and those in the bottom tier are not likely to consider themselves anything other than bottom feeders.

I was honestly taken a bit aback by the way you described yourself. I'm not passing I personal judgement on you, but I'm guessing a lot of those in the "lower tier" has a lot of the same skillset. It would seem that due to the company structure until the developers tick all those boxes, they are unable to partake in solution design.

If you actually want those in the lower tier to actually feel like developers, the company is most likely to have to restructure to integrate those tiers.

7
  • As far as I know some of the juniors complained to the HR, some to the managers. The managers (that are in our office) pass the message to us, only as information, not with a precise purpose. I'm not sure I fully understood the penultimate paragraph, could you explain it a bit more?
    – A Falluj
    Jul 30, 2019 at 7:19
  • 4
    -1 for "not really your problem." Discouraging people in a business from trying to understand and address problems that directly involve them is bad for the business and bad for the people in it. They may or may not be able to help effect change, depending on the company and their managers, but they certainly won't be able to affect change if they can't try, and if they don't understand the problem they have less chance of avoiding other companies with the same problem should they choose to switch jobs.
    – cjs
    Jul 31, 2019 at 3:16
  • 1
    It's typical, but I don't see how it's relevant. My point is that, unless you've seen specific indications that you should not try to investigate and/or address a problem, advice to ignore problems almost never results in a better outcome and often results in a worse one. In this case, HR and management asked for help to improve the situation.
    – cjs
    Jul 31, 2019 at 3:47
  • 2
    @CurtJ.Sampson I'm not saying ignore the problem. I will clarify the wording so this is clearer. Jul 31, 2019 at 3:51
  • 2
    @GregoryCurrie The "leave it to upper management" mentality is exactly the same problem, just transposed one step. Jul 31, 2019 at 9:59
1

In our case, what really helped to alleviate this dissatisfaction was to lead the development teams more closely.

We have several developers distributed in several teams. Definitely we can't lead them all, but we can lead their technical leaders. So weekly we meet up with them for one hour and talk about what's going inside the teams, about the projects, about the solutions, about the mood of the team and about the direction that we are taking about technology, tools, frameworks and so on.

The key point here is to make them be and feel part of the decisions and solutions. There is, of course, crazy ideas and hype of all sorts about new technology, but then again, we are leading them. And not them leading us.

0

Here is a great tactic to build moral over stressful multi department projects. If you know that your solution contains elements which the other team will favor or are very proficient in,... you can intentionally leave those elements out of the early multi team discussions. You’re basically baiting the team to suggest the ideas & changes so you can praise their contribution to solution. This will give the team a sense of ownership over the project and they will be happy with the final decision. You can even have someone from your department approach them afterwards and mention how you were speaking highly of their contribution to the decisions.

0

I have worked closely with architects and (arguably, depends on the exact understanding) am a solution architect myself.

My impression is that you're not architecting a solution. You're producing documents "to describe every single technical aspect that developers should know to implement the solution".

You should (in my opinion) be describing the problem to be solved, and produce high level documentation. Then let the developers take care of the concrete implementation.

Caveat: Note, that if the customer prescribes the language, exact framework, etc. - fair enough. I wouldn't let them dictate every detail, but hey, they're the customer. In that case, there's nothing you can really do.

I don't mean just some super high level diagrams. Invest the time to work out what's important. I've often found it good to start with the data - what's needed, how does it need to be stored (sensitive data, is eventual consistency fine or do we need ACID - why). What "non-functional" requirements are there, expected loads, etc. What system(s) need to be integrated with. And so on.

Then make high level diagrams to lay out an architecture. No need to prescribe the technology. If the customer wants it to work with some other system, make that clear.

Be very clear on the requirements and why they're there.

Now some developer may come up with a great solution you hadn't thought of. Nice. They may also come up with "great ideas" that really aren't great. Talk to them, flesh out the details, be available for questions. But let them do their work.

There are several reasons why this is a better approach:

  • you (and the other solution architects) assume you know what's best, and are in a closed system. You're not learning. That will eventually lead to bad specs
  • good developers will contribute to this process. This will both lead to learning (see above), and upskill the developer (if the solution architects are really that good). This may be small stuff not changing your solution (Oh look, we can now transfer this data more efficiently using fancy new CloudProviderFunction, if we use CloudProviderDB), or big stuff (there's now AIs that can do X,Y,Z, I wonder if that's an even better solution). Either is valuable, even if not always for the project at hand.
  • the company can attract good developers. Trust me, except for the very few that have personal reasons, all the good ones have left. You've currently got those that recently joined and haven't quit yet and a bunch of "I'll keep my head down and do the ticket" people. As much as those are needed, you can't build good products only with those
  • you're leaving good solutions on the table: Again, you're in a closed system. The more valuable input, the better the solution. It's getting the valuable input that's hard, and you're making it impossible
  • Not having to spec out all of the details leaves the solution architects more time to focus on the bigger picture. Think tooling. There's never enough of the right tooling. The right tooling speeds up development, making the whole process more efficient. This leads to needing less developers, or being able to do more work.
  • getting the tooling right isn't easy. This is something to be left to the really experienced Seniors. Which is a great way to build a pipeline for the future solution architects
  • the process allows for technical career advancement
  • the process encourages qualified input (with you being the arbiter). This will lead to better solutions, overall, over time.

I highly doubt your company is as efficient as you think. Also, on a personal level, you may find that training people up can be very rewarding.

I prefer working that way, and this is how I would (if I had to, which I don't) sell it to management to change ways.

That's an investment on your part, and you're taking a chance, of course. So whether you think the rewards are worth it, is up to you. Good luck

You must log in to answer this question.

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