Recently, I read a blog post titled VPE and CTO — The first 90 days. It’s a brief article in which James Turnbull shows a mind map with four areas that “every new technical leader needs to, at least, think about and explore when starting at a new organization.”
Although the author doesn’t detail how to tackle each of them, the mind map itself is very valuable. It organizes information, and make explicit the many responsibilities of tech leadership positions.
The areas are Company, Product, Technical, and Humans. For each one of them, he proposes to categorize the subtopics in:
- No action needed — everything is cool.
- This needs work — let’s work out what we need to do and when.
- There’s nothing here, and should that worry me?
In my experience, many Software Engineers feel unassisted in the process of dealing with a Tech Lead position, or when becoming a CTO. Therefore, the exercise sounded like an excellent idea to me.
In addition to James’ contribution, I brought some pieces of advice for who is transitioning or starting to a new tech leadership position.
I condensed a bit of my experience and some useful resources I’ve shared recently. I am sure they will help you somehow to succeed in a tech leadership position, at least in the first 90 days.
The company area subdivides into the following items:
- What are we committing to?
- Our metrics
- Company metrics
The mission and the answer to “what are we committing to?” are crucial pieces of information. If you have a clear understanding of them, designing an engineering roadmap gets more natural, and less risky.
The engineering roadmap is an outcome of what I call “establishing a technical vision” for the team. It gives people a north. It must align with the company metrics, and fit in the budget.
It’s part of your job to define a technical vision, and manage the team to comply with it. It applies to all tech leaders, from experienced Developers to CTO.
If you’re a Tech Lead, there are chances you don’t have a budget for you to manage on your own. However, it’s as essential as it is for a higher position to understand your limits. I’ve already written some advice for Software Engineers transitioning to Tech Lead position. It may complement this article.
The technical decisions in the engineering roadmap may require external tools, like SourceLevel, software licenses, or equipment, to cite a few. They cost money. Even though you’re not passing the credit card, you’re an active participant in the process.
Heads of Product are concerned about what engineers develop, whereas Heads of Engineering’s sphere of responsibility is on “how”.
However, CTOs and Tech Leads need to be aware of what’s coming in the future. Otherwise, they won’t be able to provide an effective infrastructure to achieve the business goals.
Jame’s chart lists in the Planning, Input, and Output topics some interesting aspects that will lead to a better understanding of the product, and consecutively bringing more results.
The last three topics can be more challenging for new leaders. They require abilities yet not well developed, like reporting to senior management and dealing with processes.
If you have no idea what to report to senior management, check out what Lucas Colucci wrote a cunning article on the matter: How to report metrics to C-Level executives?
In addition to Throughput by type of work (bug, feature, chore, etc), you may add the Time from Commit to Deploy, which measures how long a commit takes to reach production.
You may have other metrics to drill down that numbers. The chart cites Cycle Time, although I prefer to measure the Time to Review, Time to First Commit, and many other metrics I explained in an article called 50 Shades of Lead Time.
The human area is probably the most difficult area of the chart to deal with. It’s complex and very comprehensive. As a recent leader, it’s vital to pay attention to the people that make up your team.
If you look thoroughly, you probably will figure out very simple decisions you can make to add value to their daily activities. Those quick wins help you to build social capital and respectful leadership.
I consider 1-on-1’s and Mentoring the two main topics that the chart relates to the human area. In the webinar 1:1s e Gestão de Equipes de Tecnologia (currently only available in Portuguese), I talked with Know Your Team’s CTO Daniel Lopes about both subjects.
Managing the technical aspects of your new job probably is the part you’re most comfortable with, although it doesn’t mean it will be easy.
Scaling the codebase at a sustainable pace is hard. Sooner or later there will be a pile of technical debts that needs prioritization.
It’s fundamental to keep the track and tackle using an appropriate strategy. Otherwise, the team may get demotivated, the system gets messy and delivers take more than usual.
To avoid that kind of problem, you can use static analysis tools, also known as linters. Linters are great. They can enforce style guides, avoid security issues, and find code smells, among other things.
If you’re assuming a Tech Lead position, we have a dedicated page with everything a software engineer needs to know. In it, we condensed the responsibilities, required soft skills, and how to be successful in the career.
For CTOs and Engineering Managers, I strongly recommend these 5 books, plus the e-book 5 Strategies to Boost Software Deliveries in Any Company.
If you enjoy receiving hand-picked articles on software engineering, give our weekly newsletter a try. It’s full of excellent articles written by widely known professionals.
The post Succeeding in a Tech Leadership position — The first 90 days appeared first on SourceLevel.