Decoupling WordPress

The opportunity to move to a decoupled or headless WordPress system is an emerging discussion because of the broad range of possibilities it opens for developers with complex architecture needs. Decoupling, or separating the backend from the frontend with a framework like Strattic, also delivers a level of complexity that should be factored in when planning a project’s development. Certain projects can benefit from decoupling, while the fully integrated WordPress platform better serves most use cases.

When the words “Learn JavaScript Deeply” were spoken by Matt Mullenweg in 2015, the world hadn’t yet fully realized the scope of what would soon be possible. Then, when the WordPress REST API was released as part of core in 2016, the platform made a giant leap into the future. Of course, Gutenberg, the WordPress editor introduced in late 2018, highlighted what could be accomplished with this new feature as it uses the REST API to create and update posts by communicating with the WordPress core backend. Both the REST API and a modern JS framework built on React are shipped with every copy of WordPress and are now integral components.

This evolution of WordPress means that today, developers are no longer limited to PHP. Instead, developers can create apps built on React and other JavaScript frameworks, served by Node, and powered by the WordPress REST API. This enables WordPress development by frontend developers who don’t write PHP, as well as integration between WordPress and other frontend technologies and systems. 

Key Issues To Consider 

First, a reminder of some key issues worth seriously considering as you weigh decoupling, versus using WordPress as a complete solution. 

• Performance – Many developers want to decouple in the belief that this increases performance or scale. This, however, rarely proves itself in reality.  Decoupled front-ends must be scaled separately from the WordPress backend. A good host largely solves scaling in traditional architectures. A top-tier enterprise WordPress platform, such as WordPress VIP, will also scale endpoints for decoupled architectures and can serve Node apps at the same scale as anything else being served.  However, decoupled front-ends present their own points of failure, their own caching mechanisms, and generally increase performance risk.  For example, if the site is down, is the front-end causing the problem?  If so, which part of it?  Or is it the API?  
• Total Cost of Ownership (TCO) – Even teams with mature JS capacity typically find that decoupled experiences have higher TCO than traditional ones. This is primarily due to duplicate hosting, multiple technologies, split teams, multiple codebases, multiple caching strategies, and more. The overall cost of support and build of a decoupled project is almost always higher than a traditional integrated WordPress build. It is essential to consider cost in terms of the whole lifecycle of the project.
• Solved problems / ecosystem – Out-of-the-box WordPress architectures have more access to integrations and community solutions than custom front-ends.  Sure, React supports many community extensions and integrations, but when we limit the scope to the kinds of extensions required for content apps, WordPress’ extensions and integrations are almost always easier and cheaper to figure out. Examples include AMP and other delivery channels, authentication/SSO, many platform integrations, and even features such as “preview” become an issue that needs to be solved anew for decoupled sites.

Available Toolkit

Today’s decoupled WordPress toolkit is quickly growing, and it includes the following popular solutions.

• GraphQL / WPGraphQL – GraphQL is a Query Language built to craft more precise and lightweight queries to bring only the data you need from the REST API into your front-end application. WPGraphQL extends this framework to be specific to WordPress.
• GatsbyJS – GatsbyJS is a React and GraphQL-powered static site generator built for speed.
• Frontity – Frontity is a React framework for WordPress. Out of the box, it is set up to consume content from the WordPress REST API, giving developers a big head start by providing many of the most common queries already built-in.
• Strattic – Strattic is a static site generator and hosting platform tuned for WordPress.

When Decoupling is an Option

Some of the most relevant reasons developers choose a decoupled approach for complex WordPress projects include:

• Portability – The app or digital experience needs to be extremely portable or agnostic of the back-end technology.
• Diverse data sources – The app or digital experience pulls data from more than a small handful of sources, with WordPress being only one of those, and where the WordPress source is probably not the most central of those sources.
• Leveraging an existing JS-oriented dev team – Frequently, teams of JS developers, especially newly minted ones, want to build Node apps and leverage modern front-ends like React. While the current team’s capabilities are worth considering, this reason may or may not be outweighed by other factors. In addition, there is plenty of exciting work for modern JS developers to do within WordPress itself.
• Moving into the future of modern JS frameworks – Sometimes, teams want to leverage modern frameworks because the technology is newer, supports app-like behaviors natively in the browser, and it is relatively easy to hire qualified modern JS devs.  These are valid considerations, especially if there are other business reasons to invest in this capacity. However, it is crucial to avoid automatically assuming that modern JS does everything better, cheaper, or faster than WordPress’s mix of PHP and modern JS.

AccuWeather: Making Brilliant Use of Decoupling

This marriage of technologies is the result of leveraging the long-term stability of WordPress with its vast ecosystem with modern frameworks such as React. When used appropriately, this union enables the creation of brilliantly complex applications. One example of this in use is the extremely popular AccuWeather. 

AccuWeather is recognized as the most accurate source of weather forecasts and warnings in the world, serving roughly 1.5 billion people daily. The system comprises weather forecasts, local media partnerships, enterprise solutions, APIs, news, videos, podcasts, and weather data. 

AccuWeather uses a decoupled WordPress stack that includes over 750+ million WordPress requests per day and 50+ billion data calls per day. 

So what advantages were gained by AccuWeather moving to this architecture? 

1. By retaining the use of WordPress, they can utilize the backend UI/UX experience for the content team. While content is only one part of AccuWeather, it is an ever-growing piece of the brand and company. Using the WordPress backend, the editorial team can work with the most widely adopted and accessible CMS platform, which is used by 40% of the web.
2. By decoupling the front-end from the back-end, rapid site redesign was made possible without worrying about making massive changes to the platform’s CMS side. 
3. Finally, the decoupling makes the content easily accessible by other applications. Various development teams, such as app or enterprise teams, can present the content anywhere. For example, they can include a newsfeed with localized content in AccuWeather apps or present targeted video in a widget on a partner site. 

While AccuWeather makes extensive use of the REST API, many other companies and projects can benefit from utilizing and extending the REST API. For example:

• A vendor may utilize the API for large-scale content migration.
• A CMS dev team may extend the API to to create mobile apps, or facilitate communication that helps complete 3rd-party integrations.
• Much like Laravel, WordPress offers developers an extensible REST API framework. A company can easily add new routes and endpoints, giving them a more predictable and structured way to interact with site content or other backend data. They’ll spend less time building tools to access data, and more time creating better user experiences.

One Final Consideration

If all of this seems like the perfect solution for every future project, there’s one final thing to consider before making that jump. 

Decoupling requires a developer or team of developers throughout the entire lifecycle – Developers need to not only be involved in the creation of the project, but will also be needed to manage the site throughout its lifecycle. The client will rarely be able to manage this on their own. While many fully integrated WordPress websites can be left in the care of the site owner, a decoupled WordPress site is usually far too complex for the average site owner to maintain, keep updated, and ensure security and forward compatibility.

Decision Worksheet

Use an internal decision worksheet, such as the one we’ve provided here, to help determine if your project should move forward with a decoupled architecture or not. The more times you answer “No” to the questions, the more caution you should exercise before moving forward. You may still decide that decoupled is the best option, even if you’ve answered ‘No’ to many of the questions, but more deliberation might be needed in that instance.

The Best Choice For You

WordPress leverages the best of a stable, mature product with the promise of evolving with ever-changing modern technological future platforms. Some projects may benefit from the WordPress platform’s integrated approach, while others might require a decoupled architecture. When making decisions, consider the following:

1. Ask why – Identify the key drivers of your decision, and be honest about this. Are you choosing the more complex decoupling method because it’s the latest cool technology, or is it because it best serves the project?
2. Consider the total cost of ownership – The TCO over the whole project lifecycle, including multiple hosting, increased complexity, more technical debt, etc., may be significantly higher than you expect.
3. Look ahead – The landscape around JavaScript and WordPress is changing and expanding rapidly. Can you position your team and your application to thrive in the years and months to come?
4. Embrace JavaScript – Regardless of your decision to decouple or not, embracing JavaScript will enable you to do exciting things, even within WordPress internally. Learn JavaScript Deeply…still as true today as the day Matt first spoke those words.

Many factors will influence your decision, but WordPress will always be there, either integrated or decoupled, to move your project forward in the best possible way.

Written in collaboration with Donna Cavalier & Jason Caldwell from WordPress.com, and Ryan Sholin & Matt Perry and WordPress VIP.

State of the Word 2020: watch the recording

State of the Word 2020, an annual keynote delivered by WordPress project co-founder Matt Mullenweg, was streamed live on December 17th. Check the recording below to watch at your convenience. You can also watch it on the WordPress.org blog, Facebook, YouTube, or Twitter. 

Listen first-hand to all the cool improvements that have gone into WordPress this year, thanks to the contributions from thousands of developers and other WordPress enthusiasts from around the world. Also get a glimpse into what’s next for WordPress in 2021. If you develop, design, translate, own a site, or in any way connected with WordPress, then don’t miss it!

Sharing the Data: How Technical Women Navigate Their Career

In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers. We asked participants questions about how they saw their careers and next opportunities, as well as specifically asking about their reactions to our job postings. It’s easy to find advice on this topic, but the volume is overwhelming and the information is often conflicting. We wanted to cut through the vast quantity of Think Pieces On The Internet to make some changes based on actual data. Our goal, unsurprisingly, is to identify ways to increase gender representation on Automattic’s engineering teams. 

This was a fascinating process, and we are truly grateful to the 71 people who responded to our request for feedback. Given that we had this level of interest within just five days speaks to the relevance of the topic, as attracting contributors to a research project can often be far more of a challenge. While much of what we learned (discussed below) lines up with research you can find online, listening to people share their individual stories was profoundly impactful on our interviewers. It also revealed further insights that we are eager to apply. Automattic’s hiring team has been able to make some immediate changes, but have much more to think about, and expect this to influence our ongoing efforts.

Methodology

Out of our pool of 71 engineers, we conducted in-depth interviews with 14 participants, and a further 24 answered our follow up survey. The majority of our respondents had over 10 years experience working in software development, and around 60% of them had looked for a new job in the past year.  71% of our respondents were from the US, and all but one participant lived in English speaking countries. All participants self-identified as women or non-binary. The research process was very similar to that used in product user research. We described our initial rationale, invited contributions, used a consistent script, and vetted respondents to ensure the diversity of our interviewing pool. 

Results we expected?

• Respondents have strong networks that they use for job hunting and support.
• Respondents are most likely to leave a current role in search of growth – for example, Deutsche Bank discovered that women were leaving to take “bigger jobs” (DB’s term) , than they were offered internally, something that was addressed by adding a sponsorship program.
• Respondents carry out extensive research on companies before applying if they do not already have a personal connection in the organization, and are highly attuned to red flags. This matches what data shows on the experience of women in tech companies – in the Elephant in the Valley survey, 66% of women report being excluded from opportunities because of gender, 60% report being sexually harassed, and 60% of those who reported it were unhappy with the course of action. Womens’ career choices are too frequently based on avoiding a bad experience rather than seeking a place where they can thrive.
• Women in technical roles feel pushed onto the management track, and have to fight to continue to focus on technical work as individual contributors.
• Women receive a significant amount of personal outreach, and many have come to expect it. Generic requests from recruiters are unlikely to be successful.
• It’s important that other women are visible in the hiring process. Many women have experienced being “the only,” and at this point in their careers prefer that not to be the case.
• Hiring processes that are collaborative and responsive – a growth opportunity rather than purely evaluative – were perceived most favorably.
• Respondents care a lot about a respectful process. Responsiveness is a key metric, and was also a theme in interactions.

What was surprising?

• Respondents read job descriptions almost exclusively for red flags; for instance, they search for language encouraging all relevant employees (not just women)  to take parental leave.
• Glassdoor is not considered useful, being seen as mainly a place for negative reviews  by former employees or unsuccessful candidates.
• Many interviewees mentioned using Stack Overflow to look for jobs. We had previously advertised on that platform and discontinued it based on the demographics of applications it drove; diversity of applicants was even lower than the already too-low industry average (as also seen in their survey). However based on these findings, we are running another test on that platform.
• For some participants, interviewing is seen as a skill to maintain. These people are continually looking at job listings (though at a less-intensive level than a full job search), to ensure that they are aware of their options – before reaching a point where they’re desperate to leave their current position.
• Consistently being able to have an impact (including leadership opportunities) stood out as important, and they will leave their current role if they cannot find this. This is a key point related to research showing women are evaluated more on their past performance and men more on potential. 
• Women are looking for more communities focused on connecting to other senior women,  and around more technical topics (many communities focus on entry to mid-level folks). Concerns around online harassment can put women off trying to build their network online.
• Respondents look to have as much information as possible up front – about the job itself, salary ranges, the team they would join, and the hiring process, and expectations in terms of responsiveness.

What changes did we make?

• Existing work and life commitments mean that it is important to know the details of the hiring process at the outset: we have published a public page that clearly outlines our hiring process so that people have a concrete understanding of the expectations. We’ve also put together a more detailed document about what to expect during interviews, and will be creating similar materials for the other phases of our process.
• We are revisiting our employment branding strategy to take into account the extent of research by candidates, revamping our developer blog, collecting resources on what it’s like to work as a developer at Automattic.
• We are working on supporting our existing developers to increase their visibility externally, through encouraging them to write (our OSS culture goes beyond our willingness to share code), speak, and engage more in their communities. Many co-located companies use their office space to host community events, and it’s clear that is a smart strategy, because it builds employer brand, awareness, and personal connections between candidates and the host/prospective employer. We are looking to find a more distributed, office-less way to approach this.
• Historically, we’ve resisted asking existing under-indexed employees for second shift work – it’s a too-common reflex- to put the work of “diversity” ahead of and at the expense of those for whom we should be doing the work of “inclusion.” This research made it clear that the highest-leverage activity for our existing under-indexed employees was chatting with potential candidates, and we are making casual chats with other women more available to potentially interested applicants. We see this as more impactful than asking women in particular to interview. While this still amounts to asking for second shift work, we are aiming to identify the highest leverage activities and ask just for participation in those, rather than putting the full work of “diversity” on the diverse, and expecting them to do everything on top of their current job.
• We removed all the little games from our job posting page. We were trying to test people’s attention to the job posting and filter out unmotivated candidates; it turned out we were also putting people off who we want to apply.
• We removed all the language that emphasized that hiring is a competitive process -for instance, removing language about application volume.
• We will be testing adding “(Senior)” into all our technical job postings. Historically, we’ve been reticent to do this because it implied a job ladder that doesn’t exist at Automattic, but the research clarified that its absence sent the message that our positions are all mid-level roles without the path to growth that women candidates tend to look for. 
• We rewrote our job postings highlighting the learning and career opportunities for the candidate, rather than focusing on our needs.

What are we considering going forward?

Some of what we learned was less concretely applicable, or requires broader changes across our engineering organization.

We’re considering how to adjust our messaging with respect to D&I, and whether some of this messaging should be tailored to developers and D&I within the engineering organization specifically. We also need to consider how this interacts with the commitment to Open Source – the data shows that women are less likely to contribute to Open Source projects, in part because of the culture of many of these projects.

The best way to retain the women we have is to ensure that they have opportunities for growth outside of affinity networks. This is something we’re mindful of as we look to improve opportunities for growth across the organization. We’re also considering the research in Women Don’t Ask, and thinking about how to offer under-indexed folk opportunity, rather than expecting them to ask for it.

Another key area to explore is the importance of titles. As an organization, we have an unorthodox approach to job titles, promotions, and leveling; employees are free to create their own job titles, and promotion and leveling are holistic processes focused on the specific employee, their skills and development goals, and current team needs, rather than on a preconceived hierarchical chart. We hire only experienced engineers who will make the whole team better – the way they choose to do that is up to them and their team lead. Bringing in titles would be a significant change to the way we operate, potentially reduce our flexibility, and if not done carefully and thoughtfully would be destined to fail. We have to consider whether we can better facilitate growth, and make the opportunities for growth and recognition clearer in our job postings and hiring process.

Some changes we’ve made relating to this recently:

• We took a group of >20 team leads and developers to the Lead Developer event in London, and facilitated a day together. We will repeat this for US-based team leads in Austin later this year.
• We have started offering candidates the opportunity for one-on-one calls with a member of our Developer Experience team during later stages of our hiring process; we’re starting with under-indexed folks, with a view to rolling this out to everyone. These exist outside the regular hiring process, and is premised on the idea that it both provides an  opportunity for the applicant to ask any questions they have and for us to better understand their career goals and motivation so that we can assign them to the team that’s the best fit. 

It’s early for all of this, but we’re excited about the concrete changes we were already able to make, and the initial markers of progress we are tracking. As our Creed states, “I am in a marathon, not a sprint” – we have much more to do.

This project was a team effort from @sinitivity, @tobynieboer, @rlwilliams0803, @annahollandsmith, led and coordinated by @annezazu. You can find the official announcement and a more complete whitepaper here.

Leadership in Fully Remote Teams with Aaron Douglas

Aaron Douglas, one of our mobile team leads, has been with Automattic for six years. Almost immediately after starting here, he struggled to find the ability to focus and prioritize his work. He’s put significant effort into understanding how to change behaviors associated with Attention Deficit Disorder which have had numerous positive side effects. Those tools have evolved further over the last five years of him being a team lead. To share what he’s learned, he recently spoke at THAT Conference on August 8th in Wisconsin Dells, WI, USA. The conference describes itself as a “Summer Camp for Geeks”:

Over four days, folks of diverse technology backgrounds and expertise levels gather to take advantage of multiple learning mediums to maximize one’s community and career advancements.

Aaron chose to focus on leadership within fully remote teams since he’s been leading a team at Automattic for the last 5 years. As the description of his session states, “Remote working brings a whole set of challenges that should be addressed by every employee and it’s a good leader’s role to make sure nobody is blocked by them.”

To learn from Aaron and how he approaches remote team leadership with his unique background, check out his slides and reach out to him on Twitter if you have any questions. If you’re more of a visual learner, we’ve got you covered with this awesome sketchnote from an attendee at the conference:

#sketchnote from @astralbodies on #leadership protips in remote teams. I didn’t capture all of the wisdom nuggets. There was so much great info that I ran out of room! pic.twitter.com/VLkgEZZNDI

— Elysia Lock (@EvilDorkGirl) August 8, 2019

If you’re interested in getting a better understanding of Aaron’s personal experience working remotely and the impact it’s had, be sure to also watch his talk on WordPress.tv titled “How Working Remote Saved My Life”.

P.S. If you’d like to work with folks like Aaron, check out our jobs page! We’re hiring and would love to tackle problems together.

Automattic Developers at the Mid-Atlantic Developer Conference

Recently two of our developers, Brad Griffith and Jonathan Belcher, attended the Mid-Atlantic Developer Conference in Baltimore, Maryland. The conference is “designed to bring programmers from the region together, regardless of their choice of platform, for two full days of learning and community building”. We were excited to be able to show up, learn, connect, and share during the course of the two days. In the spirit of our creed’s “I will never stop learning” opening line, we were particularly keen to see what others had to teach us since the conference was not dedicated to any particular language, platform, or technology. Here’s some of the sessions that Jonathan and Brad enjoyed:

• Managing the Burnout Burndown
• Building a Mentoring Community through Live Coding
• The Coder’s Journey: Community and Gatekeepers
• Ethical Hacking for Development Teams
• Code is Not Neutral: Ethics of Web Development
• Office are Over: Lead a Remote Workforce in the Digital Age
• The Ethics of Innovation: Dark Patterns and Accessibility
• Lending Privilege

We were lucky to be able to share our own insights with those there as Brad gave a session on “Strategically Reusing Code”. Because we love to open source our work, we wanted to be sure to share links to Brad’s slides so you can learn from the comfort of wherever you might be in the world: 

Download Slides

Brad’s talk looks at how changes in the JavaScript and open source ecosystems can influence your decisions about which libraries, languages and platforms to adopt.  In the early days of the web, developers used libraries and tools to make JavaScript behave more like classical object-oriented languages and to isolate themselves from wildly incompatible proprietary browser platforms.  As JavaScript matured, developers began embracing it enthusiastically. Now, rather than attempting to isolate themselves from JavaScript, developers have embraced it in many contexts outside the browser, including on the server and in cross-platform mobile tools like React Native and Cordova.  

To those we had the chance to talk to at the conference, thanks for spending time with us!  

Growing JavaScript Skills with Grzegorz Ziółkowski

Recently, Grzegorz Ziółkowski, one of our developers who works full time on the open source project side of WordPress, spoke at the JavaScript for WordPress Conference on July 12th. As the name suggests, the conference was focused on JavaScript as it relates to the WordPress CMS and offered talks/workshops for folks no matter their skill level. Grzegorz focused in on helping bridge the gap between folks who have previously explored the welcoming world of WordPress and the new editing experience offered through Gutenberg.

We encourage you to check out the written version of his talk here to learn more and expand your own skills. From reading about the history of how Gutenberg came to be to sharing practical tips for how to improve the quality of your code, we think you’ll enjoy reading and learning alongside Grzegorz.

P.S. If you’d like to work with folks like Grzegorz, check out our jobs page! We’re hiring and would love to tackle problems together.

[Lead Developer Conference] Day Two

From 11-12 June, over 20 Automatticians attended the Lead Developer conference in London and we took extensive notes. At Automattic, we promote a culture of learning and our attendance at this conference provided some of our team leads with a valuable opportunity to reflect on and develop their own leadership tools.

If you are interested in Automattic and the roles we have available, we’re hiring!

---

Flavours of technical leadership

Pat Kua: Chief Scientist – N26 www.thekua.com @patkua

Talk Intro:

Over the many years, Patrick has trained, coached and mentored many engineers into Technical Leadership roles. He is delighted by the way that everyone has their own style and “flavour” of being a Technical Leader. In this talk, he will explore what technical leadership is and the impact people can have through their individual flavours of technical leadership.

Having run leadership courses many times for different people, there are many different types of technical leadership. We each have unique flavors, defining our own personal style.

Where do people demonstrate technical leadership?
How do people demonstrate technical leadership in typical patterns?

Leadership

“The ability to lead”. With Carol Dweck’s concept of the growth mindset, leadership is a trait that you can grow and develop.

“The act of leading a group of people ” It’s broad and inclusive. A single step or action of doing something and taking people with you. Anyone can be a leader. All you need to have is the courage to take action and this act of leadership.

There are four flavors of tech leadership:

The Knowledge cultivator

There is so much to learn: You simply can’t be an expert in everything.

Something that emerges from this ecosystem is that you have people who enjoy helping others to learn. They look for and create opportunities for learning. This act of leadership is really important. It has a big impact.

What does this person get as a result? It isn’t a zero sum game. It’s not like they are taking something from you. When you teach, you end up learning things more deeply: The Famen learning technique.

The Advocate

An interesting side effect of learning is making mistakes. A consequence of mistakes is that there are often pain points that teams feel. Some people notice this, listen to the pain points from different perspectives and decide to do something about it.

“What’s troubling you about X?”

“What do you think about Y?”

“How would you solve this if you had time?”

This act of leadership needs to get buy-in for the solution and influence people to get buy-in that this is something worth doing.

People who take on this leadership role often possess relentless patience.

The Connector

You may think of organizations as hierarchies, but they can be thought of as networks.

Sponsor someone. Invest social capital. Lend your privilege.

“Let me introduce you to X”

“Y can help you with this”

To be a good connector, you need to think about your reputation score

The Storyteller

These are people who can inspire and contextualize things for others.

People who can create the vision and bring people along the journey

There are many flavors of tech leadership – the only limitation is yourself. It’s about creating an environment for people to thrive. It’s about remembering that everyone has their own style and invest in helping people find their own flavor.

---

Business as usual: how to stop drowning and learn to swim

Jonathan Stott: Technical Architect – Royal Pharmaceutical Society www.rpharms.com @jonathan_stott

Talk Intro:

One of the challenges facing teams, particularly small ones, is having to balance the time spent on doing fun new things and having to support old (or antique!) systems and processes. These are the ‘business as usual’ (BAU) things which probably underpin the current revenue of your business. As such they are critically important but are almost certainly unloved and possibly even loathed by the teams responsible for them! BAU includes fixing bugs, handling support problems, running regular or ad hoc processes, and dealing with legacy systems amongst other things.

You will learn: how and when to say no; when to take time to fix and optimise; how to deal with a deluge of BAU; how to manage people working on BAU; and what we experienced when we were getting it wrong and finally when we got it right!

This is a story about the team maintaining Business As Usual (BAU) whilst working on projects

The one with the problem

What is Business As Usual?

• Customer support
• Infrastructure maintenance
• DB Admin
• Bug fixing
• Legacy code
• Manual processes

It is also:

• not interesting
• distraction
• “beneath me”
• keeps the lights on
• urgent – someone might die!

Why is BAU a challenge?

• Overwhelming – it feels like there’s no way to see beyond
• Overlooked – not enough time allocated because of other stuff
• Poor use of skills – people doing it need to be engaged enough
• Cause of stress – have to do a lot of extra work to keep on top of the BAU workload
• Increase turnover – more leave than you expect
• Can feel insurmountable – can’t see a way beyond

BAU: 20% to 100% of the time: there are lots of systems and services to support.

Because of problem domain, quality and precision are very important.

There was once a situation when the team couldn’t start a project for 12 months because couldn’t get around the BAU.

The one with the Kiwi

This is a token that sat on someone’s desk to say you could come and ask them about problems; that the person who held the kiwi was dealing with BAU. Everyone in the team – without exception – got to experience the BAU work: learning and sharing the knowledge.

• You have to support the person doing looking after the BAU, especially if documentation is not good.
• Don’t plan for people scheduled to do BAU to do anything else but BAU.
• Have to ensure you are fair: if someone has leave booked for the BAU time, they have to pick up their BAU responsibilities when they return.

The one with the project that will not start

There are times when you feel you are drowning in BAU. More than you can do with the number of people in your team. There were times when they had to say no.

• They needed a really rigorous triage process.
• They had to dig into what’s important vs what’s urgent.
• They had to do it again and to make sure they were really sure.
• They had to do a risk assessment of the work – what’s the impact of things not being done?
• They ringfenced one person, then limited them to only doing that.
• They contracted some stuff out – however it was hard to contract out BAU, mainly because of lack of documentation. But they knew they shouldn’t give all the fun work to contractors.
• They looked for some common aims. They figured out value for doing things.

The one where everyone leaves

They prepared for the worst scenario. What would you do if everyone but you leaves. What happens if you leave, and the rest of your team have to do the stuff that only you know?

• Three “ations” – documentation / simplification / automation.
• Documentation – write everything down. People don’t like it but it’s important.
• Simplification – question everything that you’re doing. Does everything you do have value? Just because it’s been done before doesn’t mean it has to be done again.
• Automation – think about when you should be automating it. Processes stick around for longer than you expect, so think about that when you think about time saved. It is not just about time saved, also about quality: fewer human errors.

The one where the leopard changes its spots

BAU became a toxic term. So, they rebranded it to “supported maintenance”

• They took the opportunity to consider the situation and changes priorities about how they managed this work.
• This meant not just changing the logo.
• How would you go through a corporate rebranding process? The whole business had to be involved in the mission, goals, values and tone.
• The tone is interesting – how you communicate things, do you communicate in a way that other people can understand.

The one where we fixed some things

This was a period of consolidation. It was a process where the whole team looked at what can be improved.

• It started with a list of ideas, then the team prioritized and decided upon each point.
• The team is main product owner for consolidation work.
• But they couldn’t neglect stakeholders within the rest of the business.
• They worked on bug fixing, refactoring, work on “ations”
• They identified things that would allow the team to learn.
• It was important to repeat this process: it is not a one-time only thing.
• They still have to focus on BAU whilst consolidating – it does not go away immediately.
• What they decided upon had to be achievable: it had to be broken down into smaller tasks like planning a sprint.
• They needed to be able to finish what they decided upon in the time they had.

The one with the new role

They hired a technical support engineer – main focus of this role is to do the BAU, and improve it over time.

• They had an unwritten goal: the Technical Support Engineer was tasked to automate themselves out of the role altogether and become a developer: this created a progression opportunity
• That became the transition path from technical support engineer to developer.
• It was a fantastic job to do if they were new: they learned a lot, and got involved in everything.
• Because of that, it can be fun. The person has some independent identification or problems, solutions and autonomy. It was a great way to motivate.
• The greatest effect of this role was that it unblocks the team.
• This role would still needed support so they introduced mentors

The one with the cliff-hanger

• There were no silver bullets or magic wands but the process introduced lots of inspiration
• It’s important not to stick with one approach forever
• Processes must evolve and adapt over time
• Don’t lose heart!
• It might be frustrating but patience and motivation will pay dividends

---

Behind the scenes of an effective & inclusive hiring process

Ola Sitarska: VP of Engineering – Verve @olasitarska

Talk Intro:

In my role as a VP of Engineering at a fast-growing startup, I spent hundreds of hours interviewing and sourcing candidates in the last year alone. The bar we set ourselves was high: not just hire people with excellent skills and culture add, but also maintain and improve our current diversity (33% women, 9% people of color) across experience levels. The result of that is an inclusive and effective hiring process that lets us successfully grow the team while providing a great candidate experience. Even candidates who reject our offers end up recommend us to their friends! This talk will take you through a step-by-step hands-on guide on improving your skills as an interviewer and setting up a better hiring process at your company – no matter how large or tiny.

In the current role:

• They grew team from 10-35 in 12 months
• This included 30% gender minorities, 13% PoC
• There is a 40/60 gender split in technical leadership

The objectives were:

• The process had to be inclusive: measurable and objective evaluation to eliminate bias
• Excellent candidate experience is a priority
• It was vital to hire the right candidate for us: our environment and culture.

They were a very small startup, with no ‘big name’ or reputation to rely on. So candidate experience was a priority – particularly when they were being evaluated against bigger, more well known brands. They had to show their best selves.

Process:

• Define the right candidate and build the pipeline
• Design how you gather and evaluate information
• Set your candidate up for success.

Defining candidate:

• You can look for people who are like the good people who are currently in roles
• Be aware of asking for too many requirements: this excludes people who took a different path in life
• Be certain that requirements aren’t eliminating people with more diverse backgrounds
• Be mindful that women hold themselves to higher standards (they tend to only apply if they meet 100% of the criteria), so don’t include requirements that aren’t necessary.
• The best indicator of someone performing well is evidence they successfully did similar work in a similar environment.

Define what the job is:

• Hire people who have done it before.
• “Performance profile” – drop the list of requirements, instead list expectations of the role. Illustrate what success look like.
• Help candidates self select out of the process – maybe can do it but don’t want to.
• Be transparent about salary range.
• Build representative pipeline:

1. Inclusive practices and culture will attract diverse candidates
2. Hire diverse candidates into leadership first
3. Invest in outreach

In a homogeneous culture we have to work harder to prove broader spectrum of people can be successful. Building a diverse pipeline is hard work.

Gather and evaluate:

• Define what information you need
• Decide how you’ll gather that information
• Ensure the efficiency of this process
• Ensure it’s relevant to your job
• Fight your biases

The process became:

Phone screen:

• 30 minutes to assess the candidate is looking for what we can offer them, and has relevant experience.
• Get them excited about the company and set expectations.

Coding test:

• Assess that the candidate can solve a simple problem that they’d find at work, in a similar environment.
• They asked for code review to understand values alignment and communication style. They assessed that the candidate could solve a simple problem that they’d find at work, in a similar environment.
• Give them feedback.

Interview:

• †The candidate was invited in for an interview: this was time-boxed to 2.5 hours in order to respect the candidate’s time.
• Here they outlined how things within the organization work and explained the sort of candidate they were looking for.
• The candidate’s work history was explored, in order to try and gather relevant evidence of them being successful, and to ensure they have been doing it in a similar enough environment.
• They asked questions requiring real stories and evidence: not just theory.

Eliminating bias:

The code test was blind code review:

• Test is uploaded, and all identifying information is removed
• The scorecard in held in a spreadsheet, ensuring that each engineer that reviews code test is consistent with the rest.

Interview:

• Having a representative panel is important as it ensured a representative decision.
• An evidence based scorecard was used, with a standardized list of outcomes
• In the interview they had one person leading, whilst the others focused on listening.

Debrief:

• Always ask for evidence
• Always consider facts, not opinions

It is important to use the same rubric for evaluating both candidates and employees. Performance on the job should have the same expectations as at the interview stage.

Set your candidate up for success:

• Remember that it’s a two-way street. The candidate is also evaluating you.
• Try to minimize the stress – interviews are stressful, but people generally perform better when they are not stressed.
• Genuinely care about their experience.
• Give the candidate their preferred time, and be efficient.
• Don’t create artificial deadlines.
• Get back quickly and with useful feedback.

You’ve nailed the candidate interview experience when they reject your offer but still recommend you to their friends.

Start improving tomorrow:

• Get clear what success looks like
• Make your code test more relevant
• Blind review code test
• List 10 examples of evidence of previous experience you need
• Create a template to score all candidates against the same 5 criteria
• Evaluate if you can make your process shorter

---

Mobile development in 2019: native versus cross-platform

Miriam Busch: CTO – Karlmax Berlin GmbH & Co. KG @miphoni

Talk Intro:

We’re 10 years into Android and iOS development and there are more ways to build an app than ever before.

Let’s look at the options, be it native app development or cross-platform systems like Xamarin, ReactNative or Flutter: What is core to these frameworks? What implications do they bring to your product and your development team?

We are now more than a decade into iOS and Android development.

Developers for mobile are becoming more and more specialized.

Is there a simpler way?

Let’s visit 4 alternatives

React Native

This was created by Facebook: UI and logic created in JavaScript. It is not web view based, and the rendering is done by native components. There’s a rendering bridge that components need to cross, meaning that there are some limitations and performance issues. But developers still use native for some UI. The core of RN is currently being rewritten, but it won’t be ready this year.

Xamarin

This brings C# and .net development to mobile. The logic is in C#, native UI components. When Xamarin forms are introduced, a shared UI is possible for both platforms.

Flutter

This was introduced by Google in 2017. The UI and logic is written in Dart, and is shared between both platforms. The Flutter engine does all the rendering, but has a rewrite of UI components.

Kotlin

This is multi-platform, more lightweight. It shares logic written in Kotlin, and the UI written for both platforms. We can use Kotlin multi-platform libraries for networking etc.

When the team first switched to multi-platform, it was a relief. There was no longer a need to write things twice, and platform bugs became the exception.

But there is no such thing as a free lunch

Although they removed the need to do everything twice, they introduced a new complexity due to the inherent architecture of the system. For example, rendering the bridge in RN, bundling .net with your app, and the Flutter user experience. It feels like it’s still early for the platform, and the cross platform system will always lag behind.

Should we be supporting 3 platforms instead of 2? Airbnb gave this reason for sun-setting RN support. It’s important to remember that you still need specialists!

Cross platform thinking

This is not just about technology but taking ownership for those platforms. Even if you’re just sticking with two platforms you can still encourage cross platform thinking.

The answer?

It depends! Miriam’s team decided on Flutter, but it depends on the individual business needs.

---

Leading the team through a rapid growth

Joanna Chwastowska: Engineering Lead – Google DeepMind Health

Talk Intro:

Team leadership and technical leadership come with a variety of challenges and require various skills. One of them is an insightful future outlook and being ready for what’s yet to come. Working on a new project, or joining a startup – there’s an expectation for your team to grow. Growth is good. The more hands on board, the more you can achieve. But it’s not all roses. In this talk we’ll look at challenges and risks related to the fast growth of an engineering and cross-functional team. How to notice the first signs of the change? When to react? How to keep your team’s culture when growing? What will have to change, what can stay the same? Summarizing past experiences – from bootstrapping a remote team from zero to 20 people, as well as growing DeepMind Health engineering team from 20 to 80 in a bit over a year – there are patterns emerging that can help other teams avoid pitfalls that come naturally with a rapid growth. At the end of this talk you should be aware of what changes to expect as your team grows, how to notice critical inflection points, and react to them so your team comes out bigger and stronger.

The reality is that most hospital systems aren’t as advanced as they could be, nor are they operating well with each other

With a mix of paper records and many systems — how do you make a dashboard?

A Pager is a very primitive version of a mobile phone – it only displays the number that is trying to reach you. A Doctor would come out of surgery with 20 pages. They can’t know who needs them or why. Someone might be dying!

Even in leading hospitals technology is not what it should be. They will say they use “mobile technology” but what they have is called “computer on wheels”.

In 2016 a few people started to look into whether it’s possible to create a mobile app to deliver important info to clinicians, nurses and doctors, and improve the delivery of healthcare. The good news was yes it’s possible – and this is now in live deployment in two hospitals in London.

The spectrum of what can be addressed is so broad, but they needed to start with something small enough and traceable enough that it can be measured.

The team developed an app to quickly diagnose Acute Kidney Injury by measuring blood samples and alerting staff when symptoms existed – proving that it is definitely *possible* to focus and deliver impact.

The report says that technical interventions give them 2 extra hours a day face time with patients.

The team quickly went from a few people to a hundred and fifty.

Scaling

From start up to an established team, what were the important aspects:

• Be super clear about trade-offs in technical design.
• Google operates at scale. But start ups need to move fast and evaluate.
• Through that fast evaluation, learn and find your niche in the market.
• This does not go well with technical scale.
• You will start accumulating technical debt, it won’t go away on it’s own you will have to address it.
  • Approach technical debt: put it off, or constantly think about it.
  • Either approach is fine, but be intentional.
  • Know the domain.
  • Have the time now or in the future.
  • It is not just leadership that needs to understand, the team needs to be on the same page.
  • How risk tolerant and how error tolerant are you?
  • In regulated environments, you probably cannot afford risk of leaking user’s data.

From day one, build with quality, security and privacy in mind.

• It can’t be applied as another layer.
• Security and privacy is something you build on from ground up.
• It is crucial for financial or medical information.
• Hire an expert, and include them in conversations.

Put the team at the heart of everything.

• They are the most important asset of your company.
• It is easy to forget this in times of fast growth. It started from everyone knowing and trusting everyone.
• You add one person at a time, but soon you realize you don’t know some people on your team.
• Hire responsibly. Whenever you hire a new person, make sure you need them – don’t just hire because you can.
• Scrappiness forces focus on the most important thing.
• Don’t lower your hiring bar.
• Be intentional about diversity. It is tempting to hire what is on the market, but think about the team you are building.Who do you want on that team? What will the team need to deliver on?
• Look out for signs of team burnout. It is easy to focus on just the next deadline. We have to learn to work in a sustainable way.
• People should be able to deliver results and live their life at the same time.
• Monitor for team psychological safety. It is easy to lose the sense of the culture of the team: are people feeling safe? Can they question decisions?
• It is important that people feel appreciated.
• Communication: it is not just about making it open and intentional. It is about how you scale your communication as the team grows. We need to build mechanisms for teams and roles to communicate across.
• Ensure that you, as a leader, understand how your team feels, and how people perceive decisions. If this communication breaks down, you will not know what is happening on the ground.
• Be clear on the goal – not just you and leadership, but the whole team needs to know what’s happening.
• Care for people. Other things may change, but if you have a strong group of people who can build things together, that is the biggest power you have.

---

Facilitation techniques 202

Neha Batra: Engineering Manager – GitHub medium.com/@nerdneha @nerdneha

Talk Intro:

We’ve all had that experience where we’ve planned the perfect discussion only to have it hijacked by a passionate side-person, lose focus halfway through, or produce the exact same takeaways as you had before you began the discussion. With a few tricks in your back pocket, you can recover from some of these tricky situations or even prevent them in the first place! I’ll share some of my best techniques and provide some yellow flags I’ve learned to recognize that signified needing to make a change.

Set the stage

• When facilitating an event, come in 30 minutes before the meeting to prepare. Think about what is on the desk and the messages that they are conveying to the delegates.
• The use of chairs allows for the facilitator to transition between roles.
• Agendas are great for aligning goals and packing in the information needed for inclusive audiences
• Start and end times – identifies when people need to speak and what they need to speak about
• Include breaks – human care, allows thinking time after important points are made
• Check off the items of the agenda as you’ve completed them
• Keep people to their time slot
• Have a ‘Go’ bag containing materials (post its, markers, erasers etc)

Engage your group

• Sharing – sharing ideas, thoughts and feelings
• Struggles – identifying challenges
• Solutions – finding fixes to the challenges
• Action items – identifying action-based tasks

Exercises may include (and should be shared ahead of time to allow for personal preparation):

• Splitting into pairs
• Share back
• Writing
• Contributing

Facilitating vs talking (assign roles to others who are keen)

As facilitator, you shouldn’t need to do all the talking throughout the meeting. Be careful how to phrase your questions to ensure others engage and do more of the talking!

Include all personalities

• Steam rollers vs quieter folks
• Post-its and round robins
• Museum walks – present ideas through flipcharts and have everyone walk round and ask clarifying questions
• Share 1 idea
• Dot vote – good to see what people want to prioritise
• Breakout groups
• Time to think before sharing
• Rule: let 3 people speak before you speak again
• Take a break when things get heated
• Retros using post-its and dot votes

Finish with a bang

• Appreciations
• Retros
• Swag/memorabilia

Challenge Tweet: what is the one thing you want to try at your next meeting

---

A button to pause time: how to live outside the clock

Sal Freudenberg: Chief Being Sal Officer – Cucumber Ltd salfreudenberg.wordpress.com @SalFreudenberg

Clare Sudbery: Lead Consultant Developer – ThoughtWorks medium.com/a-woman-in-technology @claresudbery

Talk Intro:

How does time impact on your working day? Would you like to hack time and live outside the clock? The answer is likely to be yes.

In October 2018, Sal and Clare took an all-female team to Hack Manchester, built a time machine and won Best in Show. They are now taking their time machine on tour: You too can press the button and stop time. Have a nap, play tricks on your friends, or force the trains to be on time.

Seriously though, repeated research has suggested the straitjacket of standard working hours does us all no good at all. Nor does the “always on” culture perpetuated by the speed of innovation and delivery in the world of software development. Yet we are all still stuck in our rigid working cultures. This light-hearted talk has a serious message: Don’t assume your teams have to be imprisoned by time. Try a little experimentation and see what a difference you can make when you play with expectations and give your people some time-based freedom.

Time travel for the win!

At Hack Manchester, the team were dedicated to self-care, instead of pushing themselves too far, eating unhealthy and staying up too late. They all rested and slept. They undertook a lightweight form of Agile. They used story maps. They had 1 hour iterations, involving 45 mins working, 5 mins retro review, 5 mins break away from desk.

So why didn’t everyone do this?

Not enough sleep

We don’t always want to sleep because we want more time to do things. But then we pay for it the next day.

Humans sleep in cycles that typically last 90 mins long

The SleepCycle App can be installed on your phone. Here, your phone ‘listens’ to breathing and moving, and it deduces sleep cycles from this.

Why do we need to sleep?

Sleep deficiency affects mood, learning, focus, reactions and emotions. It creates lots of physical and mental health issues.

Humanity is bartering the most blessed thing there is: sleeping

Larks vs owls

Larks are early risers and owls prefer to work late into the night

Most people fall into one of these categories, but some can fall in the middle of these two

Larks are in the majority which is not surprising given the society we live in. We think owls are a bit lazy for not getting up in the morning. But from an evolutionary psychology perspective, it makes sense to have people who need to sleep at different times: it reduces the hours of vulnerability.

Spoon theory

If we start the day with 12 spoons and each tasks uses a certain amount of spoons, there will come a point in the day when we run out of spoons. This has been adopted by the neurodiverse community. It demonstrates the need to recharge. But don’t forget that we can’t calibrate spoons between different people: different activities take up different ‘spoons’ for different people.

Flexible working

Sleep matters, rest matters and being a parent can confuse this.

It is important to give parents the flexibility to do wrap around care

And it’s not just about parents: we should be allowing all people to work flexible hours. It allows for self-care, caring responsibilities, or for just getting the boiler fixed.

If you don’t pay attention to people, they will lie to you, and say they are fine when they’re not. This can cause absenteeism and disengagement.

Structured Days

However, not everyone works well with the concept of a flexible day and structure is key for them…..it important to not create an environment of exclusion when trying to encourage inclusion.

So what works and what’s needed?

Self awareness

Self care

Empowerment: be flexible about flexibility

Clocks and time does not have to be our master – everyone has different needs and these should be acknowledged and addressed

---

[Lead Developer Conference] Day One

From 11-12 June, over 20 Automatticians attended the Lead Developer conference in London and we took extensive notes. At Automattic, we promote a culture of learning and our attendance at this conference provided some of our team leads with a valuable opportunity to reflect on and develop their own leadership tools.

If you are interested in Automattic and the roles we have available, we’re hiring!

---

Navigating Team Friction

Lara Hogan: Co-founder – Wherewithall

• @lara_hogan
• larahogan.me/blog

Talk Intro:

Friction is a common, and necessary, part of team growth—but when left unchecked, team friction is unhealthy for you, your coworkers, your company, and ultimately your end users.

In this presentation, I draw on my experiences at organizations large and small to illuminate the sources of team tension, how you can better understand and manage unexpected teammate reactions, and the best ways to give actionable feedback without escalating drama. Your coworkers, your organization, your users, and you will reap the benefits.

---

A study found that even when surgeons rotated shifts to different hospitals, only get better in their own hospital. This suggests that teams are crucial.

Teams of humans are amazing. Groups of people coming together to ship things is amazing.

Bruce Tuckman talks about the theory of group dynamics and the stages of group development:

• Forming: team has a name, some understanding of why they are there.
• Storming: start to see some friction. Clashing and confusion.
• Norming: things start to iron out, resolve difference, start to find groove.
• Performing: things are really smooth.

This process occurs every time the team changes, but storming is so painful. But it is critical – we can’t get to norming except through that stage. We have to feel equipped to handle it.

Brains

Pre-frontal cortex – deep, complex problem solving

Amygdala – gather data from the environment and figure out threat.

If enough threat, the amygdala shuts down pre-frontal cortex and takes over.

When the amygdala hijacks at work it is not useful. It responds to perceived threats even outside physical safety.

Human beings have six core needs to feel secure at work:

• Community, connection.
• Improvement / progress.
• Choice – flexibility, autonomy, decision making.
• Equality / Fairness.
• Predictability – resources, time, direction, future challenges.
• Significance – status, visibility, recognition.

Not all core needs are equally important to everyone.

Feedback

Humans are mostly terrible at giving feedback. We are also mostly terrible at preparing to receive feedback.

We are afraid of having our core needs challenged.

Feedback of equation:

• Observation of behavior – not about what you feel or assume. Factual.
• Impact – describe something they care about.
• Question or request – ask genuinely curious open question, help them to determine the way forward.

We should ask about their preferred feedback medium.

Team Processes

Each teammate has a different way of working. The important thing here is whatever your processes are, that you’re iterating on them, and that they are working for everyone.

Retrospectives help, as it creates a habit of talking about team health. They can help us meet core needs.

People who are willing to acknowledge their own failures are more trusted.

Team charters and docs give clarity about what’s expected of us. Having a mission makes it easier to give feedback on things that don’t align.

Throughout this process take care of yourself, and do what you need to do to distance yourself from an unsafe environment. If you aren’t sure if it’s time to walk away, speak to someone you trust.

Team health is a cycle. Team health is a thing you can continually improve.

---

12/10, Excellent doggo: the power of positive transformation

Heidi Waterhouse

Developer Advocate – LaunchDarkly

• @wiredferret
• heidiwaterhouse.com

Talk Intro:

How many talks, articles, and podcasts have you seen about organizational change, and how to implement it? How many of them talked about what we can learn from non-human psychology? This is that talk.

I’ll give you concrete and actionable advice for how to make change happen in your organization, one person at a time, by being nice. Make it rewarding to do the right thing, and people will do the right thing more often. Understand that people are motivated by different things and you’ll be able to talk to them more effectively. Inspirational leadership can only get us so far, and we can do the rest with hard work, consistency, and compassion.

---

It hurts to get fired and it’s hard to talk about. But dignity is for people who aren’t conference speakers.

What would your work life be like if you, and the person who reports to you, and the person who you report to you, had shared goals that you could agree on?

How do you get developers to write docs?

• Very few devs like writing docs
• Very few managers are good at getting people to do something they hate to do

Have you ever fired a dev for writing insufficient docs? This never happens.

Have you ever promoted someone for writing excellent docs? Maybe once in a while.

If you say you want it but you don’t reward it, and you don’t punish it, you don’t really want it.

Behavior: team effort to meet a shared goal.

Positive or training shaping isn’t new: from how you teach whales to jump through hoops, to getting cats to act in movies. At the simplest level: the trainer offers a reward until trainee starts offering the behavior spontaneously. They train to exhibit the behavior after a cue.

Dogs used to be trained using shock collars and by yelling at them.

We trained children and employees in the same way (but fewer shocks). You can get the good behavior, but not the good relationship.

Have you had that manager who criticizes you all the time? We then give them rent free space in our head.

Instead we should be incentivizing the good behaviors through using reward. This rewards the good behavior.

A lot of what we call goals are a set of interdependent behaviors and decisions. We have to be clear about what the atomic unit of a goal is. What is the minimum viable behavior that we are going to reward? the goals for other people are just as relevant, but often conflicted.

So how do we change behaviors? How do we make developers write documentation?

• Can’t achieve anything without knowing what we’re aiming for.
• Everyone has goals.
• Not all of us are clear about our goals
• We must respect others’ goals.

When you look at your goals, are you sure you know what you’re doing? What they’re used for? If you don’t have that alignment, then you might do the wrong thing.

Trying to do a lot of things at once is overwhelming. You don’t (usually) learn to swim by being thrown in a lake. Complex movements, need to be taught and learned incrementally.

We should break tasks down into things that can be rewarded. Then, the person doing the thing needs to choose their own reward. It needs to be meaningful for them. When trying to motivate someone, it’s important to ask them what they want, what would make them happy.

Successive Approximation:

Dr Skinner trained pigeons to drop bombs accurately. You can teach almost anything to almost anyone if you can figure out how to ask for it in small enough increments with enough reward.

We invest a lot in thinking about ourselves as positive and rational beings. We’re not rational, we’re just playing rational on TV. People mostly do what they get rewarded for and avoid doing things they get punished for.

Writing documentation is too big

A blank page is the abyss.

Try creating a template: then they are not writing documents, but answering questions.

Some things to remember:

• Think clearly about everyone’s goals: if you can’t write it down, it’s amorphous and squishy and no good. If you write it down and it looks like it came from a management book, it’s still no good.
• Figure out rewards together.
• Commit for the long term. Do it consistently until it becomes intrinsically rewarding, not just extrinsically rewarding.

---

Engage teams to achieve high performance

José Caldeira: Head of Development – OutSystems www.outsystems.com

Talk Intro:

When bootstrapping new teams, they need to go through the standard process of forming, storming, norming and performing. And in the context of fast-growing companies, with their own level of uncertainty, how can we achieve high performance when teams and goals are constantly changing? How do teams deal with different degrees of uncertainty? And how can leaders support them in feeling safe and motivated?

Throughout the years, I’ve found some ways to help teams achieve this. Some of those were a direct result of my experience, others were inspired by my peers and other companies, and others I was able to derive from coaching sports or teaching people. In this session, we’ll talk about some of the ideas leaders can implement to help teams move faster into high performance.

---

Teams can achieve high performance in 5 steps:

1. Identify Goal

Sports psychologists agree that high performance is connected to highly intense goals. So how do we engage the team? The goals we decide upon must have impact and meaning.

We must define the goals that will be memorable:

Bold… not reckless

Crisp… not fuzzy

Impact… not vanity

Simple… not complex

2.Constraints

Definition of the goal then creates a sense of control. By encouraging teammates onto a project, we create a personal development opportunity: 

Embrace… don’t fight it

Impose… don’t wait

Mandatory… not optional

3. Principles

Principles must be agreed upon and aligned within the team

Options… not restrictions

Align… don’t impose

Focus… not an obstacle

Fast… not slow

4. Pitch

We need to sell everything – we need to remember that the goal should create a sense of urgency.

We create a positive message in order to sell and motivate

Energize… don’t discourage

Promote… don’t wait

Consistent… not occasional

5. Storytelling

Humans use storytelling to pass to the next generation. We can use the same strategy but we must remember that creating engagement shouldn’t involve creating a lie

Empathy… not a report

Path… not the result

Truth… don’t lie

In summary:

• Create memorable goals
• Creativity through constraints
• Autonomy through principles
• Motivation by pitching
• Engagement by telling stories

---

Bottoms up with OKRs

Whitney O’Banner: Engineering Manager – Braintree @woobanner

Talk Intro:

In 2013, Google famously published a leading reference for establishing Objectives and Key Results as a way to align teams and set short-term goals. While some of the information is still relevant, it is time to take a fresh look at setting OKRs within your teams. This talk will help leaders abandon the dated, flawed approach to setting OKRs and enable organizational alignment in an exciting new way, suitable for 2019.

OKRs are commonly used, but they produce variable results in both experience effectiveness.

e.g. ‘We want to improve accessibility as measured by 75% WCAG compliance’

Objectives and Key Results

We set goals

We align teams in a shared vision

We quantify progress

We will <objective> as measured by <key result>

It is often introduced from the mindset that we know how to do this well, but most of us don’t.

Here are three brief but key strategies to adopt:

TIP: Skip Individual OKRs

Try tasks instead

Remember that company level objectives are not individual tasks

Individual OKRs are like corporate meetings, they slow us down and don’t give value. Skip the big picture and instead focus on the individual. If not, they will turn into tasks or micromanagement, and become less about alignment.

Try to move from team level OKRs to tasks, initiatives, projects. Your team will love you, because they want to focus on the work. This empowers employers with priorities.

TIP: Ignore metrics, focus on the outcomes

It was discovered that a lot of what they thought mattered was not being measured. Most key results were “swags” – sophisticated wild ass guess. Is it reasonable? Feasible? Achievable? Good? No one knew. They spent a quarter hitting baselines, instead of hitting goals.

Instead, forget the numbers, and concentrate on the measurable outcome

Re-evaluate this once you understand what your team is capable of

e.g. improve accessibility as measured by WCAG compliance: start with general outcomes, and after a couple of quarters then you can set some stretch goals.

TIP: Avoid cascading goals: take a bottoms up approach

This takes way too much time and stifles innovation. HBR found that most managers overvalue their ideas by 42%. Front line employees undervalue theirs by 11%.

Instead, take a bottoms up approach. It helps spark innovation and fosters the best ideas if employees can understand how they can build impact.

Recap:

Try tasks

Focus on outcomes

Take a bottoms up approach

---

Guiding self-organizing teams

Rebecca Hill: Frontend Engineer and Team Lead – WeTransfer rebeccahill.co.nz @rebekaka

Talk Intro:

It’s all well and good for the agile manifesto to recommend self-organizing teams, but what does that actually mean in practice? What’s the best way to do it, how far should you take it? Total anarchy is probably not the answer here… right?

After bouncing around leading a whole bunch of teams of different shapes and sizes over my career, I have some insights into how to guide effective self-organization and create amazing teams. I’ll also share plenty of battle stories, including major re-organizations of entire engineering departments, structured completely by the developers in them.

Whether your entire department needs shuffling, you’re starting a new team, or just adding a new team member, you should walk away with plenty of ideas of how to guide your team to make the best possible decisions – for themselves.

Self organizing teams is an umbrella term for a spectrum of team organizing styles:

• self governing – set direction, design the team, manage work, execute tasks
• self forming – design the team, manage work, execute tasks
• self organizing – manage work, execute tasks

Then, more traditional manager led teams – just executing tasks.

#bestteamever

Rebecca lead a team of mainly brand new people to the company. This was a rare opportunity to start from scratch:

• here was a group of people who cared about each other
• who wanted continuously to get stuff done
• wanted to have fun doing it

How long do you think it would take? A couple of months?

They started off with sessions to figure out how to work together, and everything up was up for the team to decide. Having everyone decide this stuff together was very powerful, and it meant that everyone was really invested.

The team would advocate for standard structure and keep iterating on it. They kept a team agreement document – this helped with onboarding.

They talked about values. The top two were motivation and honesty.

They chose team name together: picked Cosmos.

They felt really optimistic… but then shipped a bunch of bugs. They were too new to the code base and each other.

They ended up with people struggling to work with each other, and with people from other teams.

They began taking part in workshops on active listening. It is a simple concept, but how rare is it to feel fully listened to! They got good at asking questions and listening to the answers. They began to give specific feedback. It’s important not to forget to challenge your high performers – you should be spending as much time on them as everyone else on the team.

Do not underestimate the amount of time good leadership and management. When you have a responsibility towards people, they have to come first. If you’re struggling, look after fewer people, don’t just look after the people you have less.

Remember to authentically celebrate success.

Be positive.

Don’t fake it, but do make the time to give praise and positive feedback.

Did they reach the vision?

No.

But that’s because the vision was whack.

That vision of perfection? NO.

The vision of #BestTeamEver? Hell yes!

In summary

• People come first
• They take time
• They are worth it

---

What I learnt about hiring diverse teams from conducting a fully-anonymous recruitment process

Bethan Vincent: Head of Marketing – Netsells www.netsells.co.uk @bethanvincent

If we want to truly encourage diversity in our industry, we are going to have to listen and respond to feedback from under-represented groups that challenges our assumptions.

We spend so much time and attention on user research, user feedback and service design but when it comes to recruitment we seem to lose the same motivation. By taking the time to step back and see what our processes are saying to candidates, we can ensure that we are taking steps to increase diversity awareness. It might not be easy, but it’ll be worth it!

There was a common problem: they wanted to hire a diverse team.

They decided one way to get people in was to improve the way they hired.

They noticed that managers tended to hire people who are like them. If you have mostly white dude managers, you tend to hire mostly white dudes.

So they built a totally anonymous application system.

• Anonymous application (with a mobile number), five skills the applicant felt they had, five skills they wanted to learn.
• Slack interview
• Technical test
• Then come into the office – at this point they had to de-anonymise people.

They got some good press. They thought had solved it. But they realized they weren’t the same people as their applicants!

So they went to conferences and spoke to a lot of people. They also approached successful and unsuccessful candidates.

They learned a lot from this exercise.

People want to showcase “soft” skills alongside “technical” ones.

• They found women felt uncomfortable listing their skills. You have to explicitly tell people you want to hear about them.
• Women were put off by the anonymous platform.

Job seekers want human connection (+ they want the lowdown on what it’s really like to work with you)

• Minorities tend to speak to people before joining, “what’s it really like”.
• You can let them go around your process, but why not make it part of the process?

Lengthy tests and at home exercises are not inclusive.

• This is particularly gendered. People with caring responsibilities do not have time.
• It’s a facility that it rules out people who are “not committed” – they have lives and other things to do.

Your job listing is just as important as the application process.

• Vague job postings: if something is not explicit, people will fill in the blanks with doubt.
• Then, if you’re ashamed to fill in the blanks, you’re doing something wrong.

If we really care about diversity and inclusion, we need to listen.

• †Had good intentions, but built something for them.
• Status quo holds certain people’s values, the world is tailored to them.
• Don’t just say “thanks for the feedback”, if you really care you do something.

---

Taking Care of Alex’s Plugins

On February 27, 2019, Alex Mills (aka Viper007Bond) passed away at home surrounded by his family after a two and a half year battle with leukaemia.

Alex Mills, Montmorency Falls, Quebec. 2009.

Alex was a gifted developer and a much liked member of the WordPress community. I have always been in awe of everything he did. He contributed to core many times and is listed as a contributor to WordPress 5.1.1 that was released last month. He still has 15 open Trac tickets so I expect to see his name on future releases too. He was the primary author of many plugins as well as contributing to others.

In his last blog post he expressed the wish that his plugins would be maintained and developed.

Since all of my plugins are open-source, they are free to be forked by reputable authors in the WordPress community. It would mean a lot to have my legacy go on.

Alex Mills, February 18th 2019.

I’m glad to say that a team inside Automattic will be taking care of his plugins in the future.

We will fork each of Alex’s GitHub repositories adding them to the Automattic GitHub account. We’ll update any links in his plugin readme files so they’re pointing at the new locations.

A short paragraph about Alex will be added to the plugin readme files. You can see an example on the Regenerate Thumbnails homepage.

We’ll do our best to stay on top of support queries on the forums too. If anyone else wants to help please don’t hesitate to get in touch. I’m donncha on the WordPress.org Slack.

In times gone by authors left works of music, novels, poetry, and letters on their passing. They were static works of art frozen in time. Alex leaves behind his code that will continue to evolve and operate in a living world used by thousands (millions?) of people every day as they go about their online lives.

***

Donncha Ó Caoimh is a code wrangler with Automattic, sometimes contributor to WordPress and writer of plugins.

Launching Gutenberg Block Kit on Glitch

Today we are launching Gutenberg Block Kit on Glitch. We are hoping this experiment will help anyone with an idea for a Gutenberg block to quickly prototype and build their block.

When you click the Remix button on the Gutenberg Block Kit project, you get a full JavaScript development environment right in your browser. Nothing to install, just edit and see your changes in the live preview.

Getting Started

After you click the Remix button, you’ll be taken to your own copy of the project. You can see a live preview of the block by clicking the “Show” button at the top. As you make changes to the block, the watcher will re-build the JavaScript and update the preview window.

Take a look at src/block.js. This is the core of your block. Try making changes to the edit and save methods. You can make CSS changes in src/editor.scss (for styles that should be in the editor) and src/style.scss (for styles on the published page).

When you are happy with your block, or you want to start developing in your own WordPress environment, you can download your block as a WordPress plugin. Click the “Download Block Plugin for WordPress” link on the preview page. The ZIP file can be uploaded to a WordPress site and used immediately.

Learn more

If you want to learn more about how to develop Gutenberg blocks, take a look at the Block Editor Handbook. There you can learn more about how Gutenberg blocks work and follow along with the block tutorial.

How it works under the hood:

We are using ParcelJS to watch for changes to the source files, which transpiles, bundles, and serves your code. See server.js:7 which tells Parcel to watch src/index.html as an entry point.

Gutenberg is made up of a number of packages, exposed on the window.wp object. Normally WordPress ensures that these are available, however the constraints of Glitch prevent us from running a full WordPress development environment. Instead, we bundle the Gutenberg packages offline and upload them to Glitch’s CDN. The CDN serves the packages up as a static asset. You can see how it’s built in gutenberg.js.

Any files you put in the plugin/ directory will be added to the ZIP file for your plugin. After you download it, you can continue working on your plugin locally See the JavaScript Build Setup guide for more about what you need on your local machine to continue developing.

If you have any ideas for improving Gutenberg Block Kit, please open an issue on the GitHub repository.