What’s most important in enterprise IT?
What is the most important thing in enterprise IT?
Some may say, budget. Others, the timely adoption of new technologies.
Not really.
The best technologies may fail and the lushest budget be wasted by human efforts gone astray.
Imagine several new college graduates hired by a big company, as software developers. They can all write code, create design specifications, search information to solve difficult problems. It seems that they have everything they need to settle down and start being productive, right?
Not really.
Andrew Begel from Microsoft and Beth Simon from the CS department of the University of California, San Diego, conducted a study to find out what new hires, recent college graduates, experience at Microsoft while they are, as it is called at Microsoft, “onboarding”. The study subjects could all write code, read documentation and troubleshoot complicated issues perfectly well. But some other things hindered their work or caused frustration. This article contains some of Begel and Simon’s findings, some of my own experience and other people’s observations.
Communication
Large companies tend to have their own lingo, with lots of acronyms. It’s normal for a new hire to not understand any of what’s being said in the meetings, for the first few months. However, the new hires usually do not know that this is normal, and get scared. Some of them even start having doubts about their own sanity.
One of the biggest problems in enterprise communication is to know how and when to ask questions. New hires, in general, tend to be shy and not ask questions soon enough. Sometimes they are not assertive enough to push for enough detail from other people. These communication problems often aggravate the technical problems. For example, a developer struggles with multiple issues (new operating system, new revision control system and a new API) but does not ask for help because he feels that he must do everything on his own, “to demonstrate his value to his manager”. Developers often have difficulties to know “when they don’t know” something. Because there is so much new infrastructure to learn, it becomes the norm to have only partial knowledge of a tool or some code. While this is their reality, it also leads many of them to fail to recognize when they are truly stuck and should ask for help.
English skills are a hindrance for some non-native speakers (and for people who have to communicate with them, of course). This is a problem, as there are many non-native speakers in Canadian IT. Non-native speakers may have difficulties understanding native English speakers or other non-native speakers with a different accent. Begel and Simon describe a case when homophones caused difficulty: someone used the word “pseudo” and a non-native speaker searched on a dictionary web site for “sudo,” a commonly-used Unix utility.
When people have problem understanding other people’s accents, they might ask to repeat once or twice, but after that they usually get shy and do not ask any more. They think that asking to repeat is impolite, or they might be afraid to ask for fear that other people see them as dumb. So they just say “uh-huh” when someone talks to them, hoping to get the missing information from written sources or from another colleague whom they understand better. Of course, it does nothing to improve their productivity.
- Anna, congratulations: your understanding of spoken English improved a lot.
- How do you know? You rarely talk to me anyway.
- You’ve stopped smiling and nodding all the time when people talk to you.
(A dialog between a software developer and her manager from Anna Levina’s “Marriage a la immigration”)
Collaboration
Often software developers are explicitly told that there is little written documentation on a feature, and that the original developers had left the team or the company, and that they are on their own with the issue.
Sometimes new hires are naïve in collaborating with others. This might mean that their “more senior” colleagues could dump additional work on them, or even sabotage their work for reasons of their own (“office politics”). Begel and Simon tell a story of a developer who “was interrupted and instructed by a colleague to make revisions in a report to be passed out at a meeting that day. The first time this happened, he accepted the demand, immediately stopping his current task and editing the report. As he settled in, he started negotiating with colleagues and even his manager about how many tasks he would take on, and when he would do them”. With time, new hires get more assertive and learn how to advocate their own efforts and ideas. (This is the best-case scenario.)
Cognition and orientation
Developers struggle to collect, organize, and document the wide range of information that they need to absorb. The process of taking notes is difficult sometimes, and pen on paper notes are difficult to search for the required information. New hires have to orient themselves in low information environments, which is often aggravated by lack of documentation or by poor documentation. Large companies assign mentors and “connection coaches” to new hires but these are often very busy and don’t have time for their mentees. The mentors hide behind closed doors of their cubicles or “work from home” and do not respond to e-mails and IM. So the new hires get no information, or receive incomplete information that increases their confusion. They are floundering on their own and have to search through tons of documents (often completely irrelevant because they took a wrong direction in their search) to find the required information.
Multiple policies that all have to be followed and numerous online trainings to be taken are also a hindrance. A new hire is not likely to know whether this policy is more important than that one. A mentor usually will tell her, “this one has to be strictly followed, and for this you can just make a token gesture”, but the mentor is not always available and the new hire struggles on her own. Often there are so many policies and trainings that she has to stay in the office late or take time from her actual work to fill online policy questionnaires and such.
Likewise, one of the important things mentor can do is to indicate issues that are not worth solving or somebody else’s problem so the new developer does not continue wasting her time on them.
Cultural differences
A team manager publishes his “Vision” for the team, a document that is supposed to be inspiring and boost their morale. Most team members read it and get filled with enthusiasm. However, one or two are disgusted and frustrated. What happened?
In the document, the team manager expresses his wish that the team members work together like cogs in a well-oiled machine. In the culture to which the team manager belongs, together with 80% of the team, this is a positive image. However, in the other culture calling someone a cog in a machine is basically saying that he is worthless, can be replaced at any moment and is not even a person but a dumb soulless piece of metal. Hardly an inspiring thought.
Misconceptions that hinder
Begel and Simon list the common misconceptions that hinder new hires’ adaptation:
1. I must do everything myself so that I look good to my manager. This misconception is particularly dangerous, especially in large, complex development environments. Mostly seen in new hires from outside the USA, the perceived need to “perform” and not “reveal deficiencies” makes for much wasted time.
2. I must be the one to fix any bug I see – and I should fix it the “right” way, even if I do not have time for it. This is one of the most ubiquitous misconceptions among recent graduates – likely driven by the lack of team-based development experience and the deadline-driven grading system of academia.
3. If there was only more documentation… Even though some of more experienced new hires accompanied these pleas with recognition that such documentation becomes stale quickly, they still wished that more existed.
4. I know when I am stuck when solving a problem. Based on explicit statements made by subjects and contrary to explicit observations, it is clear that new hires almost always waste time, effort, and money by flailing – and do not recognize that they are stuck.
What does that mean for educators, managers and mentors?
Ways to go:
More and better mentorship
Development of human connections (including those outside the team)
Showing people how they fit into the big picture
Improving alignment (show people how their goal and the goal of their team is aligned)
Courses on communication, emotional IQ, assertiveness
Courses in note-taking, mindmapping, visual ways of organizing information
Education on multicultural issues
Using handy apps (for example, WhatIs, IBM Lotus Sametime bot that responds with acronym definitions)
Tools to share information (enterprise blogging, wikis)
It might be worth it in some of the college projects to imitate working with legacy code, fixing bugs, etc. which might be closer to real life than writing an application from scratch.
- How did God manage to create the Heavens and the Earth in 6 days?
- Easy. He did not have to ensure compatibility with the previous version.
This article is partly based on:
March 31, 2010 - 11:34 pm
Quite interesting……and seems like it would be quite applicable to a variety of IT roles.
It also seems like it could be applied to a consultant coming into a company for the first time – expected to know a lot, not getting the documentation that would help, and not having the luxury of a mentor.
April 2, 2010 - 11:50 pm
Don, I agree, however consultants usually have more experience and people skills, i.e. they are less likely to waste time on tons of documentation and more likely to go talk to the right person. And they are probably more assertive than usual new hires / college graduates, otherwise they would not be consultants. And, it is just my impression and it might be wrong, the consultants have to do less corporate stuff, not directly related to work (like running a test on what are the IBMer’s “core competencies” where you have to list them, etc.) Therefore less time is wasted.