There are two things I wish I had known as I started out in my career: what my manager expects of me as an employee; and why s/he expects that of me.
The interested employee can figure out the easy expectations: do good work, meet your deadlines, keep your word, be a team player. The inquisitive one can even get to the subtler ones: listen to your boss, understand his goals and make him look good. But many are the slips between the cup and the lip: reading or hearing about something is not the same as knowing it; knowing something is not the same as doing it, and neither is wanting to do something; and doing something is not the same as doing it well. How then does one know what to do and then do it well?
Use your values as a guide, a mentor once told me but that only led to a deeper question: what are my values?
Some values in life we acquire through unquestioning osmosis: from our parents, friends, the ethos; some we “choose”, driven by rebellion, individuation, the unexplored life of the parent; and others we adopt for purely utilitarian purposes. Whatever the reason, it is only over the years that we (perhaps I should say ‘I’) begin to understand truly what a value means, why we chose it, the impact it has on our lives and its effect on those around us. What then is a young knowledge worker to do?
One could faithfully follow a set of rules, say, to ‘make one’s boss happy’; but that way lies the road to short lived success, puzzling career stagnation, decision making that is agonizing and a feeling of being lost. Working at understanding and aligning the expectations at work with one’s personal values is a more rewarding way to shape career and character; but values take years to seep into our consciousness, grow roots and bloom in their full glory, and need constant and careful nurturing and nourishment. Expectations, on the other hand, are full blown and immediate. So, as I caution you on the perils of second-hand wisdom, and with the confidence that you will look to yourself to validate the truth of what I am saying, here are a few things that I learned about expectations:
Know Your Job
In my entire career, I have never had the pleasure of having my job defined for me (I can only imagine what such a Utopia would be like). Unlike the job of, say, a cashier at a movie theater, the software engineer comes into a job that has no real definition. I’ve sometimes asked, only to receive responses like a crisp “figure it out” or a half-joking “what am I paying you for if I have to tell you?” The interesting thing is that even the manager, the person hiring you, can only give you the broad outlines – “you will be part of the Cloud Infrastructure Group” or that you will “work on building the next version of our product”; what that means is for you to figure out.
If you are a young engineer, you may need to establish your credentials with the team lead to get a meaty assignment.1 You may then have to understand, choose the right technology for and design the module you are given such that it fits into the overall framework of the project (for which you need to broadly grasp the framework itself, and that may not even exist yet). You may have to provide estimates, call out milestones and lay down measurable progress markers. You may have to communicate your design to your team mates and gain their approval; understand their modules and make sure that yours is compatible; you may even have to interact and gain cooperation from other teams or members of another division. You may have to write the documentation or work with the ID team to get it right; you may have to run unit tests and write test cases for the QA team to accept the module for testing. You may have to prepare reports and presentations to show to your manager and his peers and bosses.
Or you can sit in your cube, browse the web and wait for work to be assigned to you. You can carefully listen to the requirements, finish it exactly the way it was communicated, on time and go back to waiting for your next assignment.
Both are feasible options. You won’t get fired for following the second option; but I doubt you will learn anything new. Your manager certainly won’t be looking at you as the one who gets things done. Your colleagues will be more than happy that you are not competing with them2 or showing them up; you’ll be a nameless, if dependable, cog in the machine of software development. But here’s the worst part: your manager will never tell you that you are one.3
I spent a significant chunk of my early career waiting for my next assignment: as long as I am being paid, it’s the company’s (or my manager’s) responsibility to make sure that they are getting their money’s worth, I figured. What was assigned to me was completed on time, correctly and to specifications. But little did I realize that by not defining my role to be bigger than was assigned, I was wasting precious time and missing significant opportunities at work, with not one adverse reaction from anyone around me4.
Why this is so is a little complex: your manager does not want to lose you because even in this bad economy, with all the outsourcing, the job market for even mediocre software engineers is pretty good. S/he is not going to say anything that might make you leave. Many managers have learnt the hard way that people are sensitive, and accepting criticism equably is a rare quality. I have gone to managers and said, "Tell me when I am doing something wrong because I LOVE to learn" and still the worst I ever got was "everything is great"; it's a really strange phenomenon.
Another reason could be that your manager himself doesn't know what to expect; it happens. First line managers who have lost touch with development sometimes have no idea what to expect in a project and completely rely on the team lead to do the "technical management"; the performance reviews5 then become a magical combo of gut feel, feedback from the team lead and your personal relationship with the manager. Many managers are also into 'empire building' -- they are looking at not losing anyone and making their teams bigger because that's their ticket to the next level in management. So, just because you are getting paid and your manager seems happy is not an indication that you are doing well*; and not getting criticized doesn't mean that you are meeting the job's expectations.
'Knowing your job' then, becomes these two things: one, you should meet the basic requirements of the job: know the current technologies, be able to follow directions, work in a team, communicate ideas and not need to be micro-managed. And two, and this where most people stumble, is the ability to define your job. This is not a stretch for a software engineer; as I said at the beginning, almost6 no project is handed out with everything defined and well laid out. So if you take the opportunity, the first option, of exploring the project, learning about the problem, fleshing it out, defining the boundaries, forming the solution or making it better by working with team -- you are defining your own job. In the process, if you can suggest how the modules that you have to interface with can be made better and help improve your team mates’ output -- you are defining a role for yourself that is bigger than just that of a programming cog -- you are becoming a leader!7
Having done your job well and having lent a hand to your team mates, there is one more thing that you can add to your definition of your job: help your boss shine.8
Your boss comes to you with a skeleton definition; now, instead of merely dressing that up in rags, if you can flesh it out fully because you are more in touch with the current technologies, are aware of what the industry trends are and what the competing products are doing; if you can give it back to the manager, not just having met the expected milestones but with enhancements that have a direct business impact or that give the product a leg up on the competitors through better technology, you are meeting a need that your manager had only dreamed of having fulfilled9
None of this is going to be easy: you will face resistance from peers, pushback from seniors, questions from your manager and if you are doing things right, find yourself out of your depth. But that's what the job is; that's what no manager is going to tell you to do but every manager expects; and that's the only way to success.
I originally intended this post to contain several other thoughts but it soon became so unwieldy that I decided to split it up into multiple posts. You should see them in part II of this post.
1 How you do this is up to you. You may want to dazzle the team with your knowledge during lunch; talk about the previous projects you worked on and technologies you used; point them to your open source contributions; volunteer to help team members with something they are struggling with; host brown bag talks on technology; or just schedule a 1-1 with the team lead, tell him what part of the project you are interested in and why you are a good candidate for the job
2 This obviously depends on the kind of colleagues you have. If you are lucky enough to be working with people who are all equally driven and competent, this may not be an issue. I will say more about choosing workplaces in a future post
3 Again, if you are lucky enough to have an enlightened boss, AND you have shown yourself to be someone open to receiving constructive criticism, this may not be an issue. But I think it's easier to find a team full of exemplary colleagues than a boss who knows how to nurture with criticism
4 Perhaps it was (is) a bit naive of me to expect that someone should care. I certainly believe that the desire to excel or succeed must first come from the employee; but I also think that there is many a young fire that is left to die out due to the lack of a guiding and protective hand
5 Such as they are. PR is a topic worthy of a post of its own
* What is a good indication? No raises. A good worker always gets raises, unless the company is clearly not doing well. In which case, why are you there?
6 Inevitably, there will be projects and companies where modules are handed out with everything specified to the last data structure. However, if you are working in a company that is making products (as opposed to ones maintaining them or fixing bugs) you will almost never have anything close to a specification that you have not written yourself, and even then, it will change a dozen times as the project progresses
7 I have to warn you that this is not as much of a victory lap as I make it sound to be; being thought of as a leader requires genuine qualities of humility, equanimity, knowledge and keeping the success of the team above yours, among others; not to mention dealing with the ambitions of your team mates
8 This may be seen as kissing your boss's a** but that's the job! Making your boss look good is good for the team: it means his team works well, s/he is able to suggest new solutions, deliver results on time and meet his/her own boss's expectations and the organization's goals. When you have his back on technology questions, you make the team look good. If your boss takes a hit, the team does too, because whether you like it or not, your boss is your representative. When you make your boss look good, you are really taking care of yourself.
9 Trust me: every manager is waiting for an employee who can take more responsibility, deliver results, fill in the holes in his knowledge and make the team better. S/He cannot express disappointment that none of his current team members display those traits but that doesn't mean that every night isn't spent with a hope that the morning will bring in this savior into the team