8

I work at a ~30 person engineering company (the nuts and bolts kind, not software). I'm really interested in changing roles to something focused on software tool development, instead of engineering. I have some software development background that is not used in my current role, and I am actively spending personal time learning the necessary skills, but I do not believe my skills are currently sufficient to take on the role I want.

I feel that I would be better positioned to make this transition if I could either spend some work time learning the necessary skills, or at least get paid for outside hours I spend developing my skills on projects that could benefit the company.

Within my company, there is a business case for the role I want - developing better software tools would help us. But, an experienced developer would build these tools much more quickly than I would, and I worry that at my current salary, my employer may think that I am "too expensive" to be dedicated to developing these tools.

Therefore, my question: Are there creative arrangements I could suggest to my employer to let me work on building these software tools?

For instance,

  1. Asking to spend, say, 20% of my work hours on development projects. But my current dev skill level is not worth my current salary, so maybe I'd offer to work at half-rate for those 20% of hours. (Effectively, taking a cut in pay in exchange for my employer allowing me to build my skills).

  2. Asking to contract (for a fee) for delivery of tools made outside of work hours. Projects are the best way to learn, and I might as well make a project that does something useful to someone. And get some compensation for it.

Overall, my goal is to transition from an engineering role to a software development role focused on building tools for engineers. I would like to understand how this type of transition is typically made and what sorts of arrangements are typical with employers to facilitate this type of transition.

  • 4
    I would advise against taking a pay cut. Pick a small software project and ask them if you can take it on. – paparazzo May 23 '18 at 11:43
  • 1
    Are you a design engineer i.e. doing analysis and design of bridges or power plants or HVAC etc? Or are you a machinist i.e. lathe, mill or CNC operator etc? I find the overlap in terminology disturbing but in the former setting it may be easier to achieve your goals than the latter. – ChP May 23 '18 at 12:44
  • 1
    "An experienced developer would build these tools much more quickly than I would, " -- I'm wondering if you are significantly underestimating the work (and consequently the money) required to develop a software tool that can be reliably installed and used by others. – kevin cline May 25 '18 at 1:21
  • 1
    @kevincline In the "real world", there are a host of "by engineers for engineers" tools out there delivering real business value. From a software engineering perspective, they are awful, but from an engineer's perspective, they get the job done. These tools exist and are in such wide use because building polished software is slower and more expensive and software engineers often build the wrong thing because they lack enough domain knowledge. For many one-off situations, it is also a waste of money to build a full-blown application. – Eric May 25 '18 at 2:10
  • 1
    @kevincline Plus the engineers that create these tools are usually very valuable to their company because their tools increase their own productivity and the productivity of the engineers around them. – Eric May 25 '18 at 2:12
9

Arrangements like these are likely to fail, long term.

  • Having 2 jobs like these at the same company, especially if it's formulated, with independent contracts, can be a severely career limiting move. Promoting you will be a headache so, if possible, promotions might go to other people.

  • Working flexible hours on one lower paid job while working fixed hours on the other higher paid job only works until the fixed hours job requires you to put in extra hours. At that point there's a chance for billing conflicts (work the higher paid job, get paid the lower rate) which can cause lasting damage to your relationship with the company.

  • Arrangements like these are too special for people to care about the details, and likely people aren't supposed to know the details (like the part about pay), so people will frequently approach you with demands that work out to your disadvantage.

  • Formalizing your arrangement with multiple jobs at multiple salaries at the same company makes it harder to reverse it if things don't work out.

It's possible that none of these become a problem and that things work out perfectly. Still, a better version is as follows:

  • Keep the same salary, don't even discuss salary.
  • Allocate a fixed time to the 2nd role. e.g. Friday.
  • Initially agree on a time limit (3 months), after which the success will be assessed.

Thinking that working 20% on software isn't worth 20% of your salary is the wrong idea. The company cannot hire a software developer who works for 20%, and has previous knowledge of the company and it's products. If they are interested in doing that, you are their only option.

| improve this answer | |
3

TL;DR: Bring a new idea to your bosses. Colaborate in the project with an experimented developer (external hire) to increase the benefits of undertaking the development.

Extended answer

While I mostly agree with the points made in the accepted answer, I would like to add a suggestion. Even if it may sound a bit opposed to the career limiting argument.

You stated that there is a position open for a developer who may improve your software tools, so I assume there is an interest from your management directive to start a project for this purpose.

Why don't you arrange a meeting with someone in the upper level to offer your skills not as the main developer, but as assistant one?

Since you believe that taking projects is the best way to improve, I would suggest that having a senior colleague working with you may increase even more your kwnoledge. That way you could learn not only from a real development process, but also from the experience of someone with experience in the field.

Also, an arrangement like that could be easier to negotiate with your management an obtain a part time dedication to the development task while retaining your actual salary.

You can be even more convincing if you explain why your participation in the project would help to keep part of that experience within the company, and how it could be useful to have you and your knoledge about the software and the company around. This approach may even grant you the support tasks derived from the use of the new tools and even a future plan for improving or extending the software produced.

Hope it helps.

| improve this answer | |
2

I think there is a case to be made to transition without taking a pay cut. One of the biggest challenges in creating good software is to find someone who deeply understands what users of the software will want it of it. Someone with domain experience (i.e. understands what users want) and actual development experience is very valuable. You may be better suited initially to work together with a more experienced developer, but in the long term there are lots of possibilities for someone with "hybrid" experience.

| improve this answer | |
0

There is a place for custom software development in any company when the company has a specific need which can't be addressed by available software. However, as I understand your question, you are not asking about build software to address a particular need in doing mechanical engineering, you are talking about building software tools to help build other software. If this assumption is not correct then ignore my answer.

As a general rule, if you have a passion for something then find a place that is passionate about it too.

A mechanical engineering company shouldn't be making software development tools. They will never be great at it and someone who works on it won't be appreciated. You will be considered a cost, not a revenue generator by leadership. Tools probably exist already to meet your needs. Paying for them is much cheaper that maintaining your own.

20% time projects are a disaster. Revenue generating projects will get prioritized ahead of your 20% project. Even if you work 120% to do your project your contribution won't be recognized.

If you want to be a software engineer find a company who will be delighted to have you as a junior developer and learn how to do the job by doing it. In many parts of the world software engineers are so scarce companies will be delighted to hire someone who is smart enough to be a mechanical engineer and let them learn on the job. This may mean a pay cut so you have to decide how much you want to invest in the change. In the long term working on something you are passionate about will pay off.

| improve this answer | |
-1

Take a step back and look at the situation. If you are good at your current mechanical(?) engineering job, then the company's money is best spent on you doing that kind of engineering work.

If there was truly a need for a developer, then the company's best course of action would be to hire an experienced developer. Would you allow someone to do life-saving surgery on you, if they said they would take less money since they were learning on the job? No, you would not.

If I were in your shoes and I wanted to make a transition within the company, I would think your best bet is to bite the bullet and develop a tool on your own time for free. Talk to your company and tell them you would like to do a project completely on your own time that will benefit the company. This is likely the best case for them to say yes. If the tool meets their needs, expectations, and has value, then that opens you up to the possibility of doing more development work for the company. That's when you can bring up the subject of payment, course reimbursement, etc.

Another thing to note, is there may be better tools that already exist. Have you looked for them. It could be more cost effective for the company to purchase existing software, then to pay someone to develop something.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .