Slashdot Mirror
Ask Slashdot: How Can You Manage Developers Distributed Across Multiple Projects?
An anonymous Slashdot reader asks whether it's possible to manage a "distributed" team of software developers in different locations who are all assigned to different projects, each with their own independent project managers:
All embedded software engineers from multiple offices in different countries are now being reorganized into this new distributed team [with] better control of its own development practices, processes and tools, since everyone is working in embedded software...
While there's extensive material throughout the Internet on best practices for managing distributed teams, it seems to either take an agile perspective, the project manager's perspective or be otherwise based on the assumption that everyone in the team are working in the same project. In my case, I'd be managing a distributed team of developers all assigned to different projects. How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
Anyone have any relevant experiences to share with distributed teams or "matrix" organizations? Leave your answers in the comments. How can you manage developers who are all distributed across multiple projects?
While there's extensive material throughout the Internet on best practices for managing distributed teams, it seems to either take an agile perspective, the project manager's perspective or be otherwise based on the assumption that everyone in the team are working in the same project. In my case, I'd be managing a distributed team of developers all assigned to different projects. How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
Anyone have any relevant experiences to share with distributed teams or "matrix" organizations? Leave your answers in the comments. How can you manage developers who are all distributed across multiple projects?
It's easy, git is the solution to every issue.
... to get lots of first posts while they say they're working on that other project.
Don't.
Silos don't make any sense, let your devs integrate into their teams.
Whoever mentions the word "Agile", do the opposite of what they say.
Distributed developers all working on a multitude of projects in different locations? Looks like a description of the open-source world. A huge success, with several operating systems, compilers, complete set of servers as well as office apps, generally works better than the competition. (Better on bunctionality & security, but not"polish" or "marketing")
Oh wait. You want to "manage" the teams? In our world, each maintainer manage his own sw, but not the team. Team members come and go, they are used or shut out ("fired") depending on ability. And of course, a complete asshat maintainer won't be able to get team members. Don't know if you can fit this model into a world with "wages" and "reporting"...
"Please state the nature of your emergency." (EMH mark 2, Startrek Voyager)
Hello AC, welcome to slashoverflow.
The question as formulated now is vague. There is a proposed solution (managing) but no problem stated that needs solving.
And what you have tried to resolve this problem.
Hivemind harvest in progress..
Once they're working for you and you understand your developers, either you'll figure out something, or you won't.
Quit trying to stuff them into boxes before you even know what makes them tick.
Trust only comes through stability. Developers with nothing in common and different project managers sounds like a recipe for disaster and your role sounds like a potential nightmare.
With the number of buzzwords you've spewed into the summary, you should just drown yourself in a nearby body of water.
If each team is doing something different, why the fuck do you need to "build cohesion"? Are you going to glue them together?
How can you manage developers who are all distributed across multiple projects?
You do what large companies do in such situations. You hire a middle manager for each project and then you manage those managers. Hire architects to handle any cohesion or commonality among various projects.
That is exactly what he does.
Most of the Linux maintainers also work on other projects.
Sees like you have a job with no deliverables.
Time sheets? Vacations? How exactly will you be judged?
I suggest you start looking for a job (internal or external) for soon someone will start cutting redundant staff.
You don't have a team of developers. You have a bunch of single-person teams. Don't try to manage it as a team.
Honestly, let them do their job. if you want to be a good mid manager above the other managers. you let them do their job and you act as a "what do you need" guy that simply get them what they need and keep the fuck out of the way 99% of the time.
Do not look at laser with remaining good eye.
How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
It's a traditional matrix, nothing special about it. Manage each team individually the same as any other development team;, the fact that they're matrixed is irrelevant. Occasionally (maybe once per quarter) have an all-hands meeting and have each team give a 3 minute presentation on what it's doing so people have an idea what else is going on, same as any other large development organization.
Here the way we do it is by simply assigning each developer to some percentage on each project for the billing system (adding up to 100), while each project manager expect each developer to work on his project at 100% of his/her time. Did I mention that I was leaving?
I've been in this situation before, and in some ways still am. Here are a couple tips:
- This matrixed team structure was likely put in place because the company thought there would be advantages to having these developers interacting even if they're not working on the same project. Get together, maybe once a month, and have people present on the project they're working on. It'll help give everyone visibility into everyone else's work, give some practice presenting, and provide a great opportunity to share best practices.
- More tactically, provide some social platform for the team interact and ask each other questions. We use Yammer, but a Slack channel would probably be effective too.
- You're probably responsible for some level of coaching/mentoring for your team even though you're not directly working with them. Meet with them individually and regularly to find out how they're doing and how you can help them. You'll also want to set up some regular check-ins with their project managers to get their perspective.
- Finally, you may he responsible for setting technical direction and standards for the team. Unless you're highly revered and have already earned a ton of respect for this capacity, you'll need to build some consensus rather than ruling by decree. Seek advice and feedback from your senior team members before presenting your approaches.
Best of luck!
I work on a very similar team, about 25 people, distributed globally, all contributing to various Open Source projects, all with different processes, governance, etc. Our managers focus on handling the management and human resources bits, ensuring that I have what I need to do my job. Most everything else; time management, development process, tooling, location... even travel, etc - is left up to me.
I personally feel that the key to the team is the core belief that everyone's an adult, and can manage themselves and their own work. Managers aren't authoritarian, they're coaches. We're all encouraged to be strategically minded, though a lot of that is taught and socialized in the team's always-on IRC channel. The team was founded by adapting the Valve handbook, throwing out all the things that require people to be colocated. Other than that, the unique dynamic of autonomy, mutual respect, support, and the freedom to ask any question - no matter how dumb it may seem at the time - isn't something I've ever seen reproduced elsewhere.
This signature can save you $400 on your car insurance!
"I'd be managing a distributed team of developers all assigned to different projects." This isn't necessarily a three dimensions challenge, and you should keep things as simple as possible. People with multiple bosses will often please none of them. If there are not clear lines of accountability and definitions of success, your only hope of this thing not devolving in a complete fustercluck will be the coders who find your projects interesting and don't have families to raise.
You mentioned you "independent project managers". If you are thinking about the Scrum flavor of Agile specifically but have project managers you are likely doing something wrong. More important is product ownership. "Agile" development success largely depends upon decisions being made on a daily basis. If your product owners are not engaged on a daily basis directly with the developers (even when cross-timezone meetings are painful) you're doomed.
Find your local leaders, the people who get things done. You need people on the ground who understand the culture and trust you enough to let you know what is really going on. It will be far easier to build these relationships if you regularly travel and engage with them. Do not delegate this part of your job, you are not going to be able to cultivate your leaders over video conferencing. People behave very differently in-person.
Oh, and keep your staff off of The Register, which has devolved into a DevOps cheerleading site - nothing good will come of it
I work in a matrix team where we look after functions but across multiple projects. Certain people in the team focus on specific projects but what try to maintain is the communication within our team for issues across the various projects as more often than not, we have common or similar issues and if someone has a resolution, it may help on other projects too. It's also useful as a lessons-learned sharing so that if others face something similar in the future, they have documents to refer back to. So make sure that even if you have people working on multiple projects, they talk to each other and share best practices etc
Digital Equipment Corp. (DEC) was once a billion dollar juggernaut having wonderful hardware and software products. It tried Matrix Management and today it is nothing more than a legacy in the industry. Now that’s a simplistic statement, but, true and relevant to this topic. There’ll always be a warm place in my heart for PDP-11/RSTS and VAX/VMS . . . What a pity.
Know your industries’ history; don't repeat it.
That job sounds like a career killer.
-- Large matrix organizations fail spectacularly.
Our company tried this for about 5 years. Our CIO had this grandiose notion that waterfall projects done by Project Management Professionals(tm) was the way to go, and that she was going to show the world how projects should get done. To that end all analysts would report to one pyramid, all architects to another, all engineers to another, all coders to another, all testers to another, etc. It was a slow motion train wreck. All executives who dissented to this brilliant plan were fired, because they obviously weren't team players. Instead, the answer to every problem (and they were numerous) was "add more gold-plated passenger cars to the trains so we can carry more project managers and analysts, and fill the caboose with more contractors." Fortunately for the company's long term survival, the CIO was thrown out and replaced by an actual engineer. Of course he was given half the budget of his predecessor.
The outcome was obvious. A few people transitioned from project manager to scrum master, but a large percentage of our employees were simply let go because there was no place for the excess project managers or analysts.
Of course the new guy came in and said "Agile is the solution; all teams shall be agile by year's end." While not nearly as useless as his narcissistic predecessor, he suffers from a one-size-fits-all mentality that doesn't acknowledge that large hardware/infrastructure projects are still best run by waterfall. That's bad, but he's gotten worse with the crazy edicts. Every project must now be built on open source platforms, and managed with his pre-defined set of web based tools. Doesn't matter if the teams already have the right tools for their jobs; doesn't matter if the teams are working on mainframes, web servers, or doing embedded system development. And the engineers we're hiring now have all the life experiences you might expect from people who grew up playing Warcraft in their mothers' basements, and the mistakes now being made would have been prevented if we still had a few of the people with experience hanging around.
The moral of the story? If you find yourself inside a matrix organization, keep your resume up to date. But if you find yourself inside an agile organization, keep your resume up to date.
shit can you imagine if a country tried to win a war with this level of inexperienced boy-man ceo organizational bullshit? At least with undercover internal affairs all the office politics are against you but you can sleep at night with the promise of cleaning up the rot.
run man run. this is not a game you can win.
Okay, here's what you need to do: give half of the developers red pills and give half of the developers blue pills. After that I don't remember.
Anyone else think it's kinda sad that a manager is coming to slashdot to ask how to be a manager?
You cannot serve.
My ism, it's full of beliefs.
It seems strange to me that you would want to try and manage developers across multiple projects as a single entity. If they have their own project managers, then it sounds like a more hands off approach is going to work, with occasional steering/correction onto the correct path.
Plan A: Use pseudo-random job assignments to put resources on whichever fire is the hottest today.
Result: Fires get fought, but there is a continual wasted effort for folks to learn how the thing they are working on today works.
(Or worse, rewriting the thing because they didn't.)
End result is bloated sortware which gets harder and harder to work on.
Much easier on manager because he doesn't have to understand exactly what his folks are doing.
Plan B: architect the s/w so that there are separate parts for which specific folks can become the domain experts.
Requires manager awareness of how things are structured and who to task for different areas.
(He's either the architect, or is paired with him.)
Provides accountability when a specific area is having a problem.
Given the quote "since everyone is working in embedded software..."
Looks like somebody is going with plan A.
Any side bets on if there is an MBA involved?
They're not cooperating on a common goal. What is it that you, with your "management", expect to bring to the table? Seriously, what are you beyond a gatekeeper in this scenario?
If you can come up with a genuine answer as to what value you bring to the situation, then you have your answer. If you can't, just come up with whatever bullshit you like to justify your pay cheque, like most other managers do.
How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
- Build plenty of slack into the project plan for when (not if - when) things go wrong.
- Don't put forth unrealistic commitments.
- Allocate their time accordingly.
each with their own independent project managers
Good project managers are worth their weight in gold. Crappy ones are worth their weight in lead drowning out a project. Really crappy ones will drag down other projects as well as their own. That is going to be your biggest risk - not the developers. Make sure you have a handle on your project managers and mitigate that risk first. Then focus on your developers.
We've been doing this sort of thing for a long time now.
As a manager for multiple developers all working on different projects, for different product owners, what is the benefit that you're trying to bring to these developers? If you can answer that, we can probably come up with some things you can do to reach your goals.
Easy Online Role Playing Campaign Management
First, if you truly have a bunch of single-person projects, you have an additional problem that you don't appear to have recognized: You have multiple single points of failure. I often use the notion of a "bus metric" which is "the number of people who have to be hit by a bus to cause serious problems for the organization". Your bus metric is 1, but it's a little worse than that, because you have several single individuals whose unavailability would cause problems.
This second problem actually points to part of my recommended solution: If you want to build team cohesion, you need to break down the silos between the projects and get your engineers working together more. At the same time, you don't want to impose a lot of process that will slow them down.
Some concrete suggestions (in no particular order):
1. Do code reviews. In fact, make them mandatory. In general, I'm against mandating much of anything but this is an exception because it is so extremely valuable. Mandate that every piece of code checked into the source repository must have been reviewed by someone other than the author. To make this effective and not an obstacle to getting work done, though, you need tool support. Something akin to Gerrit. Do not attempt to require code reviews until the infrastructure is in place, and once it is, ease into it and make sure everything is working well and everyone is comfortable with the tools before you mandate the reviews. However, be clear that the intention is to mandate them.
2. Do design reviews. Similar story to code reviews, except that design reviews should be attended by the entire team, or at least a largish subset. Again, good tooling is helpful. In this case using something like Google Docs or Office 360 for the design docs and then a good teleconference or, better yet, video conference solution for the review meeting. In terms of breaking down silos, cross-project design reviews will be hugely valuable.
3. Do standups via teleconference or (better yet) video conference. They don't need to be daily, and if your team is all working on different things they probably shouldn't be daily. Once a week for 15 minutes is a good place to start, just go around the "room" and have everyone briefly describe what they're working on and what challenges they're having. It's the discussion of challenges that make this valuable, because others will pipe up with their suggestions. Again, before you do this make sure that your infrastructure is in place and working *well*. Also, keep a close eye on how this is scaling. Beyond a certain number of participants it breaks down and you need to split it up.
4. Encourage lots of random, ad-hoc communication among the team. Again, good tools -- VC and shared docs, mostly, but you also need good chat and email systems -- are important for effective remote collaboration. As for how to encourage it, one good way is for you to get a solid understanding of what everyone is good at and when you have one-on-one meetings with them (which you should be doing regularly) look for opportunities to suggest collaborations.
5. Set up face-to-face get-togethers as frequently as you can, within the constraints of time and budget. Ensure that these contain equal parts business-related discussion of goals, plans, challenges, etc., and chances for people to do fun stuff together -- but make sure that you find activities that everyone can participate in and enjoy. IMO, you should avoid those obnoxious "team-building" programs.
6. If you can, consider getting budget for an additional engineer to focus on common tooling. The goal isn't to force all of your engineers into a common toolset against their will, but to build up some useful common tooling that all of them find valuable. Source control, code review system, continuous integration, automated testing, etc. This tool engineer will become another central point that everyone communicates with regularly (in addition to you).
7
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If you've hired people who need management into that situation, you've hired the wrong people. You need smart people with good time management skills who are not assholes and can work together like grownups without any oversight despite whatever personal differences they may have. They should also be humble enough to ask their peers for help when they are in over their head on something.
Good luck!
Hello there, may I suggest looking seriously at using systems like Watson or other AI systems to learn project management concepts and project tracking, this way you will be freeing yourself from the hassle, you can automate virtually every aspect of your project management processes and make it possible for a decision maker like yourself, to make informed decisions regarding team member, different development methods and other project and business related matters based on best practise methodology for each project type and real world learning regarding the dynamics of project types and each individual project....
MS, ALS, Aphasia ? http://globability.org - Me http://einarpetersen.com
I work for a medium sized multinational, and the development teams I work with are exactly as you describe. (I'm in systems integration, so I get to make their output work in the real world.) Many of the senior managers in our company have a professional services background, so development is run like a typical offshore body shop, even when the developers are local. Developers are plugged into a project and disconnected when done like they're working for one of the outsourcing code factories.
The short answer is that it's very difficult to manage developers pulled in a million different directions. Agile is definitely in use here, but the reality is that the nature of our work means that developers actually need to understand a little more than a code specification to do the work. They also need to stay involved after writing their code for that reason, but are often pulled off projects because someone shouts loudly enough or is politically connected. As a result, my experience talking with them is that no one ever feels they can get anything done to a reasonable degree before getting unplugged and reconnected to something else. Project management isn't the best around here as a rule, so there's constant emergencies.
When you're "matrix managed," the actual manager is pretty much responsible for your performance review. The rest of the management direction comes from project managers that range from good to extraordinarily bad. I know I wouldn't want to do dev work in that environment, nor would I ever in a million years want a PM job. But, with DevOps being a thing now, I imagine it's just around the corner for us too.
Pretty sure everyone there moves back and forth between projects constantly. They use some app controlled process for it, too lazy to look it up myself though, that's your job. ;)
Manage the PMs, let them manage the devs.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Managing such this type of team is no different than any other complex distributed virtual team. 1) Governance: get all the teams working from a single sheet of strategic music (HOW them implement is their decision) otherwise you will continue to experience too much organizational (team-to-team entropy). 2) Program/cross-team Trust: Trust is built through face-to-face meetings (early on) and takes time - scheduling either face-to-face meetings or conferences on some regular basis (the more distant the teams the fewer you'll be able to do physically), can also leverage video meeting technologies (i.e. vidyo, netmeeting, skype for business, skype, etc.) on a more frequent basis. To ensure folks are all working on same plan, the lead PM should implement the "Master Kanban" board from which all sub-teams driver their Kanbans/Sprints. RRP's should be frequent, regular and scheduled so there are no surprises. 3) Accountability: hold folks accountable, whether it's good stuff or bad... communicates that no one is special. Definitely cheer the good and definitely help those who aren't cutting it to improve but if they continue to not deliver you GOT to deal with it. 4) Master repo: maintain a master repo (used by testing & deployment) that pulls from all development repo's (sub repo's constructed by what makes most sense). Ensure you have rules set accordingly for pushes such that ALL pushes are tested prior to allowing that push to be integrated onto the master trunk version. 5) Continuous Build/Test: gospel!!! must have or else!!! 6) Design review whenever possible (doesn't have to be crazy, stickies on the wall, take a picture, quick document the workflow/etc.) just so everyone understands the goal, the intent and the initial roadmap. 7) Code reviews: must do prior to any push to master repo 8) Code base: be smart, be practical, this isn't supposed to be a death march but have a test(s) for each capability/function to verify it works as intended/designed 9) Management/PM's quiet in development team's RRP 10) Management/PM's have their own separate planning cycle and stand-ups that don't involve developers 11) Owners/Product Managers: push back on management but ALSO on development teams to challenge the initial response... Management always wants more than can be delivered and developers always cry that too much too soon.... Truth is in the middle. 12) If this is a long-term gig; have regular large conferences/team meetings where folks get to show-off their deliverables and how they were successful. Good work deserves recognition. Others can learn and improve. 13) Roles & Responsibilities: ensure that everyone assigned to the project/program understands their role & responsibility (foundational for accountability). For developers, there should be a common Developer's Agreement (deal with IP, etc.) for the overall project but there should/could be a similar agreement for each company/contractor if you have multiple teams working a single company/contractor's code. 14) Agreements: have your NDA's and IP management agreements in place before the work starts
My current company runs a bit like this (we have multiple major offices and several satellite offices all working together with different engineering disciplines). There are three major components (imho) to really try and hit. First, let the technical lead for each project run most of the show. Our leads are the person that is ultimately responsible for delegating tasks, managing integration, and delivering the final solution to a customer. Developers can be easily put in and taken out if your leads are strong and given enough latitude. PMs really just coordinate schedules, liaise with the customers, enforce deadlines effectively (i.e. if a developer misses a milestone they sound the alarm), and get the lead and team members what they need to accomplish the project.
Component specification (sometimes called a feature specification) is another critical point to our main process. When larger pieces of a project have to be developed don't try to distill everything down to fit into just a general requirements document that is really a high level description. Get down into the real components and define the details for with them. This doesn't have to be done for everything, but large tasks need to have a clear definition and understanding of what it does, how it looks, and in some cases how it will be implemented. The technical lead usually develops this with the team at large by having the team member write up their understanding and then going through an adjustment process just like when submitting a requirements document to the customer, but it is internal. This helps greatly reduce how much retooling and such happens when there was a misunderstanding or too broadly defined area.
Finally, and I know some people hate it, but don't be afraid to create middle management. We have several people who basically just coordinate between projects to make sure each one has adequate resource coverage, or if they don't what needs to be prioritized and not letting one project take the entire shit stick. These people generally end up wearing multiple hats depending on how big the group is that they are managing, but some do it as a full time job because of the size of the group. This offloads a lot from PMs and makes sure you have an arbitrator when there are conflicting views. They work closely with PMs to understand the needs of the project in terms of schedule and talent (i.e. some projects are always much riskier or harder to execute than others), but they do the leg work to coordinate between other projects and teams at large.
Last note, that has been successful for us, make sure to get developers in the mindset of solving business problems rather than just blindly adhering to a specification. This makes it a lot easier when moving people between projects and helps get people to really think about it in a team effort for each individual project. It also helps greatly to refine specifications as you go and can even be a sales technique to really drive new development in the direction of what a customer could actually use. Modular team members can be nice, but if they become insulated from the bigger problem they are trying to solve then they really don't grow near the way they should. Eventually you will starve yourself of the key component in the model, your strong technical leads because the existing ones move up/on.
And, to be honest, I don't recommend it, but it doesn't sound like you have any good options, so it you may as well try a better bad option. Base it on internal billing. Since the project managers will prioritize based on their projects, the priorities will be inherently heterogeneous. You need a homogenizing metric and that's the purpose which money serves.
Any guest worker system is indistinguishable from indentured servitude.
First off, this is a good question, since I see this happening more and more.
It can be done, it is just highly inefficient from a management perspective. More of the manager's time will be spent soliciting and providing feedback. Without being there in person, if there is a performance problem, it may be hard to tell what the political situation on the ground is like, and whether the team dynamics, developer or PM is at fault for any project-related issues that come up. And there is no substitute for in-person meetings when it comes to providing reviews, feedback and coaching.
If you are a manager in this situation expect to travel quite a bit in order to meet with your team members (at least quarterly) and their local co-workers and PMs. If, by chance, your company does not permit that sort of travel or you do not want to travel, I recommend finding new employment. It is not likely to work well.
I would not want to manage in that sort of environment unless I understood what problems they are trying to solve and was convinced that it was the most efficient way to solve it. The real key question for me has always been "are they paying me enough to put up with this shit?" It's going to be a lot more shit to deal with. You should expect to be compensated for it.
the growth in cynicism and rebellion has not been without cause
If you are a Project Manager, sure Agile, Kanban, Scrum, lots of good ways to make sure that people can say they are going to do something, say they did it, and show it to somebody else.
If you are a Development Manager, your first questions should be: Do I know what I expect out of my people? Do my people know what I expect out of them. Do I know how to look at their work and tell if it is any good?
I have managed people across geography and timezones on matrixed work. We did it with weekly 1 on 1 meetings over videoconference, Devs would tell me what they have been doing, show me code in screen sharing, and talk about expected results of that code.
If you are a Dev Manager, think like a developer and stay close to the technology, make sure your staff knows you expect to see results. Have meaningful, helpful things to say about their work.
If you are a Dev manager and you can't look at their work and tell if it is any good, get a job as a Project Manager.
Exercise an Iron grip of control over the Mountain Dew and Dr Pepper supply.
I've been managing teams of developers for well over 15 years, periodically assigning smaller teams from project to project. There are quite a few moving parts but it can be managed by one or more managers. It's not unusual that I'm both manager and co- developer on a given project, a DBA for another, and solely admin for yet another. Some components must be common across all projects, namely task management and time tracking (where applicable). It's wildly helpful if code versioning is also centrally managed and integrated into task management. Messaging between individual team members should be consistent across teams but groups isolated by project so as not to create cross-project noise. Reporting and accountability tracking are crucial, as well as monitoring of individual performance (from commits) vs time and customer budgets. That's probably the most complex system I had to build to manage my teams: staying within customer budgets, developer available bandwidth and accountability. I built everything based on mostly open sourced components and tied them together with my own code based on rapidly evolving needs as customers arrived and left over the years. There are purchased apps and services out there that provide comprehensive albeit expensive solutions.
Do not try to "manage" them, but try to help them achieve their goals. Be the enabler, ask them what they need to complete their tasks, and make it a priority everyone is able to function at their peak.
This of course setting up shared calendars, VC software/hardware, DVCS, and so on on the techinical side. People should be able to see what they are supposed to do, reach their peers for information, and gather together to talk about updates, and have ideas (on the VC).
On the personal side, try spending some time with each member every week. Communicate what is expected of them, and let them tell you their worries.
As long as you have competent developers, they should be able to handle the job. If you do you job well, they will not even realize you're there.
The developers must be sufficiently experienced that they can manage themselves. You can coordinate and advise, but you can't do classical "management" if you are not there. If they are good, you are good. But if someone hired the cheapest that could be found, then you are "up the preverbial polluted waterway without a means of propulsion".
In most big companies, matrix management does not work. But if you have good people, almost anything can work. 8-)