Beyond the T-shaped person: becoming star shaped

The T-shaped career model suggests that a person should have a depth of skills in a single field (the vertical bar) and a breadth of skills that enable cross-disciplinary collaboration (the horizontal bar). However to me, excelling in one area and being functional in a number of others feels too limiting for this agile, adaptable era of computing.

T shaped person - breadth of skills as the bar, depth of expertise as the downstroke

I don’t want to be a Pi shaped person either, which simply adds another leg of expertise to the diagram. Instead of having deep expertise in one field, it’s now in two fields. An improvement, but still not really doing it for me.

Pi shaped person -  breadth of skills as the bar, depth of expertise as the two downstrokes

There are variants on the model that I prefer, including the ‘V-shaped’ versatilist described by Pete Cripps.

V shaped person - broader cross discipline skills, getting narrower as expertise grows

The versatilist approach does however illuminate the very thing that bothers me with all of this. The skills development journey in all of these diagrams is towards a fixed point of deep expertise.

By contrast, I feel like I’m floating in a galaxy of fascinating topics, and I need deep expertise in many of them to be able to deliver success for my projects and clients in a rapidly changing world. Of course I’m not going to be a polymath, deeply skilled in entirely diverse disciplines (rocket science and brain surgery?), but the skills I use span across traditional disciplines, mixing IT architecture, UX design, programming, marketing, project planning, security and more to deliver successful outcomes.

I’d like to propose an alternative approach to the T-shaped person that captures how I’m growing my skills as a star-shaped person.

star shaped person - skills growing outward into many different domains

I aim to create a map of my skills, using a polar graph instead of the traditional XY axis. My skills are growing outward in all directions with the arrow length reflecting the level of expertise, and the direction indicating the domain of skill. Areas of the graph can be used to group similar and different skills together.

I’ve used simple quadrants contrasting for example creative versus analytical skills, but expect to refine this to show a more complete skills mix. Adding a new skill is reflected by adding in a new arrow, which may grow over time to exceed the existing skills. This dynamic development of my mix of skills over time is another facet that the T-shaped model doesn’t illustrate.

Coincidentally this symbol is author Michael Moorcock’s famous ‘Chaos Star’ symbol which I find very fitting. In a rapidly changing world, sticking to traditional, order-led, straight-line thinking no longer cuts it. To survive as IT people, we need to be adaptive, quickly growing skills and expertise in emerging areas and organically reinventing ourselves as the world changes around us.

In a follow-up post I will work through a practical example of acquiring skills using the T-shaped and star-shaped approaches.

The right tool for the job

Everyone seems to be doing agile these days. Not everyone is being agile however.

There is a big difference between employing the rituals of agile and really applying the agile manifesto values such as having working software that users can get benefit from every step of the way. This graphic describing how Spotify build products illustrates the point:

Copyright Spotify - Negative view - a car gradually being built from chassis upward; positive view - different modes of transport from skateboard to bike to car

The image is powerful and intuitively rings true, but there are a few deeper points – possibly unintended – that are worth exploring.

The key message from the diagram is that there is more business and user benefit from having something that can be used every step of the way, and feedback from real usage will help to shape an end result that users really need.

This is an hugely significant point for agile projects, but I argue that this benefit is dependent on how well understood the problem domain and proposed solution is, as to whether this holds true, and the key thing is to pick the right method for the problem at hand.

The ‘not like this‘ approach arguably costs less if we are building a car (to deliberately take the analogy a bit too literally). Cars are a well understood product, with generally incremental improvements to a well understood design. The ‘not like this’ approach is well suited, as every single production step is focused on building a car, without distractions or rework. In the agile approach, between the later steps a significant amount of the product needs to be thrown away or reworked based on the lessons learnt from the previous step. If you’re absolutely clear of the required end product (a car in this case) in a well understood domain, and cost is a critical factor then this kind of incremental waterfall approach is arguably the way to go.

The ‘like this‘ agile approach could transpire to be less costly if the problem domain is poorly understood and the real need is unclear. Usage may identify that a bicycle does the job well enough, and avoid over-engineering (and over-pricing) the solution. Or perhaps step 4 reveals that the user really needs to use the vehicle in rough terrain; so a quad bike would be a more appropriate final goal and you can change target at this point. By comparison, if you’re building a car using the first approach, you might not discover that what is really needed is a quad bike until the product has been launched and you’re inundated with unhappy users for whom the car is the wrong answer.

To summarise: for novel and poorly understood requirements, concentrate on exploring the user need whilst delivering working software using agile techniques; for well understood deliverables and problem domains, use more ‘industrial’ techniques such as LEAN to deliver as efficiently and effectively as possible. The trick is then to identify which ‘mode’ you’re in, and also when and how to move from one mode of development to another.

Getting used to a new Mac – Keyboard shortcuts

It’s a bit of a shock to the system getting used to a Mac after years on Windows. So much muscle memory to relearn on well practiced shortcuts for instance. Keys that no longer exist. A trackpad that does all sorts of weird and wonderful things. I’ve put together a quick summary of a few regularly asked questions and things that I’ve learned that will hopefully be useful to other new mac users. This post focusses on keyboard shortcuts. There are new keys to use for shortcuts. Going from the bottom left there are: fn (function) – normally used with Read More

Wardley Maps

At a work event last week, I was pleased to see a slot about Wardley Maps, a technique that I’ve been reading about for a while. Wardley Maps can be used to help understand systems in a different way than just as boxes linked with lines, by including x/y axes to position each component based on its evolution and position in the value chain. This allows a better visualisation of the makeup of they system and in particular which bits are novel and well suited to agile, and which are commoditised where a waterfall or ‘as as Service’ approach may Read More

Transport for London on Apps vs. Websites and APIs

A recurring question is whether to have a mobile app, or a mobile friendly website or both. The view from the Government Digital Service is that the most important thing is to have a mobile friendly website using responsive design.

“Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office.and only to approve use of apps”.

Similarly, Transport for London (TFL) have recently posted about how they haven’t created apps, but instead have a mobile friendly website and also make their data available using APIs (Application Programming Interfaces). These APIs allow TFL’s data to be used by private companies and individuals who have created over 200 apps using this data; much more than TFL would have had the resources or inclination to create.

They’ve followed the principles of open data:

“Why open data?
• It’s public data – as a public body, our data is publically owned.
• To extend reach – ensuring as many people as possible have the widest possible access to travel information.
• For best use of the transport network – enabling choice of the most effective journeys.
• Economic benefit – the small companies who make apps with our data generate highly skilled jobs and wealth.
• Innovation – thousands of developers work on designing and building apps with our data, meaning great innovation emerges”

TFL acknowledge that the private sector will cherry-pick the easiest and most profitable apps, so they then use their website to provide a fully comprehensive set of information that is available to anyone with a web-browser, regardless of whether they have a smartphone or not.

This combination of open data via APIs to encourage private sector innovation and a comprehensive mobile friendly website to provide an overall service to all users seems like a pragmatic approach, is in keeping with the Government mobile strategy and hopefully provides food for thought for public sector (and indeed all large organisations where the ‘crowd’ will help to create innovative apps) when creating their own mobile strategies.

The HTML 5 anchor tag: download attribute

The humble anchor tag. It’s the lynchpin of the web, allowing links between pages. Surely there’s nothing to improve here?

Well, one problem I encountered today is how to put a link to a resource (mp3, pdf or similar) and make sure that when the link is clicked it isn’t rendered in the browser but instead is downloaded. It turns out that HTML5 allows us to do just that, by adding the download attribute to the link. If the attribute is set to a value, that will be the filename of the download.

To force a download:
[html]Download your file[/html]

To set a filename:
[html] Posted in An HTML tag a dayTagged , Leave a comment

More on Microservices – Martin Fowler article

Martin Fowler expands on what a microservices architecture is all about.

A lot of the concepts are similar to SOA, so I’m gradually trying to understand what the practical and philosophical differences (and similarities) are. Here’s one:

When building communication structures between different processes, we’ve seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible – they own their own domain logic and act more as filters in the classical Unix sense – receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

Also I’ve been pondering services granularity and RPC vs the coarse grained calls of SOA. In this regard microservices seem closer to the SOA approach if anything:

In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don’t perform well. Instead you need to replace the fine-graining communication with a coarser -grained approach.

Are microservices made of the clear design principles of SOA but without all the heavyweight implementation details of SOAP, WS* standards, XML and all the rest of it. More reading needed!

Microservices by Paul Downey at GDS

Paul Downey at the Government Digital Service shares a interesting and visually appealing view of a proposed microservices architecture. The mix of web, APIs and systems of records looks sensible to me. Funny how we’ve gone from fine-grained RPC style webservice calls, to the coarse-grained services of SOA, back to ‘microservices‘ over the course of a few years (at least where I work …).

I do find myself wondering if the business function of the services that are exposed in a micro-architecture is actually much different from a well defined SOA service. Either way, being freed from the painful overhead of SOAP / WS-standards surely makes it much easier to contemplate building or integrating with a microservices architecture!

Microservice architecture

Unilever sustainability statement

UniLever CEO, huge industrial resource-processor, makes most important sustainability statement I've read this year

— Rick Robinson (@dr_rick) October 8, 2013

An impressive environmental statement from Paul Polman, CEO of Unilever
, muses on the limitations of our current capitalist approach and considers how we can sustainably build on this.

Installing IBM Worklight 6.0 on Windows 7

I installed IBM Worklight 6.0 following the instructions on the IBM Worklight installation page Generally my focus is on web-development and on delivering a ‘one web‘ experience using responsive design to allow a website to adapt to whatever device is accessing it (N.B. the one web article is great, make sure to read it at least once!). I do recognise that there are cases where ‘mobile apps’ are preferred either for access to device features, offline behaviour or just because that is what the customer wants. In these cases I’d rather create a hybrid app that is basically using my Read More