Samsung Galaxy S6 First Impressions

They’ve done it. After a couple of false starts, Samsung have finally worked out what people want in a phone. Good design, great materials, fast software that gets out of your way, and a kick-ass camera.

The S5 was a hilaribad warmed-over S4, stuffed with crapware and ignoring much of the great work Google has put into Android over the last few years. The S6 in comparison is a fresh start.


Apart from the obvious screen difference, the S6 and S6 Edge are all but identical. Apparently the S6 has a battery about 2% smaller than the edge. I’ve come to ignore processor, memory and screen details these days, because they’re all good enough. What matters is that the UI is responsive: Samsung have nailed it on this one. No glitches, smooth animation, and the camera startup time is finally OK (which is novel for an Android phone).

The camera is a stunner. I imagine the nerds will give some in-depth comparisons that might prove the iPhone 6+ has better chromatospores or some other nuance, but in-person it’s obvious the S6 does incredible things in low light. Our location this morning was camera-punishing: low light with a bright window. Where the iPhone couldn’t cope, the S6 pulled out well-metered, front-lit photos with great white balance. I was pleasantly surprised because we can normally completely ignore any claims of camera superiority over an iPhone.

The phone feels … robust. They’ve done away with the flimsy removable back that made the S4 and S5 creaking and cheap-feeling. The S6 by comparison feels solid and expensive.


Basically: who are you and what have you done with Samsung?!

I’m not sure if Google demanded that Samsung cut back on the crapware, or if Samsung woke up. Whatever the reason, Samsung’s take on stock Android in the S6 is massively improved over the predecessors.

S-Health, S-Travel, S-Whatever have all been relegated to simple icons in the launcher. They’re there if you want them, but not in your face like they were on the S5. Even Samsung’s take on the settings panel is logical, fast, and easy to use.

Samsung Pay is difficult for kiwis to understand, but I think it will work well in the USA, where magstripe is still a thing and will be for years to come. The convenience of magstripe is causing headaches for both chip-and-pin and NFC adoption in the USA, and Samsung have done well to find a workaround for this. I presume the S6 has a magnetic field generator inside it, and it’s pretty neat to see the way it finagles the magstripe reader into thinking it has seen a card.

The Edge

Better than the U2 version, Samsung’s Edge is more than a gimmick. For one: it looks gorgeous. It makes the phone look different to anything that has come before. It looks truly modern; space-age even. It tapers to a slim, sharp edge that feels nice in the hand, with a feeling of security that reminds me of the hard-edged iPhones 4 and 5. No slippery curves here.

The software applications for the Edge are pretty neat too. Rub it gently in sleep mode and the Edge will show you the time and notifications. An incoming call from a favourite contact will light up the Edge in a selected colour. If you’re one of those people that uses the flash-notification on your iPhone to alert you to silent calls, I think the Edge will be a nicer approach to the same problem.

Overall, I’m impressed by the S6. Samsung have pulled back from their crapware-for-everything focus, and turned their impressive heft toward hardware and system design. The results are obvious: gorgeous hardware with what looks to be the best near-stock Android platform available.

(Re)Building from the ground up

A few years ago the New Zealand Warriors went through a particularly tough patch. I remember watching them recover from that particularly tough patch. I recall the way the team would back each other up after mistakes. After a dropped ball or a missed tackle, several team mates would approach the player, offering advice and consolation. Back-pats, smiles, words of encouragement. With this supportive culture, they reduced their mistakes, improved, and went on to complete one of their greatest seasons.

A year ago the engineering team at Vend went through a rough patch. We didn’t have our shit together. We were a new team trying to operate in the hairball structure of an early start-up, where everyone demands everything and everyone just builds stuff as fast as they possibly can. We struggled to ship at pace.

With the application of focus, a bit of structure (but mostly trust), and heaps of great new people, we’ve improved. We’re incredibly tough on ourselves and are convinced that we’re a long way from optimum output, but we’re better.

experimentalI’ve come to realise that building a high-performance team in a fast growing business is just one long fail. At any point in time you can only think “hell, we have to do better than this”. Yet when you look back over a year of growth, the improvement is phenomenal.

Every day we start from yesterday’s mistakes and failures, building a team that can cope with tomorrow’s inevitable challenges and changes.

Today, we drop the ball and we pat each other on the back and offer words of advice. Tomorrow we will do better.

Tomorrow we do a bit better, but we still drop the ball and we pat each other on the back and offer words of advice.

And the next day we do a bit better.

Electionish Stuff

Hello. I reckon you should vote.

There’s one interesting thing I’d love you to think about though: no matter who you vote for, nothing much will change.

And this is great.

If you were to listen to all the ads and interviews and rhetoric, you’d be pretty sure that no matter who wins on Saturday night, New Zealand’s economy is going straight down the shitter. This will not happen.

What is being offered (by all but the most extreme parties) are minor tweaks. Sure the proposals are painted as extremist nut-job burn the world leftism or tophat and monocle 7 year old chimney sweep toryism, but this is rubbish.

Please don’t listen to the hype. Take a look at some of the policies, and make a choice based on what you think is right for us.

Us, not just you. Because we live in a society, and the prosperity of everyone from the largest business right down to the poorest kid live off that society. We’re nothing without it.


Livescribe 3 SmartPen

I’ll admit to being a bit of a pen nerd. I’ve been know to spend silly amounts of time and money at, and yeah I’ve owned and used a fountain pen. Hey, at least I don’t wear a fedora.

Despite this, I don’t actually write a lot. I spend 95% of my time behind a keyboard, and have got to the point where it really is faster for me to get my thoughts out with Evernote and a decent keyboard than it is to pick up a pen and paper. It is however the Evernote connection that got me interested in the Livescribe 3 SmartPen when the team from got in touch.

smartpenSo what do I think of it? It’s a chunky pen. Not much bigger than a nice Cross or Rotring, but – surprisingly – a lot lighter. I’ve drawn a rendering of the pen, using the pen, at right. The ballpoint nib is at the very front tip of the pen, and behind it is a little cavity that I presume contains a camera. The nib being offset is a little weird at first, but you get used to it quickly. You operate the pen by twisting the middle section, which pops out the nib and turns the pen on.

By itself, the pen doesn’t actually do anything more than a regular ballpoint. The magic comes when you pair it with a smartphone and start writing on their special notebooks. Using the pattern on the paper, the pen can track what it is writing and send it direct to your phone. It’s pretty techy, and works incredibly well.

The required Livescribe+ app is serviceable, but not stellar. It works fine to sync pages from the smartpen, but I find I use it mainly as a bridge to Evernote, rather than for any particular heavy lifting. Here’s an example of what a page looks like once it’s synced to Evernote. I’m impressed with the clarity and resolution, and the pen doesn’t seem to miss any strokes even when I’m moving very fast.

Each page in the notebook has “buttons” for recording audio and tagging notes. I was a bit disappointed that audio recording requires the app to be running – the buttons on the notebook simply signal the app to start and stop recording. If the pen itself held the recordings, I’d use that function a lot more, because the offline pen mode is brilliant otherwise. That is: you can simply use the pen without your smartphone connected, and take many pages of notes before syncing with the app. This is perfect for conferences or lectures.

The Livescribe+ app will also convert your handwriting to editable text. I found this about 80-90% accurate, but my chicken-scratch handwriting is very sub-par. In experimentation if I slowed down just a little bit and concentrated on writing clearly, the accuracy was more like 98-100%. If you have neat handwriting, this would work ok.

livescribeI’ve found I use the pen a fair amount to capture a quick scribble, an image or perhaps a mindmap; sometimes a  page of notes in an environment where I don’t feel comfortable sitting bashing away at my laptop keyboard. I think if you’re a big pen-based note taker this pen could genuinely change your world, but for me it’s supplementary.

Still, for the size and weight, this thing is bloody remarkable. I like it.



QCon NYC Day Two: Skills To Pay The Bills

[This is a slightly modified version of an internal travel blog post I wrote for the Vend crew]

It’s a dreary Thursday in downtown Brooklyn, low cloud, muggy – but at least I got some good sleep. The F-Train was packed this morning.

TL;DR: Embrace imperfection and change. Still no one doing transactional microservices.

Tweet of the day:

The day kicked off with Dianne Marsh, Director of Engineering at Netflix. She didn’t elaborate a lot on what Aidrian said about Netflix culture on Wednesday, but did list through a bunch of tools they use to do their builds and deploys. They use tools like Asgard and Animator to manage and deploy Amazon Machine Images (AMIs) directly. Apparently this is pretty old-school compared to what we’re doing with Puppet; and Chef, and new containerised deploy tools.

She talked about freedom and responsibility at Netflix, using the example of an engineer who wanted to use Python (freedom), but was required to completely integrate it with Netflix build, deploy and monitoring stack (responsibility).

Next up was my favourite session of the day: Michael Feathers talking about Conway’s Law (’s_law) and suggesting that we flip it around. What if we organised the company structure around the way we would like our architecture to look? We’re already doing this with our separation of POS clients and API, but if we were to run separate teams based on product area, would that cause us to define better boundaries between those components? Maybe.

Michael had some interesting thoughts about cruft and debt. What if we treated entire swathes of code as “open for extension, closed for modification” like OO classes? His point that there should perhaps be a more clear delineation when a section of code is “closed”, but teams instead tend to let things tail off a bit without properly “closing” stuff.

Michael also touched on constantly changing teams, and asserted that teams and employees will ALWAYS change faster than the structure of the application. So if we always assume that teams will change, then we design ways to cater for that. He suggested keeping teams small is a good idea – like smaller than 12 people per team. HAHA. LOL. [We don’t have many more than 12 engineers at Vend right now]

Also, Michael talked about combining Conway’s Law with Dunbar’s Number (’s_number) to posit that there is an actual upper limit on the overall size of a feature that a team can manage, and therefore the overall size & complexity that an entire product could safely be given a number of teams and engineers. He referred to this as “human scale” software architecture, and suggested that these limits should be taken into account using careful “asset management” when planning new features, and that features should not actually be added if they can’t be supported. Interesting.

Then (fanboy moment) Eric Evans – Mr Domain Driven Design. Warning for designers: his book has the ugliest cover design in the history of technical book covers. Ugh. Anyway, digression. Eric’s talk was about embracing imperfection, which I think surprised much of the room given how dogmatic some proponents of DDD have become.

Eric talked about creating Bounded Contexts, and how useful these are in refactoring software. Define an area of the application that you want to work on, nail down a clean domain model for it, and build a translation layer (ahoy! API!) between that context and the rest of the app to abstract away imperfection. He went on to explain that yes, this will result in multiple different models throughout the app, but this is inevitable, and in fact desirable because it gives you more flexibility to cater for the specifics in each context.

One interesting thing Eric talked about was that adopting a “trendy new language” can in fact be a good way to force the creation of a new bounded context, because:

  • Early adopters tend to be very capable developers.
  • The new language marks the part of the software where “we’re going to do it right” – at least initially.
  • The new context makes connecting with other parts of the application in a loosely coupled way a conscious step

Of course there are all the downsides of early adoption too, like will the language still be around, and will people have the knowledge to work on it? No easy answers here, but Michael (in the prior talk) did make the point that longevity of a species implies death and rebirth, not immortality. Deep.

Finally Eric talked about acknowledging imperfection at small-scale via what he calls the “spill zone”. You’re building or refactoring something and you have a wonderful elegant model that solves 90% of the cases, is within reach of a further 5%, and simply can’t cater for the final 5% weird-cases. What do you do? You use an if-then-else and write a crappy “allTheRest()” function to cater for the weird cases. He suggests this is a faster, better approach than spending much longer attempting to reach an elegant model for 100% of cases. AND the “allTheRest” function doubles as documentation of the weird cases.

In closing: I’m glad I wrote this, because Thursday’s sessions didn’t feel as interesting as Wednesday, but in review there are some interesting nuggets there. I’m looking forward to Friday because there is an entire stream on Engineering Culture with talks from GitHub and others. Peace out.

QCon NYC Day One: No Sleep Til Brooklyn

[This is a slightly modified version of an internal travel blog post I wrote for the Vend crew]

After a couple of nights of 4-hour jet lagged sleeps, I caught the F-train subway from my sister’s house (near Prospect Park) to Downtown Brooklyn. Turns out that the inside of the Brooklyn Marriot is the same as any conference centre in the world, regardless of how much Beastie Boys I listen to.

I sat through 7 talks, and will try to summarise my top 3 each day.

TL;DR: We’re doing cutting-edge work in a supportive team culture at Vend. There are some incremental ways we could improve as we grow, but nothing earth-shattering.

Tweet of the day:

Adrian Cockcroft (basically “Mr Microservices” from Netflix, now working at a VC firm) talked about the culture and process of moving to the cloud and micro services. The talk was more aimed at big enterprises trying to break down monolithic IT departments, but there were some good points:

  • Netflix has a policy: If a meeting happened, you should try your best to remove the reason for the meeting in the first place.
  • Stop doing any “undifferentiated heavy lifting”. Find a XaaS or supplier to do it for you.
  • Disruptors take something that used to be expensive and work out a way to “waste” it. E.g. cloud based SSD storage. Incumbents still treat it as precious.
  • Even if you’re doing CI and deploying multiple times a day, QA & Integration is hard at scale.
    • Gets really hard in the 100-dev range.
    • Maxes out at 10’s of deployments per day.
    • This is where microservices come in. They can reduce or remove overlap between teams.
    • Doing Microservices properly means no running components are changed. Leave the old ones there and deploy new ones, then slowly route traffic to them. “Waste” more VMs so that you can experiment and roll-back easily.

In general, microservice architecture is getting constant airtime at the conference, but I’ve yet to talk to anyone using it in a seriously transactional environment. Netflix helped pioneer it, but the way I understand it, Netflix is extremely read-only in comparison to Vend, and probably can afford to lose some input data occasionally. We can’t.

Jez Humble (Mr Continuous Delivery, now also Mr Lean Enterprise) talked about Kanban, Jidoka, and continuous improvement. He said “Lean doesn’t mean cutting costs. Lean means investing to reduce waste.” – which lends itself to carefully and analytically eliminating areas of waste and inefficiency (calling back to Adrian’s comment about removing meetings).

He also pointed out that a high trust culture is a predictor of efficiency, and recommended reading about the Nummi car plant, where Toyota re-hired a poorly performing GM workforce and completely turned it around though application of their process and policies. Foremost of which being a no-blame culture, especially during stop-the-line events. I reckon we do an awesome job of this already.

Jez reminded me about Toyota’s “Improvement Kata” (which I think we could and should do better, especially out of Retros).

My third favourite talk was by Edmund Jorgensen, on ways to improve delivery velocity. He had a pretty hilarious allegory for talking about cruft or technical debt (or other causes of slower delivery), and the way that non-technical people see it:

Imagine a stock warehouse with lots of forklifts. They drive around ok most of the time, but occasionally Ninjas appear and muck things up, slowing down the forklifts. The only way to make the Ninjas go away is to do a juggling display for them. Every time we complain about the ninjas, and non-technical users come to see, the ninjas disappear. All they see are juggling forklift operators, so they say “Stop bloody juggling and get back to work!”

His solution: don’t talk about Ninjas when talking about the Ninja fight. Kinda silly, but he did suggest finding alignment between what makes the user’s thing faster or better, and what makes our engineering stuff easier to build and therefore faster to deliver.

I think we already do this very well, by improving our architecture as we build or fix features. And given our required pace, I can’t see us stopping all the forklifts for an all-out Bruce Lee Ninja Fight.

So yeah, a pretty intense day. Tune in tomorrow for Eric Evans, Aish Fenton and more.

Where are the Developers?

The amazing recruiting team at Vend have hired a few awesome software developers to add to our already incredible team. But it is hard work. Really, really bloody hard. So hard that I sometimes wonder what we’re doing wrong. Are we looking for the right people? Are we sending the right messages to attract those people? I’ve been thinking hard about what we’re looking for, and what we have to offer, and wondering if those things match up.

I think back to classic hiring articles like Joel Spolsky’s Smart and Gets Things Done for example. Are we asking the right questions in interviews? I’m pretty sure we are, but we could do better. I think about the concept of the 10x developer. Are we looking for unattainable unicorns instead of incredibly good racehorses? Maybe, but our current unicorns would get pretty lonely if we didn’t hire more.

What about our tooling? Should we be looking for a direct match there? There are plenty of opinions on PHP, but that’s only one part of our stack, and a part that we do as well as any modern dev shop, with unit tests, dependency injection, MVC, and – quite seriously – the most robust code review and continuous delivery culture I’ve ever been involved in. I could mumble about HHVM and PHPNG, but that’s just noise. Of course we’re looking at those: we continually evolve our platform just as we also include other tools where it makes sense. I’d list all the bits but honestly you’re better off coming in for a coffee to chat through it all with our crazy-talented devops crew.

It’s particularly interesting to me, coming from a Microsoft dev background, that your average PHP developer has less in common with what we build than does a high-end C# or Java dev. Emphasis on the average in that last sentence, because we all know VB6 caused the Microsoft world just as much pain as PHP; but you could argue .NET and Java have supported good, testable OO coding for longer than PHP has.

Coming back to Spolsky’s post, there’s a quote that highlights my point on tooling:

In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.

If I’m brutally honest, I think we’ve boxed ourselves in a little by advertising hard for PHP developers, when what we really need are great developers. 10x developers. Smart and Gets Things Done developers. Developers who thrive on massive growth and solving crunchy problems in a supportive team environment built on Trust and Focus.

Maybe those developers know a bit of PHP, but it’s more likely that they’re dabbling in Node or Go or some godforsaken JVM variant. All I care is that they’re passionate and intelligent, and want to share those talents with a team of like-minded individuals.

Is that so hard? In the famous words of Delia Smith: Where are you? Let’s be avvin’ you! I’d love to chat over this stuff with anyone. Or just.. you know.



Politics and Social Media

I’m hoping for a change of government in New Zealand come September, but not for the reason you may assume.

Back in 2008 when John Key came to power, Twitter was barely kicking off and Granny Herald had about 40 or 50 thousand more subscribers than today. I genuinely can’t remember being involved in any real-time online conversations about Helen Clark’s Labour government, whereas I now read multiple personal opinions on a daily basis about the latest thing that Key or Brownlee or Cunliffe or Norman has done.

I guess it’s obvious that Trevor Mallard is just as bad as Judith Collins on Twitter, but what about Chris Carter, Cullen and Goff? What would their time in power look like through the lens of personal jibes and dumb hashtag jokes? Did they get a relatively free ride?

When National put through not one, nor two or three, but four laws that appear dodgy in respect of the Human Rights act, I paused before flipping my lid online: surely it can’t be this bad? Surely other governments have done similar things and it’s just my pinko-liberal world-view to blame. Chill out. Right?

Is the Fifth National Government truly a cesspool of dimwitted decision making, or do I only think that because the Twitter echo chamber tells me to do so? I like to think I’m equally critical of Cunliffe’s gaffes and lack of policy, but worry that I’m just suffering confirmation bias. Does John Key truly disagree more with scientific, statistical, and economic consensus than Helen Clark did, or do I just think that because there are more immediate howls of anger from the e-left (iLeft? cyber-left?) when he comes up with another pearler about his “advice” saying otherwise?

To me it looks like no politicians are getting an easy ride online right now, when any fact or opinion can be rapidly fisked by the pyjama army ranks on both the left and right. If anything, it appears that investment in polling and carefully researched talking points is many times more valuable now than it was in the time of controllable media. Just take a look at the nutty “infographics” and crappily crafted motivational posters coming thick and fast from all sides lately: any time a politician says something vaguely quotable it’s turned into a Facebook-shaped meme before bedtime. Most of these are pointless crap, but I guess the plan is if just one of them turns “viral”, then yay votes!

The question I’m asking is this: what does social media look like when your favourite team ends up winning all the time instead of losing? I’m a Greens voter, but I like to think I’ll still be calling bullshit on dumb policy if they’re ever in power. Will they turn out to look just as idiotic as the current bunch? Will Trevor Mallard be an appalling speaker, biased toward the left instead of driving for genuine answers at Question Time?

Basically: bring on a change of government so I can check my bias by trolling left-wing politicians. Also: you’re on notice left-wing echo chamber. I’ll be watching.



Sphero 2: Not just a toy

I saw my first Sphero at Microsoft’s BUILD conference in 2013. Sphero wasn’t new at the time, but after seeing it in action I just had to have one. Who wouldn’t want a silly robotic ball that you can control with your smartphone?

Image via

Fast-forward 12 months and the revised Sphero 2 is on my desk. It’s faster, brighter and apparently more agile than the original. The 10 year-old and I had a blast putting the new Sphero through its paces, bumping down the hallway and occasionally hitting the ramps. Yup – it’s still pretty hard to get Sphero heading in the direction you want, but it sure is fun while you try.

Out of the box (which includes two jump ramps), Sphero 2 is quite a bit more fun than the original. A new career mode has been added to the basic smartphone app, encouraging users to play with Sphero to unlock new tricks and develop their control skills. There are of course a bunch of other apps to play with too.

But to me, just playing with Sphero using the provided apps is only the start.

Programming Sphero

Orbotix have obviously had a lot of feedback from people like me: coders and parents of curious 10 year olds. Their Sphero MacroLab and more advanced orbBasic apps provide a great way for kids (and adults) to experiment with basic programming techniques. I’m not sure how many institutes have taken up Orbotix’s education discount, but it looks like a great idea.

For those with more experience in coding, Orbotix provides a full Sphero SDK for most platforms, and a bunch of documentation and information via their official developer portal. Orbotix’s GitHub profile is a quick way to to see some of the available samples.

Perhaps one of the more zany things about Sphero is that you can use its location and orientation sensors as input devices, rather than just telling the robot where to go. There are a few examples of Sphero as an input device for gaming and 3D input, but perhaps the coolest one is using Sphero to control a drone:

The demo above uses the AR-Drone Sphero SDK. Perhaps you could take it to the next level by using the spheroSMS package to control the AR-Drone via Sphero via SMS?

In conclusion, Sphero is totally nuts, both as a simple toy and as a tool for education and software development. It’s just plain fun, and I can’t wait to play with the new Ollie, which promises to be like Sphero on steroids.


Those following along at home will know that I recently wrote about the place of responsibility and ownership in software development. While valid throughout software engineering, ownership is especially important in the context of a rapidly scaling software business – we need to be able to rely on developers to get things done without a massive layer of management whom we neither have the time to recruit, nor the culture to support.

The seminal Netflix culture  slide deck (yeah it’s a doozy – I’ll wait while you read it), illustrates this wonderfully as the point where the growth rate of the business out-paces the density of high-performing individuals. This is traditionally the point where layers of management and process are introduced to deal with the ensuing chaos.

First ever 747The clue to solving this is imbued throughout that Netflix deck too: trust. Without trust we can’t expect responsibility to flourish. Without trust we sit on the shoulders of developers, imposing restrictions and demanding feedback. Proponents of Agile would call this an impediment.

So what does trust look like in a rapidly growing engineering team?

Solving the right problems

Newly minted development managers coming from a technical background (and there’s an argument they should only be from a technical background), often feel to manage developers one needs to prove one’s technical prowess. I’ll admit to falling into this trap myself, especially when working with a new team. If they don’t respect me as a coder, how can I have any authority?

Here’s the thing: the problems you need to solve as a technical manager are by definition non-technical. You need to create an environment in which the engineering team can execute to their potential, and otherwise just get out of their way. The last thing you need is technical authority. I suggest you get your technical jollies forking MEAN at home, and use your fading technical knowledge when liaising with the business, but otherwise close Sublime Text or Visual Studio and walk away.

Do you trust your team to choose the right libraries, architect solutions, solve loosely-defined technical problems, and code to their best abilities? How about do you trust the team to deliver a solution that is the best mix of JFDI and polish for a given timeframe? If you don’t, then you have a problem infinitely larger than your technical abilities could ever solve.

So, what problems should you be solving in order to build responsibility and ownership in your engineering team, and build a self-propelling engine of international awesome?


Work with the business to make sure the engineering team are working on the right thing, right now. Help them understand how to build the right way. The right thing of course means the number one (or two or three) thing that must be built to bring delight to your customers (new or old).

Here’s one I prepared earlier.


You are undoubtedly right to abhor a 50-page technical specification, but you do need to demand enough information so that engineers can understand the scope of the task at hand, and ensure they can connect to the right people to get the detailed answers as they build. This might be Product Management, or perhaps direct customers. Facilitate and engage, then leave them to it; don’t dictate.

You need to be a navigation buoy in the flow between engineering and their stakeholders, rather than an hourglass through which all information must travel.


Provide space and time for the team to lay their foundations. Documentation, tooling, code reviews, training, recruiting, onboarding, communication, experimentation. All of those things that are “invisible” to customers but oh so incredibly important to the smooth operation of a dev team and the production of world-class software.

You need to be the advocate for this behaviour, explaining to the business why it is essential. But trust, trust that the team can execute this foundation work themselves.


If you’re getting a lot of the above right, then your team will be a fecund swamp of talent. Engineers will be popping up and seeking out challenges. It can be super tricky to find opportunities for growth in a small team and company, but one simple way to promote growth is to delegate ownership as much as you can, because this supports the growth of both the team and the individual – things you need to be happening as the team size grows.

You can also facilitate internal presentation sessions to foster talent within the team, then support your engineers if they want to present externally.

Use your gut feel and previous technical experience to pinpoint areas for improvement and work with each engineer individually to help them improve those areas. We’ve found some benefit in plotting a modified Urban Airship Tech Ladder across four axes, which can show where an engineer perhaps excels in some areas but can improve in others. Great food for growth!

Output will flow

I imagine some readers are having heart palpitations because I haven’t mentioned delivery, or deadlines, or output. My assertion is that if you get the above right – especially focus and clarity – output will flow. Sure you can tweak the dials on time spent on foundation vs delivery work, but only for short periods of time.

Trust the team. They will deliver.

TL;DR version: Are your engineering managers solving the right problems, or are they an impediment?