Posts Tagged ‘culture’
For me, 1984 was the year of Van Halen’s wonderful [sic] album, The Right Stuff, and my second semester of college. It would also prove to be a time of enlightenment for me and computing. On this 30th anniversary of the Apple Macintosh on January 25 and the Superbowl commercial on January 22. I wanted to share my own story of the way the introduction of the Macintosh profoundly changed my path in life.
Perhaps a bit indulgent, bit it seemed worth a little backstory. I think everyone from back then is feeling a bit of nostalgia over the anniversary of the commercial, the product, and what was created.
High School, pre-Macintosh
Like many Dungeons and Dragons players my age, my first exposure to post-Pong computing was an Atari 800 that my best friend was lucky enough to have (our high school was not one to have an Apple ][ which hadn’t really made it to suburban Orlando). While my friends were busy listening to the Talking Heads, Police, and B-52s, I was busy teaching myself to program on the Atari. Even though it had the 8K BASIC cartridge it lacked tape storage. Every time I went over to use the computer I had to start over. Thinking about business at an early age (I suppose) I would continue to code and refine what I thought would be a useful program for our family business, the ability to compute sales tax on purchases from different states. Enter the total sale, compute the sales tax for a state by looking up the rate in a table.
My father, an entrepreneur but hardly a technologist, was looking to buy a computer to “automate” our family business. In 1981, he characteristically dove head first into computing and bought an Osborne I. For a significant amount of money ($1,795, or $4,600 today) we owned an 8 bit CPU and two 90K floppy drives and all (five) of the business programs one could ever need.
I started to write a whole business suite for the business (inventory, customers, orders) in BASIC which is what my father had hoped I would conjure up (in between SATs and college prep). Well that was a lot harder than I thought it would be (so were the SATs). Then I discovered dBase II and something called a “database” that made little sense to me in the abstract (and would only come to mean something much later in my education). In a short time I was able to create a character-based system that would be used to run the family business.
To go to college I had a matching Osborne I with a 300b modem so I could do updates and bug fixes (darn that shipping company–they changed the rate on COD shipments right during midterms which I had hard-coded!).
College Fall Semester
I loaded up the Osborne I and my Royal typewriter/daisy wheel/parallel port “letter quality” printer and was off to sunny Ithaca.
Computer savvy Cornell issued us our “BITNET electronic mail accounts”, mine was TGUJ@CORNELLA.EDU. Equal parts friendly, memorable, and useful and no one knew what to do with them. The best part was email ID came printed on a punch card. As a user of an elite Osborne I felt I went back in time when I had to log on to the mainframe from a VT100 terminal. The only time I ever really used TGUJ was to apply for a job with Computer Services.
I got a job working for the computer services group as a Student Terminal Operator (STO). I had two 4 hour shifts. One was in the main computer science major “terminal room” in Upson Hall featuring dozens of VT100 terminals. The other shift was Friday night (yes, you read that correctly) at the advanced “lab” featuring SGI graphics workstations, IBM PC XTs, an Apple Lisa, peripherals like punch card machines, and a 5′ tall high-speed printer. For the latter, I was responsible for changing the ribbon, a task that required me to put on a mask and plastic arm-length gloves.
It turned out that Friday night was all about people coming in to write papers on the few IBM/MS-DOS PCs using WordPerfect. These were among the few PCs available for general purpose use. I spent most of the time dealing with graduate students writing dissertations. My primary job was keeping track of the keyboard templates that were absolutely required to use WordPerfect. This experience would later make me appreciate the Mac that much more.
In the computer science department I had a chance to work on a Xerox Star and Alto (see below) along with Sun Workstations, microVAX mini, and so on. The resources available were an incredible blessing to the curious. The computing world was a cacophony of tools and platforms with the vast majority of campus not yet tapping into the power of computing and those that did were using what was most readily accessible. Cornell was awash in the sea of different computing platforms, and to my context that just seemed normal, like there were a lot of different types of cars. This was especially apparent from my vantage point in the computer facilities.
One experience with a new, top-secret, computer was about to change all that.
I ended up getting to use a new computer from an unidentified company. One night after my shift, a fellow STO dragged me back to Upson Hall and took me into a locked room in the basement. There I was able to see and use a new computer. It was a wooden box attached to a wall with an actual chain. It had a mouse, which used on the Xerox and Sun workstations. It had a bitmap screen like a workstation. It had an “interface” like the Xerox. There was a menu bar across the top and a desktop of files and folders. It seemed small and much more quiet than the dorm-refrigerator sized units I was used to hearing.
What was really magical about it was that it had a really easy to use painting program that we all just loved. It had a “word processor”. It was much easier to use than the Xerox which had special keys and a somewhat overloaded desktop metaphor. It crashed a lot even after a short time using it. It also started up pretty quickly. Most everything we did with it felt new and different compared to all the other computers we used.
The end of the semester and exams approached. The few times and couple of hours I had to play with this computer were exciting. In the sea of computing options, it was definitely the most exciting thing I had experienced. Perhaps being chained to the wall added to the excitement, but there was something that really resonated with us. When I try to remember the specifics, I mostly recall an emotional buzz.
My computing world was filled with diversity, and complexity, which left me unprepared for the way the world was going to change in just the next six weeks.
To think about Apple’s commercial, one really has think about the context of the start of the year 1984. The Orwellian dialog was omnipresent. Of course as freshman in college we had just finished our obligatory compare/contrast the dystopian messages in Animal Farm, Brave New World, and 1984 not to mention the Cold War as front and center dialog at every turn. The country emerging from recession gave us all a contrasting optimism.
At the same time, IBM was omnipresent. IBM was synonymous with computing. Sure the Charlie Chaplin ads were great, but the image of computing to almost everyone was that of the IBM mainframe (CORNELLA was located out by the Ithaca airport). While IBM was almost literally the pillar of innovation (just a couple of years later, scientists at IBM would spell IBM with Xenon atoms), there was also great deal of distrust given the tenor of the time. The thought of a globally dominant company, a computer company, was uncomfortable to those familiar with fellow Cornellian Kurt Vonnegut’s omnipresent RAMJAC.
Then the Apple commercial ran. It was truly mesmerizing (far more so to me than the Superbowl). It took me about one second to stitch together all that was going on right before my eyes.
Apple was introducing a new computer.
It was going to be a lot different from the IBM PC.
The world was not going to be like 1984.
And most importantly, the computer I had just been playing with weeks earlier was, in fact, the Apple Macintosh.
I was so excited to head back to the terminal rooms and talk about this with my fellow STOs and to use the new Apple Macintosh.
Upon returning to the terminal room in Upson, Macs had already started to replace VT100s. First just a couple and then over time, terminal access moved to an emulation program on Macs (rumor had it that the Macs were actually cheaper than terminals!).
My Friday night shift was transformed. Several Macs were added to the lab. I had to institute a waiting list. Soon only the stalwarts were using the PCs. I started to see a whole new crowd on those lonely computer nights.
I saw seniors in Arts & Sciences preparing resumes and printing them on the ImageWriter (note, significantly easier to change the ribbon, which I had to do quite often every night). Those in the Greek System came by for help making signs for parties. Students discovered their talent with MacPaint pixel art and fat bits. All over campus signs changed overnight from misaligned stencils to ImageWriter printouts testing the limits of font faces per page.
I have to admit, however, I spent an inordinate amount of time attempting to recover documents that were lost to memory corruption bugs on the original MacWrite. The STOs all developed a great trouble shooting script and signs were posted with all sorts of guesses (no more than 4 fonts per document, keep documents under 5 pages, don’t use too many carriage returns). We anxiously awaited updates and students would often wait in line to update their “MacWrite disks” when word spread of an update (hey, there was no Internet download).
In short order, Macintosh swept across campus. Cornell along with many schools was part of Apple’s genius campaign on campuses. While I still had my Osborne, I was using Macintosh more often than not.
The next couple of years saw an explosion of use of Macintosh across campus. The next incoming class saw many students purchasing a Mac at the start of college. Research funds were buying Macs. Everywhere you looked they were popping up on desks. There was even a dedicated store just off campus that sold and serviced Macs. People were changing their office furniture and layout to support using a mouse. Computer labs were being rearranged to support local printers and mice. The campus store started stocking floppy disks, which became a requirement for most every class.
Document creation had moved from typewriters and limited use of WordPerfect to near ubiquitous use of MacWrite practically by final exams that Spring. Later, Microsoft Mac Word, which proved far more robust became the standard.
The Hotel School’s business students were using Microsoft Mac Excel almost immediately.
The Chemistry department made a wholesale switch to Macintosh. The software was a huge driver of this. It is hard to explain how difficult it was to prepare a chemistry journal article before Macintosh (the department employed a full time molecular draftsman to prepare manuscripts). The introduction of ChemDraw was a turning point for publishing chemists (half my major was chemistry).
It was in the Chemistry department where I found a home for my fondness of Macintosh and an incredibly supportive faculty (especially Jon Clardy). The research group had a little of everything, including MS-DOS PCs with mice which were quite a novelty. There were also Macs with external hard drives.
I also had access to MacApp and the tools (LightSpeed Pascal) to write my own Mac software. Until then all my programming had been on PCs (and mainframes, and Unix). I had spent two summers as an intern (at Martin Marietta, the same company dBase programmer Wayne Ratliff worked!) hacking around MS-DOS writing utilities to do things that were as easy as drag and drop on a Mac or just worked with MacWrite and Mac Excel. As fun as learning K&R, C, and INT 21h was, the Macintosh was calling.
My first project was porting a giant Fortran program (Molecular Mechanics) to the Mac. Surprisingly it worked (perhaps today, equally surprising was the existence of a Fortran compiler). It cemented the lab’s view that the Macs could also be for work, not just document creation. Next up I just started exploring the visualizations available on the Mac. Programming graphics was all new to me. Programming an object-oriented event loop seemed mysterious and indirect to me compared to INT 21h or stdio.
But within a few hacking sessions (fairly novel to the chemistry department) the whole thing came together. Unlike all of the previous systems I used, the elegance of the Mac was special. I felt like the more I used it the more it all made sense. When I would bury myself in Unix systems programming it seemed more like a series of things, tricks, you needed to know. Macintosh felt like a system. As I learned more I felt like I was able to guess how new things would work. I felt like the bugs in my programs were more my bugs and not things I misunderstood.
The proof of this was that through the Spring semester my senior year I was able to write a program that visualized the periodic table of the elements using dozens of different variables. It was a way to explore periodicity of the elements. I wrote routines for an X-Y plot, bar charts, text tables, and the pièce de résistance was a 2.5-dimensional perspective of the periodic table showing a single property (commonly used to illustrate the periodic nature of electron affinity). I had to ask a lot of friends who were taking computer graphics on SGIs for help! Still, not only had I just been able to program another new OS (by then this was my 5th or 6th) but I was able to program a graphical user interface for the first time.
MacMendeleev was born.
The geek in all of us has that special moment when at once you feel empowered and marvel at a system. That day in the spring of 1987 when I rendered a perspective drawing from my own code on a system that I had seen go from a chained down plywood box to ubiquity across campus was magical. Even my final report for the project was, to me, a work of art.
The geek in all of us has that special moment when at once you feel empowered and marvel at a system.
It wasn’t just the programming that was possible. It wasn’t just the elegance and learnability of the system. It wasn’t even the ubiquity that the Macintosh achieved on campus. It was all of those. Most of all it represented a tool that allowed me to realize some of my own potential. I was awful at Chemistry. Yet with Macintosh I was able to contribute to the department and probably showed a professor or two that in spite of my lack of actual chemistry aptitude I could do something (and dang, my lab reports looked amazing!). I was, arguably, able to learn some chemistry.
I achieved with Macintosh what became one of the most important building blocks in my education.
I’m forever thankful for the empowerment that came from using a “bicycle of the mind”.
I’m forever thankful for the empowerment that came from using a “bicycle of the mind”.
What came next
Graduate school diverged in terms of computing. We used DEC VMS, though SmallTalk was our research platform. So much of the elegance of the Macintosh OS (MacApp and Lisa before that) was much clearer to me as I studied the nuances of object-oriented programming.
I used my Macintosh II to write papers, make diagrams, and remote into the microVAX at my desk. I also used Macintosh to create a resume for Microsoft with a copy of Microsoft Word I won at an ACM conference for my work on MacMendeleev.
I also used Macintosh to create a resume for Microsoft with a copy of Microsoft Word…
When I made it to Microsoft I found a great many shared the same experience. I met folks who worked on Mac Excel and also had Macs in boxes chained to tables. I met folks who wrote some of those Macintosh programs I used in college. So many of the folks in the “Apps” team I was hired into that year grew up on that unique mixture of Mac and Unix (Microsoft used Xenix back then). We all became more than converts to MS-DOS and Windows (3.0 was being developed when I landed at Microsoft).
There’s no doubt our collective experiences contribute to the products we each work on. Wikipedia even documents the influence of MacApp on MFC (my first product contribution), which was by design (and also by design was where not to be influenced). It is wonderful to think that through tools like MFC and Visual Basic along with ubiquitous computing, Windows brought to so many young programmers that same feeling of mastery and empowerment that I felt when I first used Macintosh.
Fast-forwarding, I can’t help but think about today’s college students having grown up hacking the web but recently exposed as programmers to mobile platforms. The web to them is like the Atari was to me—programmable, understandable, and fun. The ability to take your ideas, connect them to the Internet, touch your creation, and make your own experience must feel like building a Macintosh program from scratch felt like to me. The unique combination of mastery of the system, elegance of design, and empowerment is what separates a technology from a movement.
Macintosh certainly changed my path in life…
For me, Macintosh was an early contributor to my learning, skills, and ultimately my self-confidence. Macintosh certainly changed my professional path in life. For sure, 1984 was not at all like 1984 for me.
Yes, of course I’m a PC (and definitely a Surface). Nothing contributed more to my professional life than the PC!
PS: How far have we come? Check out this Computer Chronicles from 1985 where the new Macintosh is discussed.
In what could be considered an extremely bold and thoughtful move, according to reports Yahoo recently announced that employees will be required to work from a Yahoo facility rather than “remote”. As one who has spent time on these challenges, the commentary that followed was arguably predictable. With reactions ranging from tone deaf and archaic to downright anti-motherhood, there seems to be a great deal of pushback or at least feedback. Like so many things in managing a large organization there is no clear cut way to manage through this structural and organizational challenge.
What are some of the considerations in attempting to structure a modern product development team?
The key challenge in implementing any policy in a corporation is to balance the needs of the individual, the needs of the team, and the needs of the company and shareholders. As one might expect these needs are not always in alignment at the granular level. Even at the macro level it is not always clear, for example, that everyone comes to work to maximize shareholder value on any given day or that choices each party might make to accomplish that would be aligned.
In balancing these needs, a company also has the obligation to be consistent, and have a view as to why an approach is fair for a set of parties involved. This is about balancing fair across many dimensions—all parts of a company should follow the same basic set of rules/guidelines, rules/guidelines should be the same regardless of your position in the organization or type of role, geography should be implemented consistently (while adhering to local laws as well), and so on. Nothing eats away at an organization as a whole more than the feeling that one part of a company gets a better deal than another part. On the other hand when taken down to an individual level what is consistent is not always viewed as fair by some.
One of the main ways companies tend to deal with controversial or cultural issues is to empower managers throughout an organization to “do the right thing” or as it is called in the military “commander’s intent”. Netflix’s famous expense policy is a supremely good example of this approach (imho). The basic idea with this approach is that deciding at a top-most level is not optimal and so this approach allows for optimal or situational decision making where the only management communication is based on an end-state not the details (“ship great products and have a strong organization”). It also tends to optimize for the least amount of consistency across a large organization and thus potentially causes some amount of underground friction. What is laudable about the Yahoo position is that it is a clear choice from the top of the company, whether you agree with the policy or not you cannot argue that it expresses a clear point of view which is worth noting.
It is extraordinarily difficult to argue against having a flexible workstyle/workforce/team, where flexibility is defined by a whole host of dimensions. A modern product is used by a whole world of people (hundreds of millions) and there is every reason to consider that a product used so broadly should be developed by a team that is representative of the breadth of usage. Flexibility in work location is one dimension and the focus of this post and the Yahoo policy (and this post).
People ask for flexibility for a whole variety of reasons: work better from home, required to live far from an office (across the bay to across the country to across the ocean), special needs more easily serviced at a different location, worked on a project full time and needed to move, spouse/family needs (permanent or part time), or even just a feeling that there’s no need to go into an office. Those are just a few. In fact the list of motivations for working from home/remote is probably at least as long as the number of people on a team who appreciate this arrangement.
Particularly for software projects, and extra-particularly for modern cloud-based products, it seems almost absurd on the face of it not to build the products from a flexible team. In fact most of the products even target the very notion of flexible work environments—so the irony of not following that doctrine to build the product is not lost.
So why all the complexity and challenges?
Ultimately there are a bunch of considerations to take into account, none of which is easily reconciled. The flipside is that all of them can be reconciled in the specific. Therein rests the core challenge faced by a company—what if everyone says they will do the right thing, yet the net result is not the right thing for the company as a whole? What if there are a plethora of examples and counter-examples for a given policy? Everyone who works or supports someone remotely has the very best of intentions. That’s a given. Yet there must be more to this given the changes reported at Yahoo (or policies at other companies) and the dialog.
In an effort to spark some dialog, it seems reasonable to offer some of the challenges that a large organization faces with respect to flexible work. That’s what this post is about, a dialog, and not advocating one point of view or another. In fact I am writing this post living this very challenge personally right now with geographically dispersed commitments and folks willing to support me in those, and I see some of the issues discussed.
I’ve worked on teams which have been geographically split, where people have worked from sites all around the world, and where individuals have had a wide variety of special arrangements. It has never been as easy as “just being modern” and there were always extra work required. And there was always extra benefit as well. Talented people making world class contributions have worked in flexible arrangements on those projects. Some worked temporarily. Some worked permanently. Some set out to work for a short time or permanently and changed paths.
In almost all cases one or more of the following challenges were or became part of the dialog.
Collaboration. Software is a highly collaborative process. To develop software requires collaboration across multiple dimensions. Programmers need to collaborate up and down the stack, across API boundaries, and more. These boundaries evolve rapidly while a system is being developed and the evolution does not often take place through code checkin or over email. Collaboration takes place across disciplines and more often than not those are meetings that take place in person and just as often they are not scheduled. Developers, testers, program managers, operations, designers, and more need to talk frequently in an ad hoc manner. Do you tune the amount of flexible work a team supports based on some measure of how much collaboration the product/project requires? Is it reasonable to assume that the same amount of collaboration can happen between co-located teammates as remote teammates? How much of collaboration is intrinsically based on proximity?
Disciplines. One of the challenges is that different disciplines require different levels of collaboration in a typical project or workday. While every discipline is inherently collaborative, one could (and many do) argue that there are more solitary hours in coding or writing than there might be in design or testing, for example. There are certainly very few solitary hours in being a manager or being a product/program manager. Do you have an approach where some disciplines can have more flexible workstyles than others, for example? How does that feel to the rest of the team when motivations for flexible workstyles arise independent of job function?
Integration / consistency. Customers and reviewers consistently ask for more product integration and better product synergy. By almost all accounts, the “farther apart” members of a project are the more difficult this integration and consistency becomes. You can see this even when it comes to internet discussions about org charts or management structures. The root of this is because consistency and integration come from building highly collaborative give-and-take relationships and those relationships get built and maintained through a great deal of personal contact. Do you tune the amount of flexible workstyles to support based on the measure of integration you want across products or assign people differently (perhaps differently than their skillsets) based on the needs for integration across products?
Ship the org chart. A common phrase used in building software from a large organization is to take care to avoid “shipping the org chart”, which basically means to do what you can to structure a team such that the org chart does not show through in developing the product (a subject of a future post, I promise). Because product development has the potential to evolve differently when people are not in physical proximity there is the potential to mimic what would happen if there was an org design, regardless of the actual line manager. Despite a long history (and requirement) of remote work, even Boeing is reportedly struggling with this aspect of 787 production at the organizational level. When organizing a project, do those members of the team working remotely need to be assigned to projects differently to mitigate the org-distance challenges of remote work?
Turnaround to answers. A big part of a collaborative project is the timeline of asked and answered. Even in the same hallway, you can’t always get an answer from someone (despite the perception, people might not be literally chained to a desk). So the question becomes what is the turnaround time for an answer. If a person is working flexibly 40 hours a week during core working hours, then the expected turnaround should be quick (another source of flexibility is what hours, most every company has some notion of core hours, though the days of at your station by 8:00AM like Intel might be history). On the other hand, some flexible arrangements are 4 days at 10 hours each or even 3 12 hour days (putting aside part time which is another flexible workstyle). The question then becomes one of whether the team is blocked because it is a flex day? Of course this is no different than a person being out sick or on vacation, and some say that it is easier to work around a regular schedule. This challenge extends to teammates in different time zones as well—the further away the less core hours overlap. Should a team be structured with expectations of turnaround, even if it interferes with the stated goals of flexible workstyles?
Shared mindset / point of view. So much of building a software project is about the emotional connection shared by members of a team. The feeling of community, shared goals, and culture are all part of a team. Remote members of a team, by definition will always miss out on elements of this—not just the hallways and meetings, but lunch, voluntary social time, and more. These are just the nature of human beings and how we build community and evolve. As much as we talk about video conferencing, air travel, or just “days on site”, we all know the challenges of just picking up where you left off the last time you saw folks. How does a team continue to develop and evolve a shared point of view with some members of the team not physically present?
Career velocity. If your organization supports flexible work, then it goes without saying that performance appraisal, compensation, promotion, etc. should all be exactly the same whether you are working remotely or not. This is obvious, but not without challenges. For the disciplines that are highly collaborative or projects that are less about individual effort and more about team effort how do you account for the different number of hours spent doing the in-person work these require? Do you structure remote work so it requires less of this type of collaboration? Then do you choose people or projects suite to that? How would you explain the policy regarding approval for remote work?
Peer evaluation. Most employees participate in a peer review process, both offering and receiving feedback. In some sense full-time remote employees can benefit from the most pure form of evaluation in that literally only the work is evaluated. On the other hand, when a large portion of the work involves the process by which choices are made and the way the end-point is reached, the need to participate on equal footing with the team is important to peer feedback. How does peer evaluation work for the “process” or the “how” of the work not just the output?
Management. Managing remote teammates or being managed remotely are both challenging. The more senior you are the less you need (or want!) to interact with your manager, but that is not always a two-way street. Some managers like a high touch team, especially in some disciplines or some phases of a project. Some employees do better work when they can talk with their manager for a few minutes in an ad hoc manner. Newer employees require nearly daily contact/coaching from their manager. What if the manager is not on site or if the employee is not on site? Sometimes “new” does not mean new to the workplace, but just new to the project (or a new project) or just new to the domain. How do you factor in management and being managed into a remote workstyle?
Individual skills. Most any discussion of remote or flexible work hinges on the individual skills of the person working in this style relative to the needs of the team. This makes a ton of sense—any team should be staffed and organized taking into account the capabilities of the individuals on the team. The challenge becomes implementing this in a fair and consistent manner when it comes to remote work. How do you articulate the criteria for being permitted to work remotely? How do you avoid any sort of criteria from being gamed or politicized?
Accountability. Ultimately, any team functions well when accountability is clear and everyone on the team is signed up for their part of the project in terms of delivery, timeliness, and quality. Remote or not, this should not change. But projects do not always go well. When things don’t go well, the team as a whole looks for reasons. One of the darker aspects of remote work is that it becomes a variable that itself gets evaluated in context of work that was not what everyone (including the member of the team) hoped for. How do you account for the variable of remote work when things don’t go well? What happens if you identify working remote as a causal factor? Is it really a causal factor or just a difference? Is the accountability of the manager or the remote employee or the team for not working in a way consistent with the remote employee?
Life changes. Many of the motivations for remote work stem from life changes. Our society is highly mobile these days and so people choose to move to other cities/countries for a whole variety of reasons. Housing prices are crushing in much of the world and so commutes can be awful and wasteful. Spouses also work in most American families and that creates a variety of possible motivations for flexible work. Families grow and the need for one parent to be at home beyond the statutory parental leave is a strong motivator for flexible work. Life happens and perhaps someone needing care moves in with you or you yourself require major life adjustments and flexible work becomes necessary. How do you craft a policy around flexible work that accounts for these life changes that may be temporary or permanent? Given all of the above potential challenges, what is the right way to address the specifics of life? Do these life changes call for a separate policy or approach?
These are some examples. There are many more because there are so many individual circumstances. All of them can be painted in stark terms with obvious answers if that’s your goal. The truth is that at a policy level they can all be dealt with. But at an individual level this always becomes a special case. That’s just the complexity of a large organization. It why there is no easy answer and certainly no right answer. Companies ultimately can choose to differentiate themselves on policies in this regard, as is the case with any workstyle, work culture attribute (dress code, parking, office style), or even compensation or perq.
Proof flexibility works
In any discussion of flexible work, the proof point of large successful open source projects is raised. In some ways this discussion can bubble up to the difference between developing a product in a company and developing a product that by definition and from the start is distributed in nature. It goes without saying that arguing against an existing proven success only adds to the difficulty. Are the challenges of flexible work, some outlined above, due to the very nature of corporate organizations? Or are the successes of the flexible work in open source projects rooted in the very nature of those projects?
There are also whole companies like 37signals or WordPress that are for-profit and foundationally about remote work. What practices do they have that make their experiences work for the team, product, or corporate interests? Are there attributes of the product that make flexible work easier or more supportable? Is that a design or code architecture difference?
Almost all of challenges described add up to expressing that teams build software. The larger the software the larger the team. The need to have a high performance team to build high performance products is obvious. Building and maintaining a high performance team is an incredibly difficult challenge. On the one hand the team wants the very best talent from wherever and however it can find it. On the other hand keeping the team operating in a holistic manner over time is hard enough as it goes through ups and downs of product development.
Whether you argue that a flexible work environment solves the talent side of the challenge or not is just part of the equation. How to manage the challenge of maintaining the team and product over time is the other side. As with so many product development and management challenges, knowing the challenge you face is a huge part of the work. Committing to address the challenges is critical. Just as critical is deciding where energy on the team is best spent—not every challenge is one the team should take on when faced with finite resources, time, and seemingly infinite business needs.
Product development, including team management, is a social science. That means there are no right answers but just approaches or choices in context.