[KineticLensman]

> Another one has been learning how software fits the bigger picture. In order for a company to succeed with software, things starting from vision, strategy, execution need to be in line

This was something that I experienced in my career trajectory. My first shift from pure programming was to requirements definition, which I enjoyed. I then got involved in specifying the need for systems in the first place - developing business cases and evaluating solution options. I'd by then realised that by the time someone starts writing requirements, someone else must already have done some work to secure funding, teams, etc. Luckily I was (mostly) able to stay tech-focussed rather than moving into pure management. Some of the most technically challenging work was at the end of my career - looking at how systems could be affected by / drive organisational transformation. And being able to confidently brief very senior decision makers on how their organisational structures (often stovepipes) were actually driving inefficiencies, duplication and nugatory work at the systems development and operations end.

[my_usernam3]

> Luckily I was (mostly) able to stay tech-focussed rather than moving into pure management

Can you expand on this? Like what was the title, or was this a unique role to your business?

This thread has really resonated with me and where I might want to be taking my career.

[KineticLensman]

Sure!

The title was unique to my business but in practice I was a ‘Senior’ position. I joined a company that had been part of the UK civil service but which had been privatised before I joined. The part I belonged to conducted advice-side / customer-friend work as opposed to supply-side / product-development. So in effect I was an independent technical consultant deployed into UK Govt customer organisations (in Defence) to support their activities, which included the stuff I mentioned before (requirements definition, business case development, etc). I did this for approx. 10 years, starting very technically focussed (e.g. helping to draft tech sections of Invitations To Tender or contributing to standards development) but gradually looking at business / organisational issues (e.g. can we restructure this organisation to reduce commercial and technical barriers to efficiency? / what research do we need to do to conduct to de-risk this new simulation technology?). I became reasonably well known in the customer community and, crucially, was trusted as a friendly techie rather than a commercial ‘suit’.

The plus side to this was getting superb levels of customer access and some experiences not available to most civilians. Because I had been around for years the customers saw me as someone who actually understood their domain and their problems. I knew their acronyms and understood their business processes, more so than some of them did (especially customers who were new in role).

The downside was that from the perspective of my parent company, I had effectively ‘gone native’ with the customers (although was still useful because I generated revenue and demonstrated the competence of my company). I had to be commercially fire-walled away from the product side of the company so that the customers still trusted me. This limited my career development – partly because I couldn’t be involved in high-profile bids and delivery projects that attracted C-suite attention. As an example, although my salary increased okay, I found it very hard to gain evidence (e.g. third party feedback) that would support a grade rise. As it was, I didn’t mind too much (this was the latter end of my career) but had I been younger it would have been frustrating.