Your #1 j ob is to make people want to work with you. If you’re ever faced with a work decision, use that measuring stick first by asking if your response makes someone want to work with you more, less, or the same. Since a large part of my brand is clarity, I’ll break this down into specifics, but please keep in mind that this list isn’t comprehensive and that environments vary widely.
Deliver. Getting your work done is critical. This is the biggest influencer on whether people want to work with you.
Smile. Not just in your facial expressions, but in your words and voice. Being pleasant is a close second to getting your work done and close enough that I’ve seen ineffective people retain their position far longer than they should simply because everyone liked them.
Innovate. While this is a pretty overused term, I’m using it here to specifically mean “do something or create something new which is a pleasant surprise”. It only takes 1 or 2 small innovations a year for people to want to work with you and see what’s next.
Bleed. You are going to make a mistake – own that mistake and do everything you can to make things right. You should not, of course, intentionally create problems but it’s pretty safe to say that problems will come. If you are the type of person who never blames others nor covers things up then people will notice (consciously or not) and want to work with you.
Support. Keep an eye out for others having difficulty and jump in to get their head above water. Someone who can keep the team moving in the toughest of times will be sought out and held onto.
Teach. If you can make others more valuable then you are a force multiplier and people will want to work with you.
Delight. The occasional left-field surprise goes a long way.
The challenging aspect to all this is that it needs to be genuine – for example pleasant can’t be an act, it needs to be a commitment.
Nearly 7 years ago, I wrote a post on how to run a development team. Recently, I was talking to someone who needed to run a team which wasn’t focused on software development. I told him that the same basic principles applied, but instead of focusing on the theory I simply laid out the practice. Re-reading the old post I realized that while I had conveyed the strategy that had worked for me and others, I had left out any specific tactical details.
Time to fix that by presenting the 4 things you must have to run a team effectively. You may decide to add other aspects to optimize for your specific situation but these are the items which are either in place or causing you trouble.
1. Backlog
A backlog is simply a prioritized list of everything you know that needs to happen. Prioritization is key – in the absence of further instruction, a team member should be able to pull the highest priority item from the list to work on and know that it’s the right thing to do.
2. In Progress List
To run a team, you need to know what’s in progress. If you (and others) don’t know what’s being worked on, then you aren’t really managing. The easier it is for you, and the team, to see what’s in progress the better the chances of catching the “Whoa, why is that happening now!” moments before someone wastes time on the wrong thing.
3. Blocked Indicator
Almost as important as prioritizing the backlog of work, blocked items are where a manager can really shine. When a team member marks an item as blocked, it’s a way for them to say, “I can’t work on this further until _____ happens”. The faster you can make ______ happen, the better off the team is. Sometimes it doesn’t fall on you, there are outside influences like other teams, clients, vendors, etc. – know the difference. Read every blocked item and ask yourself if there’s some way in which you can help. Also, since the backlog is prioritized, a team member should be able to roll from a blocked item to the next item smoothly.
4. Finished Indicator
I’ve been surprised on numerous occasions to find out that a team has no “public” way to indicate that a task is finished nor see what other items are finished. The rational I’ve usually heard (and it’s almost always smaller teams and companies) is that finishing is what counts and the manager is usually informed. This sets up a communications bottleneck where everyone has to check with the manager to get overall status or (more likely) no one really pays attention to what’s getting completed. Having a way for everyone on the team to know what’s done not only gives the group a feeling for where projects stand, it also allows for the “Hold on there, Sparky – that’s not actually done because you forgot _____”. This is more common where projects have lots of dependencies amongst the tasks.
Tools
There are dozens of good options (and hundreds of bad ones) for tools to make this easy. My tool of choice for a team which is starting from scratch is Trello. Create 3 lists: Backlog, In Progress, and Done. Add one label called Blocked and make it red. Boom! In 5 minutes (literally) you are now ready to start prioritizing and monitoring work while keeping an eye out for blockages. A lot of teams will later “graduate” to a more formal system, but getting the initial mechanics in place is critical and you don’t want to spend hours or days hunting around for the “perfect” solution until you’ve got things humming along enough that more advanced functionality makes sense.
If you feel your work day is too chaotic or your team could be performing more efficiently, chances are you’re missing one of the 4 items above. Do yourself and your crew a favor and put just a little process in place so you can start to troubleshoot and stabilize.
As technical professionals, developers are often accused of ignoring human issues and focusing too much on the technical aspects of a solution. Hugh MacLeod said it best:
Habits, values, and attitudes, even dysfunctional ones, are part of one's identity. To change the way people see and do things is to challenge how they define themselves.
Being a Big Swinging Developer is all about changing the way that people see and do things and that second sentence up there explains a lot of the resistance you'll face. It's not enough to show people what they can do, you need to show them who they can be. For example, I know lots of programmers who love agile development techniques and have trouble getting others to follow suit. This can lead to a lot of frustration as the Agiles think that the Non-Agiles "just don't get it." I don't think that that's the case. I think the folks who resist agile techniques do so because they don't want to be agile developers. Really, it may be as simple as that. Not everyone wants to code quickly and safely, or be able to change their mind, or do the things that agile techniques enable. If you look at it that way then you start to realize that someone who codes slowly and (at least in their mind) carefully will view writing unit tests as extra work that lowers their productivity. They may see putting prototypes in front of users before all the requirements are known as opening themselves up for (gasp) more work down the road.
If the view of people defining their identity by their habits, values, and attitudes is correct then the happier they are with their identity, the harder it will be to change how they see and do things. This may explain why the multi-decade veterans stick to their ways while the freshly minted grad will try out whatever you throw at him. It's not that the new guy understands better, it's that his identity isn't as firmly cemented which means changing what he does results in less of a change of who he thinks he is.
The next time you have an idea for process or organizational change, make sure that it either fits with who the organization is or who they want to be. If it's going to be a significant departure then spend extra time painting the picture of who they can be if your change is adopted. If you can't sell the idea of the new identity, chances are you won't be able to sell the technical aspects of the change. If, however, you can make people want to be who your change enables them to be then you'll find yourself surrounded by support instead of resistance.
One of the most important skills for a Big Swinging Developer to learn is how to focus. This is more than a matter of shutting the world out while slinging code. If it were that simple, then anyone with headphones could be a BSD.
To us, "focus" means pursuing the goal of shipping great software in addition to addressing all the other "distractions" that may pop up. Someone asking for help may seem like a focus-breaking request, but if helping that person makes the system better then it’s in keeping with the goal. Researching a new technology may be a huge breakthrough, or a huge waste of time.
I found myself in this position earlier today. I signed up to look at a new way of doing something in our system. After 30 minutes it became clear that the change (pretty much regardless of what it was) was going to be more time and effort than we could afford. This wasn’t the answer I wanted — I wanted a breakthrough. The problem was that even a breakthrough wouldn’t be worth implementing. This put me into a serious funk, but the alternative was to spin my wheels looking for (and probably finding) options that all had one thing in common: they wouldn’t be implemented and, therefore, they wouldn’t make the system any better.
It’s hard to stop short of solving a problem. It’s often easier to search and search and search until you’re told to stop, because then you can feel like the reason you didn’t solve the problem is because someone told you to stop. It’s easy to blame your predecessors, your vendors, or even your colleagues for getting the system into a state that you can’t "fix" within the given amount of time. But none of these makes the system better, so it’s your job to focus relentlessly by doing the right thing and getting back to the problems that have solutions.
and something I read back on page 27 is haunting me: