Welcome

My name is Daniel Armyr. I love working with teams of people as a way to achieve things that would otherwise not be possible.

I have coached teams since I was 16 years old. Time and again I have seen empowered teams mature to perform miracles once they were given the right circumstances.

But I have also built with my own hands. I have developed both hardware and software. I have worked both as a long-term employee and as a consultant. I have worked both in the highly regulated MedTech industry and at the breakneck pace of software startups disrupting entire industries.

Where I am today

I am the CTO of Conversy, an AI startup disrupting how we work with spoken audio through biometric transcription.

How I got there

Six years of of startup software development management

Nextory

My greatest achievement so far is having been the guide on the ground for the engineers at the digital book service Nextory. During my time there, Nextory achieved year after year of consistent triple- and high double-digit customer growth and industry-leading employee engagement.

My most valuable lesson so far has been how to take a cross-cultural, cross-continent team of engineers and turn them into a cohesive, trusting unit that delivers fantastic results.

Six years of consultancy and technical sales support in data analysis

Data Analysis

My greatest achievement was being part of the team that in one shot enabled all Swedish university staff to use parallel Matlab on all of the major Swedish university supercomputers, a first of its kind sale.

My most valuable lesson was how to dive in behind the requirements and really understand the true need of the end user.

I also taught advanced and clean code for data analysis, including this presentation:

Six years of hardware development in the MedTech industry

MedTech

My greatest achievement was being lead engineer for the PeriCam PSI product that I took from pre-study to product launch, and it is still actively being sold.

My most valuable lesson was the importance of creating designs that are easy to produce and don’t require service.

Six years as scout leader

Scout Leader

My greatest achievement was as an adult later in life when I designed and then helped manage the scullery for the 2011 World Scout Jamboree that washed the dishes for 10,000 staff eating three times per day, all done completely with volunteers with no prior industry experience.

My most valuable lesson was how a group of ordinary individuals truly can form a team that achieves miracles, if given the right support.

For a more traditional version…

See my LinkedIn profile.

Just Stop: A brutalist manifesto for managing software development

  • We stop mistaking meetings for progress, instead we gather to solve real problems.
  • We stop stockpiling backlog items we will not build, instead we bring clarity to what matters now.
  • We stop spending time and energy on estimations, instead we work in small enough pieces to see real progress.
  • We stop haggling over salaries, instead we define performance and pay accordingly.
  • We stop on Fridays to reset, refocus, and start clean on Monday.

This manifesto calls for an end to the theater surrounding software development. The theater of new titles without new mandate, the theater of a calendar packed with meetings, and the theater of sprints that are just more of the last sprint.

By Daniel Armyr

read more

Accurate estimates are possible

Humans are terrible at predicting things. Especially about the future.

I have had two insights that really help. The second one turns everything I have ever been told about estimations on its head.

Assembly-lines under controlled conditions are easy to predict. But few of us run these any more, and still people who depend on us really want to know when we will deliver. So we guess, because not guessing is bad for business.

By Daniel Armyr

read more

Test Driven Development: Really? Why?

I am a huge fan of Test Driven Development (TDD). If I spend more that a couple of hours writing a piece of code, in most situations I start to lose track of the details. Exactly what worked exactly how? And if I do this refactoring, have I really covered all of the cases that the old code handled, or did one get lost in the simplification?

This is the reason why I use TDD for any code that has more than one or two execution paths. It may take a bit of extra effort, but I know that I will get that investment back allready later that same day. So it is a no-brainer.

By Daniel Armyr

read more

More

Two Questions That Build Elite Software Teams

Becoming a true leader in 16 weeks

Effective meetings

The role of the Tech Lead