6 ms·

This reinforces for me the importance of domain knowledge in engineering leadership. i.e. if you work for a finance company you need to have a decent understand

by tomgp 2y ago

This reinforces for me the importance of domain knowledge in engineering leadership. i.e. if you work for a finance company you need to have a decent understanding of finance in order to make the correct technical decisions and tradeoffs, same goes for journalism, same goes for commerce etc. etc. Successful organisations I've worked for have always included domain specific, non-technical, questions to tech team interviews whilst some of the most technically acomplished teams I've worked with have floundered through a lack of domain insight.

collinmcnulty 2y ago
I agree with your sentiment here, but I think it helps to think of those domain specific questions as technical questions, just from a different technical domain. Finance is technical, mechanical engineering is technical, even sports management and sociology have big technical components too. I think having an expansive view of what technical competence is breeds the humility necessary to work across domains.
- tomgp 2y ago
  Yes, sure, if it helps you to think in those terms I guess that makes sense. Being a bit reductive perhaps but I think what it comes down to is having an interest in the "why" as much as the "what" and the "how".
spencerchubb 2y ago
ever since i started working for an insurance company, i realized that understanding the insurance industry is far more difficult than understanding the codebases. if the codebase is acting weird, at least i can step through it with a debugger!
- kdmtctl 2y ago
  Reinsurance is a beast. I spent a good time cracking layers and trying to implement the logic with a team.
sotix 2y ago
I’m a software engineer and a CPA, so I’ve got the domain knowledge. However, I’m not sure how to find a gig where I can apply that. It seems everywhere I look vastly prefers someone with twice my experience as a software engineer and zero domain knowledge over my years of experience in accounting and fewer years of experience as a software engineer. Any insight on how to utilize it effectively?
- softfalcon 2y ago
  Unfortunately, the likely solution to this is to keep banging out work at wherever you can gain experience as a software engineer. Modern hiring practices are too rigid and filter-friendly for you to likely appear as a strong candidate based on the fact you have good accounting experience on top of your growing software skills. What will really help you though, is having friends who work at a bank in the software departments. It's almost always who you know in this world. You need to network, network, network!
- scott_w 2y ago
  As someone who worked on a bookkeeping system without being an accountant (or bookkeeper in any sense), I'd say your challenge is that it's very possible to learn enough to build a decent system, assuming your engineering knowledge is strong. I don't say this to blow my own trumpet, only to say that the non-engineering leadership at the company in question were very invested in the product details and making sure I understood basic accounting principles. That said, I went from that role to working in a billing system that was originally built by a team where leadership weren't invested in the details. The result was a lot of issues and frustration from Finance leadership. Storing monetary values in float was not the biggest issue, either. That being said, maybe branch out of just looking at accounting/bookkeeping and market yourself as "I know how money works in software systems." Your skills are extremely transferrable and knowing the Finance expectations will make it easier to make good design choices further upstream.
- salawat 2y ago
  You know, it's kind of funny, but it seems like most businesses are not interested in doing things "right". As doing things "right" is time consuming, hard, and cuts off avenues to "innovate". "That's not how accounting works" is like telling management to clean their room. No one wants to hear it.
crazygringo 2y ago
I don't know about that -- I've always understood that to be the role of the product manager, to have all the domain knowledge. It's the PM's job to work with engineering to ensure that the requirements are correct, and that the built product meets those requirements. And in an agile setting, those conversations and verifications are happening every single sprint, so something can't go for too long without being caught. If you don't have a PM, then sure I guess your engineering team had better have deep domain knowledge. But otherwise, no -- it's not engineering's responsibility. It's products's responsibility.
- kdmtctl 2y ago
  There should be a system analyst. Every ERP or core banking big name works this way. Requirements have to be processed and then passed for implementation. In an agile setup rinse and repeat. As a side effect the whole team gains the domain knowledge. Or part of it.
  - RaftPeople 2y ago
    > There should be a system analyst. Exactly, this what we try to advance our tech people to, someone with the combination of domain+systems knowledge. It results in more independent+correct action which is much more powerful than having to specify significant details to less knowledgeable people.

by tomgp 2y ago

collinmcnulty 2y ago

I agree with your sentiment here, but I think it helps to think of those domain specific questions as technical questions, just from a different technical domain. Finance is technical, mechanical engineering is technical, even sports management and sociology have big technical components too. I think having an expansive view of what technical competence is breeds the humility necessary to work across domains.

tomgp 2y ago
Yes, sure, if it helps you to think in those terms I guess that makes sense. Being a bit reductive perhaps but I think what it comes down to is having an interest in the "why" as much as the "what" and the "how".

spencerchubb 2y ago

ever since i started working for an insurance company, i realized that understanding the insurance industry is far more difficult than understanding the codebases. if the codebase is acting weird, at least i can step through it with a debugger!

kdmtctl 2y ago
Reinsurance is a beast. I spent a good time cracking layers and trying to implement the logic with a team.

sotix 2y ago

I’m a software engineer and a CPA, so I’ve got the domain knowledge. However, I’m not sure how to find a gig where I can apply that. It seems everywhere I look vastly prefers someone with twice my experience as a software engineer and zero domain knowledge over my years of experience in accounting and fewer years of experience as a software engineer. Any insight on how to utilize it effectively?

softfalcon 2y ago
Unfortunately, the likely solution to this is to keep banging out work at wherever you can gain experience as a software engineer. Modern hiring practices are too rigid and filter-friendly for you to likely appear as a strong candidate based on the fact you have good accounting experience on top of your growing software skills. What will really help you though, is having friends who work at a bank in the software departments. It's almost always who you know in this world. You need to network, network, network!
scott_w 2y ago
As someone who worked on a bookkeeping system without being an accountant (or bookkeeper in any sense), I'd say your challenge is that it's very possible to learn enough to build a decent system, assuming your engineering knowledge is strong. I don't say this to blow my own trumpet, only to say that the non-engineering leadership at the company in question were very invested in the product details and making sure I understood basic accounting principles. That said, I went from that role to working in a billing system that was originally built by a team where leadership weren't invested in the details. The result was a lot of issues and frustration from Finance leadership. Storing monetary values in float was not the biggest issue, either. That being said, maybe branch out of just looking at accounting/bookkeeping and market yourself as "I know how money works in software systems." Your skills are extremely transferrable and knowing the Finance expectations will make it easier to make good design choices further upstream.
salawat 2y ago
You know, it's kind of funny, but it seems like most businesses are not interested in doing things "right". As doing things "right" is time consuming, hard, and cuts off avenues to "innovate". "That's not how accounting works" is like telling management to clean their room. No one wants to hear it.

crazygringo 2y ago

I don't know about that -- I've always understood that to be the role of the product manager, to have all the domain knowledge. It's the PM's job to work with engineering to ensure that the requirements are correct, and that the built product meets those requirements. And in an agile setting, those conversations and verifications are happening every single sprint, so something can't go for too long without being caught. If you don't have a PM, then sure I guess your engineering team had better have deep domain knowledge. But otherwise, no -- it's not engineering's responsibility. It's products's responsibility.

kdmtctl 2y ago
There should be a system analyst. Every ERP or core banking big name works this way. Requirements have to be processed and then passed for implementation. In an agile setup rinse and repeat. As a side effect the whole team gains the domain knowledge. Or part of it.
- RaftPeople 2y ago
  > There should be a system analyst. Exactly, this what we try to advance our tech people to, someone with the combination of domain+systems knowledge. It results in more independent+correct action which is much more powerful than having to specify significant details to less knowledgeable people.