I hope this post don't get deleted because this is a throw away. I didn't want to use my real username. It would be too obvious.
I know it is up to the person at the end of the day. Every person is different. But I'd like to hear some suggestions. Maybe it will lit a light
I am NAV developer for an end user. It has been 10 years I worked there. Here is a few things I like and I don't like about my job.
Things I don't like, or bother me
- We don't use NAV base functionality. Everything is customized and very specific to company's needs. I've been reading NAV 2013 material. The difference between the base product and what I work with is significant. I felt like I missed a good opportunity by not working with the base product.
- Almost 30% of what I do is about compliance. Some of it is for the government. And some of it for the internal compliance department.
- I deal with user support every day.
- I am responsible for code merging
- Developers are the go to points for support. However if a developer worked on a subject 3 years ago, he remains as the go-to person for issues. One part of is due to bad knowledge sharing. Other reason is because the actual developer builds sufficient experience so he can fix the issues quicker.
- I have had to deal with support when I was on vacation many times.
- Users want to click a button and NAV handle everything in one shot.
- BAs are very critical of NAV. And they don't even know (or bothered to learn) how to create a sales order in NAV. When there is a need for solution for a real problem, BAs generally offer an abstract solution to the problem. So finding the solutions is almost always up to the developers. We developed a lot functionality that base version doesn't offer. But I feel the appreciation is low. I suppose it is because there is nothing to compare for.
- BAs generally want to be done with the project and don't want to bothered by it again. However, all the remaining support and bug fixing is up to the developers.
- BAs don't know the business and NAV. So their requirements are either based on developer input. Or they simply copy-paste what users wanted to see. I almost never heard a BA that says "let's use/change this functionality" . Never heard a BA doing some "best practices" research on a business problem. They are acting like a middle-guy between the user and developer without adding too much value. I have had so many examples of BA creating a requirement document that has this "As product owner, I want system to do this" where "this" means almost the whole project.
- Workload is too heavy. We finish one project and move to another one. There is no time or plan to look back at what we do, and optimize or enhance them. Even if someone brings this to the table, his idea is recognized and appreciated, but it's not followed up. I have found myself thinking about work so often at evenings. or weekends.
- Company's balance sheet and income statement is prepared not according to the standards. So we deal with really really complex accounting reports.
- Every report has a storyline like this: 1) We need a report. 2) We need the report in excel 3) We don't want to run the report manually. We need system to generate it automatically. 4) Not only that, we want an email when the report is generated. Other requests have similar timeline as well. Some change request starts small and insignificant, and 6 months or 1 year later we put that little change as a critical part of another process.
- We have a NAV upgrade project. I thought about using base functionality more.. This means users will have to do more to achieve the same thing. But the direction seems to be about implementing the same things we worked over the last 10 years.
- I missed all the NAV versions starting 2013 and up. I learning about it by reading the documentation. But we know the real experience counts and things we read are forgotten.
- Jeans not allowed in the office
Things I like
- No billable hours
- No PMs bugging me asking aggressively "Is this done?". I don't feel like I am working hard so that the PM can have a better bonus at the end of the quarter.
- No travelling.
- Suitable work environment for my low soft skills.
- Office politics not visible, or not-disturbing.
- Good pay (after 10 years)
- I work with nice people in IT. Aggressiveness is low. When my frustrations are visible on my face, people tolerate.
- Walking distance to the office
So I am thinking about what my options are. There are end-users, consulting companies, or MS-NAV partners. I am not confident with my NAV skills to be an independent contractor. I am thinking about getting a paycut and targeting MS-NAV partners and build my skills for 2-3 years and then re-think about my choices. Eventually I might go for a BA role after getting some certifications.
You might ask "what are you asking exactly?".. I don't want to do what people say.. But I don't want to be in my own bubble either. I know the grass is always greener on the other side. I just can't think of myself doing the same job, same responsibilities in next few years. I am giving away more than I receive is the problem. I am also not a person who starts working at a company and just quit in six months. I build commitment to the companies I work at.
What's your feedback?
Answers
2. Weight the pro and cons you listed. Only you know what is important for you and you cannot have both. A end user will have (most) of the problems you list. A partner will require billable hours, push you for solutions, require travelling and probably not be in walking distance to your home ;-). I've worked both for end users and partners and I know exactly what you mean :-).
3. _IF_ you decide to work for a partner and are willing to put in the extra personal hours, fell free to reach out to me (gert@lynge.org - the company I work for is currently hiring in some European countries - so if you are in Europe and can work from home we might have an offer for you)...