Some thoughts on technical leadership and coding.
The other day someone in the team asked me if I still write code. Which got me thinking about how, especially in agency land, senior technologists often don’t. Faced with the growing need for Technical management and client facing technologists, many larger digital agency environments have a fork in the road where people can pursue a less hands on route.
Over the years I’ve worked with lots of senior folks who continue to be practitioners. People from an engineering background who are still, at least some of the time working with software. This isn’t unusual in other fields - nobody expects the top brain surgeons to do all the operations, but they are expected to do some. The same is true for lawyers and in agency land often true for strategists and UX / design folks.
That’s not to say that management and leadership aren’t skills in themselves, skills that require practice and a significant time commitment. As an engineer the way you scale and produce a better output is (or at least should be) by having a team. The team is your unit of awesome.
There’s code, and then there’s code. On the projects I’m involved in the amount of real technical output I contribute varies significantly. Often the things I’m doing are prototypes, setting a direction - more like someone doing a sketch that communicate an approach or a style. It’s not about being ‘the best developer’, firstly because defining best is difficult (fastest, fewest bugs, most code, least code, best collaborator etc..) and also because that’s probably not your role on the project.
Sometimes it’s just about chipping in with a bug fix, picking up a few tickets and helping when the deadline is looming and JIRA is looking a bit unpleasant. It’s fairly unlikely that I’m going to be picking up lots of dev work across any of my client work, but it is an aspect of how I go about solving problems in my day-to-day work.
That’s not to say it’s easy to stay on top of the ever changing technology landscape, but for me it’s not a binary choice between management and coding. They are part of the dynamic of technical leadership, and it’s important that you make time to develop your skills in both areas.
2017-11-15 14:47:11 GMT permalink
2016-08-23 21:03:58 GMT permalink
Next month parliament will debate the removal of performing arts from exam options for 16-18 year olds. The debate will only take place because over 100,000 people signed an online petition. MPs on all sides seemed to have little understanding of the impact that creative and performance based subjects have on students. Both on their potential futures and the needs of businesses.
I am someone who benefited enormously from studying music and drama throughout my schooling. In particular studying performance based subjects at GCSE, A-Level and then at degree level. These studies equipped me for life and work in many ways.
These studies introduced me to a creative literacy that I hadn’t experienced before. The ability to communicate abstract thoughts or big ideas through sound, word or gesture wasn’t always part of my life. I grew up in a declining northern town in the 80s and 90s. Performing arts field trips to local theatres and concerts opened my mind to a broader view of the world. It wasn’t easy for most 16 year olds to stumble across Brahms or Brecht in Rochdale.
Beyond exposure to a broader hinterland, these performance lead studies also started to develop a set of softer skills. They gave me confidence in-front of an audience, the ability to communicate as part of a group and an understanding the importance of rehearsal time. These are skills I continue to use and develop as part of my day-to-day work. Without them I wouldn’t be able to do the job I do now.
As with most of our daily lives, technology plays an increasingly important role in performance and the arts. I spent my late teens playing with a whole range of niche and now obsolete devices. Trying to wrestle their output into some sort of communication or emotional response. I do the same sort of thing now, just with a different set of technologies.
The key skills of the future are creativity and communication linked to technical capability. We should be encouraging more children to take creative performance based subjects seriously, not fewer.
2016-06-09 10:58:07 GMT permalink
It is certainly not a recent trend for organisations to be looking to work with remote software teams. Whilst previously this was primarily motivated by a move to reduce costs and offshore development, increasingly there’s also a desire to harness technical talent irrespective of location. The growing R/GA network means that we are often reaching across offices to staff projects teams and leverage talented technologists.
Here are a few tips that help those projects along.
1. Daily stand-up has to run like clockwork
Even if you’re not running an agile or adaptive planning process it’s important that everyone is committed to making ‘the daily’ a success. This is your most important meeting of the day. It needs to be professional, effective and run to time. Time is important, on projects with a wide geographical span as someone is going to be getting up early or staying late to contribute to the daily, so everyone needs to respect that.
2. Keep an open line of communication for all developers
Informal communication is essential between the development team, what my colleague @philhawksworth calls a 'back channel’ for open discussion, questions and banter. This is where 'the culture’ of your team is going to be fostered.
3. Use video
Make all calls video calls, even though we can get by over the phone the psychology of video calls helps to re-enforce relationships. Where there are a group of people in a single location use a dedicated meeting room computer and gather round a single large screen so that remote workers take up a disproportionate amount of space in the meeting room.
4. Have a robust, repeatable build and deploy process
Whilst continuous integration and continuous deployment may not be appropriate for all projects, when working with remote and distributed teams a bullet proof build and deploy process is essential. If you’re running a semi-automated build system everyone should be able to run a build regardless of location - without this you’re going to start having bottle necks and some users are going to be more equal than others. With an automated build process all developers are have equal ability to break and fix the build.
5. Be location agnostic
If at any point the team start thinking about people who are 'offshore’ or 'in New York’ then that’s the start of a problem. Everyone on the project may not be equal, but the source of the inequality should not be location.
This doesn’t mean that you shouldn’t be sensitive to different locations and cultures - if it’s a public holiday in London, then it’s a public holiday in London. These things tend to equal themselves out and there are no surprises - you don’t often get short notice public holidays. The key thing is that you’re being equally sensitive to location and culture regardless of location.
6. Let remote people lead parts of the project
This sounds slightly counter intuitive when working with a group of remote developers or a distributed team, but if you want to embed a location agnostic culture don’t be precious about having all parts of the project led from the largest or main location. If you’ve got a fantastically talented front end tech lead on the project who is based in South America and you’re in Chicago, then there’s few reasons not to let that person lead the front end development.
7. Make time for a 1:1
If you’re leading a project and you have remote developers, make some extra time to have a one-to-one session with each individual. You won’t be to recreate that hallway conversation you might have if you were on the same corridor, but once you get a cadence to these conversations, it’s amazing how productive they can be.
8. Face to face buys you time
There’s an internal saying @RGA “that face time buys you 6 weeks”. Whatever the number for your team take advantage of any face time you can get, both from a work perspective but also from a social “let’s go to the pub point” of view. It’s worth it’s weight in something heavy and valuable.
2012-05-30 23:23:00 GMT permalink
This post originally appeared on the R/GA tech blog 3 August 2011
This week has seen the news that in the UK, Google Chrome has overtaken Mozilla FireFox to become the second most popular browser. According to data aggregated by StatCounter (a provider of website tracking software), Chrome now has 22.1% of the UK browser market, pushing it past FireFox’s 22.0% market share. Internet Explorer continues to dominate with 46% of UK users still using some version of IE.
Measuring UK browser percentages is not an exact science. Whilst StatCounter usage is widespread, it is by no means the only web tracking software available. This combined with the difficulty in identifying the geographic location of all site visitors means that despite the impression of precision, this data should be regarded as indicative. What is interesting here is the trend and also the reasons ascribed to the growth of Chrome usage in the UK.
Google clearly see speed as a key element in the rapid growth in Chrome usage. Google engineer Lars Bak has been quoted as saying “Speed is a fundamental part of it, but it’s also about the minimal design and the way it handles security”. But the success isn’t only about technical excellence and improving developer tools. A growing suite of cloud based business applications is driving adoption of Chrome by UK businesses. Unusually for a Google product, in the UK Chrome has also been supported by an extensive outdoor advertising campaign.
Whilst Chrome isn’t universally popular, it’s speed and innovative use of caching, has given it, and Google a place on many people’s desktop. With Google alsogrowing rapidly in the mobile market with it’s phone operating system, Android, and making a play at the hardware market with it’s new Chromebook, it would be difficult to see the rapid growth of Chrome slowing any time soon.
2011-08-13 23:20:19 GMT permalink