Who do you work for
I recently talked to a a doctor and during the dialog it came up that she's often torn between different responsibilities: what her administrator says, what her colleagues want, what the insurance demands, what she herself wants to do and what the patient needs. It's often hard to balance these demands, but one guiding principle that can help here is the question:
To whom is your duty?
When deciding what you do in your work, it can help to think about who benefits from something you do, who you actually work for. For doctors, this should definitely and always be the patient, but it often isn't since these other demands also exist. It's easy here, because helping patients is what doctors do, and the other demands are merely positioned around that activity. But even there, as we all know, doctors often don't prioritize helping their patients, opting instead for following administrative guidelines or their pride or their wallet or whatever.
For professional software developers, this question is much harder to answer. Who do we work for? What duty do we even have? Let's collect some thoughts.
Our options
Here are some of the options for whom we could be working. Each one brings with it different kinds of duties and we'll have to look at each other in more detail.
- Your immediate boss, ie. the person that supervises you and tells you what to do next. You might or might not even have one of those.
- Your non-immediate boss, ie. the person that supervises your team or division or whatever you're organized in. You most certainly have one of those.
- Your CEO, ie. the person that supervises the entire company, or substituted by one of the company C-level persons
- The owners of the company, be it private or stock-holder owners.
- Your immediate colleages and team-mates
- The buyers of your software, which might be different from the users of your software.
- The immediate users of your software, ie. the people that interact with the software you produce on a technical level, installing and handling it. Those might well be the end users, but in a business setting, this group is often separate from the next one:
- The users of your software, ie. the people that interact with the software as actual end users.
- The people whom your software concerns, ie. the people that the software is about. This might not apply in most circumstances, but a lot of software today is used by different people than the ones it is about. Anything that works with other persons' data here, eg. in the public sector, the banking industry or logistics.
- And finally: yourself.
Of course, each of these groups depends on the company, structure and product you work for. Some groups might not exist in your situation, or might not be relevant. You'll have to adapt to your circumstances, or write me an email and we'll talk about your specific situation.
Things will also be different for freelance developers and even more complicated for open-source developersAnd I'd love to see the essay asking this question for open source developers. I might write it some day. We will however not discuss it here., so for the moment let's go with regular salaried employees in this context.
Simplest answer: your boss
Someone tells you what to do and you do it. Good for you! I guess the only thing you have to watch out for is that your boss doesn't tell you to do something illegal. But in all other cases, your duty is simply to do what you're told. Not a lot of thinking is necessary here, and that may be a very unburdened life, if that's what you're after.
Believing in your boss can also create an awesome bond, and it's not unknown that people follow their bosses for entire careers. But it's also a bit out of style nowadays, where teams get mixed by the management every other month.
Your non-immediate boss
This is a much more balanced position than just doing what your supervisor tells you, yet isn't as un-practical as working towards a CEOs vision. Let's say you're familiar with your department head and you "work for her". You might interact with your immediate supervisor and your colleagues much more, but in tricky situations you might ask yourself "what is good for this department?" or even ask the department lead directly.
I think this is quite a healthy attitude.
The CEO
I'm sure there are developers who joined a company because of the charisma of its CEO or founder. Since one of the main jobs of a CEO is to create a shared vision, this might be a good thing. But it's also quite vague: your duty might be to make a vision into a reality, but the million steps in-between are much less clearThis is also the reason why I don't generally understand the reverence for modern CEOs. Their job is to make everyone go in the same direction, but that doesn't make them saints nor geniuses..