I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.
Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.
People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.
People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.
Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.
I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.
But this is just for managers right?
Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.
So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!
I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.
Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.
In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).
The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.
However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.
Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.
What do you think? Have you read Waltzing with Bears? Post your comments below!
I’ve had this book for a while and it finally reached the top of my Audible list. Measure What Matters has intrigued me for a while, especially as I am focusing on setting and meeting goals at the moment.
I have to confess to being a little disappointed. At it’s core the book discusses OKRs, a kind of public goal which does a very nice job of splitting out the goal and the actionable tasks required to complete it. Visibility creates transparency to make sure no teams are duplicating effort or conflicting priorities, they also allow people to assist each other in meeting their goals.
So far so good, I didn’t have a problem with any of that.
However, the majority of the book was a list of testamonials from the author’s long list of supporters. It was genuinely interesting to see how the technique has been applied to everything from IBM to U2. But I’m really not sure wheeling out the famous and successful was really needed (in the audiobook many of them actually contributed their parts). It felt more like a sales pitch of OKRs rather than a practical guide of implementing them.
I kept finding myself expecting the next chapter to be a “How to get started with OKRs in your business.” but alas, it never came.
Enlightening by adding a new way to think about goals, however disappointing because although I’m intrigued I feel far from equipped to take advantage of the concept.
Do you agree? Have you read Measure What Matters? What did you think?
Performance Management are two words which have the power to strike dread into the hearts of developers and managers alike. For engineers it conjures images of being fired, for managers it’s the sinking feeling that you’re going to have difficult talks with people with people about the quality of their work.
But that isn’t what performance management is about. At least it shouldn’t be!
Performance Management should always be about you working with your boss and mentors to continue to improve your performance. It should involve feedback, praise, and coaching. It should be something junior engineers embrace because it helps them progress their career and develop their skills. However, giving feedback is very difficult and unfortunately finding a boss who will give you honest, valuable feedback is rare.
I could write pages about Performance Management but this post is intended as part of my Junior Developer series so instead I’m going to focus on the most common mechanisms companies use and what you should expect when you join.
Probation periods are very common across the software industry (and elsewhere). In effect they’re a trial period for both you and your employer. They’re an opportunity for you to ensure you’re really happy with the company you’re working with but also for your boss to ensure you can do the job (or at least that you have the potential to do the job).
Typically probation periods last three or six months and during that time your notice period (the amount of notice the company has to give you and the notice you give the company if either wishes to end your employment contract) is significantly shorter. A month’s notice period is fairly typical for developers in the UK (or longer if it’s a more senior role), however during your probation this may be a week, or non existent. This is intended to support both sides. Personally I have never failed a probation, but I have left a company during my probation and being able to make that clean break was much simpler than having to wait an additional three months.
Every employer should set very clear objectives or what they expect you to achieve during this probation period. They should never simply book a meeting at the end of the three months to tell you if you passed or failed. The golden rule of good management is to never surprise your employer. A good manager will work with you during your probation and, if you’ve got some areas that you’re struggling make you aware of them so you’ve got plenty of time. You should never be unclear whether you’re on track to pass or fail a probation period.
1 to 1s
One of the most effective ways to support and coach your team is for managers to book in 1:1 sessions. Typically these are every couple of weeks but it varies with the individual and the circumstances. I have senior engineers who only watch to check in once a month and team leads I meet with weekly (or more often if they need it). I always hold more frequent 1:1s with people during their probation to make sure they’ve got the support they need.
Your 1:1 is your managers opportunity to coach and your chance to ask questions. It’s also your opportunity to talk about goals and career goals. There are countless excellent articles out there about 1:1s so I’ll leave it there and say that you should expect them and that they’re nothing to worry about.
End of Year Reviews
Most companies operate an end of year review cycle. These vary from company to company but they often involve talking about the positives and negatives of the year with your managers, some kind of goal setting exercise for the upcoming year, and often a discussion around pay and/or bonus. Often these are split into various conversations which may take place over a few weeks or even months.
The key is to understand what each session is for and what topics are likely to be discussed. This will help you think of examples where you’ve done especially well and give you a chance to think or a few areas where, with hindsight you may have done things a little differently.
It’s also helpful to understand what form of conversations the ones around pay and bonuses are likely to take. What’s normal for your company? Many television shows give the impression that you can march into your boss’s office and make a pitch for a higher salary. In reality (at least in the uk that’s rarely how it works). Often managers are given a pot of money to work with, once a year, and will have to make the fairest choices they can. However your manger be able to advice you on what happens at your company and what the financial review process will look like. Don’t be surprised if you’re not included in this process if you’ve been with the company for less than a year, it’s not uncommon for people who have recently joined to have to wait to be part of the uplift process.
When talking about goals for the following year try and be open and honest about what you would like to achieve. Ask your manager to support you and whether you think your ambitions are realistic. You can achieve a lot more if your manager is also looking for opportunities to stretch you than if you have to go hunting for them yourself.
Hopefully I’ve convinced you that normal Performance Management is nothing to be worried about. Sure, there are cases need to be coached through areas of under performance but the vast majority of what I’ve talked about in this post is the positive side of how to work with you manager to avoid needing and performance improvement plans.
What are your experiences of performance management? Are your experiences similar to mine?
When I saw a copy of The Advantage on the shelf at the airport I picked it up straight away. I read Five Dysfunctions of a Team a few years ago and considered it leadership gold. Learning about organisational health from the same author, sign me up!
I’m disappointed to say that for me, The Advantage just didn’t hit the same high notes. Despite only being 216 pages the book took me around eighteen months to complete and that’s simply because I wasn’t engaged and I felt I had to force myself through the final few sections.
The early part of the book recovers a lot of the same ground as Dysfunctions, I have no problem with that. Creating a leadership team who feel safe and can operate together as a team is no doubt a key part. Then we moved onto organisational values, both desired and acididental. I found that part quite interesting but when we moved onto creating and reinforcing clarity I drifted and drifted.
It’s quite possible I missed the point, the book is highly rated on Goodreads so many people have clearly got a lot from it. Unfortunately, this won’t be one I pick up and re-read again in a hurry. I will however go away and try to define my teams’ values – I grant, that’s a very valuable exercise!
Have you read The Advantage? Do you disagree with me? Let me know either on Twitter or in the comments, I’m always happy for someone to point out something I’ve missed!
I recently did a talk at DDD2020 on People Skills and one of the questions I recieved afterwards intrigued me enough to want do write about it.
How relevant do you feel non verbal communication is while we’re all work remotely?
At a very simple explanation high level I’d say absolutely essential because of the increased reliance on Email and IMs during the Covid-19 pandemic. The fact that this question was asked over Teams really hammered that point home.
But what I thought made this question especially interesting was when I started thinking about the most effective communication mechanisms when working remotely. Doist have written some brilliant blog posts on working remotely and async communication which I highly recommend you read. This means our non-verbal skills have to be absolutely on point. Doist recommend overcommunicating, making timesales clear, and really thinking about your mechanism for communicating (as well as many many other great tips). You can’t just fire off a skype message when your colleague is on the other side of the world, at least not if you expect a response any time soon. Proper thought out communication and strategies for sharing and storing information and making decisions is key.
There’s also a lot to be considered in the non-verbal of verbal communication methods. It’s much easier to get distracted during a phone call when you’re sat at your computer with your email and web browser open. I mentioned in my talk how people pick up on signs of a higher cognative load, how many times have you been speaking with someone and you’re aware they’re tapping away on their keyboard. While we may see it as efficient multitasking I can assure you the person you’re speaking with considers you rude and distracted.
Where and how we use the camera is also a key factor. I use a built in webcam and a secondary monitor. This means that if I want to see what someone is sharing I drag them over to the larger monitor and read it there. This, means that even though I’m paying complete attention to what the person is telling me I have a distracted, uninterested look to them. It’s often worth ensuring that you’re looking at the camera, rather than the image when you’re speaking with someone. At the very least make sure you’re looking vaguely at them and not off into the distance somewhere. A piece of advice I was given recently was to think of a video call like an interview for the BBC. Consider what you’re wearing, consider your background, and look into the camera – not at the interviewer. It’s extreme, but it is all true!
Without non-verbal communication our remote work would be much much harder, we’d be forced to sit on phone calls all day and we’d have no flexibility in our calendars to do the important stuff like, you know, work. Unless our written communication is organised and clear we stand no chance in cutting down the number of meetings we’re in. However, we have to be extremely important when we are having verbal communications, webcams – although an amazing technology can help us send the wrong message. Consider how you’re being perceived by the other person, being visible isn’t enough. And remember, those 1:1s are just as important whether you’re on the phone or sat around a table, resist the tempation to check your email at the same time!
It’s getting towards that time of year again, where have conversations with our managers about what they expect us to achieve over the upcoming year and we throw in a few “personal development goals” which won’t really matter when we’ve forgotten about them in twelve month’s time.
Somewhere personal development and annual performance have got mixed up somewhere here. Most companies base some element of their employees’ performance on how well they’ve met their goal. Personally I disagree with this. I believe there are three types of goals.
Goals which you need to meet to successfully perform in your role
Goals which form part of the team’s improvement plan
Goals which are designed to help you meet your long term career aspersions.
Ideally a goal should fit in to two or even three of these. However it’s the third option, goals for personal development I want to discuss in more detail.
My grandad was a train driver, he drove everything from The Flying Scotsman to the first diesel Deltics. When he joined the railways he was given a number, everyone who subsequently joined would get a higher number. As the years went by and he progressed in his career The drivers with the lower numbers, who joined before him retired and he became the senior driver on the east coast mainline because he had the lowest number.
In today’s organisations we can’t sit and wait for the people ahead of us to retire for us to gain our promotions. I’m not suggesting that there wasn’t a lot of study involved to progress on the railway, however there was a lot more structure. If we want to progress in our careers we need to identify not only the gaps, but our long term objectives.
List a few of the people you believe are very successful. I admire Barak Obama, Dwayne Johnson, Bill Gates, and several others. None of these people became successful by chance. They envisaged their careers, their successes, and they made them happen.
Ok, enough motivational writing and comparing ourselves to famous millionaires. In his book Seven Habits of Highly Effective People, Stephen Covey advised his readers to Start With The End In Mind. In order to get a big picture view of your goals in life he suggests you write your own eulogy, or perhaps less morbidly, your retirement speech. What do you want people to say about you? What accomplishments would they list? If you find this too difficult visualise where you want to be in five years. What role do you want? What skills do you want to have?
The next step is to break down those ambitious goals into smaller steps. For example if you want to start your own business but don’t have any knowledge of sales then you may set yourself a goal to complete a sales training course. If you want to be working as an iOS developer then perhaps you have to release your own personal app to the app store?
Lets stop assuming that major change in our lives and our careers will suddenly happen. Successes like Microsoft, the presidency, and film careers don’t happen by accident. They happen because those people took small, measured steps, and smaller goals which we set ourselves and complete on a daily basis.
This is why your annual goals are so important. They’re your commitment to your personal progression and an opportunity to seek support from your manager and organisation.
Our annual goals should reflect where we want to be in 12 month’s time, a step on the ladder of where we want to be in our grand vision. If we want to deliver on them we need to manage them, quarter by quarter, and even day by day.
This is why personally I don’t believe our personal development goals should factor into our annual performance reviews. However, as managers we want to coach people on their careers (not to mention meeting department goals). These are people’s personal and private goals and I don’t think any bonus or annual performance should be tied to those. But we work within the systems we’ve got!
So what should you do now?
Create a vision of what world domination looks like – what’s your super goal which you want to achieve over the course of your career (this can evolve as you go, today it just acts as a lighthouse of where to aim for).
Understand WHY you want to achieve that.
If that’s the end goal what significant steps could you make towards that vision in the next 12 months?
Discuss (if you wish) these 12 month goals with your manager.
Create an annual schedule, what will those 12 month goals look like as you move through the year? How will you know if you’re on track? Schedule these times in so you don’t forget
Reserve a little time each and every day to move one of those goals forward.
Don’t wait for that big ambitious career goal to mysteriously drop out of the sky. Make it happen, a little each day until you’re there.
Many larger companies are following the lead of companies like Spotify’s to create engineer led communities, sometimes called Guilds. The concept is simple, and very good. Creating a cross team culture of engineering excellence to drive best practice forward among employees sounds like a brilliant idea. In this post I’m going to discuss my experience of working with Communities of Practice and my thoughts on their true value.
Companies usually start a CoP initiative when they want to engineers to take ownership of:
Defining Standards and Best Practice
Training and developing it’s members
Breaking down Silos around teams
Hiring and building a better team
It sounds great right?
As with most things the reaslity isn’t quite as straightforward as that.
As anyone who reads my blog may pick up I enjoy a little amateur psychology, I believe it helps me in my role as a team manager. One of the things I’m acutely aware is the tribe mentality of scrum teams, when people get so focused behind their products they often find it difficult to see other teams as allies – too often they’re seen as impediments to deliveries or competing products. Forming a Community of Practice asks people to shift their focus and split it away from their scrum teams to think as a wider team. It can be hard to sit with two hats on!
So, how do you get started?
There’s a very good book by Emily Webber called Building Successful Communities of Practice which outlines a very good approach. She talks about a Community Maturity Model which outlines various objectives the forming community should aim to hit as they grow. By splitting out into distinct Potential, Forming, Maturing, and Self Sustaining phases. It’s important to realise that giving someone a goal and letting them go is not enough to build a Community of Practice.
With CoPs I’ve helped develop it’s crucial to start with a small group of engaged people who set goals and achieve them. Using these successes and achievements as an example to recruit more members and take on more ambitious goals. You can force dozens of people to join a meeting but you won’t get engagement, you want to be able to hold up what the community has achieved, show it off, advertise it, and ask other people if they would help deliver the next goal.
Communities should set their own goals. They need the ability to ask their members what work is needed and the autonomy to be able to go and make it happen. Otherwise they’re simply a vehicle for management to share project work between teams.
Finally, these formative and fragile communities need real organisational support. They need people to have goals set around forming the community, these people need time (I recommend setting the expectation of a day a week out of regular team duties), they also need a discretionary budget. Breakfast, coffee, prizes, and events go a long way to getting people in the door to hear what you want to achieve and once you’ve got them a social budget is a great way to help those cross team relationships form!
If you’ve been involved in Community of Practices or “Guilds” as they’re sometimes known let me know. What advice would you give to someone who wants to form them in their organisation?
I recently listened to the audiobook version of Matt Skelton and Manuel Pais’ book Team Topologies. It was so good I bought the kindle version while I was still halfway so I could make notes and highlight the good bits (most of the book it turns out).
The book takes several principals such as Conway’s Law and really applies them to business teams. This is something I’ve seen first hand. When several teams work on one large product the codebase becomes decoupled if the teams are given ownership of particular components. However, if teams are expected to work across the codebase the solution becomes monolith and the teams become a super squad.
In the book the authors argue that there are actually a very limited number of team types in a modern organisation. I don’t want to list them because I’d strongly recommend you to buy the book and read the descriptions for yourself. However, if the various types it was the concept of platform team which intrigued me the most.
I actually think Matt and Manuel underplay the huge value of a platform team. They discuss brilliant ideas about consumable APIs and documentation for product teams which consume them. However, a data driven business like mine I believe we should run far more platform teams and far fewer product teams. If we want our Product Owners to be able to innovate and prove the value of ideas quickly we need our data sources and components to be as plug and play as possible. This allows any product or concept to be built and tested very quickly. If all these services were owned and managed by platform teams, instead of falling down the gaps between product teams the solutions would be more robust and the lead times far lower.
If you’ve never given any thought to how teams are created and assigned areas of ownership then this is a brilliant book to read. If you’re not sure how your teams communicate and share information then this book is essential.
A few weeks ago I went to a talk at Agile Yorkshire by Tom Hoyland where he discussed the how he formed an agile team. In it he claimed that Velocity is a Vanity Metric.
If you haven’t read it then I highly recommend you pick up a copy of The Lean Startup by Eric Ries, this was my main introduction to the term. In the book Eric talks about how a Vanity Metric is any figure which is skewed to inflate the success of a product. One of the example he gives is Number of Registered Users, a figure which will clearly go up and up over time. A better metric, Ries argues, would be Number of Active Users. Obviously if you’re looking for a successful product you’re more interested in how many users are currently using it than how many people completed the signup process.
He claims that by basing metrics and KPIs on these Vanity Metrics is akin to giving yourself a pat on the back for building a successful product while sticking your head in the sand about why your business was losing money (or the startup running out of runway as he describes it in his book).
So, to return to Tom’s question – is Velocity a vanity metric?
Most Scrum Masters calculate a teams’ velocity by taking an average over the previous sprints. The number of sprints varies but six (around 12 weeks of work) is the norm. Using this figure the the team can then calculate how far a particular story is away from delivery or epic from completion.
There’s no doubt that Velocity is a useful forecasting tool (although, as one of my colleagues pointed out recently that if you plan a sprint on your average velocity then you will, by definition, fail 50% of the time). However, is it deluding us into thinking we’re a successful team and detracting us from more accurate measurement?
I think this comes down to how you measure success. Most people would agree that judging a development team on how many features they can deliver is fairly narrow minded. A development team includes a Product Owner, their remit should be to develop a product not to simply crunch features. If that was their goal then they could simply create huge numbers of easy, yet useless features just to score points.
In this new age of DevOps a Development Team should use their PO’s expertise and take ownership of the success of their product. For them to be judged on how much work they produce, rather than how much success they’ve had is a limited measure. It reminds me of the from the book The Goal where they measured and optimised the workstations rather than asking whether the system was effective.
Therefore, although shocked when I heard it I agree with Tom. Velocity is a useful tool for the team to forecast. But if it’s chased as a KPI or used to measure the team then it is indeed a vanity metric and will distract the team from trying to improve their product. If we want to measure our teams’ success then we should look at the metrics of our products, not try to calculate some kind of Hours to Story Point ratio or chase an ever increasing Velocity. We should focus on Number of Active Users or Number of Requests via the API, this will measure the teams’ success, rather than it’s productivity. As a friend of mine is fond of saying, effective rather than efficient.