I have often pondered what makes a Senior Developer “Senior” and what makes a Junior Developer “Junior”. Invariable such titles are bestowed upon software developers based upon where they are in their career and how many years of experience they have.
The idea that the number of years you have been doing a job is in my view quite an old fashioned idea. In some industries this may be valid; clearly I would prefer to be operated on by a heart surgeon with 15 years experience as opposed to a surgeon who is newly qualified – that said even in this context the newly qualified Dr may be versed in more modern techniques that the seasoned surgeon may not have knowledge.
I’m not suggesting that experience shouldn’t be considered but I would suggest that we are more interested in the skills that an individual has. Experience means that the individual has had longer to gain those skills but it in no way guarantees that the individual has used the time wisely.
With this in mind recently I’ve been giving some thought to how we should measure the performance of our developers and how to support them in building skills that benefit us as a company.
One of the tools that I have developed to help with this is a Developer Skills Matrix. The concept is really simple – across the top I list all of the skills that I want my developers to have and down the side I specify levels of knowledge (No Knowledge, Basic, Good, Great, Superstar).
When specifying the skills its important to drill down to a granular level of knowledge; being to broad brush doesn’t give you enough detail. In the example above you might be tempted to group all of the skills under the heading “React” – this would limit the benefit of the matrix as it is perfectly feasible for a developer to have no-knowledge of Redux and still be a great developer.
The idea is to create headings which cover areas that a developer might have knowledge or could be expected to have knowledge in order to effectively do their job.
In order to make best use of the ratings its important to provide clarity on what level of knowledge you would expect an individual to have in order to achieve the rating.
I use the following guidance but it can be adjusted to suit your own context.
You might have heard of the technology but you’ve never used it.
You have a working understanding and are able to make basic use of the concept or technology. You would usually ask a lot of questions and rely heavily on others to support you in any implementation work.
You are comfortable using the concept or technology as part of your everyday work but struggle with some of the advanced concepts. Sometimes its good to get help from someone who has more experience than you.
You are really comfortable with the concept / technology and feel you have a great working knowledge of most of the more advanced concepts. You can identify when people are incorrectly using the concept or technology and will offer support to assist them.
You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Once you’ve set up your matrix ask your Developers to complete it. I like to ask Engineers to justify their ratings in each area – this in turn leads to good 1:1 conversations and also helps normalise ratings across the development team.
Scoring the Matrix
When the matrix has been completed by the whole development team I like to score the matrix. No Knowledge = 0, Basic = 1, Good = 2, Great = 3, Superstar = 4.
When view across the whole of the development team this scoring allows you to identify areas of team weakness, where perhaps you have limited knowledge as a company in a particular area. This can then inform your recruitment strategy by identifying the areas you want to particular focus on when interviewing potential new joins.
The scoring can also be used to identify weaker team members or to help inform performance conversations. I would caution that this is not a silver bullet and should not be used as the only way to measure an individuals performance but it does open up some opportunities to recognise your staff and to inform clear and quantifiable objectives.
Ways to use the data
There are many ways to use the data to help your teams with continuous improvement such as:
Identify 3 skill areas where a developer has no knowledge. Set an objective that by the next performance review the developer will have basic knowledge in all 3 areas and ask the individual to provide evidence of their achievement.
The knowledge can be gained in a variety of ways such as independent research, an online course or pair programming. The method isn’t important but the commitment to improvement will benefit both the individual and your company. You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Company / Team OKRs
If you use Objective Key Results within your organisation then this data can be used as a quantifiable measure of performance improvement.
Objective: As an Engineering Team we will continually improve the skills required to build our products:
Key Result: The average score for every skill should improve each quarter.
The skills Matrix is not a silver bullet – it can be used as one tool to help with your overall performance management strategy.
When I first considered introducing this tool into my team I discussed with other Engineering Managers in my network and I heard horror stories of similar frameworks being abused – in one case engineers had nicknamed the tools “The redundancy framework”.
Like all tools its success is very much dependent upon its implementation – if implemented well as part of a wider performance strategy the framework can help identify areas of weakness within the team and help guide areas of focus for improvement over time.
Have you used a framework like this in your organisation? If you have I would be really keen to hear from you – please comment below or reach out to me on Twitter @stevewestgarth.
Agile is a term which has become synonymous with Software Development. For those of us who work in Engineering organisations the term conjures up ideas of Sprints, Burn-down, Iterative Delivery Cycles and Retrospectives.
The term itself has a very different meaning:
Recently within my organisation we have been embarking on an agile transformation journey. The Executive team continually refer to the need “to be agile”.
This direct instruction has, at least within IT, been interpreted as a direct instruction to adopt an Agile Software Development methodology and change our ways of working. Speaking as an advocate of agile development I fully support this initiative; I do wonder though if the meaning of the ask “to be agile” can be achieved if all we do is adopt a new methodology.
What is being asked?
As a large corporate we have historically been slow to respond to change. Layers of management approvals and the need to justify expenditure has led to a slow, bureaucratic and risk averse corporate machine.
The world around us is changing at a very different pace; companies like Monzo, Netflix, Facebook and Google are demonstrating that the need to respond to change is a key differentiator which is required to survive.
I don’t believe our Executive team really care about the successful adoption of a methodology, albeit that it may be a means to an end; what is being asked is that as an organisation we need to rewire our DNA so that we are able to respond to change with flawless execution and at pace.
Why is adopting a methodology “not” the answer?
For me adopting an agile methodology as a company allows different levels of middle management to feel a sense of comfort. We have taken a tried and tested system and have been able to weave it into our existing processes to achieve an objective set by the Executive.
According to the 2018 state of agility survey 96% of Agile Transformations fail to generate the capability to adapt to changing market conditions. In my view this clearly demonstrates that achieving the Executive objective “to be agile” cannot be met by simply adopting a methodology.
I am not suggesting that using an existing methodology is not helpful — learning from others is a key component of any successful agile organisation. A framework can bring structure to the organisation but in order for that framework to be successful the people within the business need to understand and buy into why adopting an agile framework is not enough.
A structural change
I recently read a book called Measure What Matters; the author discusses the organisational structure of Google. One of the points which I found most interesting was that a common feature of Google’s management is that managers have large numbers of direct reports. The rationale for this is to flatten the hierarchy which forces managers to delegate work into their teams and reduces the levels of approval required.
In order to be an agile organisation it is critical to remove bureaucratic process. Quite often within an organisation a decision to invest has already been made by the Executive; why is it therefore necessary for several levels of management to approve the release of the money?
The rationale for this approval chain would typically be linked to risk management; to ensure that the money is going to be well spent and that appropriate due diligence has been performed to verify that the spend is wise. In my view this is one example of where organisations fail to grasp what being agile really means.
One way that I think an organisation can signal that they really are serious about an agile transformation is to flatten the organisational hierarchy and restructure. By reducing the number of approval levels required for an investment decision it becomes much easier for teams to respond quickly to changing market demand and therefore achieve the true intention of the Executive; that is to respond and adapt to consumer demand.
Simplifying Governance and Process
Another key facet of a successful agile transformation is the need to simplify process. In my organisation we have well established processes that have been developed and implemented over many years. While the intention of these processes is well meaning the effect is often to slow the speed of change.
In addition we have also found that many of our processes are siloed into different teams and groups. As a result processes often conflict with one another or cause delays because there are interdependencies between teams.
In my view the solution to this is to break down the silos and develop cross functional teams which contain all of the skills and authority required to respond to change. This doesn’t mean creating one big team but instead focusing on making sure the smallest number of people possible can work together to achieve the stated aims and objectives end to end without the need to depend on other teams within the organisation.
I am not suggesting all processes should be thrown away; but it is important to challenge the need for a process and then when process is required is should be robustly tested to ensure that it is fit for purpose. Critically it should make life simpler for all concerned as opposed to introducing complexity.
We have found that quite often a process is introduced by one group of people which is either not understood by another group or requires information that it is difficult for the other group to obtain. This is an example of an ineffective process because it doesn’t make life simpler for all process consumers and therefore reduces agility.
In summary for organisations “to be agile” every part of the organisation needs to understand that the true ask is that collectively we need to adapt so that we can respond to change at pace. Methodologies can take us so far but if the bureaucratic machine isn’t ready to adapt then ultimately the transformation can never succeed.
Within your organisation have you undergone, or are you in the process of an agile transformation? Have you found that there is a mismatch in understanding between the definition of the word Agile and the adoption of an Agile methodology? Is your organisation one of the 96% who have experienced a failed transformation? If so please reach out to me on twitter and share your experience @stevewestgarth.
In this day and age it is almost inconceivable to imagine a world without “the car” or other motorised transport. It is hard to believe that the car was only invented in the late 1880’s and even harder to accept that motorised transport has only been common place for the last 80 years.
During this time, society has moved at a tremendous pace, which has led to the introduction of health and safety legislation that now controls all aspects of our day to day lives. It is therefore interesting to ponder what would happen if the car had been invented today.
Let’s imagine that the automobile did not exist and that an inventor puts forward a proposal, suggesting that it would be a good idea to create a machine that has four wheels, controlled manually by someone, who for the purposes of this article will be referred to as the driver.
In order for the machine to work a large (typically 40 litre) tank of highly flammable liquid would be strapped to the underside of the vehicle and this liquid would then be ignited and pumped through an engine placed in front of the driver, in order to propel the machine forward.
The proposal would need to suggest that the flow of flammable liquid would be controlled at the whim of the driver via a pedal mechanism allowing the speed of the vehicle to be increased or decreased as required.
In order to mitigate the risks associated with the idea the proposal would suggest that rules would be put in place stating that the maximum speed that the machine would be permitted to travel and guidelines would need to be developed stating safe speed limits on each stretch of tarmac (roads) that the vehicle used.
In reality, however, nothing but the power of the engine would prevent the vehicle going far faster potentially reaching speeds of over 130 miles per hour in standard automobiles, but potentially far faster in some models.
Assuming this concept, by some miracle, was approved and allowed to go ahead, consider if you will how an inventor could sell the concept of producing 30 million of these machines and then allowing them to be used on roads travelling at these high speeds in opposite directions.
To push the boundary further is it conceivable that the idea of a motorway would be accepted; a road which is specifically designed to allow these machines to travel at high speeds and facilitate the concept of vehicles overtaking one another when a driver feels another driver isn’t travelling fast enough.
This description sounds almost farcical given that in today’s society it is necessary to do a risk assessment for the most mundane task. It seems ludicrous that such a dangerous proposition would ever be permitted to go further than planning stages, if indeed it was ever given any serious consideration.
This opens up a related debate as to whether modern health and safety principles are stifling innovation and creativity. Had the car first been proposed post millennium it is unlikely that it would have ever been allowed to go ahead; it is therefore conceivable that great inventions that could revolutionise the human race are being prevented due to bureaucracy, which, is not proportionate to the potential risks of the task, problem, or idea.
The argument can be applied in principle to many innovations that have allowed man kind to develop over the millennia, including electricity, nuclear power, and coal mining.
This article serves as a warning to society that our history is based on innovation and growth and in the modern world it would appear there is a real danger of stifling that innovation which could jeopardise progression and lead to a society that forgets how to innovate.
Those of you who know me will know that I really value conferences. The opportunity to take some time out to learn, develop and grow is so important in order to contribute to our community, to network and to share ideas.
This week I have been privileged to join Lead Dev London at the Barbican Centre. The conference itself has been hugely well organised and I think Meri Williams needs huge kudos for being an excellent host.
On a personal note it is also hugely refreshing to see diversity and inclusion at the heart of an event. June often sees companies and events go all rainbow coloured but so often this is simply a token gesture – Lead Dev have really thought about how to ensure that everyone can participate fully in the event – from rainbow lanyards, to pronoun stickers, to live captioning, to free childcare this event has done a great job and I would encourage other events to follow their example!
So lets take a look at my best bits of the conference! It really has been an amazing two days!
Navigating Team Friction – Lara Hogan
This was a great opening keynote for the conference. Its so important to understand the phases that teams go through and to find ways to allow the team to progress naturally through the phases of team development. Lara succinctly summarised what to expect during team development and reinforced the idea that the forming, storming, norming and performing cycle really is a cycle. She has also written a book on Resilient Management I haven’t read it yet but its totally on my reading list.
Bottoms Up with OKR’s – Whitney O’Banner
If you have ever used Objectives and Key Results this talk radically challenge the way you’ve written and thought about them. The biggest takeaway from this talk was to stop setting OKR’s for individuals, focus on the teams and rather controversially remove the numbers from the goals – I totally agree that nine times out of ten such numeric goals are Scientific Wild Ass Guesses (SWAG) – and thank you for the new term to quantify what I already knew!
Building Security Culture on Infrastructure Teams – Franklin Hu
How long is a piece of string: the key to solving the conundrum of software estimation. – Jonathan Rigby
This is a problem that I have grappled with in every role I have undertaken – Jonathan argued that the true resolution to this problem is all about trust that expectations will be effectively set with stakeholders by team members. We need to trust that developers will give honest estimates that truly reflect the work that they think is involved and trust on the part of the product owner that they will not make hard and fast promises to the business based upon those estimates. Alternatively, if all else fails we could always join the #NoEstimates movement – getting more work done in the time you would have spent producing inaccurate estimations – GREAT CONCEPT!
So many other talks deserved a mention in this post – videos are apparently on their way soon so you can check them out yourself and I’ll post a link when it becomes available! A huge thank you to everyone for a great two days and hope to see you all again next year!
Joining any organisation in a management position is challenging; you will likely have people reporting directly to you (directs) and you will also be reporting into a more senior manager yourself.
Prior to your arrival in the role it is likely your new directs will have been told that they are about to get a new boss. This can be incredibly nerve racking for the individuals concerned and will have likely been asking themselves questions like “What is s/he going to be like?”, “will we get on?”, “what if they don’t like me?” and “how can I make a good first impression?”.
What is often forgotten is that the new manager is likely to be feeling the exact same feelings but from an alternative perspective and within this lies an opportunity for a meeting of minds.
My approach when joining an organisation is not to immediately force the relationship; meet your new directs as soon as you can and start with the principle of just being a nice person. Try to find out something about them and try to find common ground both inside and outside of work.
As I started my new role at Boots one of the key strategies I have adopted is to ask everyone that I have met about the challenges they are currently facing within their role and the challenges that they feel are currently being faced by faced by (in my case) the Digital Portfolio within the organisation. My intention in focussing on this question is:
- To understand where there are common themes. Are different people reporting the same challenges from different perspectives.
- To evaluate where I need to focus my attention most urgently and the areas that I might be able to have a positive impact.
- To open up a dialogue where I am clear from the outset that I am here to help and that I will work with the individual to help them to remove their pain points.
The same is true of my directs. In asking these questions it immediately sets a tone that I want to help them to succeed. Where challenges exist I can then work with the individual concerned to help them to overcome the obstacle.
I’ve recently been reading some very interesting articles about the difference between a Boss and a Leader (more posts on this soon). My belief is that from the very first conversation you have with a new direct report you need to ensure you are displaying leadership attributes as this sets the tone for all future conversations that you have with the individual. If you’ve missed this opportunity and haven’t been able to set the right tone from the outset don’t panic – its definitely not to late to change the dynamic but it becomes a little harder to do so.
In my experience making the first impression count is incredibly important; you only get one chance to create a first impression and if you get the relationship off to good start you can remove the mutual nervousness that you and your new direct are feeling. It is your responsibility as the new manager to own this first impression.
If you have any thoughts on how to approach meeting new direct reports please comment below to continue the conversation.
In the last few months there has been a huge amount of change in my life which has culminated in me being appointed as the Engineering Manager for Boots UK in Nottingham.
Digital at Boots is in a really interesting position; you only have to look at the climate on the high street to realise that retailers need to adapt or die. Boots have clearly expressed a vision to enhance digital and focus on in store experiences.
In September a new CEO was appointed for Boots UK – Sebastian James comes from a strong retail background having previously been CEO of Dixons Carphone. In his role at Boots is opening stating that digital transformation must be at the heart of the business.
Joining Boots as the Engineering Manager provides me with a unique opportunity to shape the development of digital platforms across the business focussing on Design Driven Development to drive our customers digital experiences.
Having previously worked in small business environments this change is a radical shift in my own career progression. Taking some of the ideas and initiatives I have introduced on a much smaller scale and providing me with the opportunity to see how these models can scale for use in a large corporate environment.
Over the coming weeks I intend to document my journey and the journey of Boots UK here on WestgarthsWeb as we reinvent the digital experience of one of the UK’s best known retailers!
If you have any comments, feed back or questions please feel free to reach out on Twitter.
Recently I’ve been giving a lot of thought to design patterns within .NET Projects. I was invited in February to give a talk at DotNetNotts and I explored the Unit of Work Design Pattern which is often selected as a valid design pattern by developers due to the way it conforms to the requirements for separation of concerns.
The approach does however break several of the SOLID principles and this has lead many to favour other patterns and approaches.
Below is a recording of the talk given in February 2018. Would love to hear your feedback
I recently gave a talk at NSManchester, an IOS Developer Meetup group. The talk focussed on common mistakes that developers often make when developing apps.
While the talk was focussed specifically on Software Developers a number of “mistakes” are directly relevant to end users and consumers who might be considering embarking on an app development project.
One of the most frequent mistakes we find when a client describes a new app idea to us is that the idea lacks focus. It is very temping to create an app that has a huge amount of functionality under the allusion that more features will result in more users.
The reality is that 26% of mobile apps will only ever be opened once and 48% of mobile apps will be opened less than 10 times. It is therefore incredibly important to focus your service offering so that the core idea of the app can be tested with users before to much money is spent on the development of the product.
Within the software community we often use the term “Minimal Viable Product” this essentially means you should write the smallest amount of software that makes a viable product and then test this directly with users to see if the intended value proposition is well received.
Understand the Business Model
It is a widely held belief that releasing a good app will automatically make significant amounts of money. Take Angry Birds, developed by Rovio; the company has generated millions off the back of a successful app.
What isn’t as well documented is that Angry Birds was actually Rovio’s 56th app concept and that prior to angry birds their development bill had ran into several millions of pounds as they tried to find the right product.
In addition Angry Birds was first released into a much less crowded app store where it was much easier to get noticed. Today with over 2.2 million apps in the app store it is incredibly difficult to get noticed.
We find that the most successful apps are the apps that build upon an existing customer base and provide a new value proposition to users who are already using a service or product provided to a company.
There will always be exceptions to the rule; flappy birds was one such example, but sadly without huge marketing budgets the majority of apps simply go unnoticed and never gain any form of social traction.
It is therefore important to understand where the revenue will come from before investing in developing a product.
Building for Multiple Platforms
This is something often recognised by app entrepreneurs; do I develop for Android, iOS or both. In reality you want to feature on both platforms but I believe it is a myth that both platforms need to be at the same stage of development. It is much better to invest money in one platform to prove a concept, iron out the bugs and get user feedback before duplicating the effort on another platform. That way you can learn from your mistakes and ensure that you don’t spend money making the same mistake twice.
Market your App as soon as possible
People are often worried about sharing their app idea in case someone “steals it”. The reality is that its hard work creating an app and its unlikely anyone would ever do this. Much better that you tell as many people what you are creating as soon as you start creating (or even before you do) as this will allow people to contribute ideas, tell you what they think and hopefully avoid money being wasted on an idea that is unlikely to gain traction.
If you wait until you app is in the app store before marketing it you are likely to be incredibly disappointed with the numbers of downloads and find paying for changes to your app that could have been incorporated into the initial development.
The best people to test your app are the people who are ultimately going to use it. A software development is a living thing, that’s why apps are constantly being updated. Get as many people as possible to use your app and provide feedback; that’s the only way you will ensure that you do not release a buggy app and that the app does what it was intended to do.
So there you have it, a few pro tips that might come in handy if you are considering developing an app. If you have an idea for an app get in touch and let us talk it through with you; hopefully this will result in you making a sensible investment decision and not wasting money on an idea that is unlikely to gain market traction.