Surviving My First Few Weeks as a Tech Lead
Having the opportunity to make a difference is one of the most important things in my life. Goals, challenges and un-solved problems that require working software to solve them are the biggest motivators you can give me.
Having landed an opportunity as a tech lead, and chiefly responsible for delivering a phase of a project, motivation and excitement were sky high. But now I really had to prove to myself and others that I’m not just a hopeless dreamer.
So my first few weeks as a tech lead, how did I approach it?
Document Anything That May Improve Or Harm Delivery
Having been given the responsibility to lead development of the project, any time a piece of knowledge enters my mind I need to know if it’s going to affect the success of the project.
For instance, I’m reading some of the requirements and there’s an ambiguity — I have to make a note and ensure it’s chased up or the rest of the team is made aware. I can’t sit back and expect to remember it next week, or for someone else to pick it up. If ignoring it results in the project being less successful than it could have been, I will be mightily disappointed.
I created a few wiki pages and documents to try and keep on top of this
One of them is called “Current Unknowns”; a document shared with all of the tech and non-tech people so they can see what information is stopping the system being built or will slow-down progress in the future.
Another document I created for the tech team was “Outstanding Design Decisions”. There are a number of ways we can develop the system, and there are some really fundamental decisions that are quite inter-related.
The importance of this document is to keep these yet-to-be-made decisions at the front of everyone’s mind, so as the system is being built the business-critical trade-offs and options are explicit. It allows me especially to start solving a problem one-day, and build on it each day, without ever forgetting the list of options and trade-offs that I previously learned about.
Balancing Business Requirements And Tail Recursion
My role spans all the way from meetings with clients to refactoring tail-recursive functions in Scala. Too much focusing on requirements and no code gets written. Too much focus on coding and I fear I will lose sight of the big picture.
My approach to this problem is iterating. Step 1 is to learn more about business requirements. Step 2 is to update a conceptual design, visualised with some architecture diagrams, that theoretically will satisfy business requirements. Step 3 is to write some code and validate aspects of the design.
Having a design — just 4 or 5 diagrams at present — helps me to understand how the system is going to satisfy all the criteria the client has asked. I can’t stress how much mental clarity and confidence this gives me that me I’ve got the important details covered, or identified any problematic areas at an early stage.
Collaboration and Humility
I’m really lucky that the architect I’m working with is especially knowledgeable whilst being friendly enough to guide technical decision making. Equally, the sysadmin has agreed we can work together setting up EC2, configuring puppet and related tasks.
Working with the project manager has also been fun because she has been an invaluable source of client-related knowledge. If I play nicely with her then we can work together on helping each other understand what the other is best at (business aspects or development aspects) in order to find the optimum solution for the project, which means we both win.
What these situations all have in common is that I need all of these people to get the job done. Without their help I won’t achieve my personal goals of delivering the project as best as I possibly can, or the company’s goals of satisfying the client (and the bit about making a few pennies).
So… I just made sure that I showed people respect — was willing to listen them, accept their ideas were sometimes better than mine and was patient when asking for support.
Maintaining a positive attitude and continuing to have good working relations with everyone will give me as much satisfaction as nailing any programming challenge. I’m working as hard on this part of the job as the others.
Moving Forward
With an iterative process that feeds back business knowledge and technical discoveries into a conceptual architecture I have a lot of confidence that development of the system will be efficient and responsive.
I believe a positive mindset and good working relationships will also help everyone in the project achieve their goals.
But my next steps will not only be working hard to improve in all the areas I’ve mentioned in this post, but introspection and reflection that will allow me to keep improving in other ways too.
After all, the first few weeks of a new job are really just a holiday — the real challenges require long-term focus and commitment. I haven’t achieved anything yet.
All pictures used are legally free to download and use from: http://www.sxc.hu/, http://www.stockfreeimages.com, http://photopin.com or google advanced search with “free to use or share” option.
