Your first 90 days in a new leadership role (in particular, a VP Engineering or CTO role) will be largely spent in orientation. You’ll be getting to know the ways and hows of the business in detail: its culture, its values, its structure, its current priorities, the things that work well and, of course, the things that don’t. You need to see warts and all, leaving no stone unturned.
A big investment of time will be getting to know your peers on the exec team (your first team): what makes them tick, what are their strengths, what skills are they working on (“weaknesses”), what are their frustrations, what are their interests. Similarly, you’ll be getting to know the people you’re managing as direct reports. First impression count. On both sides.
Approaches to tackling the first 90 days in a leadership role have been well documented already, so in this article I want to focus on using a SWOT analysis-based framework for helping to identify the priorities of a department or organisation, in order to shape team strategy. This isn’t a technique intended to replace the job of getting out there and meeting with as many people as you can – that’s still crucial for building relationships and trust. It’s a structure to use for an information gathering exercise that has proved really useful to me.
While it’s especially useful for people coming into a new leadership role, I’ve found it really valuable as a recurring annual exercise to run in your engineering organisation. Change is the only constant in life and you need to keep up.
As defined by Wikipedia, a SWOT is:
a strategic planning technique used to help a person or organization identify strengths, weaknesses, opportunities, and threats related to business competition or project planning
Put simply, this means gathering views from across your organisation about what’s good and what’s not so good, both internally and externally. This diagram explains:
In order to gather the feedback, publish a Google Form (or similar) to allow participants to easily provide answers to the four basic SWOT questions, anonymously. The form goes to everyone, across the board – individual contributors (ICs), testers, engineering managers, IT and security staff as well as the leadership team. My form looks like this:
Allow people a couple of weeks to complete the form, you don’t want to rush it. Participation is optional but push for people to make every effort to complete it. You’ll have to chase people (engineers typically have a lot on their plate), but aim for 70%+ engagement.
Once submissions are closed, you need go through the data and collate the responses into themes. There are probably some clever technical approaches you could apply here, but is it worth the time? For better I worse I always use a manual, brute force method which, on balance, is good enough despite being more art than science. It will take a good couple of hours to do this but that’s fine because you probably want to read all the responses anyway.
During this data-wrangling phase, clusters of ‘hot topics’ will start to appear alongside a long tail of more fragmented ideas and feedback. The long tail ideas are interesting but it’s the hot topics that will become your key areas for further discussion and prioritisation. You’ll take these to relevant teams, start discussions, run workshops and eventually factor work into your roadmap.
The good thing about SWOT is that it focuses as much on the good stuff as the not-so-good. Don’t just pay lip service to strengths and opportunities – these are the things that are working really well, and things to get excited about for the future. Analyse strengths and opportunities and see how you can capitalise on them elsewhere.
You don’t want all the effort people have put into the survey to be left unrewarded, so it’s important to communicate your results. Create a slide deck and present the results in your weekly engineering all-hands meeting (if you don’t run one of these, this is your excuse to start!).
When taking the team through the results, I’ll first present the previous year results (obviously only if we’ve run a SWOT before!) and reflect on whether we managed to take action successfully. It’s important to look back and celebrate wins, however big or small – it’s so easy to overlook this because it’s natural to be looking forward to the next thing, and the next thing.
Finally, after presenting, I’ll run a Q&A to allow everyone time to ask questions and give feedback.
The main point of running the survey is to identify actions to prioritise. I’ll work with my leadership team on how we can work the most pressing actions into our strategy for the upcoming year and get them factored into team roadmaps. Some of the actions might be big-ticket projects which will require a lot of further analysis and discussion, but there will be plenty of low-hanging fruit as well.
Over the years I’ve been doing this we’ve had some really big wins. The first time we did it, the most problematic area by far was deployment pain. There were too many steps, not everyone had the ability to deploy, it was increasingly time consuming to get changes out of the door and we had no clear plan towards continuous delivery. As a result we prioritised the building of an entirely new CI/CD platform which had a dramatic effect on number of deploys per day and led to a happier and more productive team! It wasn’t like we didn’t know this was a problem before, but surveying the entire team and getting unambigious raw data from dozens of engineers gave us a much-needed reality check.
Of course the big wins are not a result of this particular framework. It’s just one of many techniques you could use. The underlying message here is to give everyone on your team a voice and demonstrate that you are listening.
