I worked myself out of a tech job not once… but twice
The first time it happened I was just a senior Java developer graciously going about his job when I was informed my services were no longer required, and that I had a few months to look for my next job. I was given the offer to stay on if nothing materialized within those few months, but thankfully I managed to find another job within a month.
The second time, I was an accomplished Software Architect and I knew better when to walk before being asked to do so.
Here are some of the things I believe helped me “walk on water” and “shoot the lights out” in these 2 roles.
Understand the Big Picture
One major pitfall that software developers suffer from is focusing on coding mostly, in the process they miss out on understanding the big picture of why they are coding in the first place. One thing that I always set out to do is to probe the stakeholders for the big picture.
In the Java developer role, the team was experiencing an influx of Business-to-Business integration projects and their turnaround times were no longer acceptable. I was hired to come in and streamline the delivery of these integration projects.
In the Software Architect role, I had just been tasked to lead a business portfolio, after being a Technical Architect for over 3 years. The business division needed to roll out its reporting solution to 5 subsidiaries, read countries, within 2 years. The problem was that the team at the time was taking over a year to roll out the solution to a single subsidiary.
Communicate the Vision
One of the key things an Architect has to get right is to understand what needs to be built, create a vision for building it and make the appropriate design decisions. Equally crucial is communicating the vision so that everybody involved in the delivery of the project understands what needs to be done so they can contribute in a positive way to its success.
On both occasions, I spelt out the vision of what we needed to achieve and I purposefully scheduled recurring sessions where I shared progress with the team. With the recurring sessions, my aim was to ensure visibility and make the point that everyone was equally responsible for the successful delivery of the project.
Delegate
Software developers who eventually move on to lead development teams usually struggle with letting go of their software development duties and as a result, they end up spreading themselves too thin as they strive to balance between their main duty of leading the team and dabbling in software development tasks.
While I struggled with this for some time, I quickly realized that I would be more effective if I could not only delegate some of the difficult programming tasks but also deliberately impart my architectural knowledge to the team. You will be surprised how many developers struggle to move onto architecture and they will gladly take on the offer if someone avails it to them.
By allowing your team to take on more responsibility, you eventually free yourself to move on and do something else which could actually contribute to your growth as well. So in the end everyone gets to benefit.
Reusability
One of the architectural principles that I heavily relied on in both engagements was Reusability. In both cases, I was able to identify the blocks of functionality that could be abstracted and reused, sometimes without even the need to code except maybe to perform a few minor configuration tweaks, for the subsequent delivery of future projects. This, and automation, are the main attributes that made me dispensable.
Needless to say in both projects I was able to reduce the project implementation times significantly. For the Business-to-Business project, I was able to reduce delivery time from a month to a few days and the reporting solution from just over a year to one month. Yes, one month you read that right. How we pulled this off is worthy of a post on its own. Stay tuned…
Automate
I have always been fascinated with build, test, and deployment automation since I wrote my first custom Maven plugins years ago to achieve automated deployments, and need I say I have never looked back since then.
When I joined the reporting team, the developers were manually writing release notes on some collaboration platform. The operations team would in turn read through these instructions and deploy the changes to the environments. In short, deployments used to take a lot of the team’s development time. When I left we had the same build, test and deployment scripts running from the developers’ local environments through to test environments and into production. We actually implemented One-Click and Zero-Downtime deployments in the test and production environments.
Aim to automate as much as possible so as to free the team from doing repetitive and boring tasks. This will leave the team free to concentrate on delivering real business value.
Passion
I am a naturally introverted person but over the years, I became so passionate about Software Craftsmanship to an extent that I felt the need to impart some of my knowledge to the teams that I worked with. In the process I had to overcome some things that totally terrify me, like public speaking.
In the reporting development team, I managed to host technical design sessions once a week for a few months.
During this time I also eventually hosted a general tech discussion forum every Friday. These sessions attracted the attention of other development teams on the floor and we found ourselves looking for bigger meeting rooms to accommodate extra numbers.
I was amazed I pulled it off, but I think this all boiled down to my passion to share my knowledge.
Documentation is a Superpower
This point will probably make me very unpopular among developer circles, but I will make it anyway.
Development teams tend to leave project documentation till the last phase of the project. But in most cases than not, when this last phase comes, still little or no documentation is ever done.
I have mastered the discipline of documenting early and often and I have seen the benefits. Documenting early forces you to think about the project delivery by challenging some of the assumptions you have about the requirements, in the process I find I usually consult extensively and refine my design a couple of times before it eventually sticks.
Take time to document the project incrementally, in this way the knowledge does not only stay with you, but any team member or stakeholder can reference it whenever.
Conclusion
Would I work myself out of a job again if I had the chance? Absolutely YES!
Working yourself out of a job not only gives you satisfaction, but also the confidence to move on and break new ground.
