Some management archaeology from me today. Republishing a few posts after a recent site upgrade. This one seems even more critical in our current era than it did when I first wrote it…
When I started managing teams and projects for the first time I used to write down my most significant insights and lessons I’d learned in a little Black & Red A5 notebook.
A couple of months ago I pulled it off of the shelf and thumbed through my old notes. They’re almost all still as relevant today as they were over a decade ago.
Hiding among the notes on capacity planning, estimation, reporting, change management, innovation, reward systems, performance management, situational leadership and even a list of personal “observed best practices” was a single half-page of bullet points that simply read:
“How to ensure offshore teams are successful”
Since not long after I started writing publicly I’ve not needed to use those insights.
I’ve had the rare luxury of working with completely co-located teams (even “the business” sat with the teams in some of the the best cases). However most of us now face the challenges of working with remote, hybrid, distributed, offshore, and near-shore collaboration. These tips apply to any globally diverse team, not just “offshore”.
So that these insights aren’t lost to time, I thought I’d share and expand them here. I’m bound to have missed many others and this is my personal view from being UK-based and working with teams all around the world.
I have 2 requests for you as readers…
What tips and suggestions would you add to this list?
If you’re based in a remote or distributed team team, please, please, please share your insights from the “other side” – we don’t hear enough here.
1 – Management & Team Mindset
First – stop thinking “offshore” or “remote”. You’re a global team. Once you start treating your remote staff/suppliers/contractors as being “on your team” relationships start to build.
Pair team members and managers across locations. You’re working on the same goals, behave like it.
Manage all your team in the same way. Arrange 1-1s, feedback sessions, informal catch-ups, full team training. Have off-sites or outings for every site and share the pictures. Better still, do it together.
Your team includes your customers and suppliers too – involve them in your challenges and be rewarded.
2 – Shared Accountability
We often outsource to reduce effort, overhead, cost and risk. As soon as these become significant motivations, you’re already behaving in a flawed way. You’ll find your offshoring or outsourcing isn’t actively owned or managed.
You own the working relationship. It’s up to you to make it work. Find a counterpart on the other side to pair up with and make it successful.
A remote team will never be successful if your only reason for using them is cost. Figure out the unique strengths, talents and value they bring to you. Invest in partners and locations where you have better access to specialist domain knowledge, broader experience or better delivery capabilities.
A great example of this lies in the domain of one of my former employers – power systems. Power systems engineers are rare people at the best of times. In the US in particular, much of the power systems & networks domain knowledge is being lost through retirement. China on the other hand has a huge number of extraordinarily smart engineers in this space.
3 – Quality of Team
Perhaps it’s purely a capacity thing – staff availability in your home location may be a problem.
It’s a lot harder to hire a dozen amazing developers in Cambridge than it is in San Francisco or Mumbai. But given the size of the talent pool in those locations, it’s also a lot easier to hire mediocre or bad team members. Your bar should be set high whereveryou are.
Expect the same from your partners or suppliers. If your supplier is competing on cost alone and not capability you’ll eventually fail – period.
4 – Selection Of Work
Don’t just farm out the dull stuff, the maintenance, support, and bug fixing. This is something very few people enjoy taking personal ownership of or pride in. I’ll admit there are exceptions (I love clearing down a massive bug backlog) but most technical people need a balance. All brown-field work wears people down eventually.
5 – Political Structures & Power Dynamics
Career paths and job titles are important. The “senior” in someone’s title may even be seen as acceptance to push others around or exclude team members from important conversations.
Halt “pecking order” problems early.
Be inclusive, publicly encourage collaboration, and transparent communication from senior managers and give direct private feedback when you smell a problem.
6 – Management Style
Some countries and companies have a more top-down formal style than others. It may be unacceptable to “question your superiors” despite the fact that nobody can be right 100% of the time.
Learn about how things run. Who’s respected, who’s feared, who helps things happen and who gets in the way.
Encourage questioning. Explain that everyone is making rapid decisions all the time. If someone doesn’t understand, is worried or unsure about a decision, make it safe to call out, ask or correct. This capability may take months to build but it’s worth the slog.
As a tech lead in one company I worked at I used to run a game called “Captain, you’re wrong”. We made calling out errors fun and engaging rather than difficult and negative.
Recognise that career paths, job titles and management styles differ from country to country.
7 – Respect cultural and language differences
I had mentee that would say “I have a doubt” when they had a question or needed support. That’s quite an interesting translation. “Doubt” in English reflects personal uncertainty. Be supportive, take time to explain things clearly and most of all encourage questions and discussion.
Work ethic may varies from place to place and person to person but sometimes you just don’t see what’s going on.
I had a team member in Hyderabad who consistently outperformed everyone else globally. She was truly amazing at everything but more than that she worked relentlessly.
I’d come into work in the morning at 8 and she’d have been in the office for 4 hours. I’d leave at 6 or 7 in the evening and she’d still be working. The irony was that even when working sensible hours she was still smarter, more productive and delivered higher quality output than a lot of our team. The excess hours weren’t healthy.
Having spotted the excess working I’d check daily around 4/5 pm and if she was still Online I’d call her up and just and encourage her to go home and enjoy her evening. (Her home life was great too so I’m pretty sure she wasn’t avoiding going home).
8 – Spend Time Together
Seek ways to bring your whole team together for a day, a week, a month or even longer. If this really isn’t possible, how can you do the same for individuals and managers instead?
Spending time together helps you understand the working environment, the personal subtleties and nuances and communication styles. After you’ve spent quality time face to face with someone, those offline interactions become much easier to understand.
It works both ways. Spend some time (at least a couple of weeks) in the remote environment yourself. Go see what working life’s like over there. I promise you’ll learn something every day you’re out there.
9 – Re-learn how to communicate
A lot of communication on a co-located team happens by osmosis.
If some of your team are remote they won’t get that benefit. Invest in tools like Slack and Githubthat support asynchronous collaboration but don’t just use them for “work” – dial up the chatter and small talk so that everyone can feel part of a human team.
You might be aware of the ongoing discussions around the #noEstimates movement right now. I have the luxury here of rarely needing to use estimates as commitments to management but I usually (not always) still ask my teams to estimate their tasks.
My consistently positive experiences so far mean I’m unlikely to stop any time soon.
3 weeks ago I joined a new team. I decided I wanted to get back into the commercial side of the business for a while so I’ve joined our Sales Operations team. (Think DevOps but for sales admin, systems, reporting, targeting & metrics).
Fortunately for me the current manager of the team who took the role on a month or so earlier is amazing. She has so much sales domain knowledge, an instinct for what’s going on and deeply understands what’s needed by our customers (the sales teams).
I’d been working with her informally for a while getting her up to speed on agile project management so by the time I joined the team already had a basic whiteboard in place, were having effective daily standups and were tracking tasks.
The big problem with an ops team is balancing strategic and tactical work. Right now the work is all tactical, urgent items come in daily at the cost of important but less urgent work.
We’re also facing capacity issues with the team and much of the work is all flowing to a single domain expert who’s due to go on leave for a few months this Summer – again a common problem in ops teams.
I observed the movement of tasks on the team board for a week to understand how things were running, spot what was flowing well and what was blocked. As I observed I noted challenges being faced and possible improvements to make. By the end of the week I started implementing a series of near-daily changes – My approach was very similar to that taken in “a year of whiteboard evolution“.
Since the start of April we’ve made 17 “tweaks” to the way the team works and have a backlog of nearly 30 more.
Last week we started adding estimates to tasks.
I trained the team on task estimation – it took less than 10 minutes to explain after one of our standups. The technical details on how I teach this are in my post on story points. But there’s more than just the technical aspect. (In fact the technicalities are secondary to be honest)
Here’s the human side of task estimation…
Tasks are estimated in what I describe as “day fragments” – essentially an effort hours equivalent of story points. These are periods of time “small enough to fit in your head”.
The distribution scale for task estimates I recommend is always the same. 0.5, 1, 2, 4, 8, 16, 24 hours. (the last 3 are 1, 2 and 3 days) – It’s rare to see a task with a “24” on it. This offers the same kind of declining precision we see with Fibonacci-based story point estimates.
For the level of accuracy & precision we’re after I recommend spending less than 30 seconds to provide an estimate for any task. (Usually more like 5-10)
If you can’t provide an estimate then you’re missing a task somewhere on understanding what’s needed.
Any task of size 8 or more is probably more than one task.
Simply having an estimate on a task makes it easier to start work on – especially if the estimate is small (this is one of the tactics in the Cracking Big Rocks card deck)
By having an estimate, you have a better idea of when you’ll be done based on other commitments and activities, this means you can manage expectations better.
The estimates don’t need to be accurate but the more often you estimate, the better you get at it.
When a task is “done”, we re-check the estimate but we only change the number if the result is wildly off. E.g. if a 1 day task takes just an hour or vice versa. And we only do this to learn, understand and improve, not to worry or blame.
So why is this worth doing?
Within a day we were already seeing improvements to our flow of work and after a week we had results to show for it.
The majority of tasks fell into the 0.5 or 1 hour buckets – a sign of lots of reactive small items.
Tasks with estimates of 8 hours or more (1 day’s effort) were consistently “stuck”.
We spotted many small tasks jumping the queue ahead of larger more important items despite not being urgent. (Because they were easier to deliver and well-understood)
Vague tasks that had been hanging around for weeks were pulled off of the board and replaced with a series more concrete smaller actions. (I didn’t even have to do any prompting)
Tasks that still couldn’t be estimated spawned 0.5 or 1 hour tasks to figure out what needed to be done.
Large blocked items started moving again.
Team members were more confident in what could be achieved and when.
We can start capacity planning and gathering data for defining service level agreements and planning more strategic work.
I’m not saying you have to estimate tasks but I strongly believe in the benefits they provide internally to a team.
If you’re not doing so already, try a little simple education with your teams and then run an experiment for a while. You can always stop if it’s not working for you.
A quick update – Janne Sinivirta pointed out that “none of the benefits seem to be from estimates, rather about task breakdown and understanding the tasks.”
He’s got a good point. This is a key thing for me about task estimation. It highlights quickly what you do & don’t understand. The value is at least partially in estimating, not estimates. (Much like the act of planning vs following a plan). Although by adding the estimates to tasks on the wall we could quickly see patterns in flow of tasks that were less clear before and act sooner.
As we move from tactical to strategic work I expect we’ll still need those numbers to help inform how much of our time we need to spend on reactive work. (In most teams I’ve worked in it’s historically about 20% but it’s looking like much more than that here so far).
Martin Burns also highlighted that understanding and breaking down tasks is where much of the work lies. The equivalent of that in this team is in recognising what needs investigation and discussion with users and what doesn’t and adding tasks for those items.
This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.
“For a million dollars we’ll make you Agile.
Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.
Here’s some REAL DATA …”
Axis titles shamelessly acquired from a recent company presentation
What you’ve not been told is that those testimonies are statistical outliers!
These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.
The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.
Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.
Let’s replay this with a more realistic conversation…
A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.
“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”
Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.
Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?
Every company, organization and site differs.
The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).
If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.
Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.
In fact chances are there wouldn’t be a competitive software industry.
Or would there?
• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.
• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”
• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.
There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.
There are only “best known practices for your current state, knowledge and context”.
When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?
What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)
You may reach a point where your organizational immune system (politics and process) blocks progress.
Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.
Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!
Back in June 2013 I was asked to facilitate a discussion exploring one of Red Gate’s company values – “No Politics“. This was the second in a series of open sessions that the company had initiated to preserve and highlight what they have valued for many years and to get to the bottom of what these values mean, their relevance and impact on individuals and teams around the business. The expanded wording for our “No Politics” value is:
No gossiping, no intrigue, no pussy-footing around problems and no telling people what you think they want to hear whilst privately disagreeing. We will be transparent in our dealings.
Many of our staff – myself included – were starting to feel that we were no longer being true to this value.
After an hour’s discussion between about 40 of us including concrete examples of where many of us felt we’d seen or been involved in “politics” we established:
Politics are created when “your needs” conflict in some way with “my needs” and where both “you” and “I” fail to openly communicate.
Taking this further – all the examples of politics we’d seen boiled down to a combination of failures in communication of motive and intent and failure to share conflicting needs. Ironically, we’re usually all trying to achieve the same ultimate goal.
Our encouraged altruistic culture tended to exacerbate the situation further and cause us to wade in when we felt a decision had insufficiently involved those impacted – even when the person taking exception felt the decision was right. (You should have seen the angst when a rapid decision was taken “on high” to move to Github for all product development)
Our values and culture have encouraged this “challenge everything” behaviour for years!
Being on the receiving end of a change or decision we don’t fully understand, agree with or have had no involvement in makes us feel bad, we internalize and build that frustration up and start sharing it in passing conversations, at coffee and in corridors – because we’re entitled to share our opinions. But we’re all pretty gentle and fluffy here. We’re a software company, many of us are shy and conflict-averse. This means we share our worries in private and let them radiate out. (This also means any vocal or forceful minority have much stronger voices)
We create the politics ourselves
Since discussing and recognising this fact I started making a concerted effort to tackle issues head-on again and had a deeply humbling moment when a colleague pulled the “grown up” card on me for my own bad behaviour.
It’s amazing how the weight comes off when you realise that everyone is trying to do the right thing within their own context and needs and often have simply not recognised where this butts up against our own. (And that you have failed to empathize with them!) Gently calling out those disconnects and addressing them has defused even some of the thorniest conflicts I’ve faced.
Oddly, I hadn’t recognised a link until a serendipitous moment yesterday but my friend Clarke talked me through some aspects of this same challenge a few years ago. He’s since written up his thoughts in detail here.
If you’re still reading, as some background here’s the wording of the full set of values as included in the “Book of Red Gate” (an earlier 2010 Edition is also available) – we’re reviewing whether these are still the right set and the right words even now but they do capture a lot about working here.
You will be reasonable with us. We will be reasonable with you
We’re all trying to treat each other as we would like to be treated in the same circumstances. Sometimes the circumstances are difficult, but we will all still be reasonable.
Attempt to do the best work of your life
We’d like you to achieve your own greatness and to be all that you can be. We’ll try hard to allow that to happen and we’d like you to try hard too.
Motivation isn’t about carrots and sticks
Constant oversight and the threat of punishment are incompatible with great, fulfilling work. We believe in creating appropriate constraints and then giving people the freedom to excel.
Our best work is done in teams
We work in groups and towards a common goal. The company is more important than the team, and the team is more important than the individual.
Don’t be an asshole
No matter how smart you are, or how good you are at narrowly defined tasks, there is no room for you here if you’re an asshole.
Get the right stuff done
We admire people who get stuff done. While there’s a place for planning, thinking and process it is better to try – and try well – and fail than not to try at all.
Visible mistakes are a sign that we are a healthy organization
What we do is very difficult, the current situation is hard to understand and the future is uncertain. Mistakes are an inevitable consequence of attempting to get the right stuff done. Unless we can make mistakes visible both individually and collectively we will be doomed to mediocrity.
No gossiping, no intrigue, no pussy-footing around problems and no telling people what you think they want to hear whilst privately disagreeing. We will be transparent in our dealings.
Do the right things for our customers
We believe that if we do what is right for our customers then we will thrive.
Profits are only a way of keeping score, not the game itself
Focusing purely on the numbers is a sure way to kill Red Gate’s culture. We believe that if we focus on the game – building awesome products that people want to buy, and then persuading them to buy them – the success will follow.
We will succeed if we build wonderful, useful products
Shipping something amazing is better than creating something average and to budget and on time. We cannot market, sell, manage or account our way to success.
We base our decisions on the available evidence
Not on people’s opinions, the volume of their voices or who they are. When the evidence changes, we are prepared to change our minds. We will thank, and never shoot, the messenger.
We count contribution, not hours
What you achieve is more important than how long it takes.
Back in December last year I started supporting Red Gate’s .NET Developer Tools Division. As of this month, we’ve restructured the company and from next week, the old division will be no more (although the team are still in place in their new home).
When I joined the team things were going OK but they had the potential to be so much more so I paired up with Dom their project manager and we set to work.
The ANTS Performance Profiler 8.0 project was well under way already and the team had a basic Scrum-like process in place (without retrospectives), a simple whiteboard and a wall for sharing the “big picture”.
I spent the first week on the team simply getting to know everyone, how things worked and observing the board, the standups and the team activities.
We learned some time ago here at Red Gate that when you ask a team to talk you through their whiteboard, they tell the story of their overall process and how it works. Our whiteboards capture a huge amount about what we do and how we do it.
I attempted to document and capture at least some key parts of the journey we’ve have over the year in which we released over a dozen large product updates across our whole suite of tools. This post is picture heavy with quite limited narrative but I hope you’ll enjoy the process voyeurism 🙂 If there’s any specifics you have questions about, please ask and I’ll expand.
Next time, I think I’ll get a fixed camera and take daily photos!
The end result? Multiple releases of all 5 of our .NET tools including a startup and quality overhaul for our 2 most popular products, support for a bunch of new database platforms, full VS2013 support (before VS2013 was publicly released), Windows 8 and 8.1 compatibility and a huge boost for the morale of the team. See for yourself if you’re interested!
Of course this is just one aspect of what I’ve been up to. You might notice the time between photos over the summer grew a little. See my last post for more insights into what happens at Red Gate Towers.
I’ve been quiet on here for a few weeks as I’ve been head-down on some pretty major work at Red Gate and publishing what I and the team have been up to on their freshly launched dev.red-gate.com mini-site.
Here’s a roundup of the highlights:
“Slack” – Exploring how we approach “slack time”. Ensuring slack is available to the right people at the right time and trying to keep it guilt-free.
A Manifesto (of sorts) for personal development – what we expect from each other in developing ourselves and our careers. The outcome of 2 months of Genchi Genbutsu (go see at the source) – asking some really direction questions face to face (individually) with every single member of our development teams.
Top Tips for personal development – 12 Tips on personal development from Red Gate’s development team (plus another 12 linked from this one). These are the tips we use as part of our new personal development plans but are equally useful as prompts to simply “get out and do something”.
Skills Maps – An overview of the skills maps we’re developing at Red Gate for our development team roles (it turns out what we’re trying is pretty unique and developed a bit of a buzz.
Fresh off the press yesterday; Organizational Restructuring – An Insider View – Putting Convergence & Divergence into practice. How Red Gate are performing a complete organizational restructuring to their teams without the usual cloak and dagger HR hell.
Finally, Johanna Hunt and I have paired up again on our “Cracking Big Rocks” cards and workshop. After much editing, re-editing and review we published the second edition of the card deck at the end of September and took them out for a first run at Agile Cambridge. The revised deck includes a few new patterns, rewording of many of the old ones, some basic instructions and some lovely artwork on a few of the cards from our good friend Paul Stapleton.
It’s been a month since I last posted about the work I’ve been doing around career development. Things are moving well and trials of the process described in the first 2 posts in this series have been really successful and way more popular than I expected. Everyone I’ve spoken to about it has been really excited and we’re now doing an expanded second round of trials with another 20 staff before adjusting and rolling out as a tool to all our development teams.
This is just a quick post to highlight a few tweaks and important points for anyone wanting to try this themselves…
So far everyone that’s tried it has found it really useful. My 2 favorite quotes so far…
“I never would have thought of some of the areas to action without this process”
“I’m better able to prioritize actions because of the process”
This will almost certainly work best for people with quite a strong sense of self-awareness and self-improvement already (as does any development plan) and remember you can’t forcethis on someone.
There’s bound to be cases where this process doesn’t work but we’ve not found one yet. If you try this yourself, we’d love to hear how it’s worked for you and remember, after trying it out once or twice, it’s worth tailoring to your own needs further.
Clarity – In a change to the original recommendation (working blind), we’ve found it’s more useful to share a clear agenda and state where we are in the process and why at each step so people understand what they’re meant to be thinking about and know what’s left to do.
Skill Levels – In addition to the “out of 10” ratings, we’re going to try developees/managers discussing where they feel they stand in terms of SLII (Situational Leadership) development level (e.g. D1-D4). This requires a bit more thought in understanding the differences but keeps our teams aligned with our broader efforts to use SLII when developing each other. We’ve not tried this bit yet (but will be doing so in the next couple of weeks) so it’ll be an experiment within an experiment – we’ll be seeking feedback and thoughts on how this best works.
Action Grid – Rather than defining all the actions in the action grid up-front; partially filling the set of actions at the beginning and then pulling more in after each step seems to work better for people. It’s important however that developees have filled something in each space to work from toward the end of the session before transferring things across to their plan grid. The idea with pushing for all these actions is to stretch our thinking a bit and gently encourage people out of their normal comfort zone.
Supporting the write-up – It’s still really important that the developee writes this up for themselves but format can be a bit challenging. Whilst we have a couple of people using Mural.ly and one other gave this a shot with excel, we’ve found keeping the visual management aspect afterward is important. Here’s a “blank” PowerPoint presentation with heading placeholders and post-it templates to help people along.
Pitfalls / Caution
Skills Categories – The skills category columns (Job/Role, Soft Skills, Domain/Industry) can be a bit tricky. We’re developing a role-based skills map for each role in development that participants can use as a cue (I’m planning to post more about how this is developing over the next month). Our suggestion here is to select a subset of these skills and traits to talk about in more depth rather than using them all.
Flow – As we’re looking at similar things from multiple angles to find patterns, there’s not always a logical progression through activities. This is deliberate but can sometimes feel a bit “bumpy”.
Time – This takes a lot of time and effort (a minimum of 2 hours depending on how “chatty” the participant is) you could consider breaking it up into 3 sub-meetings:
Skills session (including one small next step)
Actions brainstorm around common themes (using action grid)
(I’d still aim for running one straight-through session first time around as the energy from doing it all in one shot is fantastic)
Managing the session – Seriously avoid time-boxing each step. It’s better to reserve more time and let each part play out naturally.
Energy – This can be quite an exhausting session for both participants and we know one size won’t fit everyone so it’s worth setting expectations that this is hard work. I’d recommend running this when participants both have a lot of energy (e.g. start at ~10AM)
Follow-through – It’s reallyimportant that you follow up within the first 2 weeks to ensure the write-up is done and first actions are planned, (Momentum tails off really fast for development plans) and then remember to follow up regularly – e.g. on a monthly basis after that.
Longer-term – We expect people to want to return to this session in future but not to need to spend quite the same level of effort again unless they’re radically altering their role and direction. At the moment, my thinking is an in-depth refresh after about a year however you may feel like 6 months is more useful.
Inspired by a twitter conversation with Bob Marshall, Marc Johnson and Nicole Rauch.
What really are my needs when I’m looking to hire someone onto my team or organization?
This article is a great start on interviewing and the goals of doing so. (whether or not you agree or disagree with the content)
In particular, understanding :
Can they do the job?
Will they be motivated?
Would they get along with the team?
I have to admit that’s a good summary of my needs – I’d add “Will they fit with the way we do things as a company?” as well.
What about the needs of the person applying?
Well there’s the whole safety, security Maslow’s hierarchy of needs type stuff for starters. There’s also Dan Pink’s work on Drive
“. Mastery, Autonomy, Purpose. Jurgen Appelo is doing some amazing stuff around this at the moment too but…
At the end of the day, this is a 2 way relationship. If neither of us will find our needs fulfilled, it’s just not going to work.
Incidentally we’ve found from talking to all of our teams recently that trust, respect, peer recognition, support and self-fulfillment are pretty key.
Chapter 1 of “Love ‘Em or Lose ‘Em” has some great research on what makes people want to stay in a company that’s worth a read.
Before we even get to this point there’s a bunch of work to do though.
At the moment I see hiring as a funnel type of workflow with iterative filtering:
Perform an initial filter (CV sifting) to develop a shortlist to invest in further
Filter again (Telephone Screen) to get beyond the introduction and get a “feel” for capability, personality and salary/role expectations (both ways)
Filter again (1st interview) to check capability
Filter a final time (2nd interview) to check motivation & team fit (both ways)
Make a decision – offer or reject
Nurture to start date
On-board with team & company
Review progress/probation – is the relationship working out (both ways)
Note, this is just one example – I generally see the hiring process continuing through to being a successful, happy team member with a happy team.
I’m writing this post quite hastily but if we look at that flow, there’s a value stream in terms of effort and cycle time per candidate and also a funnel at which points candidates “drop out”. There’s a lot of effort, a lot of waiting and a lot of waste. I truly think there could be something better but I’ve not tackled the problem yet (and perhaps that’s part of my problem!)
Here’s the first challenge I face…
As a hiring manager, my time is at a premium. I’m usually trying to do at least one other job at the same time as hiring (usually running a project and team) and often working on other “hidden projects” such as improving the way parts of the organization work (including adjusting and learning from feedback on the hiring process itself and the types of candidates we’re getting through).
On top of that, it’s really hard to attract the “right” people – back to skills, motivation, team & company fit.
Our first port of call in most cases is a covering letter and CV. Sometimes we start with an introduction or conversation but eventually we usually go back to a CV.
We’ve hired most of the people we already know are good that want to work here (location and company-wise), that we can honestly afford and are available. (Being based within an hour’s easy commute of London means competition for good people is tough). So most remaining applications come from strangers.
If someone’s a stranger, how are they able to catch our attention (in a positive way) to make it clear to us they’re worth engaging with, spending our limited time getting to know and developing a positive relationship with? Particularly when there may be dozens (or in my last company, hundreds) of others competing for that same attention. This works both ways – how do I get your attention too?
For my current job, I developed an early relationship through reputation first but at the point we decided to formalize things, I was still happy to present my CV. I’m proud of what I’ve achieved and earlier conversations could have missed things that were relevant and valuable. In my case this was particularly true. I worked on CRM and order management systems early in my career and the conversations I’d been having so far weren’t around this area but it turned out this experience was really valuable to them. We wouldn’t have made that connection without my CV.
If someone approached us without a CV as a total stranger we’d have no idea what to expect it’s a gamble as to whether we’re dealing with someone we really want to know or not and realistically the little time I have for hiring isn’t an area I choose to gamble blind. That initial “Yes/Maybe/No” that I can get from reading a CV is a lot quicker that talking to every single person that applies to figure out what they can offer that’s relevant or valuable.
Similarly, job specs are like CVs – would you apply for a job with no spec? How do you know what’s expected of you and whether you’re a good match?
So, my needs – assuming you’re a stranger…
(Without being a stalker) Seek me out, get in touch, say hi, invite me to stuff, find a way to get to know me and start building an interesting professional relationship.
Make it easy for me to get you through that first sift of candidates with useful, relevant stuff.
Make it clear what your motivations and skills are, how you work and what sort of person you are. I don’t hire assholes and I’m pretty wary of “Alphas“.
Link up what’s on your CV to what I’ve said I’m looking for but please do share the other cool stuff you’ve done – you might have useful experience I’ve not even considered.
If you’ve done cool things that are publicly visible and don’t need me to do a mountain of digging, point me at them. If the rest of the CV is interesting, I’ll go and look.
I won’t have time to read your twitter stream, blog, Stack Overflow activity, Github check-ins and Linkedin profile unless I’m already interested in you. (I don’t do Facebook) But if you’re interesting, I assure you I’ll look for you on all of these.
Don’t over-inflate or lie. It might get you through the CV screen but when I find out you can’t back it up later you’ll just piss me off.
Show me real evidence of what you’ve achieved and how. I can’t standall theory and no results. But if you have a love of the theory, show me how you’ve applied it and made a difference by putting it into action!
I’m sure there’s more but this is plenty for now.
What are your needs when you look for a new job and how do I get your attention?
This is a tip that I originally picked up from Liz Keogh in one of her talks on BDD a couple of years ago…
“Can you give me an example of that?”
OK, so it’s not quite BDD but I’m currently working with the team of function heads at my current employer (a team of us leading communities of practice around each function of development) to explore and addressconcerns and issues around career progression for development team roles within our flat organizational structure.
We don’t have “Junior” or “Senior” type job titles so someone who’s great at their job can easily remain with the same job title for many years. But there’s still a desire from individuals to feel their careers are progressing. Rather than conceding to job titles we’re in the process of completing a study by interviewing every member of our development teams and asking a really direct set of questions. (we’ll publish more detail on the questions we’re asking over at dev.red-gate.com.) These were pretty daunting to start with but the candid responses and conversations we’ve been having have been amazing.
As a sneak preview so far, one aspect of our data is showing us that the majority of team members here don’t care about job titles – except in the ability to use them to define a sort of communication contract that allows us to set expectations about the kind of things we’re interested in and expect to be discussing.
As an example, we rely heavily on our User Experience team to do a lot of analysis and design work but this consists of multiple roles or specialized activities; Visual Design, Interaction Design, User Research, Functional Design, Service Design etc.
When talking to a UX person we frame our context in “User Experience” but that might not be precise enough to focus on the right value. Equally, most UX people I’ve worked with have natural specialisms within their field.
We expect all our staff to have some level of interdisciplinary skills – “T-Shaped” people. Some have a desire to become more “A-Shaped” (or even M-Shaped) by developing additional specialisms over time, some want to broaden their interdisciplinary skills whilst some want to extend their current specialism.
This is a really tough problem to solve so we’re looking at various paths around career development using named roles, collections of directionally aligned skills and personal development planning conversations (see my previous two posts).
In exploring our options, we kept coming onto discussions like “what about the person who has no idea what they want to do” and then diving into trying to develop a skills framework, map or tool that would support this problem. In reality this is an edge case and we’re probably trying to solve the whole problem without tackling issues that would work for the majority and then learning from these.
So I borrowed Liz’s BDD trick. We’ve already interviewed and gathered concrete qualitative data from nearly 80 staff but were still talking about cases in the abstract.
“From the data we already have, can you give me a concrete example of someone that has this problem”.
After 3 failed attempts we realized that even in the cases where staff didn’t know what they wanted their next role to be, they still had a desire to progress and some idea of the direction to head. Rather than trying to develop a catch-all framework we realized that what we need to provide is simply an awareness of options and a means of exploration for their given context.
We’re still working on the solution but things we’ve found so far are:
Most people have a desire to feel they’re making progress. They want direction, differentiation, support, safety and opportunity.
Nobody we’ve spoken to yet wants a wholesale reset of their role (as an aside, I did once have a great developer who decided he wanted to be a medical doctor – he succeeded!). So in the examples we have so far, people are either looking to extend their current job into related roles, expand expertise in their current role or move into an adjacent job or role.
This allows us to frame conversations in terms of adjacencies, current job/role, desired job/role, role models, skills and specialisms.
There’s also another critical component to this – what I’ve chosen to call “Fit”. If there’s no space to fill or a chosen path isn’t a good fit for a team or person we need to be having those conversations too.
So my thinking model for this at the moment is to talk about direction in terms of:
Job -> Roles -> Fit -> Skills -> Specialisms
Rather than trying to fix everything at once, our next step is to seek early feedback, inspect and adapt. We’ll be looking for a few people across roles to trial the ideas we’re coming up with and help us identify concrete examples we don’t know about at the moment and work through those.
I’m expecting us to have some concrete results before the end of September but we’ll be putting things into motion in the next week or so.
Following on from part 1 last week where I described the foundation concepts for a lean/agile development plan, here’s the detail…
So far I’ve done this twice with some of my team here and I’m in the process of introducing it across a couple of other teams and managers. As part of writing the details up, I’ve come up with some minor refinements and sequencing options that we didn’t think of at the time and added these in.
Before you start make sure you have a decent space to work in with no distractions and plenty of time. You’ll need about 2 hours but give yourself 2-3 so you have some slack. You don’t have to use it all and it’s surprising how good people feel when they think they’ve recovered some time back.
Grab a room, a pile of stickies and some markers. Did I mention you’ll need to use a lot of space? (We used 3 walls). In the cases I’ve run so far, I didn’t prepare anything in advance but it’s probably best to write up the headings beforehand – don’t show them until the participant is at the stage they’re needed though! (focus on 1 thing at a time – single piece flow!)
Step 0 – What are we trying to achieve?
An important point before we start. Are we working with someone who wants to improve themselves in their current role, address some known (or unknown) issues or who wants some kind of progression – a promotion, a sideways move, expansion of skills, increased responsibility, or something else?
Take 5 minutes to discuss the possible scope and direction of the session. Think about the level of change, disruption and ambition behind the improvement and what is or is not achievable. How long have they been in their current state, what sort or timescales are we looking at for the plan etc.
Step 1 – Looking Forward – “Over the next … … I will”
We’re going to use planning horizons and swim lanes to develop a timeline.
Build a large grid using stickies for each heading with vertical planning horizon columns (I suggest 1, 3, 6, 12 months) and 4 “achievement” (“I Will”) swim lanes; “Done”, “Improved At”, “Tried” and “Learned”.
It should look something like this:
Aim for the grid to have space for roughly 1-3 stickies per horizon/swim lane cell. – We’re using visual management and physical constraints to minimize over-commitment and set WIP limits. I’ll refer to this as the “plan grid” for the remainder of this post as we return to it a few times.
Now spend a few minutes adding stickies to the plan grid for the things you know you’re going to be doing. (don’t worry if there’s not many to start with we’ll be coming back to this later).
Here’s an example recently completed from one of my UX specialists at the start of the process…
This covers the baseline set of directions and commitments before we start adding to it.
If the person you’re working with has a good grasp of upcoming work for themselves, the team and product plans, you might find this fills quite well already. In the case above we’ve spent a lot of time talking about interests and direction in the past. We also have some pretty clear ideas on where we want to go with the product and technology. Visualizing this as a roadmap with a series of planning horizons and the “Do, Improve, Try, Learn” swim lanes for actions gives some initial structured thinking and timing to work from. We’ll circle back to this at the end of the session after exploring other areas of personal development and skills.
In this particular case, you can see we’ve actually filled quite a lot of space already. This doesn’t leave much room for new things unless we over-commit or trade-out other activities and that’s precisely the point – we’ve just baselined our commitment and workload.
Now let’s explore things further. We’ll take multiple approaches to exploring options. Some of these may duplicate information – that’s perfect, it’ll help us spot common threads later.
We’ve developed a grid of over 20 actions with a single placeholder for each action (borrowing a 5S technique from Lean). The set of actions is my chosen selection and works well so far. You may want to add or remove some of these depending on your context but the thinking behind these is to get participants to explore their available options beyond what might naturally come to mind.
Our aim is to place a single post-it/action under each heading. Eventually we’ll have every space completed with something sensible.
We’ve deliberately not looked at any personal skills, strengths, weaknesses or needs yet. This is simply thinking about what types of actions a person could employ to develop themselves.
Sequencing Options: The first couple of times I used this with my team we completed the grid in its entirety at the beginning. In hindsight, I recommend splitting the effort here to partially complete the list of actions at the beginning and then return to it after each of the next steps.
If you’re working with someone who needs more support in developing an understanding of their needs first, you may choose to start this step toward the end of the session after exploring strengths and skills further.
If you choose to use any of this process, please do experiment with the format and post your experiences and improvements here!
When we first used this action grid, we wrote “over the next 12 months I will/would like…” It worked well in our situation but it’s important to emphasize the difference between achievable and aspirational actions, so…
Minor Refinement: Once the grid is completed, run through it together and mark which actions are achievable – “I Will” – and which are aspirational -“I Would Like”. (using red/blue sticky dots or similar).
This encourages you to discuss and think through what will be possible and what may be a stretch (or even unrealistic). When looking at transferring actions to the plan grid, you can decide how much of a stretch you want to make in any given period based on workload and other existing commitments. The “I Would Like” actions may also require some additional support to be achieved.
3 – Self-Reflection – “I’m Happy As I Am With…”
So we’ve got a structure for a plan, we know what commitments already exist and we have a set of potential actions. Let’s take a step back and deliberately reflect on strengths and improvement areas.
As I mentioned in part 1, it’s really important not to go overboard on perceived “weaknesses” so here we break a person’s perception of what they do and how they work into 3 areas:
In order to reduce waste we want to emphasize improving strengths and bringing any gaps to a necessary minimum level only. At this point we focus mostly on the person side of things. How do they work and what do they do? (Not“what does their current or desired role need?” )
As a person or individual, what’s their self-perception around their day to day actions, activities and behaviors. Ask them to think about and describe what areas they see as real strengths – what’s their specialism or superpower if any, what do they really enjoy (and how competent are they at it?), what things do they feel they suck at (and is that a problem or not?). What are the remaining things that they just get on and do? How well do they do those?
Here’s an example of the sort of things we’re after…
Note how this is general activities that tie-back to what a person is doing on a day to day basis in their current context, not just the usual skill inventory type list. It’s about the things we perceive – what we do and how we do it. (we’ll look at the skills next)
If you decided to develop the action grid from step 2 in small steps, now’s the time to re-check to see if there’s some actions that could be added as a result of the strengths or improvement needs here.
Allow enough time for the participant to run out of things to add – don’t be afraid of a bit of silence or thinking time – just sit back and let them run until the ideas dry up.
4 – Skills Investigation
We’ve explored self-perception and started rolling on possible actions. Now we’re going to look more at role-based skills.
Depending on the scope and direction agreed in step 0, this may be covering either a current or desired role.
Have the developee list out what they think the skills they have/need for that role are, what additional industry or domain-related skills they have/need and what additional soft skills they have/need.
We want to steer participants into thinking of these skills themselves so if you think they’re missing anything, try to use coaching questions rather than direct addition of examples. Encourage thinking about their gaps or using examples. (E.g. “Assuming you’re about to kick off a new feature, what types of activities do you need to undertake? What skills do you need to engage the team?)
Once again, give this enough time to play out to a natural end.
Once you’ve got 3 lists of skills, have the participant rate themselves out of 10 at how good they think they are at each one of these skills. Get them to mark this consistently in one corner of each sticky. (They might guess what’s coming next but let this bit finish first).
Talk through what makes them say they’re at that level. Now get them to think about what their desired level for that skill would be – make sure they understand that “getting to 10” may not always be needed or even beneficial (remember their strengths and weaknesses). What would be right for them. Mark that in the opposite corner.
Now get them to mark the top 3 areas that they would particularly like to focus on.
For each of these focus skills, talk through what actions or activities they would need to do to get from their current state to move one point forward. E.g. If someone’s at a “4” today and eventually wants to get to a “7”, what would it take to get to “5”. Ask them to visualize what that result might look like and describe it to you.
Again if you’re partially completing the action grid as you go. Now’s the time to see if there’s some more actions to add or any existing ones that could be switched out or replaced.
6 – Common Threads & Themes
We’ve now tackled skills, behaviors and improvement ideas from multiple directions and explored (hopefully) some areas in quite a bit of depth. Looking across all the details on the walls, are there any patterns, common threads or themes?
What do these highlight?
Name these, write them out and put them next to the plan grid from step 1
This comes back to my love of patterns and naming. By giving something a name and focus you can assemble more of a mental model around what that thing is. This makes it easier to understand what is or isn’t in scope for a theme.
As with the skills, I recommend limiting the number of threads / areas of focus to 3 or less.
When I’m trying to get stuff done I have a small mental buffer and 3 is about my upper limit (2 works better). Any more than that and my brain starts thrashing. The same works here – trying to fit too much in your head will make things harder later.
7 – Actions – Pulling It All Together
Now let’s get back to the action and plan grids.
First of all, make sure we’ve got a single item in every space on the action grid. You might need to get some creative thinking in to fill them all but it’s worth the effort. When that grid is filled it gives us an unsorted long-term backlog of ideas for our developee. When someone completes a particular action type you can decide whether to add a replacement or to continue clearing down the grid before adding anything new.
Don’t forget to mark which are directly achievable – “I Will” – and which are aspirational – “I Would Like”.
For the aspirational items, take some time to discuss and understand what support or commitment will be needed to make them achievable.
Now have the participant copy a small number of the actions from the action grid and decide where to place them in to the 1/3/6/12 month plan in the plan grid. (don’t move the originals – you’ll need them)
Next, have them look at those top areas identified for improvement (from the Self-Reflection and Skills Investigation activities) and identify any further specific actions for each (or a subset if there’s too many)
For each selected action, they need to decide when they intend to undertake it and place it in the corresponding location on the plan.
If there’s not enough space on the plan grid, remember that physical space constraint gives us a WIP limit! What do they need to trade out to stop themselves over-committing?
Here’s an updated example from step 1. Note we didn’t add much beyond the first 1-3 months this time around as we expect to come back to this again when that planning horizon has cleared. We also had some really powerful conversations around their overall development and direction.
Don’t underestimate the value of the conversations themselves, not just the artifacts! For the participant in particular, those conversations may have crystallized a whole bunch of questions about their personal direction and goals for the future.
8 – Review – Is It Achievable?
Talk through the final plan grid, discuss timings and workload. Does the participant feel that the plan is achievable? Is there anything they might change? Are there any areas of risk or concern?
Take some time to talk through the actions grid (now a backlog). Are there any things there that might be time-sensitive or wholly unachievable or mis-aligned that they want to swap out?
9 – Ownership – Whose Plan Is It?
Here’s where many development plans fall down.
Chances are you can’t leave all that stuff on the walls so capture all the content on decent (readable) photos and then harvest the stickies in their respective groups.
Ensure the participant gets both the original stickies and a copy of the photos. Ask the participant to type up the results of the session and to share back – agree when they’ll have this completed – ideally within the next 24 hours. (It’s amazing how much you learn from typing up post-it notes after any session!)
Ensure their actions grid is converted to a backlog and the plan grid is written up as a plan that can both be updated and modified easily. (one of my UX team wrote theirs up using Mural.ly – this is particularly neat as they were able to mimic the format we used in the room very closely)
In discussing ownership of development plans we’ve identified that simply handing over ownership is not enough. The developee will still need support, coaching and mentoring to progress successfully. Don’t let them fail alone.
10 – Follow-Through
Once the write-up is complete (depending on the participant you may need to chase them to ensure this happens). Follow up quite frequently to start with. I recommend at least once or twice in the first 2 weeks, and then again at the end of the first month planning horizon.
Minor refinement: It may also be useful to extend the planning horizon backwards by a month or more during your review cycle. You can encourage the developee to add other things they’ve achieved and “bank” these.
We know that people naturally do things that aren’t strictly on a plan. Make a point of marking those achievements. This lets us review what we’ve achieved on a rolling basis and gives us a trailing indicator of progress and capacity.
Depending on how things are progressing and the level of interaction or support needed, agree on a follow-up cycle and set dates for a regular one on one catch-up session to talk through progress, changes, adjustments or resets. At the 3 or 6 month point, schedule a more detailed review and repeat session.
That’s it! (so far).
Edit: We’ve been so successful in our initial trial with a few staff in my division that we’re expanding the trial across the company. We’ve also learned a few important tweaks and traps along the way. See where we are now in part 3.