Monday, 12 November 2018

Textual description of firstImageUrl

Leading Developers

I hit something of a milestone this year, I started managing developers. This didn't seem like a big thing at the time - simply a sensible internal restructure to establish clearer leadership responsibilities in my company and allow me to really focus a new team on trying to get a brand new product off the ground. It was only through later recollections and reading that that it occurred to me that leading developers as a non-programmer was perhaps a more significant change than I appreciated.

One recollection was Paul Gerrard introducing Rob Lambert for his keynote at EuroSTAR 2014 - out of the wealth of positive things that Paul could have highlighted, one he picked out was that Rob was a rare example of a tester who had transitioned to leading developers. It did strike me as rather a sad reflection on the state of testing that such a step should be considered unusual for a person of Rob's talents.

A second event was that I recently meet a former boss of mine for a drink as he was staying in the area. Having just returned to the UK after a period heading up development for a product company overseas, he was now looking for a new role but had encountered some frustrations. Coming back to the UK he was finding it harder than he expected to get similar roles because he didn't have hands on development experience. It seems that despite the fact that he had successfully run two product development teams in his previous two roles, his background in product management rather than programming precluded him from being a suitable applicant to an equivalent job, as for many development leadership roles the employer insisted that the applicant be a programmer.

A third trigger was when I saw this quote from this summary of a Mind the Product Leadership forum

"At the most innovative organisations, Product and Engineering report into the same leaders."

If I was to choose one word to characterise how I want the Product Development at Team River to behave it would be innovative, so naturally my confirmation bias went into overdrive on reading this. I'm aware that this statement says nothing about whether those leaders come from development or not. The fact remains that such an arrangement was unusual enough to be highlighted as trait of particularly innovative organisations.

I can't say I really understand why this is apparently such a novel arrangement. If it is the case that the most innovative companies align product and development to the same leaders, why do so many organisations insist on their development leaders being programmers when people from other roles could be just as capable, if not more so?

Doing the right thing ...

The two best leaders of development departments that I worked for in my earlier career both came from product roles. I've personally found product leaders to be more inclined to focus on the value and outcome rather than process and standards of a product development operation. To me the former is a healthier focus for a development group. The product leaders I've worked with tended to worry less about rigidly sticking to methodology than being flexible around delivering value in their own product context. This provides a strong motivational benefit for the teams they lead. It's far more engaging to collectively work to address risks to customer value than striving to deliver the perfect process.

There is naturally a risk that a focus on features over process can be just as damaging, however the most effective leaders I've seen have respected the team and delegated responsibility effectively to ensure that process decisions are made within the teams rather than being dictated. In short the strongest collective innovation and collaboration around effective processes that I've been involved in has been from teams headed by folks coming from product roles rather than coding.

... or not doing the thing right

By contrast I've seen some very poorly run development teams when the leaders have come directly from development roles.

I've found that some strong developers can have a very fixed idea of how things are done, which can stifle and suppress ideas from other members in the teams they are leading. I've seen more than one development team whose regular meetings descended into a process of repeating the same arguments about coding standards and methods between the development leads.

This doesn't just apply to coding. Methodology and process is another area where imposing certain methods or architectures on teams can result in resentment and frustration from those members who felt they could input more creatively into how the team work. Developers in leadership that I've encountered were more inclined to arbitrarily apply and insist on doctrine from books or development gurus, without questioning the contextual value of such practices, than more business oriented leaders. In one extreme example an extremely talented and capable developer friend of mine described to me working in a new role where he was reprimanded for delivering too many story points, as the development lead placed a high value on consistent sprint velocity and wanted to minimise deviation.

I have, of course, encountered some really good leaders who were developers. I also strongly believe that technical leadership is essential to help coalesce teams and drive progress - I actually recommended the introduction of more technical leadership to address some of the productivity challenges we were facing when I started working on the River agency programmes. What don't agree with is the argument that development skills are a pre-requisite to effectiveness in a role with overall responsibility for a software development operation. Strong leadership skills cut across disciplines and are more important than any technical ability when it comes to running software development.

What do I wish for?

Leading a development team on an entirely new product has been as challenging as it is exciting so far. As I wrote in this post my approach aligns with the principles of servant leadership, with all the challenges that entails. As a team we've had heated debates about the shape of the product; the value of certain features ; how visually 'shiny' an early stage product needed to be; whether to remove certain features; whether to automate tests before we're confident in our early features and all manner of other topics.

Through these discussions I've found myself wishing I'd had lots of things

  • More time to work problems through before presenting to the team
  • More access to users
  • More experience of user research
  • More design skills
  • More real world examples of our target market
  • More persuasive communication skills
  • and more sleep
One thing that I've never found myself wishing for its that I had more programming skills. I'm by no means a technical slouch, my first job was programming years ago and I have learned a few languages since, but I've limited knowledge of the specific architecture that our developers use. This hasn't been a challenge, because I have a number of developers in the team who do have that knowledge to a level I'd never hope to achieve, and more importantly, I trust what they tell me. What I can say for certain is that as a team we're definitely collectively focussed on delivering the right thing. Working out what that is, now that's a different challenge.

New Product, New Story

As Team River and I progress in this journey of getting a brand new product off the ground I'll be writing more around the themes of building a start-up product. It's a process that involves a wealth of mistakes, a huge amount of learning and a whole lot of testing across the whole process. I'm looking forward to sharing some of the successes and failures that we encounter as we go.

Photo by Ilya Pavlov on Unsplash

Monday, 8 October 2018

Textual description of firstImageUrl

The Sacrifices of the Servant Leader

Being in a position of leadership is a mixed blessing. Many of us starting out in our careers assume that achieving a position of leadership, and the respect that comes with it, is something to ultimately aspire to. Others don't feel this calling and at some point on their career path decide that a position of deep expertise is more suited to their skills. Some end up in leadership without any real concept of what their approach is - after all many people are promoted into a leadership role from a technical position without any real training or initiation into the role. Many such folks tend to 'find their style' rather than intentionally selecting a particular approach based on their personality or context - in my experience this can result in some rather unpleasant and dictatorial work environments.

Having studied management science in the past I have found that as I've moved into senior roles my approach has been guided heavily by my former studies on management, leadership and motivation. Whilst not a purist in any sense, I do find that the concept of 'servant leadership' is one I can strongly associate with. Research, and my own experience, suggests that the approach - whereby leadership is delivered through promoting collective decision making and supporting teams in taking responsibility - is very effective at leading teams to successful results, particularly when compared to more autocratic approaches. This success can, however, come at some personal cost to the leader themselves....

What is servant leadership and why is it a good idea?

I don't particularly like the term servant leader. It under-sells itself as a term, for me coming across rather weak and woolly. The reality could not be further from this. Yes servant leadership is a more supportive approach than other approaches, but it's a hard approach to adopt that takes strength and commitment to deliver.

  • A servant leader will seek to bring together diverse opinions rather than dictating their own ideas with a focus on inclusive decision making
  • Servant leadership is built around the idea of culture of mutual trust between leader and team which requires a high level of openness and honesty
  • The aim of a servant leader is to encourage others to take responsibility and provide support to improve their ability to do so
  • A servant leader places a high level of autonomy on teams and motivates people to step up and deliver

This definitely correlates with my style of leadership. I believe that building strong autonomous teams containing the right balance of skills and supporting them through a process of collaborative decision making provides the greatest opportunity for long term high performance and incremental improvement.

Does it work

I can appreciate that one person's experience does not provide for exhaustive evidence. Also my personal approach isn't one of 'pure' servant leadership. Last year I took an IDEOU course in creative leadership which identified 3 types of leadership.

  • Leading with a strong point of view
  • Leading through culture
  • Leading alongside

Servant leadership ties in strongly with the last of these. I agreed with the couse approach that to be effective this needs to be combined with other leadership approaches that can be adopted at appropriate times. This allows a leader to establish a vision and culture necessary to establish an environment that supports servant leadership.

In the situations where I have personally succeeded in creating such an environment and adopting an approach aligned with the principles above, I've experienced significant benefits as compared to other leaders that I've seen adopt a more autocratic standpoint

  • Team motivation - Being more inclusive in decision making really does motivate everyone to contribute ideas. I find that people respond well to being part of a decision making process and really engage as part of a team that makes their decisions and deals with their mistakes collectively.
  • Not hiding the problems - Playing a supportive role for people working in your department helps to more quickly spot the problems and keep them out in the open. Rather than having a culture of hiding bad news from the boss, keeping problems out in the open helps to identify where genuine and useful improvements can be achieved.
  • Collective Responsibility - Delegating responsibility for decisions helps to ensure that people are genuinely considering the risks and benefits of what they are doing. One of the biggest dangers of command and control leadership is that those implementing decisions are aware of the problems that may arise from them, but don't act on this as they have no personal responsibility for the negative outcome
  • In it together - Adopting a standpoint of serving the team provides a sense of being all in it together which makes it easier to drive through difficult times or raise and discuss challenging subjects. I recently raised a subject with my team around some potentially negative habits which, as an autocratic leader would have made them very defensive. Instead I discussed whether there were any underlying causes and whether the habits indicated problems with direction or motivation that I could help with. As a result we had an honest and open discussion without animosity about a potentially emotional subject.
  • Knowing how to help - When problems do arise I find that a servant leader approach actually positions me well to help the team to work through and deliver. When I've been in a more isolated 'pure management' role relative to a team with problems I've found my input very limited. There's nothing worse as a leader than being limited to repeating platitudes and passing ineffective generic advice on issues that I don't really understand.

With this in mind - I'm not about to change my approach to leadership in a hurry, however it's not all plain sailing...

Challenges of being a servant leader

Given all the benefits I've outlined why at the start did I suggest that being a servant leader may not be so great for the leader themselves?

I think the main challenge is that, being an effective servant leader is only possible if you work within and among the people who report to you. Unfortunately this can diminish your standing from the perspective of other with different ideas on what leaders look like.
It's a frustrating dichotomy that to be a really effective leader requires humility and the abdication of ego, yet doing so may undermine some people's perception of you as a strong leader and can place at risk some of the 'respect' that comes with a position of leadership. In a world that increasingly promotes individual 'profile' and accomplishment, delegating responsibilities and achievements is something that may appear to place our profile on the back foot on a few different fronts.

In the team

  • Not leading the charge - It can be hard to give up being the one at the front. For someone used to setting direction it can be unnerving to accept input from others on the best approach. This is something that I have got used to, while at the same time having to remind myself not to be too defensive about my own opinions.
  • Finding the time for strategic thinking - Leaders will naturally have responsibilities for strategic direction and long term planning that may not be the focus of other members of the group. Yes we can coordinate group planning and strategy workshops, but ultimately the responsibility for strategy will lie in leadership and it can be hard to carve out time to do this when operating to support the day to day team activity. I find that taking time away from the office at fixed times (e.g. 'Strategic' Work from Home Wednesday mornings) helps to step into that more long term mindset and ensure the important long term considerations aren't forgotten.
  • Constant questioning can be demotivating - This is one that I find personally tiring. While the dictatorial leader can issue JFDI commands and expect unquestioned obedience, a servant leader can and should expect to have to justify their decisions. This undoubtedly results in a lot more consideration of the decisions that you make, which overall is a good thing but can become tiring if you are having to do preparations worthy of a court prosecutor to progress decisions. There's a balance to be had here and in my current role I've worked to establish an expectation around the degree of questioning that is appropriate. This is based on trust in my decisions and has been necessary to ensure we avoid justification paralysis and avoid the risk of not being able to progress anything.
  • Bring together opinions - Inevitably when it comes to collective decision making not all opinions will align and individuals sometimes come to loggerheads over which approach to take. This is when the strength inherent in servant leadership really comes apparent. Being able to bring opinions together into a considered approach that everyone at least supports is critical to avoid ongoing resentment and counter-productive behaviour towards other people's ideas.
  • Being T-shaped - As part of an effective Square-shaped team, leaders need to be T-shaped people as much as everyone else. This inevitably means having to learn basics of a lot of skills at a level that allows you to understand and evaluate options, if you are to drive decisions that others respect.

Amongst other leaders

  • Underestimation resulting from not visibly making all decisions - Allowing others to drive success and supporting them in doing so means stepping out of the limelight so that others can step in. In environments of competitive leadership this can seem like a personal sacrifice.
  • People think it’s easy - This is an unfortunate consequence and something I've encountered a few times. When you are running effective teams or departments with little fuss, this can result in others' perceiving your situation as somehow easier than if you're battling disorganisation and discord.
  • Less credit for achievements - Inevitably when working to share collective responsibility and recognition for work there's less of a sense of personal achievement. Whilst this is both right and good, it is still a relative sacrifice when compared to the high level of individual achievements that we may have enjoyed through education and early career. It's right and good for those not in leadership roles to get the lion share of recognition for their efforts - after all being in a leadership role in itself is an ongoing reward for achievements of the past. At the same time it's important to gain appropriate acknowledgement for your achievements so maintaining a solid professional profile both internally and externally e.g. on LinkedIn is a good way of tracking your own achievements.
  • Less time for leadership positioning - Leading from alongside a team requires a much higher level of involvement in day-to-day work than high altitude command and control behaviour. This is time consuming and can result in having less time for general high level relationship building that's key to progressing oneself and influencing the higher level decisions in a company. Just as maintaining time for strategic work is important, so too is taking the time to maintain solid relationships with your peers and ensure that your close connection to practical delivery doesn't diminish your internal credentials.

What flavour respect

At the start of this post I used the word Respect to describe an aspirational goal for those pursuing leadership roles. In a literal sense this seems harmless and should be something that we should all expect and drive for. In a leadership context it's one, as I've stated above, that we fear is most at risk when we adopt a servant leadership oriented approach. Respect however is nuanced, and I'd argue that respect is a word that has negative connotations as well as positive, and I personally place much higher value on some sources of respect than others:-

  • I value respect from my teams, however I would never expect to insist that they respect me purely through my position.
  • I value respect from my peers, whilst at the same time not wanting to receive that respect for values that I don't believe in.
  • I don't believe that respect should ever come through fear, such as wielding the power of hiring and firing.

I think that with an approach aligned with servant leadership, respect comes mutually. It gets greater over time and is strengthened rather than diminished by admitting mistakes and admitting others opinions may be more valid. It is reinforced by taking on board others' ideas and including them in decisions.

Most importantly respect for the servant leader is received because it is given. For me that provides the strongest basis for deserving it, so even if the principles of servant leadership may present some challenges on the way, I don't see myself giving up on them any time soon.


Robert Greenleaf is probably the most notable advocate of servant leadership * A brief introduction can be found here - * A more in depth exploration of the concept here - The Servant As Leader * Interesting arguments presented here as to why the approach is not more popular -


Tuesday, 14 August 2018

Textual description of firstImageUrl

A Salesperson for Testing

One of the challenges of progressing in your career is maintaining the ability to admit you're still not great at some things. As you progress into more senior leadership roles it's easy to fall into the trap of getting more defensive about your shortcomings when a younger you would have been more open about them and therefore ironically more likely to address them.

As I progress in different roles I try to make sure I continually maintain a realistic sense of vulnerability and look for areas where I can continue to improve. One such area I'm working on right now is persuasive communication. I often find myself frustrated with an inability to persuade a group of my position, even if I feel that it is justified. I find that my inability to concisely persuade others is the cause of a significant amount of my work stress in not being able to turn insight and experience into influence.

Selling without knowing it

In order to try to improve on this I was recommended the book 'To Sell is human' by Daniel Pink. It's a fascinating book written around the idea that, although the number of people employed in direct sales roles has reduced, the number of people who spend their time in activities to influence and persuade others has increased such that we are all essentially salespeople in one form or another. One of the key sections of the book explores research performed on how much sales-like activity people are involved in as an inherent part of their working lives ... quite a lot as it turns out:

"People are now spending about 40 percent of their time at work engaged in non-sales selling - persuading, influencing and convincing others in ways that don't involve anyone making a purchase. Across a range of professions, we are devoting roughly twenty -four minutes of every hour to moving others."

I've never wanted to be a salesperson. I'll admin that I have harboured a certain level of disdain for sales jobs in the past, along with many of you reading this I'd dare to suggest. I felt that salespeople were a certain 'type' with potentially a higher level of extroversion coupled with a slightly lower degree of integrity than I was prepared to adopt in my professional life. They were prepared to mislead customers to a false understanding of the value that they were going to achieve in order to achieve a sale. I have in the past rolled my eyes as I tried to manage expectations with a customer after an over-enthusiastic colleague in sales has promised capabilities in our software which hadn't yet progressed beyond the white-board. How much of my opinion was informed by such experience and how much purely driven by stereotype I can't say for sure, however based on the research and analysis presented in Pink's book I'm certainly not the only one to have held such opinions.

Whilst I have always rejected the idea of being in sales, Pink provides a compelling case in his book that actually being more effective at selling is something that has benefits way beyond just sales. The ability to convince someone to exchange their resources in exchange for your product, idea or service is one that is invaluable in any role that interacts with others as part our information and communication rich on-line industry of software creation.

Selling testing

In the testing community I've long moved beyond the idea that throwing counts of test cases and completion percentages at people was an effective way of communicating the status of testing. What I had perhaps failed to appreciate, until reading Pink's book, was that I believe a lot of the value that testers can add is in selling. If selling is the process of persuading people to trade their resources for an idea, opinion or position then the testing role can require a great deal of such activity.

  • Testers sell the need to prioritise one issue over another
  • They sell the need to commit more time to risk mitigating activity prior to releasing
  • They sell the need for testability to developers
  • They sell the value of spending effort on rigour in development processes in order to reduce risk
  • They sell the reduction in scope of features in order to achieve greater confidence in a robust outcome

So, whilst we may not necessarily feel or want to be expert salespeople, to be an effective tester requires negotiation skills that would make most salespeople proud.

Reasons to be positive

Before you cry into your coffee in the realisation that you've actually been working in a sales role without realising it, there are some great take-aways from Pink's book that leave a lot of reasons to be positive.

  • Ambiverts make better salespeople - The belief that extroverts make the best salespeople is so ingrained in our expectations that it is rarely questioned - yet evidence suggests that it simply isn't the case. In actual fact there is a strong link between effectiveness at sales and level of extroversion, however the most successful level is in the middle - neither introvert nor extrovert. If you worry that to be effective at persuasion requires you to be the most gregarious character in the office - don't. Chances are if you're a tester who balances a strong analytical focus on detail with the ability to communicate with various stakeholders, you're probably better at selling than you think.

  • Salespeople with integrity are better - If we genuinely believe in the value of what we are selling then we negotiate on the basis of progressing towards a mutually beneficial outcome. Pink suggests shifting the focus from "selling" to "serving" and making sure that you believe that both parties will benefit from the transaction will result in you being a more effective salesperson.

These should be give us a lot of encouragement when it comes to 'selling' testing. To start with most testers I know fit solidly into the ambivert camp. Plus I'm confident that in the situations where I've negotiated for greater testability, or argued for the roll-back of a volatile change, then I'm striving to benefit both sides of the transaction. I'm not typically in the habit of just negotiating in my own interests or the interests of just the testers - it has always been from the position of trying to reduce risk and achieve the best outcome for everyone concerned. Just as a better salesperson who genuinely believes that what they are selling will benefit the customer, so as long as we believe in the value of our information and the decisions coming from it then we'll be better and more persuasive testers. If, however, our negotiations are purely geared towards the interests of our own roles or teams with no tangible benefit for anyone else (read this post for a great example) then we should consider ourselves no better than the stereotypical car salesman in a pie hat putting sawdust in the gearbox in order to flog a dying car.