Sometimes the greatest challenge of leadership is making your boss understand what you do all day

Everyone loves a maverick. The one who bends the rules, who gets the job done. Who leaves fireworks in his wake (it’s always a man) and doesn’t mind breaking a few chickens to make an omelette. The people who rescue the projects in a tailspin, who shout loud and carry a big stick.

What happens to the projects without fireworks? The sysadmins that don’t have to explain why they got breached? The project managers who don’t have to explain why they went over budget? The developers who aren’t in the office past midnight fixing bugs? The people who aren’t visible because they fix the problems before they become visible?

I grew up watching Formula 1 with my dad, in the era of Senna and Mansell. Senna was fiery, pushed the car to the limits, exciting to watch. Mansell was controlled, steady, hitting the right line, and easing the car in as if it was on rails. Senna looked like the hardest worker, but Mansell broke his run of world championships.

If you’re competent, if you get the job done, then people believe that your job must be easy. It’s not easy to beat a triple world champion. Sometimes you need to anchor your achievements in advance, so people understand the challenge in hindsight, especially if you are marginalized in the workforce such that your achievements are minimised.

The Difficulty Anchor

Hey underrepresented folks in technical roles! Performance review season is upon us. I want to take a few moments to remind you about some practical tips that can help you be evaluated more fairly in this and future seasons.

— Mekka *My Mask Protects You* Okereke (@mekkaokereke) August 9, 2018

It’s even harder once you move into any management role, success is due to your team (and be damn proud of that success), but failure falls squarely on your shoulders. If you don’t have a strong sense of your own self worth, it can hollow you out, and leave you with nothing but a thick skin.

Take on extra responsibilities, be the consistency for the team when the powers above you are a maelstrom of confusion and musical chairs. And nothing happens.

Remove obstacles and no-one sees them.

Anchor your team’s success. Quiet, dependable successes make everyone on the team happy : no drama, no overtime. But it can be hard to show the work behind the scenes that makes it look so smooth.

It’s not just a dev problem, a good sys admin is invisible, designers struggle to prove their worth (How to Prove Your Design’s Value – Hack Design
https://hackdesign.org/lessons/57-how-to-prove-your-design-s-value?utm_source=newsletter&utm_medium=email&utm_campaign=howtoproveyourdesignsvalue ).

Market yourself. I know you hate sales and marketing, you’re happy to leave it to others, but you need to give yourself the confidence to be proud of your achievements and make sure people understand what you did. Share it with your boss and your peers (you’ll need some recognition when it comes to your appraisal). Promoting yourself is not someone else’s job. Practice it. Embrace it. Be proud.

Advertisement

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

The importance of language: acknowledgements

There’s a few little things that sneak in to conversations and emails that you probably don’t realise you’re doing, until someone points them out to you.

No problem VS You’re welcome

Darlene Price has a great list of phrases you should never say at work. One that really stuck with me was replying to “thanks”, with “no problem”. It was something I did reflexively, either because I thought I was Australian, or because I wanted to minimise the work I’d done. As the article above explains however, it also implies that it would be a problem in other circumstances. Whilst that may be true, there’s an implicit “it’s OK, this time” vibe that, once I spotted it, started to come across to me like a passive aggressive threat. I don’t think that’s how it was perceived, but once I saw that, I couldn’t unsee it, so stopped using “no problem” almost immediately after reading that article.

You’re smart VS You worked hard

This is a parenting basic tip, but it’s a useful thought in general. If you’re smart, then you’re #1, so why try harder. If you worked hard, then you can see the effoer for your reward, and hard work is not a barrier to future success. If you’re smart and you fail, then you’re just not smart enough. If you worked hard and fail, then you either keep working, or seek help. It’s OK to ask for help if you’ve put effort in and need support. It’s not OK if you’re not smart enough, your ego will get in the way.

Bad change : re-opened tickets and the neverending change

It goes on and on and on

One reason I don’t trust change is when that change has no defined end goal. When a change is requested, and the ticket completed, but it then enters a cycle of scope-creep that means the ticket can never be closed.

They often start with something simple e.g. “can you improve the performance of this search”, with a simple tweak – add a JOIN clause to avoid SELECT 1+n queries. In some cases the user acknowledges the improvement, but some users will start pushing new features against the request “because it’s in the same area”. After all, changing the colour of the links on the search page is still part of the same use case, right? And the fact the search is still slow when I use this rare combination of fields means the original ticket wasn’t fixed.

Close it and move on

In some scenarios, it’s easy to be brutal. These are time-bounded sprints, so anything raised must be factored in. This works where features and bugs are interchangeable and represent simply “work to be done”, however they are charged, and let the retrospectives and other analysis worry about whether any particular piece of work is a bug or a feature, so that the team can ensure it’s delivering the best business value.

The definition of done needs to be clear from the ticket (although maybe not to the detail of a SMART objective, it’s worth thinking about that framework). If the provided steps no longer produce an incorrect result, or a speed improvement is recorded, or some other pre-defined success criteria is met, then the ticket is done. Any further discussion is a new ticket. If the objectives aren’t met, it should not be marked as done and the developer should continue work on it.

It’s under warranty

Many software products and projects have a grace period of warranty, where bugs are fixed for free. This is typically useful to resolve conflicts in untested combinations, or volumes, but it can also be used as a stick if the developers aren’t careful. Provided the warranty period is reasonable for the size, complexity and support arrangements within the project, bugs should be fixed to ensure the original scope is delivered. Some customers will however try to extend scope by issuing bug amendments to change scope, under the guise that the bug was raised during the warranty period is therefore should be resolved. After all, bugs should be fixed, but features must be paid for.

Make sure you have a good rapport with your client, and make sure the terms are clear.

Decide now what done means, and how to manage tickets

The last thing you need is to decide this when the tickets that’s blocking the release gets re-opened for the 100th time because the CSS is broken in IE6.

What does it mean to be done?

What constitutes a failure?

Can the software be released as it is?

Bootstrapping new developers

Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?

The tech diversity blind spot

 

Technology makes the world better. It promises to make our lives better. It will free us from work.

Except “The best minds of my generation are thinking about how to make people click ads”. And tech lives in social bubbles as well as financial ones. Apps designed for silicon Valley don’t always travel to the rest of the USA, apps for Western countries don’t always apply in the East, Facebook and Google aren’t always trusted, VR headsets that don’t work if you wear make up, facial recognition fails if you don’t have the same skin as the webcam software developer, or the photo auto-categorising application developers.

Sometimes the solution is to write technology in another bubble. Brazil, India, China, and many other places have strong home grown technology far more popular than the “global” leaders. Sometimes you expand your bubble, diversified teams, balanced teams, who are smarter than homogeneous teams anyway.

Sometimes you look outside your bubble. I get paid to write software that I will likely never use. Line of business applications, including public interfaces, for government clients. I don’t know what their business is until I ask. I don’t know how they work, or what is important to them. And sometimes I have to ask several times, and sometimes people can never understand or articulate what they do, let alone what they want, even after asking them in several ways. So what makes you uniquely qualified to understand what you do, or what problems you have, or whether those problems are universal?

If you want to know if your intuition applies to the population as a whole, make sure your stakeholders reflect that population, or accept that you are deliberately limiting your audience, because that’s what makes sense to you.

Agile : The importance of heartbeat

Scrum is built on the weekly/bi-weekly cycle. It provides a structure, a routine. It minimises surprises. You know that the planning session is on a Friday, for the work that starts on Monday, so you can get things on order on Wednesday.

It lets you see what’s coming.

It’s not about process, it’s about expectation. The more you can plan, the less you have to think about. You know when it’s coming and you can line things up in advance.

Have a heartbeat. Know what happens on a Monday, even if you don’t know yet what you’ll achieve.

The Constant Gardener : Knowing your team

One of the most interesting challenges in becoming a lead is understanding your team, and balancing project tasks between them. Whilst experience, both technical and domain, is a valuable indicator of how to assign tasks, there’s a few other things to take into account.

Having worked with a few people over the years, I can see 2 main types of developers. Managers may be asking which of the 16 Myers-Briggs personality types these represent, but I’m trying to give a persona sketch rather than a detailed breakdown.

Innovators are the ones I see most often – developers who want to work on the hot new thing, keep seeking out new ideas, and often like to throw things out and start again. They can pick up new projects quickly, by focussing on certain areas but are likely to get bored if they stay on one project for too long and may sometimes miss the bigger picture. That’s great for learning, and pushing forward the boundaries, but may not provide the stability that some projects need, and may need closer code reviews to ensure they maintain the house style for the project. If you’ve ever needed a white knight on your project, they’ll probably be an innovator.

Gardeners will take longer to get up to speed with a new project, because they prefer to dig in and find out how everything works, and build a detailed knowledge of the system before making changes. They will tend to evolve systems over extended periods. If you get someone like that on your project, you’ll want to keep them for several months, as their value to the project increases over time. Long lived projects with several maintenance releases benefit most from this type of individual. You may well find that they know the business domain better than the customer.

I think everyone I have worked with has qualities of both, but there are individuals who are clearly more innovators, and others that are clearly more gardeners. A good project should have both, with innovators pushing ideas and bringing new technologies to the tables, and the gardeners bringing the domain knowledge to make sure the right changes are made for the long-term health of the project. As a lead, your job should be to understand the way your team things, so that you can take the right ideas on board at the right time, and bring your team along with you. And, most importantly, know yourself. The most important thing the others on the team bring is knowledge of things you don’t know, or at least questions that force you to think about them. Embrace it. Inspire your innovators and nurture your gardeners.

Keep it Simple, John Sonmez

I’m trying to build a better blogging habit, after following John Sonmez’s blogging email course. I started following him, and his Simple Programmer blog, after I saw a review of his Soft Skills book on Christos Matskas’ blog and thought it was something I needed to know more about.

I’ve been presenting and blogging for a while, since I realised that my technical skills were a necessary but not a sufficient condition for a fulfilling career, because the soft skills open the doors to the greater challenges of customer and team relationships, and greater responsibility. Communication and explanation are becoming more important right from the start of a developer’s career however, as more companies move towards adopting portions of the agile manifesto and encourage greater interaction between the technical and the business owners, as well as expecting a much higher degree of collaboration within teams,

For those of you just starting out, or those looking to jump things up a gear, the course lays out some great motivation and practical steps to get you set up, and start building up your soft skills by communicating.

Blogging may not be for everyone, but I don’t have much faith in a software engineer who can’t clearly communicate their ideas. So if you don’t currently blog, vlog, present or attend Guided Conversations, today is a great day to start.

If you’ve just started, please feel free to include a link to your blog, YouTube channel, or other communication forum below. Part of the soft skills are about collaboration and sharing.