How writing my job description helped me own and define my career

AND Digital Principal Consultant Paul Boca has, like many others, had to build his career on mistakes and missteps. A few years ago he decided to take full ownership of his career and really define what he wanted to do. To do that, he created his own ideal job description. Here he discusses what he included and why...

The tech industry is so diverse in terms of both roles and organisations that it can be difficult to know exactly what you want to do or where you should be working. Just about every successful career in technology is built on many failures, mistakes and missteps - the trick is drawing lessons from those mistakes to move forward.

But saying we’ll learn from experiences is one thing - what if we actually used them to formulate what we want from the future? This is something I did recently when I decided to write my own job description. I scoured LinkedIn ads for inspiration and reflected on what I enjoyed doing.

Let me describe what I put in my job description and how my previous experience informed my decisions.

Troubleshooting

The opportunity to find out why client deliveries are not as efficient as they could be is something I really enjoy. It challenges me, requires deep thinking and allows me to explore the art of the possible. It took me a while to realise that this is something I enjoyed. But I finally got that chance to work as a troubleshooter when I took up a consulting role. For me it is one of the most exciting aspects of the role, as every problem is different and you need to be a detective to piece together the facts through interviews and reviewing artefacts (or evidence to keep the analogy going)

I can date my interest in troubleshooting back to my university days. I hadn’t given my career a lot of thought following my graduation. During my PhD research I became interested in ways to develop defect free software. This led me to start looking at the other causes for project failure. I soon realised that this was a rich area with many interesting problems to solve, so my aspiration was to be a troubleshooter in industry. There was a tv programme of the same name, which probably put the idea in my head (you can watch an entire episode on YouTube here). I had no idea whether this was a real job, so I played it safe and applied for developer roles. Several years later, however, I finally got to be a troubleshooter; the takeaway, then, is never give up.

Read next: Are your stand-ups a waste of time? Here's how you can improve them.

Complex deliveries

I love complexity, but love simplicity even more. The best of both worlds is the opportunity to work on complex deliveries with a view to simplifying them. I really enjoy taking on such engagements, as they pose a stimulating challenge. It’s more enjoyable if no-one else wants to take on the engagement, or if others have tried and failed.

Sometimes clients with complex deliveries become overwhelmed and lost in the detail. Compounding the problem is that people often overcomplicate things. Simplification is key to making headway. Clients often need a fresh pair of experienced eyes, someone to come in, take a step back and determine a way to deliver the outcome in spite of the complexities.

I attribute my approach and interest in simplification back to my experiences and love for an area that may surprise you: functional programming. It is a beautiful paradigm that shaped my thinking. Let me explain why.

I was diagnosed with “BASIC damage” at my university interview, following several years of being immersed in personal computing and teaching myself how to programme (or so I thought). Fortunately, they saw potential and I enrolled for a degree in Computer Science and Maths. The maths was different from anything I had seen before, as was the computing. It was like starting a new adventure and slightly daunting at times. I had a brain reset and was taught how to program using a blackboard notation known as ISWIM (If You See What I Mean). We turned ISWIM programs into Pascal programs; my BASIC days and “damage” were, by this point, well and truly behind me.

However, I spent a lot of time wondering whether I’d made a mistake: I didn’t really understand much of the course! I recall being particularly perplexed by recursion. However, everything fell into place once I started studying functional programming. The simplicity and power of these languages, together with their mathematical underpinnings, aligned with my background and technical interests. I could also do fun things like construct program correctness proofs using mathematical induction. I recall writing a Lisp interpreter in Lisp was an epiphany, as it allowed me to really grasp recursion and its power - I was hooked.

I graduated to other functional languages, and I eventually got a job as a compiler writer programming in Objective CAML. Building functional programs by composing simpler ones together really helped me in problem solving, and I still think in these terms several years on.

Varied Work on Short Engagements

As a consultant, I had worked on different projects, fulfilling different delivery roles, was a trusted advisor to a CTO at a bank, and had built up a successful delivery team and grown the client engagement. Sounds successful, right? I was proud of my achievements but wanted to reevaluate what was really important to me. I had spent far too long on a client site and was starting to wonder if I’d ever get out. I went into consultancy to gain breadth of experience and to work on a variety of verticals. So I was looking to move to a role where I would be on short-term engagements: solve a problem or help achieve an outcome and then move to the next client, while still remaining as a trusted advisor to a portfolio of clients. That’s where I’d like to get to.

For me it’s all about learning new things, taking on new challenges. Working across different verticals and different clients is my fast-track route to achieving this.

Opportunities to Learn

I loved learning and didn’t want my time as a student to end. So, like many others in my situation, I decided to study for a PhD. This was an incredibly rewarding experience, but it took much longer than expected.

Admittedly my research contribution was extremely modest, but the experience was valuable as I learnt so much about myself: to never give up, even when ideas turn out to be unproductive or fail, to tap into my creative side to generate new areas to explore, to take ownership for an area of work that was full of unknowns, to keep calm and focussed. I became more resilient and developed my approach to solving complex problems.

This gave me a good grounding, and my desire to keep learning new ideas is central to what I do. At one point in my career I decided that it was time to get back to my craft, relinquish my management responsibilities and become a Quality Assurance Lead. This allowed me to get close to the technology again, and to release software to customers - pushing that button was great. But it was tough at first as I was a bit rusty. I persevered and re-trained myself by reading articles online, watching youtube videos, attended online courses and tried things out on my laptop at home. I had to learn quickly and not be afraid to make mistakes. I drew on my experience, which gave me confidence and strength. I was out of my comfort zone at first and it was hard work. I was enjoying the challenge and learning new things, but did at times think this role might not be for me.

No line management responsibilities

I've tried it a couple of times; I didn’t like it and never want to do it again! It’s a skill I just don’t possess and one that’s very hard to fake. Let me elaborate.

After a couple of years as a developer at a startup, I decided that it was time to change careers. The obvious next move was Development Manager. How difficult could it possibly be? Quite difficult in fact, for me. I made a few mistakes while learning on the job how to be a manager. I had to learn to step back and lead others to the solution, rather than jumping in with a solution. I had to learn to be empathetic and understanding, not to say “yes” to every demand from my Managers. I was too eager to please. At times I was too open with the team. But somehow I was able to turn the mistakes into opportunities to learn and improve.

The role probably wasn’t the best one for me, and perhaps I was driven by salary rather than suitability. It highlighted what I enjoyed, though, and it got me into the exciting area of quality engineering.

Quality focus

I often find that people who work in delivery have come from a quality background; that holistic view is instrumental in making deliveries a success. My entry into the field was by chance after learning a very valuable lesson following a mistake.

I had finished university and was looking for my first job. I found an advert for a really exciting role as a software developer at an electronics company. This was no ordinary role - it was using functional programming. I just had to accept the job. There were some complex and challenging (computer science) problems to work on, which was very stimulating. I became totally immersed in the work, losing track of time as I was so engrossed. You know that feeling.

I learnt some valuable lessons in software delivery, how to work with teams that were located in different geographies, and how to ensure that the code changes I made did not block my colleagues. I did fail spectacularly on that last one - it’s permanently etched on my brain - but it never happened again. I had been working on developing a key feature of the tool. I thought I had understood the requirement - you can see where this is going. I checked in my code, ready for my colleagues to use. When I arrived at work in the morning, there were a number of emails waiting for me, explaining that my code did not work as expected. Had I written some tests up front, had them reviewed, I could have avoided this situation. As a result of this blunder, I became interested in testing. Remember, making mistakes is good, provided that you don’t keep making them.

My career took me into a quality engineering role some years later. This was a defining moment, as it changed my whole perspective on software delivery. For the first time I was personally on the hook if software shipped with defects. I had to explain to customers why defects hadn’t been fixed and how defects would be prevented in future. I fought for customers to get their defects fixed (to the frustration and annoyance of my colleagues!).

But I didn’t act quickly enough on a security defect once. I received an email from a penetration tester who said he had found a security vulnerability in the software product I was overseeing the quality of. The details he gave were quite vague in places. I had a couple of phone calls with him to discuss the vulnerability and how he found it. I investigated, but didn't act quickly enough in securing a fix. The penetration tester went ahead and disclosed the vulnerability. I learnt a valuable lesson that day.

Read next: The secret to building great stuff? Talk little but often.

No regrets - just learnings

• Follow your dream. Define your dream job and plan how to get there. It may take time, and there will be peaks and troughs. But you can get there with patience and hard work.
  
  
• Never stop learning. I loved being at university, and work is an extension of that for me. I learn something new everyday, and find opportunities to explore new ideas. By learning new things, you may end up changing roles a few times as your interests develop and expand. That's part of the journey.
  
  
• Turn the negatives into positives. At the time, those career troughs can set you back. I’ve been there. But I try to see how I can make the best of these situations, and I often draw on them years later when I need to make a decision.
  
  
• Don’t be driven by salary alone. It’s very tempting to go for a role because of the salary, I’ve been there, and soon found out that the role was not for me. I did use the time to find out what I liked and didn’t like, and that helped me on the next stage of the journey.
  
  
• Know your value. Over time, I found out what I was good at, and areas that I could take on that distinguished me from others. It took me some time to understand my value, but once I did my journey became more exciting.

• Check in regularly on what you want to do. I find it helps to review what I’m doing on a regular basis to see whether there are other challenges I’d like to take on. Looking at role descriptions on LinkedIn, for example, is a great way to get ideas.
  
  

If you’d like to know more about what it's like to work for AND Digital in Consulting, specifically in the Delivery Practice, please do reach out to me on email or on LinkedIn. I’m always interested to hear about delivery challenges, and would love to help you. If you want to get in touch, please reach out to me on LinkedIn or by email: paul (dot) boca (at) and (dot) digital (dot) com.

Ready to take on a new challenge? Explore all our open roles.