Career Development Planning Questions

Part of the role of an Engineering Manager is to help others to achieve their career aspirations. However, it's not always easy for people to articulate the direction they hope their career will take them. For some, it can be difficult to describe their ideal future role, or to answer that "where will you be in 5 years time?" question.

I have struggled with this question too. I wanted to share a technique one of my previous managers used with me to uncover my aspirations. During the session, he asked a number of questions about my current role and then asked me to transport myself to a point in time in the future. Once there, we discussed what my day-to-day work looked like, and uncovered some of the aspects I considered important for any future role.

We then spoke about the distance between my current day-job and the role I described as part of my future self, and built a plan to address the differences.

The technique is very similar to the futurespective retrospective activity that many agile teams use to uncover problems with the way they work.

I've used this technique with others in my team to build their own career plans. In doing so, it's helped me to understand some deep-seated desires within people I work with, and given me a better understanding of the things I need to do to help them reach their goals.

If you want to run a similar session, I've included the questions I ask below. I usually conduct these sessions in front of the whiteboard, asking the questions, and writing or drawing the answers on the board. This allows the person whom you're conducting the session for to really concentrate on visualising the future, rather than having to take notes.

First, let's talk about your current role

  • How do you describe you current role?
  • What does a typical day or week look like for you?
  • Who are your key stakeholders?
  • What makes you happy?
  • What was the best thing you worked on?
  • What irritates you?
  • What was the worst thing you worked on?
  • Thinking of a typical week, how would you plot your time on a pie-chart?
  • Are you more of a specialist or generalist?
  • Are you more strategic or operational?
  • Are you reactive or proactive?

Now let's look forward. Imagine we meet in 5 years time...

  • Where are we meeting? What are we doing?
  • Where do you live? Have you moved?
  • What are you doing wth your free time?
  • Are you working? Is it full-time or part-time?
  • Which country are you working in? Which City?
  • Are you working from an office or somewhere else?
  • Do you travel with work? How many times a quarter?
  • What industry do you work in?
  • Tell me about your work. Do you work for a company? Or yourself?
  • Are you a developer? What are you building?
  • What is the culture of your workplace?
  • What projects are you working on? Tell me about them.
  • Tell me about the company you work for.
  • How big is the company? Where are they based?
  • What is your role? Who are your stakeholders?
  • Are you managing people? How about mentoring people?
  • What do others say about you?
  • How do you learn new things?
  • How do you stay current?
  • Thinking of a typical week, how would you plot your time on a pie-chart?
  • Are you more of specialist or generalist?
  • Are you more strategic or operational?
  • Are your reactive or proactive?

Looking at you future self...

  • Is there anything else that will help me understand your future role?
  • What aspects are non-negotiable?
  • What answers are you certain of? Which are more difficult to answer?

Comparing you and your future self...

  • What are the main differences?
  • How did you move between specialist and generalist?
  • And how did you move between strategic and operational?
  • And between reactive and proactive?
  • What skills are you missing?
  • What do you need to improve?
  • What new experiences do you need?
  • What's going to stop you from achieving your aspirations?
  • Who's going to stop you from achieving your aspirations?

Finding great places to work

Early today I tweeted this.

I thought it was worth giving a little more detail as to what was underlying this pithy sound-bite.

Over the last year, I’ve changed companies twice. At the start of 2016 I left eBay and started a new role with Marks and Spencer. Later in the year I left Marks and Spencer to join Alfresco.

In both cases, I’d become frustrated with my current company and thought that there existed better options for me to progress as part of a different team. I left eBay because I was fed up with the international travel required in the position, something which was becoming more frequent as my role became more senior. I left M&S when it became clear that my ideas of what great engineering teams look like didn’t align with the way the senior leadership wanted to take the team.

As I moved teams, I was optimistic that the new position would relieve those frustrations I’d had with the old one. Whilst in most cases, this has been true, plugging one hole only caused the frustrations to come from elsewhere.

What’s clear in every change I’ve made, is that there are very few (in fact, there maybe none) truly great places to work. Whilst there are many places which may appear fantastic from the outside, there's always something about them that will cause frustrations.

Therefore, if there really is few great places to work, then it’s likely that you’ll end up at the ones that aren’t so great. If this is the case, what matters more is whether you have the freedom to drive the place to be great.

So, rather than assessing your next position on how good the team currently is, look at how likely it is that you’ll get the opportunity to make them better. A team that has a track record of inspecting and adapting, and can acknowledge its problems, is likely to be a better long term fit than the team that already believes it has achieved “great” status.

Are Scrum Masters Harmful?

This year, I’ve had the opportunity to work with agile teams across a couple of different companies. Whilst Alfresco and Marks and Spencer work in different industries, both have adopted agile as their way of working. To help teams deliver, both employ full-time Scrum Masters, and at both companies, most agile delivery teams use Scrum, complete with all the ceremonies, to deliver software.

Seeing the way that both development teams work over the course of the year, I’ve begun to wonder whether the role of Scrum Master is actually harmful. To be clear, I’m not saying that the people in these roles are bad people, rather that by employing a full-time Scrum Master, you are unconsciously locking yourself into a particular development methodology.

The Scrum Guide defines the Scrum Master role as:

“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”

Embedded in this definition is the assumption that by employing a Scrum Master, that you have someone who’s responsibility is to guarantee that your teams are adhering Scrum. This person ensures that teams are following the Scrum practices (estimating, burn-downs) and operating within the confines of the Scrum framework. The Scrum Guide adds this restriction when discussing the use of retrospectives (emphasis my own):

“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.

For some teams, other development practices or frameworks are more appropriate. For example, it may be more appropriate for a team to use Kanban when more flexibility is necessary, or when teams of specialists exist.

Unfortunately, over the past year I’ve seen teams cargo-culting Scrum in their teams, and it’s my hypothesis that having a role of Scrum Master is partly to blame for this. It becomes hard for a team to challenge Scrum as a way of working, when a person they work with every day holds a role that is solely there to employ Scrum. A vote against Scrum can be seen as a vote against this person. This results in the team continuing with practices that don’t help them to deliver software in their context.

The good Scrum Masters recognise that the job title is just that, and that it shouldn’t unduly influence the way the teams work. However, this can’t be said for all. Challenging Scrum as a framework is seen as questioning their validity, and so they act to defend all aspects of the framework. It’s in these cases where I consider the role of Scrum Master to be harmful.

Of course, it could be that the organisation wants to use the Scrum framework, whatever the implications. This doesn’t feel right to me, as it’s at odds with the ideas behind the agile manifesto, in particular “people over process”. In these cases, further inspection is required to understand why an organisation is so hell-bent on implementing Scrum. I’d wager that in many cases it’s down to a lack of understanding of agile development.

So, what is the alternative?

I’ve talked this through with a couple of colleagues, and others in the software industry. GDS steers away from the Scrum Master role title, instead using the role “Delivery Manager” for providing team support, and developing team efficiency. If job listings at NotOnTheHighStreet, Co-Op, ITV and ASOS are anything to go by, then other teams are taking a similar approach.

I’ve not worked with a company that uses this approach, so I can’t comment on what impact this change has, or whether this title change has other unintended consequences. One of my concerns would be the introduction of another “Manager” role (to add to Engineering Managers) into the engineering organisation.

Would M&S and Alfresco operate better after just changing the job title of a few people? I think it’d send a good message (we’re not tied to Scrum), however I think it’s just one aspect of a change in culture that’s needed. After all, the same people will still hold these titles, and if these individuals see Scrum as the one true way, then it’s unlikely to have the necessary effect to improve team performance.

Another alternative is to remove the role entirely, and have the team self-organise around the work. Operating in this mode requires engineers that deeply understand how what they do fit into the wider business, and have the necessary skills to introspect and improve. Many teams can’t do this effectively without support.

Finally, there’s the approach we took whilst at eBay. Some teams had Scrum Masters, yet it was a hat a developer wore rather than a dedicated full-time role. For some teams this worked really well, however for most the Scrum Master role was seen as team secretary and as such wasn’t a hat many people wanted to wear.

The right approach for your organisation will depend on your context and the goals you’re trying to achieve. I don’t think that there’s a single way of solving this issue, however I’m also pretty sure that unless you are unreservedly dedicated to the Scrum framework, that the role of Scrum Master can have unintentional consequences.

The titles that individuals take on in your organisation will influence the way you work. I’ve described the effect the role of “Scrum Master” can have on the way a team works, and the (sometimes) unconscious decisions we’re making by employing people into this role. It’s a widely known idiom within software development that “naming things” is one of the two hard problems in computer science. We’ve seen here, that this not only applies to code, but also to people within your organisation.

Books from 2016 - Part Two

This is part two of my review of books I've read in 2016. Part One can be found here.

My complete "Year in Books" can also be found on Goodreads.

Quite simply, this is a must read for any modern software engineer, or for anyone associated with building software. The nitty-gritty of implementation isn't really covered, so don't expect to finish the book with all the answers. It talks from a high level of abstraction, and it's clear that it's somewhat targeted to managers as well as developers.

The book lays out the reasoning for changing your development process through automation, and provides a high level view of how to do this. It's opinionated, without being preachy, and leaves enough room for the reader to make their own choices of how to implement the ideas in their own context.

It is fairly repetitive in places, however I forgive it as the topic is so important to all involved with building software.

FIVE DYSFUNCTIONS OF A TEAM
By LENCIONI PATRICK

Another book that presents a management model in the form of a fable. This form gives the reader enough of an introduction to a concept in order to get them interested, however not enough to know how to apply the ideas in practice. I think this is the main problem I had with the book.

Whilst the concepts were presented well through the story, it did leave me wanting more detail to understand how I could apply the ideas in my context. I was also aware that the story was fictional, so whilst the ideas seemed sound, it did leave me thinking whether they actually work in practice.

The book is often lauded in management circles, and it does provide a good introduction into becoming a leader rather than just a manager. It shows that empathy and trust are necessary to build and lead a great team, and that just getting the best people together isn't a guarantee for success.

Overall, an enjoyable and thought-provoking read, although a little light on details and actionable ideas.

This book made me feel uncomfortable at times. Not because it was bad, but because it was too close to situations I'd personally experienced.

Because of this, I could see the gap between reality, and the way the fable described process and process improvement. Readers of the book will be left with a couple of tools that they'll be able to use, but probably won't leave with the depth of knowledge to understand why these tools work. It also takes the author a long time to get to some of the key points, which means that their importance is lost.

I think it provides a good introduction into the world of DevOps and IT management techniques, and the use of a story, will help inspire those IT managers that are struggling with their own organisations to find out more.

I've been a follower of Jarvis for a while, and was eager to read his views on privacy. Jarvis lays out a compelling vision of publicness, going into detail to explain the benefits to both businesses and individuals. In parts, he pulls on his own experiences to show how being public can be of a great advantage to an individual.

Jarvis also tackles some of the problems with being public, however I think that because of his stance he doesn't dive into them as deep as he could. A book which talks so much about privacy online is also subject to falling out of date quickly, and in some places this is already the case.

Radical Focus is another business book, wrapped up in a fable to inspire. The Fable in question focuses on an early-stage start-up with a couple of founders who are struggling to grow the business. The founders want different things, and operate largely independently in order to achieve the necessary growth.

In steps a knowledgable VC along with an experienced CTO, both singing from the same OKR hymn-sheet. Hanna, our main protagonist sees the value of the approach, and implements the OKR system into the company. A year later, the start-up is soaring, and OKRs take a large portion of the credit.

It's a good story, and helps to frame the "why" of using OKRs in your business. Like many of these fables, it gives the reader enough of an introduction to the topic to inspire them to find out more.

The second half of the book details more examples around the implementation of OKRs at different companies. I found this really good, as it gives the reader some things that they can go away and try - something that is often missing from the business-fable genre. It also mentions alternative literature (specifically Google's implementation).

I would have liked to see more detail on the implementation of OKRs, perhaps backed up by some empirical studies into the effectiveness of the system. Whilst several well-known companies are mentioned, there's not much science to back up the claims around increased alignment, productivity and ultimate success.

That said, I'd suggest it as a beginners read into the subject of OKRs and goal setting.

Books from 2016 - Part One

At the start of 2016, I made a resolution to read more. I managed to do this, and read more this year than I've been able to do in recent years. Most of my choices have been leadership or management books, or those related to sport. It's also been mostly non-fiction.

Over the coming posts, I'm going to share the books I've read this year, and my thoughts on them. Part one, starts below.

Bock is part of the people operations team at Google, however I don't think that this limits this book to only people working in HR. The book is an insight into the way that Google works, the practices they use, and the "science" behind implementing these practices.

I found that in some parts the book, that I was being sold on how cool Google was to work at, and why my workplace wasn't doing things right because we're not offering the same way. It wasn't preachy, but the "come on, it's not that hard" attitude was at times a little off-putting. I would have liked to see more balance, perhaps with more emphasis on some of the things that didn't work out so well.

That said, the content in general is good. Each chapter closes with a clear set of "Work Rules" for making the work environment a better place for people.

As a fan of Pixar, I'd been looking forward to reading this book for a while, and finally got round to it earlier this year.

The stories behind the creation of some of Pixar's most successful movies, including Toy Story, were fascinating. As was the behind the scenes look at the acquisition of Pixar by Disney and the resulting impact on both teams.

Whilst the anecdotes were, in the main, entertaining, the actionable insights and content was sometimes lacking. Looking back on the book, I think that the title of Creativity Inc, is slightly misleading as it focusses more on improving the productivity of a team.

You also need to consider that Pixar were part of the wage-fixing group that was exposed a few years ago. Knowing this information, some of the ideas fall a little flatter than I believe the author intends.

I don't really know what to think of this book. Lyons tells a great story - a 50-something ex-journalist taking a position in a fast paced, growing start-up. The cynicism of the author on the practices of his host company help to highlight some of the ludicrous activities that are perceived as normality on the tech-bubble. It's the call-out that the tech scene needs, as some of the practices look really stupid when you lay them out on paper (for example, graduating from a company, rather than being fired).

I found Lyons view to be amusing, yet in places, it did across as bitterness. It left me feeling that Lyons had a chip on his shoulder about no-longer being the most important person in the room and for his status at Hubspot. He also comes across as unauthentic, shaming brogrammers for their culture whist in the same time praising the boys-club culture of media. Whilst he makes the claim that he was in the start-up for the long-term, it does leave the reader wondering whether the author's intention was to take the job in order to write this book. Hubspot just ended up being the "lucky" company to enable him to do this.

If you work in the tech-scene, then it's a good read, however being able to empathise with the author does mean that the impact of this book is limited.

It's hard to read this book and not let your opinion on it be tainted by your thoughts on Silicon Valley, and the start-up and tech cultures. I think that those who are living in these cultures, or on the fringes will find it enjoyable, however living in the UK, the story doesn't resonate in the same way.

From what I can tell (from media), the story told is pretty accurate. Focussing on teams as they progress through the incubator is a good way of hitting all the main points. The book also covers some of the criticism of Y Combinator.

You're not going to learn any secrets from behind the curtains of Y Combinator in this book, however the anecdotes do provide the reader with a view of what it's like to be a start-up founder in SV. How relatable you find that story, and ultimately how enjoyable you find the book, will be dependent on your own view on the SV start-up culture.

The story of how Elon Musk left South Africa, emigrating to the US and ended up founding some of the most innovative companies in the world is a fascinating one, and makes for an excellent read.

The book covers the life of Musk well, however it is at times a little bit fanatic in it's love for all things Musk. The hard topics such as his relationship with his father, his divorce and the way he manages the companies aren't explored in detail. Doing so, would have created a more complete view of the man and his ambitions.

Because of these missing details, you're left wondering whether this is a true recount of the achievements of Musk.