The Lounge - CodeProject

MSBassSinger1-Nov-23 7:28

1-Nov-23 7:28

To be clear, there are some jobs where there are clear, legitimate, reasons to have everyone in a specific location at least once a week. I am not addressing those here. I am using software development and testing as an example. I hope the discussion focuses on whether hybrid work is a good idea within that context or not.

If work can be done remotely 1 day a week or more, with the same or better level of quality and productivity as can be done in an office, then what value does hybrid bring? The hypothesis for debate in this posting is that a position should be 100% remote or 100% in-office, and that hybrid detracts from productivity and employee satisfaction.

Some common arguments for hybrid:
- Face-to-face in the office helps build team relationships. Face-to-face interactions do help build team relationships. But being in-office is not necessary for that. Use conferencing tools like Teams for two or more coworkers having a discussion and require that the video is on. Audio and video together greatly multiply the personal effects of interaction done remotely, to a degree near enough to in-office as to eradicate any in-office value from hybrid for this argument for hybrid.
- Being in-office ensures the person is working. Most of us who have worked for years in-office know how easy it is to appear to be working when in the office. In-office is no guarantee of productivity. Setting goals for each worker works much better. If goals are not met, then work with the worker to see if the goals were too optimistic, or if the worker needs some help to produce at a reasonable level. That works whether in-office or remote.
- As a manager or team lead, it is easier to walk over to a worker's cubicle or call him/her into my office to help build that manager/employee relationship. The same benefits can be had by scheduling a weekly meeting of 15 to 30 minutes with each of your reports using Teams (or whatever you use for that functionality). With both video and audio, the benefits of building that relationship via one-on-one meetings is just as present with remote as with in-office meetings.

Some common arguments against hybrid:
- The travel time for the employee is wasted time. A typical hybrid employee wastes 1 to 3 hours every day they travel into the office. Plus the cost of commuting. Getting rid of this pain for the employee improves employee loyalty and reduces turnover.
- Tracking each employee's schedule for when to be in the office or working remote is a burden on managers. Either the manager has to keep track of the schedule, opening opportunities for negative effects on work, or the schedule becomes a "one size fits all" that results in ad hoc changes that are also a burden to manage.
- Remote workdays are not just flexible for the employee, but also for the project. There are times an hour or two extra is needed to work on a project. If in the office, traffic and home obligations cause that extra time on a project to be missed or postponed.

The truth is that, in most cases, there is a non-technical (meaning not a software engineer, in this case) manager who is concerned that because they do not understand the technology and sociology of what their team does, the natural (and understandable) concerns arise that their reports may be taking advantage of their lack of knowledge and experience in the hands-on portion of the discipline. Add to that the management that they report to who, for lack of knowing better, have unreasonable expectations.

There is a common perception among non-technical management that developing software is a process of assembling widgets to build something. In fact, a lot of modern Agile is based on taking the manufacturing origins of Agile and trying to apply it to software development. In most manufacturing of material goods, the work done is assembling parts in a pre-described manner on a production line, requiring little, if any, creativity to ensure success. Software engineering is not like that. Software engineering includes some assembly of purchased third party components (the "buy" in the buy vs. build analysis), but usually around half to three-fourths involves applying engineering knowledge to the specific requirements of the project, which takes engineering knowledge and creativity. Software development is not an assembly line process, nor will it ever be.

That is the downside in having software engineers report to those who are not software engineers. Scrum masters, project managers, etc. rarely have the software engineering background to know how to do the work their team does. Unfortunately, this too often manifests with unreasonable expectations, a lack of trust of team members, and a lack of knowledge of how to effectively supervise and lead software engineers.

The two best ways to correct that imbalance are:
1. Hire experienced software engineers to be "hands on" team leads, scrum masters, and software project managers (combining roles into one position is a good idea where practical), with enough allotted time for the manager/team lead to be responsible for at least some of the coding. That garners respect and trust from the team members and provides a team lead/manager who truly understands what their team is doing, why they do it, and what it takes to complete a software project successfully. It is easier, and less expensive, to train a seasoned software engineer in managerial skills, how business works outside the technical areas, and how to relate to non-technical management.
2. Train the scrum masters and project managers in how to be software developers, so they understand what and why their reports do what they do. Having that ability in common, and even requiring some appropriate "hands on" work in the project will help that leader gain respect from the team, and respect for, and better understanding of, what their team does. This approach will take more time, as software engineering is a much more academically challenging discipline than what scrum masters and project managers normally deal with. But it can sometimes be worth the effort. An added bonus is that some team members will gladly help that leader in the learning process becauwse it now becomes a method of bonding manager to the ones being managed.

Welcome to the Lounge